Commit Graph

7 Commits

Author SHA1 Message Date
Stefano Facchini
3c6737f738 autoWorkspaces: fix creation of new workspaces with application launchers
In the workspace-collecting code we add a check to avoid collecting a
workspace if any startup sequence is running there. Since the sequence
can take some time to load, an helper function is also added which keeps
the (empty) workspace around for a very short time, while waiting for the
sequence to start.

https://bugzilla.gnome.org/show_bug.cgi?id=664202
2012-03-16 16:41:30 +01:00
Colin Walters
0af108211c apps: Ensure running apps override new .desktop file data
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
2011-09-05 17:29:41 -04:00
Colin Walters
d25610903a ShellWindowTracker: Rename self variable for consistency
Historically it was monitor, now tracker.

(I want to move more things to self, but that's a different bug).

https://bugzilla.gnome.org/show_bug.cgi?id=648149
2011-08-11 10:11:36 -04:00
Dan Winship
e187961d72 src: update for mutter include reorganization
https://bugzilla.gnome.org/show_bug.cgi?id=641724
2011-03-07 18:33:33 -05:00
Colin Walters
c92ce5983d Consume startup-notification APPLICATION_ID
This patch ensures we're showing the correct data when doing
startup-notification.

https://bugzilla.gnome.org/show_bug.cgi?id=612833
2010-03-30 17:36:05 -04:00
Colin Walters
ed129b40a3 [ShellWindowTracker] Add shell_window_tracker_app_from_pid
In some situations we might need to look up an application from
a process identifier, such as the notification system where we
will determine application from the message sender.
2010-02-03 19:07:22 -05:00
Colin Walters
e941e8088b Split ShellAppMonitor into ShellWindowTracker, ShellAppUsage
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
2009-10-20 12:55:07 -04:00