The application proxy is created asynchrously after the dbus name
is registed. This means that when tracking the first window (and
therefore creating the first window GActionGroup) there is no
app proxy yet.
https://bugzilla.gnome.org/show_bug.cgi?id=633028
Implement the background-size CSS property, specified by the CSS
Backgrounds and Borders Module Level 3, including the keywords
"contain", "cover", and fixed-size backgrounds.
https://bugzilla.gnome.org/show_bug.cgi?id=633462
It's not guaranteed that the application DBus proxy appears before
we receive the first focus event from the toplevel window.
Ensure that the first method to access the action muxer creates it if
hasn't been created yet.
We now have GRemoteActionGroup interface with the needed API,
implemented by GDBusActionGroup.
With the new API we could theoretically turn GActionMuxer itself into a
GRemoteActionGroup and expose the _full API to the shell so that the
timestamps could be passed from there.
Pass the current timestamp as platform data when activating
an action. This is implemented slightly hacky, since we use
clutter_get_current_event_time() to get at the timestamp, but
the alternative is to expose g_action_muxer_activate_action_full
to js, which would be quite a bit more involved.
GTK+ also exports window-specific actions, by putting the object path
for the exported action group in the _DBUS_OBJECT_PATH X property.
We add this action group to the app's muxer with a 'win' prefix,
since that is what the exported menu expects. Whenever the focus
window changes, we update the window-specific actions of its
application, and emit notify::action-group to cause the app
menu to be updated.
GDBusActionGroup api has changed again, adapt to that.
Also, use a GActionMuxer to add the 'app.' prefix to actions,
instead of manually stripping it out of the action names.
In the future, the muxer will also contain per-window actions
with a 'win.' prefix.
GMenuProxy has been replaced by GDBusMenuModel, and the object path
has been moved (now needs to be retrieved from the AppMenu GApplication
property).
Update the test to prefix each action with "app." as documented,
and use a GtkApplicationWindow instead of a plain GtkWindow.
Use the new GApplication support in ShellApp to create the application
menu. Supports plain (no state), boolean and double actions.
Includes a test application (as no other application uses GApplication
for actions)
https://bugzilla.gnome.org/show_bug.cgi?id=621203
GDBusActionGroup and GMenuProxy are new objects in GIO 2.32 that
help with accessing menus and actions of remote applications.
This patch makes it possible for the shell to associate an
application with a dbus name and from that a GMenu, that will
be shown as the application menu.
https://bugzilla.gnome.org/show_bug.cgi?id=621203
grid_width and grid_height were inverted, which caused a crash
in GdkPixbuf code. This was never noticed because the animation
in the panel is a square.
https://bugzilla.gnome.org/show_bug.cgi?id=666606
commit 5350302b09 dropped the possibility
to make a dbus name acquisition failure non-fatal.
Btw, it has also overriden the name in the error message.
Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
Signed-off-by: Colin Walters <walters@verbum.org>
https://bugzilla.gnome.org/show_bug.cgi?id=663941
Rewrite code acquiring dbus names so that it uses GDBus, and rewrite
ShellDBus so that it is exposed on the GDBus connection. Ports of
the other objects will follow.
https://bugzilla.gnome.org/show_bug.cgi?id=648651
Not all desktop files tracked by the shell have
Exec lines. This could be because they're actually
run by another process, for instance, and the desktop
file is merely there to provide metadata. For example,
nautilus-pastebin provides a desktop file without an
Exec line.
The shell currently crashes if one of these partial
desktop files is installed and the user attempts to
search from the overview.
commit 37726a4cb6 fixed
a similar crasher.
This commit fixes the next one lower in the code.
https://bugzilla.gnome.org/show_bug.cgi?id=663815
Instead of saving the last_used_time per-app, grab the maximum time for all
windows. The logic is less hard to keep track of, and it solves some edge
case issues where windows that no longer exist update the user time, even
if none of the other windows have been used recently.
https://bugzilla.gnome.org/show_bug.cgi?id=660650
Allow push_modal to optionally only work with a keyboard only grab and
use that in altTab as a fallback to allow switching windows while a pointer grab
is in effect (like during DND operations).
https://bugzilla.gnome.org/show_bug.cgi?id=660457
For some reason, the texture cache decides to make a request and then look up
an icon in the icon theme. If it's valid, it just returns, fine, but if it
doesn't add the icon, it tries to undo the request, leaking an
AsyncTextureLoadData that isn't freed in the process.
https://bugzilla.gnome.org/show_bug.cgi?id=660968
Rather than have five or six structs allocated duplicating data,
just keep one and simplify the code considerably.
Again, part of my ongoing quest to merge St and Mx.
https://bugzilla.gnome.org/show_bug.cgi?id=660968
shell_global_get_memory_info tries to zero initialize the output
parameter with memset, but it passes the wrong size (because of
a missing *). There's no reason to do the memset, though. In the
normal case all members of the struct gets initialized before the
function returns anyway.
This commit drops the memset call in favor of one explicit 0 assignment
that only gets executed on on atypical platforms.
https://bugzilla.gnome.org/show_bug.cgi?id=662236
Without the desktop, even Nautilus hardcodes "Home" in all places
nowadays (except for the desktop itself). I think a run-time dependency
on nautilus being installed (GSettings will abort if the schema is not
found) is not worth it to keep compatibility with the desktop.
(Also, nautilus itself could probably hardcode "Home" for the desktop as
well and remove the preference).
https://bugzilla.gnome.org/show_bug.cgi?id=659895
