If we aren't going to fill the content area of the node with a solid
background color, then we need to clear it of any artifacts left over
from drawing the border.
https://bugzilla.gnome.org/show_bug.cgi?id=640465
This reverts commit b4ec342d06.
The alpha > 0 checks should actually be alpha < 255 for the commit to
make sense as designed. The design isn't right either, though,
since we need to preserve the translucency in translucent gradients,
not block it with a solid color fill.
https://bugzilla.gnome.org/show_bug.cgi?id=640465
This patch fixes the summary notification reappearing if you click on the
summary item to hide it and hover away. It also ensures that when you click
on any summary item which doesn't correspond to the summary notification
being shown, a new summary notification will replace it right away.
What used to happen is that we'd unset the clicked item in _unlock() that
was called when the focus was ungrabbed because the user clicked outside
of the summary notification, but then would have this._clickedSummaryItem
be null in _onSummaryItemClicked() , and set it to the clicked item all
over again. This patch ensures that we unset the clicked item only when
it is necessary.
We also needed to add the code to call _updateState() again to show a new
summary notification when a previous one was hidden, but
this._clickedSummaryItem was set.
https://bugzilla.gnome.org/show_bug.cgi?id=642005
Follow-up to commit 09717aae58 so
title changes also support markup instead of the ugly "<i></i>"
status.
Additionally, make sure to escape the contact's title as that
may accidentally contain unsafe markup or characters.
https://bugzilla.gnome.org/show_bug.cgi?id=642209
We were adding pango markup to the message in ContactManager.setPresence,
but weren't correctly marking the message as containing pango markup,
allowing for uglyness such as "User is <i>away</i>." being shown to the
user.
https://bugzilla.gnome.org/show_bug.cgi?id=642209
As the dash is one of the primary drop targets for dragging application
launchers, it's reasonable to use the dash icon size for app icons'
drag actors, especially with the larger size now used in the application
view.
https://bugzilla.gnome.org/show_bug.cgi?id=639428
As elements in the dash are scaled to accommodate a growing number
of items, the icon size used may end up rather small. In that case,
dragging items to the dash which are significantly larger than items
in the dash is getting clumsy, so it makes sense for some components
to synchronize the size of drag actors with the currently used icon
size in the dash. To enable other components to do this, make the icon
size a public property.
https://bugzilla.gnome.org/show_bug.cgi?id=639428
- Center the icon texture in the area allocated for it, and always give
the nominal size - avoid off-by-one scaling if the parent allocated
a little less or more size than we wanted.
- Use Math.floor() when centering horizontally to avoid allocation
at a half pixel.
https://bugzilla.gnome.org/show_bug.cgi?id=642124
Make calling workspace.setReservedSlot(null) do nothing if the slot was
already null; this improves efficiency and more importantly chills out some
weird reentrancy at the end of drag and drop that removes a window from
a workspace.
We were properly accounting for the fact that an ancestor of the
parent could be scaled rather than the parent itself when computing
the snap-back scale, but directly using parent.scale_x for the
snap-back location.
https://bugzilla.gnome.org/show_bug.cgi?id=642117
A right click was propagating through to the parent actor meaning
that a right click would activate the workspace twice and leave the
overview instead of just switching to it.
https://bugzilla.gnome.org/show_bug.cgi?id=641973
If you want to select a workspace and go there, having to go back to
the main part of the window selector and click on a window is annoying,
so make a second click on the active workspace go to the main view.
https://bugzilla.gnome.org/show_bug.cgi?id=641973
If a background gradient isn't fully opaque, then we need to first
fill in the background color so the border color doesn't leak into
the interior.
https://bugzilla.gnome.org/show_bug.cgi?id=640465
We need to be careful to ignore any preexisting color information
in the interior of the node when filling it with the background color,
since the border color may have leaked into the interior and the
background color may be translucent.
https://bugzilla.gnome.org/show_bug.cgi?id=640465
