This is causing more confusion than anything else these days; the DBus
API is properly documented now and that's what people are expected to
use, the rest are implementation details we're not interested in
exposing.
https://bugzilla.gnome.org/show_bug.cgi?id=681797
These are for all search results except apps (and Wanda).
We also simplify a bit the packing of search results, which removes some
ugly code in navigateFocus() where we needed to call
st_widget_navigate_focus() twice, since the grid icon was composed by
two nested boxes, both focusable.
https://bugzilla.gnome.org/show_bug.cgi?id=681797
Display a '+' icon on the provider icon if there are more results that are
hidden. If the provider icon is clicked, ask the provider to launch itself and
perform a search with the current terms.
https://bugzilla.gnome.org/show_bug.cgi?id=681797
this._gnomecc is currently unused; we actually need a GAppInfo for this
provider if we want to display an icon next to it (see future commits),
so just turn it into one.
We might move this to an external provider altogether in the future.
https://bugzilla.gnome.org/show_bug.cgi?id=689735
The only case when we're interested in using those parameters nowadays
is for DnD, which is handled in a separate method already.
Since we're not going to support DnD for non-app search results anyway,
drop the params from all the activateResults() calls; this will be
useful later since we're going to add another parameter to it.
https://bugzilla.gnome.org/show_bug.cgi?id=689735
Desktop files can specify if the application should only be shown for
specified desktops with OnlyShowIn and NotShowIn directives options.
If a menu category only contained entries for a different desktop, we
were still creating the category.
We now only add a category button if there is at least one application
to be displayed in this category.
https://bugzilla.gnome.org/show_bug.cgi?id=687970
We simply hide the label when the popup is opened instead of relying
on the popup state when the hover state change.
To do this we replace the flag isMenuUp by a 'menu-state-changed' signal
on the AppWellIcon. This simplifies the dash label visibility handling
code that need additional changes for the bug.
https://bugzilla.gnome.org/show_bug.cgi?id=657315
We explicitly include NoDisplay applications in the ShellAppSystem because
we want app tracking for them, but we explicitly filter NoDisplay applications
out when showing them to the user because we don't want to show them to the
user. We also based our "All" apps view on a flattened list of apps. While
we did check for NoDisplay on the app item itself, we didn't check against
its parents. Refactor the app display view to not use a separate flat list
of applications, but instead a concatenation of all the applications in all
the loaded categories.
https://bugzilla.gnome.org/show_bug.cgi?id=658176
As shown in the previous commits, synchronous search is easily implemented
by the asynchronous search API. The only reason we still have a
synchronous search API is of historical reasons. Well, we're not a museum,
and git log can keep our fossils safe if need be....
https://bugzilla.gnome.org/show_bug.cgi?id=675328
Instead of using an St.Tooltip to show the app's name under the icon,
manually position a new St.Label ourselves. Make sure to keep the label
hidden when right-clicking so it doesn't get in the way of the popup menu.
Only one tooltip/label will be displayed at a time.
https://bugzilla.gnome.org/show_bug.cgi?id=666166
The last patch in the sequence. Every place that was previously
setting prototype has been ported to Lang.Class, to make code more
concise and allow for better toString().
https://bugzilla.gnome.org/show_bug.cgi?id=664436
All classes that have at least one other derived class (and thus
benefit from the framework) have been now ported. These includes
NMDevice, SearchProvider, AltTab.SwitcherList, and some other
stuff around.
https://bugzilla.gnome.org/show_bug.cgi?id=664436
The Lang module in gjs has recently gained a small yet powerful
Class framework, that should help improve the readability of code
when using complex inheritance.
This commit starts porting shell code, by rewriting all classes in
popupMenu.js (and all derived classes) to Lang.Class.
https://bugzilla.gnome.org/show_bug.cgi?id=664436
js2-mode is no longer developed and we recommend js-mode these days,
so switch the modelines to specify that, and make them consistent
across all files.
https://bugzilla.gnome.org/show_bug.cgi?id=660358
The dash object is currently exposed as a public object.
It's only used outside of the overview for the dash object's
iconSize property though.
This commit makes the dash object private and proxies the dash
iconSize property to the overview.
https://bugzilla.gnome.org/show_bug.cgi?id=657082
Since almost all of the callers of shell_app_activate were using the
default workspace (by passing -1), remove that parameter.
Add a new shell_app_activate_full() API which takes a workspace as
well as a timestamp; previously we might have been ignoring event
timestamps from elsewhere.
https://bugzilla.gnome.org/show_bug.cgi?id=648149
This dramatically thins down and sanitizes the application code.
The ShellAppSystem changes in a number of ways:
* Preferences are special cased more explicitly; they aren't apps,
they're shortcuts for an app), and we don't have many of them, so
don't need e.g. the optimizations in ShellAppSystem for searching.
* get_app() changes to lookup_app() and returns null if an app isn't
found. The semantics where it tried to find the .desktop file
if we didn't know about it were just broken; I am pretty sure no
caller needs this, and if they do we'll fix them.
* ShellAppSystem maintains two indexes on apps (by desktop file id
and by GMenuTreeEntry), but is no longer in the business of
dealing with GMenuTree as far as hierarchy and categories go. That
is moved up into js/ui/appDisplay.js. Actually, it flattens both
apps and settings.
Also, ShellWindowTracker is now the sole reference-owner for
window-backed apps. We still do the weird "window:0x1234beef" id
for these apps, but a reference is not stored in ShellAppSystem.
The js/ui/appDisplay.js code is rewritten, and sucks a lot less.
Variable names are clearer:
_apps -> _appIcons
_filterApp -> _visibleApps
_filters -> _categoryBox
Similarly for function names. We no longer call (for every app) a
recursive lookup in GMenuTree to see if it's in a particular section
on every category switch; it's all cached.
NOTE - this intentionally reverts the incremental loading code from
commit 7813c5b93f. It's fast enough
here without that.
https://bugzilla.gnome.org/show_bug.cgi?id=648149
The specs call for a 2 pixel gap between the panel and its menus,
though we need to specify this as 4 pixels, since it's relative to the
bottom of the icon/title, not the bottom of the panel (up until now,
the point of the menu arrow was actually overlapping the menu's
highlight underline).
Also, move the gap specification into the CSS, since it makes more
sense there.
https://bugzilla.gnome.org/show_bug.cgi?id=655627
Theme authors now have the power (and responsibility) of creating fade
effects with the new CSS length property '-st-fade-offset'. A value of
0 disables the effect.
This new CSS approach replaces the current programmatic toggle of
the 'vfade' property. A new CSS style class name 'vfade' is used as
a replacement for the old property.
https://bugzilla.gnome.org/show_bug.cgi?id=651813
A "cosmetic" code arrangement I requested in code review resulted
in one too few items being removed from the queue for each incremental
chunk of icons added. Fix.
https://bugzilla.gnome.org/show_bug.cgi?id=648739
ViewByCategories._removeAll clears the sections, but the filter passed
to view still expects them to exists. Therefore, refresh the view
after the section has been rebuilt and the All filter reapplied.
https://bugzilla.gnome.org/show_bug.cgi?id=645801
While we have menu for an app icon open, we want to show the prelight
for the item instead of removing the prelight when the user mouses
away from the item and into the menu, and if there's a tooltip
(like for the dash), we want to show the tooltip immediately when
the menu is popped up.
https://bugzilla.gnome.org/show_bug.cgi?id=642871
When right-clicking on an AppWellIcon, the icon will become focused,
which (presumably via style-changed) invalidates its current
allocation, causing "icon.y" to return 0 until it has been
reallocated, messing up our idea of where in the AppDisplay the icon
is. Work around this by calling get_allocation_box() instead.
https://bugzilla.gnome.org/show_bug.cgi?id=645162
