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
Currently manual dnd mode is used with St.Clickable to avoid messing
up its internal state with a pointer grab. To avoid code duplication,
move this special handling into dnd.
https://bugzilla.gnome.org/show_bug.cgi?id=610385
While most of the code already is CSS stylable, the two-colum setup
is still done using Big.Box with hard coded spacings. Port those
remaining parts to St.Widget, so that all spacings can be adjusted
by the theme.
https://bugzilla.gnome.org/show_bug.cgi?id=610385
The POPUP_LIST_SPACING constant was used for the AltTabPopup.actor's padding,
AltTabPopup.actor's spacing and SwitcherList._list's spacing.
Switch to CSS and remove the constant.
https://bugzilla.gnome.org/show_bug.cgi?id=613195
When the window's top-left corner is the same as the monitor's top-left
corner the check in shell_global_get_focus_monitor fails to detect that.
Use <= rather than < to fix that.
https://bugzilla.gnome.org/show_bug.cgi?id=613944
Left-clicking an app icon and holding the button used to pop up the
app menu, but regressed when rewriting appDisplay.
Restore the previous behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=609013
Clicking the eject button in the places display always triggers an
unmount action. In some cases like USB drives or DVDs, eject makes
more sense - it is also consistent with nautilus' behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=613405
After closing a window, the remaining previews are repositioned
after a timeout; when it is called while the user zooms a preview,
the window positions get all messed up, so postpone the positioning
in this case until the zoom ends.
https://bugzilla.gnome.org/show_bug.cgi?id=613536
The idea behind this move is that we have a lot more control over
rendering if StWidget isn't a big pile of actors, and things are
more efficient.
https://bugzilla.gnome.org/show_bug.cgi?id=607500
The hover rewrite added a freeze/thaw_notify to
st_clickable_leave_event() (to match the one already in
st_clickable_enter_event()), which broke code in two places that
assumed "pressed" would still be TRUE when "hover" changed to FALSE.
Fix that by exposing the "held" property as well.
A pointer does not equal to an int on x86_64
(which results into pointer - pointer not being an int either),
fix that by casting the resulting value to an int.
Breakage was introduced by commit 909b5ec43c
St.Widget's new "hover" property takes reactive children into account
when deciding whether or not the pointer has actually left the actor,
so it works better than the code that used to be here.
https://bugzilla.gnome.org/show_bug.cgi?id=610726
If track-hover is set, update the hover property automatically, and
the "hover" pseudo class to match, as StClickable used to do. (Remove
the corresponding code in StClickable). Tweak the tooltip handling to
use track-hover, which also makes it slightly more reliable in the
presence of reactive children, etc.
Since style_class and pseudo_class are space-separated lists of names,
add new methods to add and remove individual names rather than just
re-setting the entire name.
Update existing code to use the new pseudo-class methods where
appropriate. In some cases, this may result in actors having multiple
pseudoclasses where previously they only had one at a time, but there
don't seem to be any visible differences.
(There are some places that could usefully use the new style_class
methods as well, but this patch doesn't change them.)
Also, update test-theme.c to test the new methods.
https://bugzilla.gnome.org/show_bug.cgi?id=604943
When the user runs the same command as the last one saved there
is no need to save it again, otherwise we the history might end
up having lots of dupes which makes searching for an old command
harder.
https://bugzilla.gnome.org/show_bug.cgi?id=613731
Using a clone for the drag actor causes the animation into
the final position not to work as expected; instead use
the newly added DND parameters to change the original
drag actors size and opacity. (This reverts the change in
011db9f).
Since we are using the original actor, we have to be careful
not to change it during the drag, so don't actually position
dragged window actors in Workspace.positionWindows().
https://bugzilla.gnome.org/show_bug.cgi?id=613367
