Commit Graph

24 Commits

Author SHA1 Message Date
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
Colin Walters
d705c1bb52 [ShellApp] Fix handler signature for workspace switch
This was causing crashes or undefined behavior.

https://bugzilla.gnome.org/show_bug.cgi?id=598227
2009-10-15 14:05:19 -04:00
Colin Walters
d9df7c1b1e [AppWell] Fix D&D for ShellApp
The drag and drop case needed to be updated to use ShellApp
correctly.  Export _is_transient for better compatibility.

https://bugzilla.gnome.org/show_bug.cgi?id=598227
2009-10-15 13:24:19 -04:00
Colin Walters
38c06ca837 Create ShellApp, rebase things on it
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
2009-10-14 14:37:34 -04:00