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-11 20:40:00 +00:00
|
|
|
/* -*- mode: C; c-file-style: "gnu"; indent-tabs-mode: nil; -*- */
|
|
|
|
|
2009-11-24 14:07:40 +00:00
|
|
|
#include "config.h"
|
|
|
|
|
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-03 18:07:44 +00:00
|
|
|
#include "st.h"
|
2009-10-15 23:28:29 +00:00
|
|
|
#include "shell-app-private.h"
|
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-11 20:40:00 +00:00
|
|
|
#include "shell-global.h"
|
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-03 18:07:44 +00:00
|
|
|
#include "shell-enum-types.h"
|
2010-04-17 20:57:58 +00:00
|
|
|
#include "display.h"
|
2010-03-24 13:42:59 +00:00
|
|
|
#include "st.h"
|
2010-06-07 20:31:30 +00:00
|
|
|
#include "shell-window-tracker-private.h"
|
2010-03-12 20:57:01 +00:00
|
|
|
|
|
|
|
#include <string.h>
|
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-11 20:40:00 +00:00
|
|
|
|
2010-06-09 18:50:01 +00:00
|
|
|
/* This is mainly a memory usage optimization - the user is going to
|
|
|
|
* be running far fewer of the applications at one time than they have
|
|
|
|
* installed. But it also just helps keep the code more logically
|
|
|
|
* separated.
|
|
|
|
*/
|
|
|
|
typedef struct {
|
|
|
|
guint refcount;
|
|
|
|
|
|
|
|
/* Last time the user interacted with any of this application's windows */
|
|
|
|
guint32 last_user_time;
|
|
|
|
|
|
|
|
/* Signal connection to dirty window sort list on workspace changes */
|
|
|
|
guint workspace_switch_id;
|
|
|
|
|
|
|
|
GSList *windows;
|
|
|
|
|
|
|
|
/* Whether or not we need to resort the windows; this is done on demand */
|
|
|
|
gboolean window_sort_stale : 1;
|
|
|
|
} ShellAppRunningState;
|
|
|
|
|
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-11 20:40:00 +00:00
|
|
|
/**
|
|
|
|
* SECTION:shell-app
|
|
|
|
* @short_description: Object representing an application
|
|
|
|
*
|
|
|
|
* This object wraps a #ShellAppInfo, providing methods and signals
|
|
|
|
* primarily useful for running applications.
|
|
|
|
*/
|
|
|
|
struct _ShellApp
|
|
|
|
{
|
|
|
|
GObject parent;
|
|
|
|
|
2010-06-09 18:50:01 +00:00
|
|
|
ShellAppState state;
|
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-11 20:40:00 +00:00
|
|
|
|
2010-06-09 18:50:01 +00:00
|
|
|
ShellAppInfo *info;
|
2010-03-12 20:57:01 +00:00
|
|
|
|
2010-06-09 18:50:01 +00:00
|
|
|
ShellAppRunningState *running_state;
|
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-11 20:40:00 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
G_DEFINE_TYPE (ShellApp, shell_app, G_TYPE_OBJECT);
|
|
|
|
|
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-03 18:07:44 +00:00
|
|
|
enum {
|
|
|
|
PROP_0,
|
|
|
|
PROP_STATE
|
|
|
|
};
|
|
|
|
|
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-11 20:40:00 +00:00
|
|
|
enum {
|
|
|
|
WINDOWS_CHANGED,
|
|
|
|
LAST_SIGNAL
|
|
|
|
};
|
|
|
|
|
|
|
|
static guint shell_app_signals[LAST_SIGNAL] = { 0 };
|
|
|
|
|
2010-06-09 18:50:01 +00:00
|
|
|
static void create_running_state (ShellApp *app);
|
|
|
|
static void unref_running_state (ShellAppRunningState *state);
|
|
|
|
|
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-03 18:07:44 +00:00
|
|
|
static void
|
|
|
|
shell_app_get_property (GObject *gobject,
|
|
|
|
guint prop_id,
|
|
|
|
GValue *value,
|
|
|
|
GParamSpec *pspec)
|
|
|
|
{
|
|
|
|
ShellApp *app = SHELL_APP (gobject);
|
|
|
|
|
|
|
|
switch (prop_id)
|
|
|
|
{
|
|
|
|
case PROP_STATE:
|
|
|
|
g_value_set_enum (value, app->state);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
G_OBJECT_WARN_INVALID_PROPERTY_ID (gobject, prop_id, pspec);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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-11 20:40:00 +00:00
|
|
|
const char *
|
|
|
|
shell_app_get_id (ShellApp *app)
|
|
|
|
{
|
|
|
|
return shell_app_info_get_id (app->info);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* shell_app_create_icon_texture:
|
|
|
|
*
|
|
|
|
* Look up the icon for this application, and create a #ClutterTexture
|
|
|
|
* for it at the given size.
|
|
|
|
*
|
|
|
|
* Return value: (transfer none): A floating #ClutterActor
|
|
|
|
*/
|
|
|
|
ClutterActor *
|
|
|
|
shell_app_create_icon_texture (ShellApp *app,
|
|
|
|
float size)
|
|
|
|
{
|
|
|
|
return shell_app_info_create_icon_texture (app->info, size);
|
|
|
|
}
|
2010-03-12 20:57:01 +00:00
|
|
|
typedef struct {
|
|
|
|
ShellApp *app;
|
|
|
|
int size;
|
|
|
|
} CreateFadedIconData;
|
|
|
|
|
|
|
|
static CoglHandle
|
|
|
|
shell_app_create_faded_icon_cpu (StTextureCache *cache,
|
|
|
|
const char *key,
|
|
|
|
void *datap,
|
|
|
|
GError **error)
|
|
|
|
{
|
|
|
|
CreateFadedIconData *data = datap;
|
|
|
|
ShellApp *app;
|
|
|
|
GdkPixbuf *pixbuf;
|
|
|
|
int size;
|
|
|
|
CoglHandle texture;
|
|
|
|
gint width, height, rowstride;
|
|
|
|
guint8 n_channels;
|
2010-03-13 17:56:15 +00:00
|
|
|
gboolean have_alpha;
|
2010-03-12 20:57:01 +00:00
|
|
|
gint fade_start;
|
|
|
|
gint fade_range;
|
|
|
|
guint i, j;
|
|
|
|
guint pixbuf_byte_size;
|
|
|
|
guint8 *orig_pixels;
|
|
|
|
guint8 *pixels;
|
|
|
|
GIcon *icon;
|
|
|
|
GtkIconInfo *info;
|
|
|
|
|
|
|
|
app = data->app;
|
|
|
|
size = data->size;
|
|
|
|
|
|
|
|
icon = shell_app_info_get_icon (app->info);
|
|
|
|
if (icon == NULL)
|
|
|
|
return COGL_INVALID_HANDLE;
|
|
|
|
|
|
|
|
info = gtk_icon_theme_lookup_by_gicon (gtk_icon_theme_get_default (),
|
|
|
|
icon, (int) (size + 0.5),
|
|
|
|
GTK_ICON_LOOKUP_FORCE_SIZE);
|
|
|
|
g_object_unref (icon);
|
|
|
|
if (info == NULL)
|
|
|
|
return COGL_INVALID_HANDLE;
|
|
|
|
|
|
|
|
pixbuf = gtk_icon_info_load_icon (info, NULL);
|
|
|
|
gtk_icon_info_free (info);
|
|
|
|
|
|
|
|
if (pixbuf == NULL)
|
|
|
|
return COGL_INVALID_HANDLE;
|
|
|
|
|
|
|
|
width = gdk_pixbuf_get_width (pixbuf);
|
|
|
|
height = gdk_pixbuf_get_height (pixbuf);
|
|
|
|
rowstride = gdk_pixbuf_get_rowstride (pixbuf);
|
|
|
|
n_channels = gdk_pixbuf_get_n_channels (pixbuf);
|
|
|
|
orig_pixels = gdk_pixbuf_get_pixels (pixbuf);
|
2010-03-13 17:56:15 +00:00
|
|
|
have_alpha = gdk_pixbuf_get_has_alpha (pixbuf);
|
2010-03-12 20:57:01 +00:00
|
|
|
|
|
|
|
pixbuf_byte_size = (height - 1) * rowstride +
|
|
|
|
+ width * ((n_channels * gdk_pixbuf_get_bits_per_sample (pixbuf) + 7) / 8);
|
|
|
|
|
|
|
|
pixels = g_malloc0 (rowstride * height);
|
|
|
|
memcpy (pixels, orig_pixels, pixbuf_byte_size);
|
|
|
|
|
|
|
|
fade_start = width / 2;
|
|
|
|
fade_range = width - fade_start;
|
|
|
|
for (i = fade_start; i < width; i++)
|
|
|
|
{
|
|
|
|
for (j = 0; j < height; j++)
|
|
|
|
{
|
|
|
|
guchar *pixel = &pixels[j * rowstride + i * n_channels];
|
|
|
|
float fade = 1.0 - ((float) i - fade_start) / fade_range;
|
|
|
|
pixel[0] = 0.5 + pixel[0] * fade;
|
|
|
|
pixel[1] = 0.5 + pixel[1] * fade;
|
|
|
|
pixel[2] = 0.5 + pixel[2] * fade;
|
2010-03-13 17:56:15 +00:00
|
|
|
if (have_alpha)
|
|
|
|
pixel[3] = 0.5 + pixel[3] * fade;
|
2010-03-12 20:57:01 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
texture = cogl_texture_new_from_data (width,
|
|
|
|
height,
|
|
|
|
COGL_TEXTURE_NONE,
|
2010-03-13 17:56:15 +00:00
|
|
|
have_alpha ? COGL_PIXEL_FORMAT_RGBA_8888 : COGL_PIXEL_FORMAT_RGB_888,
|
2010-03-12 20:57:01 +00:00
|
|
|
COGL_PIXEL_FORMAT_ANY,
|
|
|
|
rowstride,
|
|
|
|
pixels);
|
|
|
|
g_free (pixels);
|
|
|
|
g_object_unref (pixbuf);
|
|
|
|
|
|
|
|
return texture;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* shell_app_get_faded_icon:
|
|
|
|
* @app: A #ShellApp
|
|
|
|
* @size: Size in pixels
|
|
|
|
*
|
|
|
|
* Return an actor with a horizontally faded look.
|
|
|
|
*
|
|
|
|
* Return value: (transfer none): A floating #ClutterActor, or %NULL if no icon
|
|
|
|
*/
|
|
|
|
ClutterActor *
|
|
|
|
shell_app_get_faded_icon (ShellApp *app, float size)
|
|
|
|
{
|
|
|
|
MetaWindow *window;
|
|
|
|
CoglHandle texture;
|
|
|
|
ClutterActor *result;
|
|
|
|
char *cache_key;
|
|
|
|
CreateFadedIconData data;
|
|
|
|
|
|
|
|
/* Punt for WINDOW types for now...easier to reuse the property tracking bits,
|
|
|
|
* and this helps us visually distinguish app-tracked from not.
|
|
|
|
*/
|
|
|
|
window = shell_app_info_get_source_window (app->info);
|
|
|
|
if (window)
|
|
|
|
{
|
|
|
|
return st_texture_cache_bind_pixbuf_property (st_texture_cache_get_default (),
|
|
|
|
G_OBJECT (window),
|
|
|
|
"icon");
|
|
|
|
}
|
|
|
|
|
|
|
|
cache_key = g_strdup_printf ("faded-icon:%s,size=%f", shell_app_get_id (app), size);
|
|
|
|
data.app = app;
|
|
|
|
data.size = (int) (0.5 + size);
|
|
|
|
texture = st_texture_cache_load (st_texture_cache_get_default (),
|
|
|
|
cache_key,
|
|
|
|
ST_TEXTURE_CACHE_POLICY_FOREVER,
|
|
|
|
shell_app_create_faded_icon_cpu,
|
|
|
|
&data,
|
|
|
|
NULL);
|
|
|
|
g_free (cache_key);
|
|
|
|
|
|
|
|
if (texture != COGL_INVALID_HANDLE)
|
|
|
|
{
|
|
|
|
result = clutter_texture_new ();
|
|
|
|
clutter_texture_set_cogl_texture (CLUTTER_TEXTURE (result), texture);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
result = clutter_texture_new ();
|
|
|
|
g_object_set (result, "opacity", 0, "width", size, "height", size, NULL);
|
|
|
|
|
|
|
|
}
|
|
|
|
return result;
|
|
|
|
}
|
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-11 20:40:00 +00:00
|
|
|
|
|
|
|
char *
|
|
|
|
shell_app_get_name (ShellApp *app)
|
|
|
|
{
|
|
|
|
return shell_app_info_get_name (app->info);
|
|
|
|
}
|
|
|
|
|
|
|
|
char *
|
|
|
|
shell_app_get_description (ShellApp *app)
|
|
|
|
{
|
|
|
|
return shell_app_info_get_description (app->info);
|
|
|
|
}
|
|
|
|
|
2009-10-14 21:25:17 +00:00
|
|
|
gboolean
|
|
|
|
shell_app_is_transient (ShellApp *app)
|
|
|
|
{
|
|
|
|
return shell_app_info_is_transient (app->info);
|
|
|
|
}
|
|
|
|
|
2010-04-17 20:57:58 +00:00
|
|
|
typedef struct {
|
|
|
|
MetaWorkspace *workspace;
|
|
|
|
GSList **transients;
|
|
|
|
} CollectTransientsData;
|
|
|
|
|
|
|
|
static gboolean
|
|
|
|
collect_transients_on_workspace (MetaWindow *window,
|
|
|
|
gpointer datap)
|
|
|
|
{
|
|
|
|
CollectTransientsData *data = datap;
|
|
|
|
|
|
|
|
if (data->workspace && meta_window_get_workspace (window) != data->workspace)
|
|
|
|
return TRUE;
|
|
|
|
|
|
|
|
*data->transients = g_slist_prepend (*data->transients, window);
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* The basic idea here is that when we're targeting a window,
|
|
|
|
* if it has transients we want to pick the most recent one
|
|
|
|
* the user interacted with.
|
|
|
|
* This function makes raising GEdit with the file chooser
|
|
|
|
* open work correctly.
|
|
|
|
*/
|
|
|
|
static MetaWindow *
|
|
|
|
find_most_recent_transient_on_same_workspace (MetaDisplay *display,
|
|
|
|
MetaWindow *reference)
|
|
|
|
{
|
|
|
|
GSList *transients, *transients_sorted, *iter;
|
|
|
|
MetaWindow *result;
|
|
|
|
CollectTransientsData data;
|
|
|
|
|
|
|
|
transients = NULL;
|
|
|
|
data.workspace = meta_window_get_workspace (reference);
|
|
|
|
data.transients = &transients;
|
|
|
|
|
|
|
|
meta_window_foreach_transient (reference, collect_transients_on_workspace, &data);
|
|
|
|
|
|
|
|
transients_sorted = meta_display_sort_windows_by_stacking (display, transients);
|
|
|
|
/* Reverse this so we're top-to-bottom (yes, we should probably change the order
|
|
|
|
* returned from the sort_windows_by_stacking function)
|
|
|
|
*/
|
|
|
|
transients_sorted = g_slist_reverse (transients_sorted);
|
|
|
|
g_slist_free (transients);
|
|
|
|
transients = NULL;
|
|
|
|
|
|
|
|
result = NULL;
|
|
|
|
for (iter = transients_sorted; iter; iter = iter->next)
|
|
|
|
{
|
|
|
|
MetaWindow *window = iter->data;
|
|
|
|
MetaWindowType wintype = meta_window_get_window_type (window);
|
|
|
|
|
|
|
|
/* Don't want to focus UTILITY types, like the Gimp toolbars */
|
|
|
|
if (wintype == META_WINDOW_NORMAL ||
|
|
|
|
wintype == META_WINDOW_DIALOG)
|
|
|
|
{
|
|
|
|
result = window;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
g_slist_free (transients_sorted);
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* shell_app_activate_window:
|
|
|
|
* @app: a #ShellApp
|
|
|
|
* @window: (allow-none): Window to be focused
|
|
|
|
* @timestamp: Event timestamp
|
|
|
|
*
|
|
|
|
* Bring all windows for the given app to the foreground,
|
|
|
|
* but ensure that @window is on top. If @window is %NULL,
|
|
|
|
* the window with the most recent user time for the app
|
|
|
|
* will be used.
|
|
|
|
*
|
|
|
|
* This function has no effect if @app is not currently running.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
shell_app_activate_window (ShellApp *app,
|
|
|
|
MetaWindow *window,
|
|
|
|
guint32 timestamp)
|
|
|
|
{
|
|
|
|
GSList *windows;
|
|
|
|
|
|
|
|
if (shell_app_get_state (app) != SHELL_APP_STATE_RUNNING)
|
|
|
|
return;
|
|
|
|
|
|
|
|
windows = shell_app_get_windows (app);
|
|
|
|
if (window == NULL && windows)
|
|
|
|
window = windows->data;
|
|
|
|
|
|
|
|
if (!g_slist_find (windows, window))
|
|
|
|
return;
|
|
|
|
else
|
|
|
|
{
|
|
|
|
GSList *iter;
|
|
|
|
ShellGlobal *global = shell_global_get ();
|
|
|
|
MetaScreen *screen = shell_global_get_screen (global);
|
|
|
|
MetaDisplay *display = meta_screen_get_display (screen);
|
|
|
|
MetaWorkspace *active = meta_screen_get_active_workspace (screen);
|
|
|
|
MetaWorkspace *workspace = meta_window_get_workspace (window);
|
|
|
|
guint32 last_user_timestamp = meta_display_get_last_user_time (display);
|
|
|
|
MetaWindow *most_recent_transient;
|
|
|
|
|
|
|
|
if (meta_display_xserver_time_is_before (display, timestamp, last_user_timestamp))
|
|
|
|
{
|
|
|
|
meta_window_set_demands_attention (window);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Now raise all the other windows for the app that are on
|
|
|
|
* the same workspace, in reverse order to preserve the stacking.
|
|
|
|
*/
|
|
|
|
for (iter = windows; iter; iter = iter->next)
|
|
|
|
{
|
|
|
|
MetaWindow *other_window = iter->data;
|
|
|
|
|
|
|
|
if (other_window != window)
|
|
|
|
meta_window_raise (other_window);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* If we have a transient that the user's interacted with more recently than
|
|
|
|
* the window, pick that.
|
|
|
|
*/
|
|
|
|
most_recent_transient = find_most_recent_transient_on_same_workspace (display, window);
|
|
|
|
if (most_recent_transient
|
|
|
|
&& meta_display_xserver_time_is_before (display,
|
|
|
|
meta_window_get_user_time (window),
|
|
|
|
meta_window_get_user_time (most_recent_transient)))
|
|
|
|
window = most_recent_transient;
|
|
|
|
|
|
|
|
if (active != workspace)
|
|
|
|
meta_workspace_activate_with_focus (workspace, window, timestamp);
|
|
|
|
else
|
|
|
|
meta_window_activate (window, timestamp);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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-03 18:07:44 +00:00
|
|
|
/**
|
|
|
|
* shell_app_activate:
|
|
|
|
* @app: a #ShellApp
|
|
|
|
*
|
|
|
|
* Perform an appropriate default action for operating on this application,
|
|
|
|
* dependent on its current state. For example, if the application is not
|
2010-04-17 20:57:58 +00:00
|
|
|
* currently running, launch it. If it is running, activate the most
|
|
|
|
* recently used NORMAL window (or if that window has a transient, the most
|
|
|
|
* recently used transient for that window).
|
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-03 18:07:44 +00:00
|
|
|
*/
|
|
|
|
void
|
|
|
|
shell_app_activate (ShellApp *app)
|
|
|
|
{
|
|
|
|
switch (app->state)
|
|
|
|
{
|
|
|
|
case SHELL_APP_STATE_STOPPED:
|
|
|
|
/* TODO sensibly handle this error */
|
|
|
|
shell_app_info_launch (app->info, NULL);
|
|
|
|
break;
|
|
|
|
case SHELL_APP_STATE_STARTING:
|
|
|
|
break;
|
|
|
|
case SHELL_APP_STATE_RUNNING:
|
2010-04-17 20:57:58 +00:00
|
|
|
shell_app_activate_window (app, NULL, shell_global_get_current_time (shell_global_get ()));
|
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-03 18:07:44 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* shell_app_open_new_window:
|
|
|
|
* @app: a #ShellApp
|
|
|
|
*
|
|
|
|
* Request that the application create a new window.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
shell_app_open_new_window (ShellApp *app)
|
2009-10-15 23:28:29 +00:00
|
|
|
{
|
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-03 18:07:44 +00:00
|
|
|
/* Here we just always launch the application again, even if we know
|
|
|
|
* it was already running. For most applications this
|
|
|
|
* should have the effect of creating a new window, whether that's
|
|
|
|
* a second process (in the case of Calculator) or IPC to existing
|
|
|
|
* instance (Firefox). There are a few less-sensical cases such
|
|
|
|
* as say Pidgin. Ideally, we have the application express to us
|
|
|
|
* that it supports an explicit new-window action.
|
|
|
|
*/
|
|
|
|
shell_app_info_launch (app->info, NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* shell_app_get_state:
|
|
|
|
* @app: a #ShellApp
|
|
|
|
*
|
|
|
|
* Returns: State of the application
|
|
|
|
*/
|
|
|
|
ShellAppState
|
|
|
|
shell_app_get_state (ShellApp *app)
|
|
|
|
{
|
|
|
|
return app->state;
|
2009-10-15 23:28:29 +00:00
|
|
|
}
|
|
|
|
|
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-11 20:40:00 +00:00
|
|
|
/**
|
2009-10-15 23:28:29 +00:00
|
|
|
* _shell_app_get_info:
|
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-11 20:40:00 +00:00
|
|
|
*
|
|
|
|
* Returns: (transfer none): Associated app info
|
|
|
|
*/
|
|
|
|
ShellAppInfo *
|
2009-10-15 23:28:29 +00:00
|
|
|
_shell_app_get_info (ShellApp *app)
|
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-11 20:40:00 +00:00
|
|
|
{
|
|
|
|
return app->info;
|
|
|
|
}
|
|
|
|
|
|
|
|
typedef struct {
|
|
|
|
ShellApp *app;
|
|
|
|
MetaWorkspace *active_workspace;
|
|
|
|
} CompareWindowsData;
|
|
|
|
|
|
|
|
static int
|
|
|
|
shell_app_compare_windows (gconstpointer a,
|
|
|
|
gconstpointer b,
|
|
|
|
gpointer datap)
|
|
|
|
{
|
|
|
|
MetaWindow *win_a = (gpointer)a;
|
|
|
|
MetaWindow *win_b = (gpointer)b;
|
|
|
|
CompareWindowsData *data = datap;
|
|
|
|
gboolean ws_a, ws_b;
|
|
|
|
gboolean vis_a, vis_b;
|
|
|
|
|
|
|
|
ws_a = meta_window_get_workspace (win_a) == data->active_workspace;
|
|
|
|
ws_b = meta_window_get_workspace (win_b) == data->active_workspace;
|
|
|
|
|
|
|
|
if (ws_a && !ws_b)
|
|
|
|
return -1;
|
|
|
|
else if (!ws_a && ws_b)
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
vis_a = meta_window_showing_on_its_workspace (win_a);
|
|
|
|
vis_b = meta_window_showing_on_its_workspace (win_b);
|
|
|
|
|
|
|
|
if (vis_a && !vis_b)
|
|
|
|
return -1;
|
|
|
|
else if (!vis_a && vis_b)
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
return meta_window_get_user_time (win_b) - meta_window_get_user_time (win_a);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* shell_app_get_windows:
|
|
|
|
* @app:
|
|
|
|
*
|
|
|
|
* Get the toplevel, interesting windows which are associated with this
|
|
|
|
* application. The returned list will be sorted first by whether
|
|
|
|
* they're on the active workspace, then by whether they're visible,
|
|
|
|
* and finally by the time the user last interacted with them.
|
|
|
|
*
|
|
|
|
* Returns: (transfer none) (element-type MetaWindow): List of windows
|
|
|
|
*/
|
|
|
|
GSList *
|
|
|
|
shell_app_get_windows (ShellApp *app)
|
|
|
|
{
|
2010-06-09 18:50:01 +00:00
|
|
|
if (app->running_state == NULL)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
if (app->running_state->window_sort_stale)
|
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-11 20:40:00 +00:00
|
|
|
{
|
|
|
|
CompareWindowsData data;
|
|
|
|
data.app = app;
|
|
|
|
data.active_workspace = meta_screen_get_active_workspace (shell_global_get_screen (shell_global_get ()));
|
2010-06-09 18:50:01 +00:00
|
|
|
app->running_state->windows = g_slist_sort_with_data (app->running_state->windows, shell_app_compare_windows, &data);
|
|
|
|
app->running_state->window_sort_stale = FALSE;
|
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-11 20:40:00 +00:00
|
|
|
}
|
|
|
|
|
2010-06-09 18:50:01 +00:00
|
|
|
return app->running_state->windows;
|
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-11 20:40:00 +00:00
|
|
|
}
|
|
|
|
|
2009-10-15 23:28:29 +00:00
|
|
|
guint
|
|
|
|
shell_app_get_n_windows (ShellApp *app)
|
|
|
|
{
|
2010-06-09 18:50:01 +00:00
|
|
|
if (app->running_state == NULL)
|
|
|
|
return 0;
|
|
|
|
return g_slist_length (app->running_state->windows);
|
2009-10-15 23:28:29 +00:00
|
|
|
}
|
|
|
|
|
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-11 20:40:00 +00:00
|
|
|
static gboolean
|
|
|
|
shell_app_has_visible_windows (ShellApp *app)
|
|
|
|
{
|
|
|
|
GSList *iter;
|
|
|
|
|
2010-06-09 18:50:01 +00:00
|
|
|
if (app->running_state == NULL)
|
|
|
|
return FALSE;
|
|
|
|
|
|
|
|
for (iter = app->running_state->windows; iter; iter = iter->next)
|
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-11 20:40:00 +00:00
|
|
|
{
|
|
|
|
MetaWindow *window = iter->data;
|
|
|
|
|
2009-10-16 14:50:33 +00:00
|
|
|
if (meta_window_showing_on_its_workspace (window))
|
|
|
|
return TRUE;
|
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-11 20:40:00 +00:00
|
|
|
}
|
|
|
|
|
2009-10-16 14:50:33 +00:00
|
|
|
return FALSE;
|
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-11 20:40:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
gboolean
|
|
|
|
shell_app_is_on_workspace (ShellApp *app,
|
|
|
|
MetaWorkspace *workspace)
|
|
|
|
{
|
|
|
|
GSList *iter;
|
|
|
|
|
2010-06-09 18:50:01 +00:00
|
|
|
if (app->running_state == NULL)
|
|
|
|
return FALSE;
|
|
|
|
|
|
|
|
for (iter = app->running_state->windows; iter; iter = iter->next)
|
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-11 20:40:00 +00:00
|
|
|
{
|
|
|
|
if (meta_window_get_workspace (iter->data) == workspace)
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* shell_app_compare:
|
|
|
|
* @app:
|
|
|
|
* @other: A #ShellApp
|
|
|
|
*
|
|
|
|
* Compare one #ShellApp instance to another, in the following way:
|
2010-05-11 15:55:33 +00:00
|
|
|
* - Running applications sort before not-running applications.
|
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-11 20:40:00 +00:00
|
|
|
* - If one of them has visible windows and the other does not, the one
|
|
|
|
* with visible windows is first.
|
|
|
|
* - Finally, the application which the user interacted with most recently
|
|
|
|
* compares earlier.
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
shell_app_compare (ShellApp *app,
|
|
|
|
ShellApp *other)
|
|
|
|
{
|
|
|
|
gboolean vis_app, vis_other;
|
2010-05-11 15:55:33 +00:00
|
|
|
|
|
|
|
if (app->state != other->state)
|
|
|
|
{
|
|
|
|
if (app->state == SHELL_APP_STATE_RUNNING)
|
|
|
|
return -1;
|
|
|
|
return 1;
|
|
|
|
}
|
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-11 20:40:00 +00:00
|
|
|
|
|
|
|
vis_app = shell_app_has_visible_windows (app);
|
|
|
|
vis_other = shell_app_has_visible_windows (other);
|
|
|
|
|
|
|
|
if (vis_app && !vis_other)
|
|
|
|
return -1;
|
|
|
|
else if (!vis_app && vis_other)
|
|
|
|
return 1;
|
|
|
|
|
2010-06-09 18:50:01 +00:00
|
|
|
if (app->state == SHELL_APP_STATE_RUNNING)
|
|
|
|
{
|
|
|
|
if (app->running_state->windows && !other->running_state->windows)
|
|
|
|
return -1;
|
|
|
|
else if (!app->running_state->windows && other->running_state->windows)
|
|
|
|
return 1;
|
|
|
|
return other->running_state->last_user_time - app->running_state->last_user_time;
|
|
|
|
}
|
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-11 20:40:00 +00:00
|
|
|
|
2010-06-09 18:50:01 +00:00
|
|
|
return 0;
|
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-11 20:40:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
ShellApp *
|
|
|
|
_shell_app_new_for_window (MetaWindow *window)
|
|
|
|
{
|
|
|
|
ShellApp *app;
|
|
|
|
|
|
|
|
app = g_object_new (SHELL_TYPE_APP, NULL);
|
|
|
|
app->info = shell_app_system_create_from_window (shell_app_system_get_default (), window);
|
2009-10-15 23:28:29 +00:00
|
|
|
_shell_app_system_register_app (shell_app_system_get_default (), app);
|
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-11 20:40:00 +00:00
|
|
|
_shell_app_add_window (app, window);
|
|
|
|
|
|
|
|
return app;
|
|
|
|
}
|
|
|
|
|
|
|
|
ShellApp *
|
|
|
|
_shell_app_new (ShellAppInfo *info)
|
|
|
|
{
|
|
|
|
ShellApp *app;
|
|
|
|
|
|
|
|
app = g_object_new (SHELL_TYPE_APP, NULL);
|
|
|
|
app->info = shell_app_info_ref (info);
|
2009-10-15 23:28:29 +00:00
|
|
|
_shell_app_system_register_app (shell_app_system_get_default (), app);
|
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-11 20:40:00 +00:00
|
|
|
|
|
|
|
return app;
|
|
|
|
}
|
|
|
|
|
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-03 18:07:44 +00:00
|
|
|
static void
|
|
|
|
shell_app_state_transition (ShellApp *app,
|
|
|
|
ShellAppState state)
|
|
|
|
{
|
|
|
|
if (app->state == state)
|
|
|
|
return;
|
|
|
|
g_return_if_fail (!(app->state == SHELL_APP_STATE_RUNNING &&
|
|
|
|
state == SHELL_APP_STATE_STARTING));
|
|
|
|
app->state = state;
|
2010-06-09 18:50:01 +00:00
|
|
|
|
2010-10-06 21:30:30 +00:00
|
|
|
if (app->state == SHELL_APP_STATE_STOPPED && app->running_state)
|
2010-06-09 18:50:01 +00:00
|
|
|
{
|
|
|
|
unref_running_state (app->running_state);
|
|
|
|
app->running_state = NULL;
|
|
|
|
}
|
2010-06-07 20:31:30 +00:00
|
|
|
|
|
|
|
_shell_window_tracker_notify_app_state_changed (shell_window_tracker_get_default (), app);
|
2010-06-09 18:50:01 +00:00
|
|
|
|
|
|
|
g_object_notify (G_OBJECT (app), "state");
|
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-03 18:07:44 +00:00
|
|
|
}
|
|
|
|
|
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-11 20:40:00 +00:00
|
|
|
static void
|
|
|
|
shell_app_on_unmanaged (MetaWindow *window,
|
|
|
|
ShellApp *app)
|
|
|
|
{
|
|
|
|
_shell_app_remove_window (app, window);
|
|
|
|
}
|
|
|
|
|
2009-10-16 14:50:33 +00:00
|
|
|
static void
|
|
|
|
shell_app_on_user_time_changed (MetaWindow *window,
|
|
|
|
GParamSpec *pspec,
|
|
|
|
ShellApp *app)
|
|
|
|
{
|
2010-06-09 18:50:01 +00:00
|
|
|
g_assert (app->running_state != NULL);
|
|
|
|
|
|
|
|
app->running_state->last_user_time = meta_window_get_user_time (window);
|
2010-05-11 15:55:33 +00:00
|
|
|
|
2009-10-16 14:50:33 +00:00
|
|
|
/* Ideally we don't want to emit windows-changed if the sort order
|
|
|
|
* isn't actually changing. This check catches most of those.
|
|
|
|
*/
|
2010-06-09 18:50:01 +00:00
|
|
|
if (window != app->running_state->windows->data)
|
2009-10-16 14:50:33 +00:00
|
|
|
{
|
2010-06-09 18:50:01 +00:00
|
|
|
app->running_state->window_sort_stale = TRUE;
|
2009-10-16 14:50:33 +00:00
|
|
|
g_signal_emit (app, shell_app_signals[WINDOWS_CHANGED], 0);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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-11 20:40:00 +00:00
|
|
|
static void
|
2009-10-15 17:52:17 +00:00
|
|
|
shell_app_on_ws_switch (MetaScreen *screen,
|
|
|
|
int from,
|
|
|
|
int to,
|
|
|
|
MetaMotionDirection direction,
|
|
|
|
gpointer data)
|
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-11 20:40:00 +00:00
|
|
|
{
|
2010-06-09 18:50:01 +00:00
|
|
|
ShellApp *app = SHELL_APP (data);
|
|
|
|
|
|
|
|
g_assert (app->running_state != NULL);
|
|
|
|
|
|
|
|
app->running_state->window_sort_stale = TRUE;
|
|
|
|
|
|
|
|
g_signal_emit (app, shell_app_signals[WINDOWS_CHANGED], 0);
|
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-11 20:40:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
_shell_app_add_window (ShellApp *app,
|
|
|
|
MetaWindow *window)
|
|
|
|
{
|
2010-05-11 15:55:33 +00:00
|
|
|
guint32 user_time;
|
|
|
|
|
2010-06-09 18:50:01 +00:00
|
|
|
if (app->running_state && g_slist_find (app->running_state->windows, window))
|
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-11 20:40:00 +00:00
|
|
|
return;
|
|
|
|
|
2010-06-09 18:50:01 +00:00
|
|
|
g_object_freeze_notify (G_OBJECT (app));
|
2010-05-11 15:55:33 +00:00
|
|
|
|
2010-10-06 21:30:30 +00:00
|
|
|
if (app->state != SHELL_APP_STATE_STARTING)
|
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-03 18:07:44 +00:00
|
|
|
shell_app_state_transition (app, SHELL_APP_STATE_RUNNING);
|
|
|
|
|
2010-10-06 21:30:30 +00:00
|
|
|
if (!app->running_state)
|
|
|
|
create_running_state (app);
|
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-11 20:40:00 +00:00
|
|
|
|
2010-06-09 18:50:01 +00:00
|
|
|
app->running_state->window_sort_stale = TRUE;
|
|
|
|
app->running_state->windows = g_slist_prepend (app->running_state->windows, g_object_ref (window));
|
|
|
|
g_signal_connect (window, "unmanaged", G_CALLBACK(shell_app_on_unmanaged), app);
|
|
|
|
g_signal_connect (window, "notify::user-time", G_CALLBACK(shell_app_on_user_time_changed), app);
|
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-11 20:40:00 +00:00
|
|
|
|
2010-06-09 18:50:01 +00:00
|
|
|
user_time = meta_window_get_user_time (window);
|
|
|
|
if (user_time > app->running_state->last_user_time)
|
|
|
|
app->running_state->last_user_time = user_time;
|
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-11 20:40:00 +00:00
|
|
|
|
2010-06-09 18:50:01 +00:00
|
|
|
g_object_thaw_notify (G_OBJECT (app));
|
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-11 20:40:00 +00:00
|
|
|
|
2010-06-09 18:50:01 +00:00
|
|
|
g_signal_emit (app, shell_app_signals[WINDOWS_CHANGED], 0);
|
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-11 20:40:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
_shell_app_remove_window (ShellApp *app,
|
|
|
|
MetaWindow *window)
|
|
|
|
{
|
2010-06-20 20:46:21 +00:00
|
|
|
g_assert (app->running_state != NULL);
|
2010-06-09 18:50:01 +00:00
|
|
|
|
|
|
|
if (!g_slist_find (app->running_state->windows, window))
|
2009-10-23 17:15:13 +00:00
|
|
|
return;
|
|
|
|
|
2009-10-20 21:43:51 +00:00
|
|
|
g_signal_handlers_disconnect_by_func (window, G_CALLBACK(shell_app_on_unmanaged), app);
|
|
|
|
g_signal_handlers_disconnect_by_func (window, G_CALLBACK(shell_app_on_user_time_changed), app);
|
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-11 20:40:00 +00:00
|
|
|
g_object_unref (window);
|
2010-06-09 18:50:01 +00:00
|
|
|
app->running_state->windows = g_slist_remove (app->running_state->windows, window);
|
2009-10-20 21:43:51 +00:00
|
|
|
|
2010-06-09 18:50:01 +00:00
|
|
|
if (app->running_state->windows == NULL)
|
|
|
|
shell_app_state_transition (app, SHELL_APP_STATE_STOPPED);
|
2009-10-23 14:56:48 +00:00
|
|
|
|
2010-06-09 18:50:01 +00:00
|
|
|
g_signal_emit (app, shell_app_signals[WINDOWS_CHANGED], 0);
|
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-03 18:07:44 +00:00
|
|
|
}
|
|
|
|
|
2010-05-24 14:59:52 +00:00
|
|
|
/**
|
|
|
|
* shell_app_get_pids:
|
|
|
|
* @app: a #ShellApp
|
|
|
|
*
|
|
|
|
* Returns: (transfer container) (element-type int): An unordered list of process identifers associated with this application.
|
|
|
|
*/
|
|
|
|
GSList *
|
|
|
|
shell_app_get_pids (ShellApp *app)
|
|
|
|
{
|
|
|
|
GSList *result;
|
|
|
|
GSList *iter;
|
|
|
|
|
|
|
|
result = NULL;
|
|
|
|
for (iter = shell_app_get_windows (app); iter; iter = iter->next)
|
|
|
|
{
|
|
|
|
MetaWindow *window = iter->data;
|
|
|
|
int pid = meta_window_get_pid (window);
|
|
|
|
/* Note in the (by far) common case, app will only have one pid, so
|
|
|
|
* we'll hit the first element, so don't worry about O(N^2) here.
|
|
|
|
*/
|
|
|
|
if (!g_slist_find (result, GINT_TO_POINTER (pid)))
|
|
|
|
result = g_slist_prepend (result, GINT_TO_POINTER (pid));
|
|
|
|
}
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
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-03 18:07:44 +00:00
|
|
|
void
|
2010-10-06 21:30:30 +00:00
|
|
|
_shell_app_handle_startup_sequence (ShellApp *app,
|
|
|
|
SnStartupSequence *sequence)
|
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-03 18:07:44 +00:00
|
|
|
{
|
2010-10-06 21:30:30 +00:00
|
|
|
gboolean starting = !sn_startup_sequence_get_completed (sequence);
|
|
|
|
|
|
|
|
/* The Shell design calls for on application launch, the app title
|
|
|
|
* appears at top, and no X window is focused. So when we get
|
|
|
|
* a startup-notification for this app, transition it to STARTING
|
|
|
|
* if it's currently stopped, set it as our application focus,
|
|
|
|
* but focus the no_focus window.
|
|
|
|
*/
|
|
|
|
if (starting && shell_app_get_state (app) == SHELL_APP_STATE_STOPPED)
|
|
|
|
{
|
|
|
|
MetaScreen *screen = shell_global_get_screen (shell_global_get ());
|
|
|
|
MetaDisplay *display = meta_screen_get_display (screen);
|
|
|
|
|
|
|
|
shell_app_state_transition (app, SHELL_APP_STATE_STARTING);
|
|
|
|
meta_display_focus_the_no_focus_window (display, screen,
|
|
|
|
sn_startup_sequence_get_timestamp (sequence));
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!starting)
|
|
|
|
{
|
|
|
|
if (app->running_state && app->running_state->windows)
|
|
|
|
shell_app_state_transition (app, SHELL_APP_STATE_RUNNING);
|
|
|
|
else /* application have > 1 .desktop file */
|
|
|
|
shell_app_state_transition (app, SHELL_APP_STATE_STOPPED);
|
|
|
|
}
|
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-11 20:40:00 +00:00
|
|
|
}
|
|
|
|
|
2010-03-24 13:42:59 +00:00
|
|
|
/**
|
|
|
|
* shell_app_request_quit:
|
|
|
|
* @app: A #ShellApp
|
|
|
|
*
|
|
|
|
* Initiate an asynchronous request to quit this application.
|
|
|
|
* The application may interact with the user, and the user
|
|
|
|
* might cancel the quit request from the application UI.
|
|
|
|
*
|
|
|
|
* This operation may not be supported for all applications.
|
|
|
|
*
|
|
|
|
* Returns: %TRUE if a quit request is supported for this application
|
|
|
|
*/
|
|
|
|
gboolean
|
|
|
|
shell_app_request_quit (ShellApp *app)
|
|
|
|
{
|
|
|
|
GSList *iter;
|
|
|
|
|
2010-06-09 18:50:01 +00:00
|
|
|
if (shell_app_get_state (app) != SHELL_APP_STATE_RUNNING)
|
|
|
|
return FALSE;
|
|
|
|
|
2010-03-24 13:42:59 +00:00
|
|
|
/* TODO - check for an XSMP connection; we could probably use that */
|
|
|
|
|
2010-06-09 18:50:01 +00:00
|
|
|
for (iter = app->running_state->windows; iter; iter = iter->next)
|
2010-03-24 13:42:59 +00:00
|
|
|
{
|
|
|
|
MetaWindow *win = iter->data;
|
|
|
|
|
|
|
|
if (!shell_window_tracker_is_window_interesting (win))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
meta_window_delete (win, shell_global_get_current_time (shell_global_get ()));
|
|
|
|
}
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
2010-06-09 18:50:01 +00:00
|
|
|
static void
|
|
|
|
create_running_state (ShellApp *app)
|
|
|
|
{
|
|
|
|
MetaScreen *screen;
|
|
|
|
|
|
|
|
g_assert (app->running_state == NULL);
|
|
|
|
|
|
|
|
screen = shell_global_get_screen (shell_global_get ());
|
|
|
|
app->running_state = g_slice_new0 (ShellAppRunningState);
|
|
|
|
app->running_state->refcount = 1;
|
|
|
|
app->running_state->workspace_switch_id =
|
|
|
|
g_signal_connect (screen, "workspace-switched", G_CALLBACK(shell_app_on_ws_switch), app);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
unref_running_state (ShellAppRunningState *state)
|
|
|
|
{
|
|
|
|
MetaScreen *screen;
|
|
|
|
|
|
|
|
state->refcount--;
|
|
|
|
if (state->refcount > 0)
|
|
|
|
return;
|
|
|
|
|
|
|
|
screen = shell_global_get_screen (shell_global_get ());
|
|
|
|
|
|
|
|
g_signal_handler_disconnect (screen, state->workspace_switch_id);
|
|
|
|
g_slice_free (ShellAppRunningState, state);
|
|
|
|
}
|
|
|
|
|
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-11 20:40:00 +00:00
|
|
|
static void
|
|
|
|
shell_app_init (ShellApp *self)
|
|
|
|
{
|
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-03 18:07:44 +00:00
|
|
|
self->state = SHELL_APP_STATE_STOPPED;
|
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-11 20:40:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
shell_app_dispose (GObject *object)
|
|
|
|
{
|
|
|
|
ShellApp *app = SHELL_APP (object);
|
|
|
|
|
|
|
|
if (app->info)
|
|
|
|
{
|
|
|
|
shell_app_info_unref (app->info);
|
|
|
|
app->info = NULL;
|
|
|
|
}
|
|
|
|
|
2010-06-09 18:50:01 +00:00
|
|
|
if (app->running_state)
|
|
|
|
{
|
|
|
|
while (app->running_state->windows)
|
|
|
|
_shell_app_remove_window (app, app->running_state->windows->data);
|
|
|
|
}
|
2010-03-10 23:22:06 +00:00
|
|
|
|
|
|
|
G_OBJECT_CLASS(shell_app_parent_class)->dispose (object);
|
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-11 20:40:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
shell_app_class_init(ShellAppClass *klass)
|
|
|
|
{
|
|
|
|
GObjectClass *gobject_class = G_OBJECT_CLASS (klass);
|
|
|
|
|
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-03 18:07:44 +00:00
|
|
|
gobject_class->get_property = shell_app_get_property;
|
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-11 20:40:00 +00:00
|
|
|
gobject_class->dispose = shell_app_dispose;
|
|
|
|
|
|
|
|
shell_app_signals[WINDOWS_CHANGED] = g_signal_new ("windows-changed",
|
|
|
|
SHELL_TYPE_APP,
|
|
|
|
G_SIGNAL_RUN_LAST,
|
|
|
|
0,
|
|
|
|
NULL, NULL,
|
|
|
|
g_cclosure_marshal_VOID__VOID,
|
|
|
|
G_TYPE_NONE, 0);
|
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-03 18:07:44 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* ShellApp:state:
|
|
|
|
*
|
|
|
|
* The high-level state of the application, effectively whether it's
|
|
|
|
* running or not, or transitioning between those states.
|
|
|
|
*/
|
|
|
|
g_object_class_install_property (gobject_class,
|
|
|
|
PROP_STATE,
|
|
|
|
g_param_spec_enum ("state",
|
|
|
|
"State",
|
|
|
|
"Application state",
|
|
|
|
SHELL_TYPE_APP_STATE,
|
|
|
|
SHELL_APP_STATE_STOPPED,
|
|
|
|
G_PARAM_READABLE));
|
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-11 20:40:00 +00:00
|
|
|
}
|