Commit Graph

53 Commits

Author SHA1 Message Date
Jasper St. Pierre
95de48e986 ShellApp: Junk last_used_time
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
2011-10-24 16:22:32 -04:00
Florian Müllner
8a39145e3c Replace deprecated GDK functions
https://bugzilla.gnome.org/show_bug.cgi?id=662245
2011-10-24 18:31:22 +02:00
Florian Müllner
6bc34e0f32 shell-app: Plug a small memory leak 2011-10-13 22:09:39 +02:00
Florian Müllner
aee3c6f041 shell-app: Remove MATCH_MULTIPLE_{PREFIX,SUFFIX}
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
2011-10-13 17:46:45 +02:00
Florian Müllner
c427bba9f1 shell-app: Improve prefix matches
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
2011-10-13 17:46:45 +02:00
Colin Walters
3833124d66 apps: Uniquify application instances explicitly by id
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
2011-09-20 13:56:53 -04:00
Colin Walters
37726a4cb6 app: Don't abort if a .desktop file has no Exec= key
Seen in the wild in nautilus-pastebin-configurator.desktop.
2011-09-19 14:13:20 -04: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
Dan Winship
14e8cba2b1 Add some (element-type) annotations to appease g-i master 2011-08-30 12:07:43 -04:00
Colin Walters
fa0268f35a ShellApp: Avoid crashing during state transition for window-backed apps
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
2011-08-24 12:32:33 -04:00
Jasper St. Pierre
91cba1f8f4 ShellApp: Make sure that we use a valid timestamp when activating
Otherwise, we'd be comparing against the last_used_time and setting
it to 0.

https://bugzilla.gnome.org/show_bug.cgi?id=656374
2011-08-12 03:21:42 -04:00
Colin Walters
2efcbaf206 ShellApp: Fix comment about window-backed apps
https://bugzilla.gnome.org/show_bug.cgi?id=648149
2011-08-11 10:11:36 -04:00
Colin Walters
b9edb1dc01 ShellApp: Ensure we set the size of returned texture for window backed apps
Unify the two code paths too.

https://bugzilla.gnome.org/show_bug.cgi?id=648149
2011-08-11 05:56:00 -04:00
Colin Walters
b0cc778c49 ShellApp: Use stable sequence for id, not pointer address
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
2011-08-11 05:47:38 -04:00
Colin Walters
ff840db708 ShellApp: Use global time, not clutter time
This is correct in more circumstances.

https://bugzilla.gnome.org/show_bug.cgi?id=648149
2011-08-11 05:45:48 -04:00
Colin Walters
11f30e2e09 ShellApp: Use integer for size, not float
We were basically casting it everywhere except for ClutterActor -
let's be consistent with StTextureCache and use integers.

https://bugzilla.gnome.org/show_bug.cgi?id=648149
2011-08-11 05:44:19 -04:00
Colin Walters
4886275df4 ShellApp: Change activation API
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
2011-08-11 05:35:23 -04:00
Colin Walters
c5de239e25 shell_util_normalize_and_casefold: New utility function
Merge the duplicated copies into shell-util.
2011-08-10 13:00:06 -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
Jasper St. Pierre
74a39ae57c shell-app: Fix a case where last_user_time isn't updated.
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
2011-05-04 12:10:52 -04:00
Jasper St. Pierre
68710c4647 Revert "shell-app: Fix a case where last_user_time isn't updated."
This reverts commit 7d7cbde1f3.

This was acidentally pushed.
2011-04-27 12:53:33 -04:00
Jasper St. Pierre
7d7cbde1f3 shell-app: Fix a case where last_user_time isn't updated.
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
2011-04-27 11:12:27 -04:00
Giovanni Campagna
54e3a54489 Transition the ShellApp state when ready.
shell_app_state_transition emits a signal, so invoke it only when
ready, or signal handlers will see an object which is in an invalid
state.

https://bugzilla.gnome.org/show_bug.cgi?id=632501
2011-03-21 22:42:25 -04:00
William Jon McCann
dd99ed73a9 Fallback to using a generic when requested image isn't found
Use a type specific generic image when the requested icon
can't be loaded instead of using an empty texture.

https://bugzilla.gnome.org/show_bug.cgi?id=644668
2011-03-17 14:02:04 -04:00
Colin Walters
4bf1df0894 ShellApp: Report error when we fail to run an app
https://bugzilla.gnome.org/show_bug.cgi?id=644402
2011-03-16 15:07:22 -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
Owen W. Taylor
0d32017ffc Don't switch to a workspace when dragging it to launch on that workspace
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
2011-02-08 19:43:21 -05:00
Dan Winship
99a865fb0f ShellApp: is_on_workspace() should be TRUE for workspaceless apps
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
2011-01-13 12:16:38 -05:00
Giovanni Campagna
ac1b814851 Revert "Transition the ShellApp state when ready."
This reverts commit c171ea12df.
2010-11-12 18:41:54 +01:00
Giovanni Campagna
c171ea12df Transition the ShellApp state when ready.
shell_app_state_transition emits a signal, so invoke it only when
ready, or signal handlers will see an object which is in an invalid
state.

https://bugzilla.gnome.org/show_bug.cgi?id=632501
2010-11-12 17:43:05 +01:00
Maxim Ermilov
4456954d30 [panel] Only show starting applications for current workspace
Add the workspace we started on to ShellApp.  Use it inside panel.js
to filter the list.
https://bugzilla.gnome.org/show_bug.cgi?id=623688
2010-10-07 01:31:22 +04: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
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
1f550dbc72 [ShellApp] Move assertion below precondition check
Need to track down why we're calling _remove_window with a window not
in the app, but this is the quick fix for a crasher.
2010-06-19 11:32:00 -04:00
Colin Walters
da4e24555b Split off running state handling into separate structure
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
2010-06-18 13:03:41 -04: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
b736f52037 Rework compare to take into account closed windows
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
2010-05-17 13:37:13 -04:00
Colin Walters
78e3126f97 [ShellApp] Add quit method
Closes the app, will be used for the panel app menu.  Note
this is just a very primitive implementation.

https://bugzilla.gnome.org/show_bug.cgi?id=613804
2010-05-11 14:10:35 -04:00
Colin Walters
0d1ac8cb5b [ShellApp] Add method to focus an app (all windows), make _activate do this
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
2010-05-06 11:19:44 -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
32fd323153 [ShellApp] When fading, don't read alpha channel if none available 2010-03-13 12:56:15 -05:00
Colin Walters
3aea09b614 Fix app icon fading
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
2010-03-13 12:50:38 -05:00
Owen W. Taylor
163b2d0403 Fixes for dispose and finalize
* 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
2010-03-11 15:08:48 -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
d9ff1f2ec1 [ShellApp] Ignore removal of windows we're not interested in
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
2009-10-23 13:19:29 -04:00
Colin Walters
369e0c2c6f [ShellApp] Signal windows-changed when removing a window
https://bugzilla.gnome.org/show_bug.cgi?id=599412
2009-10-23 10:59:04 -04:00
Colin Walters
81d579aca0 Disconnect from window signal handlers when removing a window
We need to remove all of our signal handlers attached to a window
when being disposed.

https://bugzilla.gnome.org/show_bug.cgi?id=598502
2009-10-21 11:44:07 -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
Dan Winship
79a614240b [ShellApp] fix app/window sort order
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
2009-10-16 11:15:21 -04:00