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
We can't use gdk_display_get_pointer/gdk_window_get_pointer from gjs
when XKB is active. We already had a wrapper that did the
get-modifier-state part of that, but some places also need the
get-pointer-location part of it. So update our wrapper to return both,
and update js code to use it.
https://bugzilla.gnome.org/show_bug.cgi?id=613428
The original window dnd code needed to track whether or not the
pointer was in the clone. Some later rewrite made this unnecessary,
but we were still keeping track anyway.
When the notificaionBin has an odd width this could result into
loosing pixel aligment (and ugly looking font).
As the notification is already reactive make it non reactive and
remove the use of garvity.
https://bugzilla.gnome.org/show_bug.cgi?id=614702
Also reorganizes the notification layout to use an StScrollView; very
tall notifications are now scrolled instead of just taking up more and
more of the screen.
https://bugzilla.gnome.org/show_bug.cgi?id=608999
Also, remove a lot of cruft from genericDisplay.js leftover from
previous St-ifications, and remove the pre-gtk-2.16 hacks from the
status tray in panel.js (which are much less needed with the
nearly-all-black panel anyway).
https://bugzilla.gnome.org/show_bug.cgi?id=614516
The actual changes to shell-menu.[ch] are pretty minimal; most of the
changes there are just style/spacing/indentation.
Also, removed shell_menu_append_separator() since it wasn't needed;
the separators would already have been behaving as intended just
because they were non-reactive.
https://bugzilla.gnome.org/show_bug.cgi?id=614516
Most subclasses override get_preferred_width/height, but if they don't
(eg, StDrawingArea), then make sure they still take CSS-specified
sizes into account.
https://bugzilla.gnome.org/show_bug.cgi?id=614516
StThemeNode holds a reference to its parent, but we never released
that reference. This could cause us to hold onto whole chains
of theme nodes with rather dire memory usage implications.
Also move the other g_object_unref into _dispose.
https://bugzilla.gnome.org/show_bug.cgi?id=614660
We want to have Clutter built with the external json-glib, with
introspection support. Clutter's build breaks if we compile
it with introspection but the system install doesn't have it,
and anyways the internal copy is buggy and unmaintained.
Currently shell_global_get_primary_monitor just returns the first screen,
in the list as primary.
This is not always correct as the first screen reported by mutter isn't always,
the first one listed by RANDR.
Use gdk_screen_* to query the monitor information and add a heuristic to prefer
LVDS displays (similar like in done for gnome-panel) to prefer the laptop's
internal screen over external displays.
https://bugzilla.gnome.org/show_bug.cgi?id=608647
The check in _windowsRestacked checks for
windows[i].x >= primary.x
and
windows[i].x <= primary.x + primary.width
(likewise for y).
This is wrong because a fullscreen window on the secondary screen is likely
to have windows[i].x == primary.x + primary.width which means that the checks
for _both_ screens would be valid, but the first one would win due to
the "break;" statement.
But here the window isn't really on the primary but on the secondary one.
Fix that by using < instead of <= for those checks.
https://bugzilla.gnome.org/show_bug.cgi?id=614509
Moving to St.Table introduced a regression that resulted in the height
of Places section to only depend on the height of the left column.
This could result into some bookmarks not being displayed at all because
there are not enough items in the left column to allocate the needed height.
Fix this by removing the St.BoxLayout actors and add the items directly to
the table.
https://bugzilla.gnome.org/show_bug.cgi?id=614144
Notify() was calling setApp() unconditionally after attempting to
determine an application. However, determining the application can
fail (for example, when notify-send is used) and resulted in an exception
being printed.
Ok, there admittedly wasn't a strong rationale for having it in a
later, and by performing this immediately we reduce race conditions
for our focus_app versus startup_notification handling.
https://bugzilla.gnome.org/show_bug.cgi?id=612833
Rather than having the notificationBin, summaryBin, and
summaryNotificationBin span the whole width of the screen and just
align their children to the right spot, set their anchor_gravity
appropriately, set their anchor point correctly, and let their width
vary with the width of their child.
Fixes the fact that the area to the left and right of an expanded
notification was reactive, because the notificationBin was invisibly
covering it.
https://bugzilla.gnome.org/show_bug.cgi?id=612072
Paint/pick all children, regardless of whether or not they lie within
the content_box. The previous behavior was that a child that was 99%
outside the box would be fully visible, but a child that was 100%
outside the box would be fully hidden. This is somewhat odd, and
doesn't match the behavior of the other St container classes, and at
any rate, the use of clutter_actor_get_allocation_box() for this
optimization was incorrect since it doesn't take into account
transformations (anchor point, rotation, etc) that might cause the
child to be drawn within the content_box anyway.
(For scrolled StBoxLayouts, drawing is still clipped to the
content_box, as before, but will now properly take transformations
into account as well.)
https://bugzilla.gnome.org/show_bug.cgi?id=614047
Add a border to items which highlights on hover, just like the style
of (non-running) app-well items. For removable items in the places
section, this has the additional benefit of making clear to which
item the unmount button belongs.
https://bugzilla.gnome.org/show_bug.cgi?id=610385
