Commit Graph

47 Commits

Author SHA1 Message Date
Giovanni Campagna
2a95273b79 ShellWindowTracker: complete WM_CLASS fix
Chromium (but not google-chrome) has a StartupWMClass in the desktop
file, so we must match the instance part first to have chrome
web apps working.
Also, we must take care of apps without a wm_class or instance at
all.

https://bugzilla.gnome.org/show_bug.cgi?id=673657
2013-08-08 14:15:34 +02:00
Giovanni Campagna
3586e53fd9 ShellWindowTracker: fix reference leak
get_app_from_window_wmclass() now returns a reference to the ShellApp,
no need for another one.
2013-08-07 12:54:14 +02:00
Giovanni Campagna
db75734774 Use StartupWMClass to associate window and applications
Some applications (such as most Java apps, as well as Chrome Web apps) ship
with desktop files that have the wrong name, but whose StartupWMClass
field contains the right value. Therefore first check that key, against
both the class and instance part of WM_CLASS, and only use the filename
if nothing else works.

https://bugzilla.gnome.org/show_bug.cgi?id=673657
2013-08-07 12:17:42 +02:00
Giovanni Campagna
a1bb0ec738 WindowTracker: fix ref counting bug in get_app_for_window()
get_app_for_window() is (transfer full), but shell_app_system_lookup_wmclass()
is (transfer none), so we must reference the result, or crash
occur.

https://bugzilla.gnome.org/show_bug.cgi?id=678992
2012-06-27 19:27:30 +02:00
Florian Müllner
c303c6b5c1 shell-app: Update app menu if necessary
Currently we assume that GTK_UNIQUE_BUS_NAME is shared between all
windows of an application. This assumption does not hold true for
applications that specify G_APPLICATION_NON_UNIQUE, so make sure
to update the menu as necessary.

https://bugzilla.gnome.org/show_bug.cgi?id=676238
2012-06-19 17:57:34 +02:00
Jasper St. Pierre
2e8881b77c notificationDaemon: Match app based on WM_CLASS
Most tray applets won't have an associated window in the same PID. We
need to fall back to the WM_CLASS in this case.

https://bugzilla.gnome.org/show_bug.cgi?id=673761
2012-04-27 15:49:18 -04:00
Giovanni Campagna
55a4517cd1 Fix documentation warnings
gobject-introspection now emits many more warnings for malformed
comments, and they fail the build.

https://bugzilla.gnome.org/show_bug.cgi?id=673656
2012-04-09 19:57:51 +02:00
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
Jasper St. Pierre
b40b19997a shell: Use generic marshaller
https://bugzilla.gnome.org/show_bug.cgi?id=662152
2012-01-25 19:03:48 -05:00
Matthias Clasen
6c4e9d23f2 Add per-window actions
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.
2011-12-20 17:36:59 -05:00
Jasper St. Pierre
628e59894b Doc fixes
https://bugzilla.gnome.org/show_bug.cgi?id=663277
2011-11-07 15:24:59 -05: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
Colin Walters
10dcc100e9 Kill off ShellAppInfo, move into ShellApp
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
2011-08-10 12:59:32 -04:00
Dan Winship
aed50e2a39 shell-global: add a "display" property
and update callers to fetch that rather than doing
"global.screen.get_display()"

https://bugzilla.gnome.org/show_bug.cgi?id=654639
2011-08-03 09:09:55 -04:00
Adel Gadllah
1309b64c33 shell-window-tracker: Fix signal handler leak
Disconnect the on_wm_class_changed handler when removing a window
in disassociate_window().

https://bugzilla.gnome.org/show_bug.cgi?id=652388
2011-06-13 17:04:22 +02:00
Colin Walters
4cab0c95d3 ShellWindowTracker: Remove title tracking workarounds for OO.org and Firefox
LibreOffice does WM_CLASS correctly as of recently, and Firefox has for
some time.  Strip out the title pattern workarounds.

https://bugzilla.gnome.org/show_bug.cgi?id=651015
2011-05-25 12:11:09 -04:00
Colin Walters
d51e79d483 Track changes to WM_CLASS
LibreOffice changes applications dynamically; we should support this.

https://bugzilla.gnome.org/show_bug.cgi?id=649315
2011-05-25 12:09:52 -04:00
Ionut Biru
eb54662098 Require startup-notification >= 0.11
sn_startup_sequence_get_application_id appeared first in this release

Signed-off-by: Ionut Biru <ibiru@archlinux.org>
2011-05-24 17:07:32 -04:00
Colin Walters
f4852d7264 ShellWindowTracker: Ensure WM_CLASS remains canonical if it matches
I unintentionally made .desktop->pid association "win" over
WM_CLASS.  Fixing this makes the case of ancillary .desktop file
entry points (e.g. gnome-control-center's various shortcut .desktop
files) correctly show System Settings, and not whatever the shortcut
is.

In the future I'd like to have a way to say "this .desktop file
is a shortcut, ignore me" or something.

https://bugzilla.gnome.org/show_bug.cgi?id=646689
2011-04-20 15:04:57 -04:00
Colin Walters
db6caac9cc ShellWindowTracker: Follow transients for focus app
As a side effect of (see bug 642221), we no longer put docks or
transient windows into the hash table mapping windows to apps.  The
"focused application" code relied on at least transients being in
there.

Fix this by calling the public API to map a window to an app, which
will at least follow transients.  Whether we also want further
matching here (e.g. with window grouping) is another issue, but that
can happen as a different bug.

https://bugzilla.gnome.org/show_bug.cgi?id=647082
2011-04-12 17:57:20 -04:00
Dan Winship
43020b20b7 ShellWindowTracker: don't create ShellApps for non-interesting windows
If a process does not have any "interesting" windows, then it can't be
considered a running app. (Previously we were calling
get_app_for_window() before ruling out non-interesting windows, which
ended up calling _shell_app_new_for_window(), which would add the
window to the ShellApp directly, bypassing the is_interesting check.)

https://bugzilla.gnome.org/show_bug.cgi?id=642221
2011-03-15 15:37:08 -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
Giovanni Campagna
5683bb9b8e ShellWindowTracker: fix a reference counting bug
When retrieving a ShellApp from the GHashTable of child processes,
we need to take an extra reference, that the GHashTable of windows
to apps will own.
Also add some documentation to avoid repeating this bug in the future.

https://bugzilla.gnome.org/show_bug.cgi?id=642699
2011-02-22 16:34:08 +01:00
Colin Walters
95e6eae23b Fixes for previous ShellAppSystem patch a138f59c
Wasn't amended by mistake.
2011-02-08 14:38:24 -05:00
Colin Walters
a138f59cb0 Use new GLib application API for launching
Launch child processes more directly; we retrieve the PID, and
use it to keep track of the .desktop file we launched.

Now, when we get a window, since the X window has a PID, we
have a pretty strong association.

.desktop file <-> PID <-> window

And can thus map window back to .desktop file.

https://bugzilla.gnome.org/show_bug.cgi?id=637745
2011-02-08 10:43:39 -05:00
Dan Winship
13edecde6c Remove set-but-unused variables, to appease gcc 4.6
https://bugzilla.gnome.org/show_bug.cgi?id=640447
2011-01-24 13:35:03 -05:00
Giovanni Campagna
21ac225981 StIcon: add support for GIcon
Add a "gicon" property so that a GIcon can be used instead of an
icon name, while still getting icon recoloring from the theme.
Also include a compatibility wrapper in libshell until GJS has
support for interface static methods.

https://bugzilla.gnome.org/show_bug.cgi?id=622451
2010-11-16 22:11:27 +01:00
Owen W. Taylor
aed6375a2d Move StIconType to st-types.h from st-texture-cache.h
StIconType will be used by a new StIcon class, so move it to the
header file of common enumerations. Including st-types.h which had
the St single-include check revealed that st-texture-cache.h didn't
have that check and several places were including that directly.
Fix that up.

https://bugzilla.gnome.org/show_bug.cgi?id=633865
2010-11-12 17:36:25 -05:00
Maxim Ermilov
6925a82204 [ShellApp] refactor handling startup sequence
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
2010-10-07 01:30:30 +04:00
Colin Walters
dddd97f6df introspection: Build with --warn-all --warn-error
* Use --warn-all, --warn-error
* Fix various broken gtk-doc
* Drop unused shell_get_event_related
* For header defines, we currently require them to end in _H to be skipped
* Drop the no-longer-necessary fix-meta-rectangle.py hack
* Move to the convention of using -private.h for headers that are,
  well, private.
* Add shell-wm-private.h
2010-09-07 13:07:52 -04:00
Florian Müllner
4b1fea2fa4 [windowTracker] Only remove "interesting" windows
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
2010-06-21 15:35:36 +02:00
Colin Walters
bf6d0dc808 Associate process identifiers with applications
Cache the set of pids for an application, in preparation for
landing an XSMP patch which requires this information.

https://bugzilla.gnome.org/show_bug.cgi?id=619542
2010-06-09 14:44:15 -04:00
Colin Walters
e4a6bf994f Fix ShellAppSystem's use of no_focus_window, clean up state handling
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
2010-06-09 14:44:15 -04:00
Colin Walters
8aeadcdf9a Don't try to track remote windows
Previously we were trying to match up remote windows with local
.desktop files, which is definitely wrong.  This patch simply
falls back to the app-from-window case for this; better handling
would need design.

https://bugzilla.gnome.org/show_bug.cgi?id=620855
2010-06-07 16:39:39 -04:00
Colin Walters
26c8227df5 [ShellWindowTracker] Add a signal to notify when tracked windows change 2010-04-20 14:47:45 -04:00
Colin Walters
6aaf4b87d5 Major ShellApp API cleanup, startup notification, window focus handling
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
2010-04-12 16:32:21 -04: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
1a25cd98ea Move focus change handling out of a meta_later
Ok, there admittedly wasn't a strong rationale for having it in a
later, and by performing this immediately we reduce race conditions
for our focus_app versus startup_notification handling.

https://bugzilla.gnome.org/show_bug.cgi?id=612833
2010-03-30 17:36:03 -04:00
Colin Walters
22948b3d39 Merge St.TextureCache and Shell.TextureCache
Brute force merge these two by essentially replacing St.TextureCache
with a (renamed) Shell.TextureCache.

One function was added for convenience, namely "st_texture_cache_load_file_simple".
St.TextureCache had a function to load a texture from a filename, and it
returned NULL on error but only half the callers actually checked this.  This
function is better.

https://bugzilla.gnome.org/show_bug.cgi?id=607500
2010-03-05 16:19:40 -05:00
Adel Gadllah
40a8e9c1a6 Fix tracking of single-process multi app cases
When starting oocalc or ooimpress from oowriter's menu get_app_for_window,
fails to recognize the newly started up as such, which result into the appMenu
still showing "Openoffice.org Writer" as app name.

Fix this by trying to window itself first before using the group for finding the app.

https://bugzilla.gnome.org/show_bug.cgi?id=611288
2010-03-01 19:29:39 +01:00
Maxim Ermilov
c793d7d0a4 get_app_for_window_direct search ShellApp by window, before create.
https://bugzilla.gnome.org/show_bug.cgi?id=610324
2010-02-21 03:19:24 +03: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
Dan Winship
dd8f05c81d include "config.h" in all .c files
Also, fix shell-global.c to actually compile with config.h included.

Was supposed to fix bug 602802, but doesn't...
2009-11-24 09:15:35 -05:00
Colin Walters
10991d363d [ShellWindowTracker] Create fallback apps again
Creating window-based apps got lost in the code refactoring.
2009-10-23 12:26:05 -04:00
Colin Walters
7548f2d71e [ShellWindowTracker] Don't skip "uninteresting" windows for focus
For the purposes of determining which application is focused, don't
skip "uninteresting" windows.  The old get_focused_window code
was used for usage tracking, but here we want reliable application
association.

Also convert a .text= to .set_text that was missed with the last
patch.

https://bugzilla.gnome.org/show_bug.cgi?id=599206
2009-10-21 11:30:13 -04: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