isa/gnome-shell
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
4d2dce2c52
gnome-shell/src/shell-app-private.h

28 lines
706 B
C
Raw Normal View History

Split ShellAppMonitor into ShellWindowTracker, ShellAppUsage The two parts were mapping windows to applications, and recording application usage statistics. The latter part (now called ShellAppUsage) is much more naturally built on top of the former (now called ShellWindowTracker). ShellWindowTracker retains the startup-notification handling. ShellWindowTracker also gains a focus-app property, which is what most things in the shell UI are interested in (instead of window focus). ShellAppSystem moves to exporting ShellApp from more of its public API, rather than ShellAppInfo. ShellAppSystem also ensures that ShellApp instances are unique by holding a hash on the ids. ShellApp's private API is split off into a shell-app-private.h, so shell-app.h can be included in shell-app-system.h. Favorites handling is removed from ShellAppSystem, now inside appFavorites.js. Port all of the JavaScript for these changes. https://bugzilla.gnome.org/show_bug.cgi?id=598646
2009-10-15 19:28:29 -04:00
/* -*- mode: C; c-file-style: "gnu"; indent-tabs-mode: nil; -*- */
#ifndef __SHELL_APP_PRIVATE_H__
#define __SHELL_APP_PRIVATE_H__
#include "shell-app.h"
#include "shell-app-system.h"
[ShellApp] refactor handling startup sequence 1. move logic to shell-app.c 2. change state to RUNNING only after startup sequence complete 3. correct handle state for applications with several .desktop files https://bugzilla.gnome.org/show_bug.cgi?id=623688
2010-10-06 17:30:30 -04:00
#define SN_API_NOT_YET_FROZEN 1
#include <libsn/sn.h>
Split ShellAppMonitor into ShellWindowTracker, ShellAppUsage The two parts were mapping windows to applications, and recording application usage statistics. The latter part (now called ShellAppUsage) is much more naturally built on top of the former (now called ShellWindowTracker). ShellWindowTracker retains the startup-notification handling. ShellWindowTracker also gains a focus-app property, which is what most things in the shell UI are interested in (instead of window focus). ShellAppSystem moves to exporting ShellApp from more of its public API, rather than ShellAppInfo. ShellAppSystem also ensures that ShellApp instances are unique by holding a hash on the ids. ShellApp's private API is split off into a shell-app-private.h, so shell-app.h can be included in shell-app-system.h. Favorites handling is removed from ShellAppSystem, now inside appFavorites.js. Port all of the JavaScript for these changes. https://bugzilla.gnome.org/show_bug.cgi?id=598646
2009-10-15 19:28:29 -04:00
G_BEGIN_DECLS
ShellApp* _shell_app_new_for_window (MetaWindow *window);
app: Port to be based on GDesktopAppInfo We weren't using the GMenuTreeEntry for anything special anymore, so remove it. https://bugzilla.gnome.org/show_bug.cgi?id=698486
2013-02-08 22:52:25 -05:00
ShellApp* _shell_app_new (GDesktopAppInfo *info);
Split ShellAppMonitor into ShellWindowTracker, ShellAppUsage The two parts were mapping windows to applications, and recording application usage statistics. The latter part (now called ShellAppUsage) is much more naturally built on top of the former (now called ShellWindowTracker). ShellWindowTracker retains the startup-notification handling. ShellWindowTracker also gains a focus-app property, which is what most things in the shell UI are interested in (instead of window focus). ShellAppSystem moves to exporting ShellApp from more of its public API, rather than ShellAppInfo. ShellAppSystem also ensures that ShellApp instances are unique by holding a hash on the ids. ShellApp's private API is split off into a shell-app-private.h, so shell-app.h can be included in shell-app-system.h. Favorites handling is removed from ShellAppSystem, now inside appFavorites.js. Port all of the JavaScript for these changes. https://bugzilla.gnome.org/show_bug.cgi?id=598646
2009-10-15 19:28:29 -04:00
app: Port to be based on GDesktopAppInfo We weren't using the GMenuTreeEntry for anything special anymore, so remove it. https://bugzilla.gnome.org/show_bug.cgi?id=698486
2013-02-08 22:52:25 -05:00
void _shell_app_set_app_info (ShellApp *app, GDesktopAppInfo *info);
apps: Uniquify application instances explicitly by id Commit 0af108211c4f5d3511b085313587e8d5541e51bb introduced a regression where applications that appear in multiple categories were duplicated in the "All Apps" list, because we switched from uniquifying on desktop file ID to the GMenuTreeEntry. Switch back to keeping the set of apps based on ID. To flesh this out, we keep the ShellApp instance for a given ID around forever, and when we're loading new contents, we replace the GMenuTreeEntry inside the app. That means callers still get new data. We still keep around the running app list, though we could just recompute it from the app list now. https://bugzilla.gnome.org/show_bug.cgi?id=659351
2011-09-19 12:49:05 -04:00
[ShellApp] refactor handling startup sequence 1. move logic to shell-app.c 2. change state to RUNNING only after startup sequence complete 3. correct handle state for applications with several .desktop files https://bugzilla.gnome.org/show_bug.cgi?id=623688
2010-10-06 17:30:30 -04:00
void _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 14:07:44 -04:00
Split ShellAppMonitor into ShellWindowTracker, ShellAppUsage The two parts were mapping windows to applications, and recording application usage statistics. The latter part (now called ShellAppUsage) is much more naturally built on top of the former (now called ShellWindowTracker). ShellWindowTracker retains the startup-notification handling. ShellWindowTracker also gains a focus-app property, which is what most things in the shell UI are interested in (instead of window focus). ShellAppSystem moves to exporting ShellApp from more of its public API, rather than ShellAppInfo. ShellAppSystem also ensures that ShellApp instances are unique by holding a hash on the ids. ShellApp's private API is split off into a shell-app-private.h, so shell-app.h can be included in shell-app-system.h. Favorites handling is removed from ShellAppSystem, now inside appFavorites.js. Port all of the JavaScript for these changes. https://bugzilla.gnome.org/show_bug.cgi?id=598646
2009-10-15 19:28:29 -04:00
void _shell_app_add_window (ShellApp *app, MetaWindow *window);
void _shell_app_remove_window (ShellApp *app, MetaWindow *window);
G_END_DECLS
#endif /* __SHELL_APP_PRIVATE_H__ */
Reference in New Issue Copy Permalink