| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Now that all of the elements are in place to support (dynamically) the
action icons, we can use the 'key' in place of the 'label' when the client
sends an hint requesting it.
Some other minor issues were corrected in this change, such as ensuring that
we always show *all* widgets inside of the notification window so that when
a live notification window is updated, the action box state is not then
hidden from view.
Signed-off-by: Ikey Doherty <[email protected]>
|
|
Prior to this commit we would always end up adding multiple pie_countdown
widgets in a number of situations when updating the notification. In modern
media player apps, many updates are sent for the lifetime of a single
notification window, leading to new drawing areas being added and counting
down with each track/information change.
Note this hasn't been noticable for quite some time, because in many of the
themes the pie countdown hasn't actually been visible due to the actions
box having become hidden completely, meaning that the actions and pie show
very briefly, and are immediately nuked on a change to the notification.
Signed-off-by: Ikey Doherty <[email protected]>
|
|
Each of the themes will have to detect the 'action-icons' hint passed to
them in 'set_notification_hints' to make a determination on whether or not
to use image based buttons, instead of textual buttons, in their actions
boxes.
This factory behaviour simply extends the existing checks for urgency-hint,
as well as unifying the code style between the various in-tree theme
implementations.
Signed-off-by: Ikey Doherty <[email protected]>
|
|
The freedesktop specification states that clients may opt to use named icons
instead of textual labels on action buttons. In this instance, the icon name
is passed as the 'key' (actions[i+1]) element in the actions data passed
to the daemon.
For themes to render the icon, they should check the hints passed by the
client for a boolean value of "action-icons", and if it is set they should
then create an image button based on the key, and not the label.
Many applications now make use of action-icons, such as media players, to
provide self describing actions with well known icon names, such as playback
controls. In the absence of support for action-icons they fallback to less
useful buttons and generally less actions.
Signed-off-by: Ikey Doherty <[email protected]>
|
|
|
|
|
|
|
|
|
|
theme looks really better now
|
|
|
|
taken from:
https://git.gnome.org/browse/notification-daemon/commit/?id=b156f34
|
|
|
|
By using a bit, rather than a byte for gbooleans.
https://bugzilla.gnome.org/show_bug.cgi?id=622556
taken from:
https://git.gnome.org/browse/notification-daemon/commit/?id=c43d398
|
|
|
|
|
|
|
|
|
|
|
|
we dropped color reversing in d80ac825a8815317e06d206c2199bedfe0474f85 anyway
as it never worked properly in GTK+3, so now override_style function does nothing
|
|
|
|
|
|
fixes animation effects with compiz
|
|
|
|
|
|
|
|
|
|
It's enough to call gtk_widget_override_* functions on the toplevel element, child elements will inherit the style properly. Fixes issue #90.
|
|
inspired from:
https://git.gnome.org/browse/metacity/commit/?id=f201335
|
|
|
|
This reverts commit 7d162d83a2008c25b3134fcdda8265f23d461585.
fixes https://github.com/mate-desktop/mate-notification-daemon/issues/91
|
|
taken from:
https://git.gnome.org/browse/notification-daemon/commit/?id=9d38817
|
|
|
|
Coco:fix the height of the entire notification window in gtk3 builds, not just the visible area This gives consistant position no matter what the height of the notification window, and never overlaps the panel regardless of panel position. Top, bottom, left, right panels tested along with top left, top right, bottom left, and bottom right notification locations. None overlapped, consistant spacing from notification window to panel in all cases-just like slider. The previous "fix" has been reverted and is not present in this commit.
|
|
- this fixes also the position of the notifications
credits to.....
Author: lukefromdc
|
|
fixes https://github.com/mate-desktop/mate-notification-daemon/issues/86
Currenty the theme use the font color from gtk theme,
which give us unreadable notifications text in case of
using a dark gtk theme with mostly light font colors.
|
|
|
|
- theme.c:1010:31: warning: passing argument 1 of 'gtk_style_context_get_color' from incompatible pointer type [-Wincompatible-pointer-types]
gtk_style_context_get_color (context, GTK_STATE_FLAG_NORMAL, &color);
- theme.c:1011:25: warning: passing argument 1 of 'gtk_style_context_get' from incompatible pointer type [-Wincompatible-pointer-types]
gtk_style_context_get (context, GTK_STATE_FLAG_NORMAL, "background-color", &fg_color, NULL);
- theme.c:979:19: warning: variable 'style' set but not used [-Wunused-but-set-variable]
GtkStyleContext* style;
|
|
gtk_style_context_get_background_color"
This commit breaks the bg of notifications, in result notifications are unreadable, black fg color on black bg.
This reverts commit 0fb782d2dcc129ab0858ea0d4399f6c183cb20c1.
|
|
|
|
GTK3 daemon: fix deprecated gdk_display_get_pointer
|
|
inspired from:
https://git.gnome.org/browse/notification-daemon/patch/?id=9f376d3
|
|
GValueArray is deprecated so move to GArray instead in
_notify_daemon_pixbuf_from_data_hint()
|
|
|
|
Don't forget to free the result of g_settings_get_string(). Also, change
`slocation' to proper type gchar* for storing results of
g_settings_get_string(). Furthermore, this allows to use that pointer in free()
without any casting.
|
|
|
|
|
|
|
|
|
|
|
|
|
