The old calculation did not take into account the icon and the spacing
between columns. This resulted in the notifications that had a slightly
longer title/banner combination than could actually fit not being expandable.
The new calculation is done in _bannerBoxAllocate() so
that we don't need to hardcode which other elements are present.
https://bugzilla.gnome.org/show_bug.cgi?id=627985
A Source needs exactly one summary icon (which in the case of a
trayicon-based source won't even be just an image), but possibly many
notification icons, which may vary for successive notifications
(particularly in the case of NotificationDaemon notifications). So
differentiate these cases in the API.
https://bugzilla.gnome.org/show_bug.cgi?id=627303
The tray itself does not actually need them, and to make status icon
sources work correctly the NotificationDaemon will need to be tracking
its sources by two separate IDs, so the existing system won't work.
Also remove MessageTray.removeSourceByApp(), which is
NotificationDaemon-specific, and implement the functionality in
notificationDaemon.js instead.
https://bugzilla.gnome.org/show_bug.cgi?id=627303
The librsvg theme engine uses now-gone GTK+ drawing functions so doesn't
compile with GTK+ 3. Since we don't need the theme engine anyways,
skip bulding it.
Creating an FBO may be expensive, so we should avoid the operation
if possible. When transitioning between theme nodes, the widget's
opacity is used to paint to the offscreen textures which are blended
together - this means that the textures have to be recreated each time
the widget's opacity changes. It is much more effective to paint the
textures at full opacity and respect the widget's paint opacity when
blending the textures together.
https://bugzilla.gnome.org/show_bug.cgi?id=627085
The current search system uses the OR operator to concatenate search
terms. While results which are matched multiple times sort before
other matches, it is almost guaranteed that adding an additional term
to the search increments the number of results, which is rather
surprising.
https://bugzilla.gnome.org/show_bug.cgi?id=610955
gdk_screen_get_rgb_colormap() has been removed from GTK+; there's
no longer a special visual that is used for drawing true-color
images distinct from the system visual. So, we don't need to
check for it; if the visual isn't the system visual, we just
fall through to the case where we create a new GdkColormap.
The 1.9.14 snapshot, along with many other things, fixes a major bug in
painting images that was causing the cairo-converted Metacity theme cod
not to work properly.
When calling Notification.update, reuse the previous _bannerBox and
related labels (only changing the label content and relayouting), so
that the opacity set on popOut is preserved. As a consequence, updating
an opened notification no longer shows (or flicker) the banner at the
top.
https://bugzilla.gnome.org/show_bug.cgi?id=625502
This reverts commit b76fe12209.
We now have a workaround symlink server side for the git 1.7.2 handling
of '+', and also there's a patch in git upstream and in some distros, so
we don't need the workaround around in our moduleset anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=626302
The function has been upstreamed as clutter_actor_contains() - with
the switch to clutter-1.4 it is now available to the Shell, so it
is no longer necessary to keep a copy in-tree.
https://bugzilla.gnome.org/show_bug.cgi?id=626512
Build the Clutter 1.4 development branch instead of against Clutter 1.2;
this seems to work fine with GNOME Shell at this point, with various
fixes having been applied Mutter, GNOME Shell, and Clutter.
The space between the rightmost item and the edge of the screen should
be considered part of the rightmost item, and the space between items
should be considered part of the adjacent items, to prevent excess
jitter when moving between them.
https://bugzilla.gnome.org/show_bug.cgi?id=626112
Add support for the CSS :first-child and :last-child properties to
StContainer, and thus to all containers in St and ShellGenericContainer.
The internal ordering of the container's children is used to determine
the child to which to attach the pseudo class, not the children's
positions. This means that containers where positions can differ from
the ordering (ShellGenericContainer / StGroup) may behave unexpectedly,
so some caution is required.
https://bugzilla.gnome.org/show_bug.cgi?id=625316
The start date is shifted by a week if the day number of the month's
first day is smaller than the week start's day number. Probably the
only real world examples are months starting on a Sunday with locales
using Monday as start of week.
https://bugzilla.gnome.org/show_bug.cgi?id=625756
When we are manually starting dconf in the case where it can't
be activated via D-Bus, we need to set LD_LIBRARY_PATH in its
environment, since dconf is no longer linked with a rpath.
(Unlike the rest of GNOME, it doesn't use libtool.)
It is not obvious that only the icon is clickable to activate the
default action - in fact, with the area being that tiny, many don't
even know that notifications can be clicked.
Just extend the clickable area to the whole notification.
https://bugzilla.gnome.org/show_bug.cgi?id=613932
