It's not guaranteed that the application DBus proxy appears before
we receive the first focus event from the toplevel window.
Ensure that the first method to access the action muxer creates it if
hasn't been created yet.
GTK+ also exports window-specific actions, by putting the object path
for the exported action group in the _DBUS_OBJECT_PATH X property.
We add this action group to the app's muxer with a 'win' prefix,
since that is what the exported menu expects. Whenever the focus
window changes, we update the window-specific actions of its
application, and emit notify::action-group to cause the app
menu to be updated.
GDBusActionGroup api has changed again, adapt to that.
Also, use a GActionMuxer to add the 'app.' prefix to actions,
instead of manually stripping it out of the action names.
In the future, the muxer will also contain per-window actions
with a 'win.' prefix.
GMenuProxy has been replaced by GDBusMenuModel, and the object path
has been moved (now needs to be retrieved from the AppMenu GApplication
property).
Update the test to prefix each action with "app." as documented,
and use a GtkApplicationWindow instead of a plain GtkWindow.
GDBusActionGroup and GMenuProxy are new objects in GIO 2.32 that
help with accessing menus and actions of remote applications.
This patch makes it possible for the shell to associate an
application with a dbus name and from that a GMenu, that will
be shown as the application menu.
https://bugzilla.gnome.org/show_bug.cgi?id=621203
Not all desktop files tracked by the shell have
Exec lines. This could be because they're actually
run by another process, for instance, and the desktop
file is merely there to provide metadata. For example,
nautilus-pastebin provides a desktop file without an
Exec line.
The shell currently crashes if one of these partial
desktop files is installed and the user attempts to
search from the overview.
commit 37726a4cb6 fixed
a similar crasher.
This commit fixes the next one lower in the code.
https://bugzilla.gnome.org/show_bug.cgi?id=663815
Instead of saving the last_used_time per-app, grab the maximum time for all
windows. The logic is less hard to keep track of, and it solves some edge
case issues where windows that no longer exist update the user time, even
if none of the other windows have been used recently.
https://bugzilla.gnome.org/show_bug.cgi?id=660650
We originally OR'ed search terms and favored results which matched
multiple times to get more relevant results. When changing search
to AND search terms, the semantics of "multiple matches" were
changed to refer to a single term matching multiple criteria (name,
executable), which seemed like a good idea at the time.
However in practice this just results in applications whose
user-visible name matches the executable name on disk being
favored over applications using a more generic name, which
isn't too useful (in particular when taking usage frequency
into account).
https://bugzilla.gnome.org/show_bug.cgi?id=623372
Currently we use a very strict definition of "prefix", where the
search term has to match at the very beginning of the searched
criteria (application name, executable name). Use a more liberal
definition by including matches where the preceding character is
a space (application name) or hyphen (executable name) as well;
as many applications use a prefix, this should improve the quality
of results.
https://bugzilla.gnome.org/show_bug.cgi?id=623372
Commit 0af108211c introduced a
regression where applications that appear in multiple categories were
duplicated in the "All Apps" list, because we switched from
uniquifying on desktop file ID to the GMenuTreeEntry.
Switch back to keeping the set of apps based on ID. To flesh this
out, we keep the ShellApp instance for a given ID around forever, and
when we're loading new contents, we replace the GMenuTreeEntry inside
the app. That means callers still get new data.
We still keep around the running app list, though we could just
recompute it from the app list now.
https://bugzilla.gnome.org/show_bug.cgi?id=659351
This patch fixes the "apps vanish from alt-TAB bug".
If a "package system" rips away and possibly replaces .desktop files
at some random time, we have historically used inotify to detect this
and reread state (in a racy way, but...). In GNOME 2, this was
generally not too problematic because the menu widget was totally
separate from the list of windows - and the data they operate on was
disjoint as well.
In GNOME 3 we unify these, and this creates architectural problems
because the windows are tied to the app.
What this patch tries to do is, when rereading the application state,
if we have a running application, we keep that app around instead of
making a new instance. This ensures we preserve any state such as the
set of open windows.
This requires moving the running state into ShellAppSystem. Adjust
callers as necessary, and while we're at it drop the unused "contexts"
stuff.
This is just a somewhat quick band-aid; a REAL fix would require us
having low-level control over application installation. As long as
we're on top of random broken tar+wget wrappers, it will be gross.
A slight future improvement to this patch would add an explicit
"merge" between the old and new data. I think probably we always keep
around the ShellApp corresponding to a given ID, but replace its
GMenuTreeEntry.
https://bugzilla.gnome.org/show_bug.cgi?id=657990
During a state transition from running to not-running for
window-backend apps, it's possible we get a request for the icon.
Avoid asserting here and just return an empty image.
https://bugzilla.gnome.org/show_bug.cgi?id=656546
As danw points out,
"It's unique during the lifetime of the window, but reasonably likely to be
reused by another window after this one is destroyed. Using
meta_window_get_stable_sequence() might be better."
https://bugzilla.gnome.org/show_bug.cgi?id=648149
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
When activating an uninteresting window, the last_user_time isn't updated,
because we aren't tracking the window that the user_time gets updated on.
Hack around this by setting the last_user_time in shell_app_activate when
activating an uninteresting window.
https://bugzilla.gnome.org/show_bug.cgi?id=643302
When activating an uninteresting window, the last_user_time isn't updated,
because we aren't tracking the window that the user_time gets updated on.
Hack around this by setting the last_user_time in shell_app_activate when
activating an uninteresting window.
https://bugzilla.gnome.org/show_bug.cgi?id=643302
With workspace thumbnails, we don't switch workspaces when dragging windows
between workspaces or adding new workspaces, so we also shouldn't switch
on launch.
* Add workspace parameters to shell_doc_system_open(),
shell_app_activate, shell_app_open_new_window()
* Pass a 'params' object when activating items in the overview with
two currently defined parameters: workspace and timestamp. (timestamp
is only implemented where it is easy and doesn't require interface
changes - using the global current timestamp for the shell is almost
always right or at least good enough.)
https://bugzilla.gnome.org/show_bug.cgi?id=640996
If a starting-up app has not requested a particular workspace, then
shell_app_is_on_workspace() should return TRUE for any workspace.
Otherwise we will never get startup notification for them, since the
app menu only shows apps that are starting on the current workspace.
https://bugzilla.gnome.org/show_bug.cgi?id=635089
1. move logic to shell-app.c
2. change state to RUNNING only after startup sequence complete
3. correct handle state for applications with several .desktop files
https://bugzilla.gnome.org/show_bug.cgi?id=623688
Windows are only added to an application if they are considered
"interesting". If we keep it that way, we cannot unconditionally
call _shell_app_remove_window() - applications without interesting
windows are not considered running, so the call crashes the shell.
https://bugzilla.gnome.org/show_bug.cgi?id=622236
This is a small memory usage optimization, and cleans up the code.
In particular, this will help for later patches which perform
more substantial operations on running apps.
https://bugzilla.gnome.org/show_bug.cgi?id=621203
First, we were passing an incorrect timestamp to
meta_display_focus_the_no_focus_window - fix that.
The invocation of set_focus_app to the started app there couldn't
really work, because (if the above call had worked) we'd get the
X reply *after* the started app.
What we need to untangle here is the distinction that's now made in
ShellApp between _STATE_STARTING and _STATE_RUNNING. A nice way to
start doing this is to rebase ShellWindowTracker to only be concerned
with app states. Concretely, the current "has windows implies
running" logic now lives just inside shell-app.c.
Rename the app-running-changed signal to be app-state-changed. This
will ultimately be useful so that inside the panel, we can track
the last started app.
https://bugzilla.gnome.org/show_bug.cgi?id=620899
The API docs for ShellApp claimed it sorted by the last time the
user interacted with the app, but if one closed a window, then
we would fall back to comparing against a possibly much older
timestamp from another window. Fix this by just keeping a
user time per app.
Also clean up the comparison function to explicitly check the state
instead of deferring to the window list.
https://bugzilla.gnome.org/show_bug.cgi?id=618378
The design calls for raising all windows for a given app in
certain circumstances; implement this. The new _focus method
raises all windows for the app if it's running.
We further change the _activate method (which a lot of the shell
UI calls now) to invoke _focus for the running case, which means
that e.g. the application well will now raise all app windows.
https://bugzilla.gnome.org/show_bug.cgi?id=616051
This patch combines several high level changes which are conceptually
independent but in practice rather intertwined.
* Add a "state" property to ShellApp which reflects whether it's
stopped, starting, or started. This will allow us to later clean
up all the callers that are using ".get_windows().length > 0" as
a proxy for this property
* Replace shell_app_launch with shell_app_activate and shell_app_open_new_window
A lot of code was calling .launch, but it's signficantly clearer
if we call this ".open_new_window()", and later if we gain the ability
to call into an application's menu, we can implement this correctly rather
than trying to update all .launch callers.
* Because ShellApp now has a "starting" state, rebase panel.js on top of
this so that when we get a startup-notification sequence for an app
and transition it to starting, it becomes the focus app, and panel.js
cleanly just tracks the focus app, rather than bouncing between SN
sequences. This removes display of non-app startup sequences, which
I consider an acceptable action in light of the committed changes
to startup-notification and GTK+.
https://bugzilla.gnome.org/show_bug.cgi?id=614755
The way we were loading data into a CoglTexture, then pulling it out
and manipulating it on the CPU, then loading it back into a texture
was a bit lame.
Clean things up a bit here by loading directly into the CPU, doing
the fading, then creating a texture.
Also cache the faded data in StTextureCache.
https://bugzilla.gnome.org/show_bug.cgi?id=612759
* Add missing chain-up for dispose and finalize methods
* ShellGenericContainer needs to destroy its children in dispose()
* Fix variable naming and excess casts in st_label_dispose()
https://bugzilla.gnome.org/show_bug.cgi?id=612511
Previously shell_app_remove_window assumed that it was being
passed a window in its list; rather than having callers check
whether a window is interesting and only if so removing it
from the app, just ignore removal of windows we aren't interested
in, like how we ignore addition of windows we already have.
https://bugzilla.gnome.org/show_bug.cgi?id=598502
The two parts were mapping windows to applications, and
recording application usage statistics. The latter part
(now called ShellAppUsage) is much more naturally built on top of
the former (now called ShellWindowTracker).
ShellWindowTracker retains the startup-notification handling.
ShellWindowTracker also gains a focus-app property, which is
what most things in the shell UI are interested in (instead of
window focus).
ShellAppSystem moves to exporting ShellApp from more of its
public API, rather than ShellAppInfo. ShellAppSystem also
ensures that ShellApp instances are unique by holding
a hash on the ids.
ShellApp's private API is split off into a shell-app-private.h,
so shell-app.h can be included in shell-app-system.h.
Favorites handling is removed from ShellAppSystem, now inside
appFavorites.js.
Port all of the JavaScript for these changes.
https://bugzilla.gnome.org/show_bug.cgi?id=598646
The window lists were not being resorted when user-time changed, and
the app list was mistakenly "penalizing" apps for having *any*
minimized windows, rather than for having *only* minimized windows.
https://bugzilla.gnome.org/show_bug.cgi?id=598389
Previously, we had ShellAppInfo, which contains fundamental
information about an application, and methods on ShellAppMonitor
to retrieve "live" information like the window list.
AppIcon ended up being used as the "App" class which was painful
for various reasons; among them that we need to handle window
list changes, and some consumers weren't ready for that.
Clean things up a bit by introducing a new ShellApp class in C,
which currently wraps a ShellAppInfo.
AppIcon then is more like the display actor for a ShellApp. Notably,
the ".windows" property moves out of it. The altTab code which
won't handle dynamic changes instead is changed to maintain a
cached version.
ShellAppMonitor gains some more methods related to ShellApp now.
In the future, we might consider changing ShellApp to be a GInterface,
which could be implemented by ShellDesktopFileApp, ShellWindowApp.
Then we could axe ShellAppInfo from the "public" API and it would
return to being an internal loss mitigation layer for GMenu.
https://bugzilla.gnome.org/show_bug.cgi?id=598227
