We were adding one child too much to the style context path when
generating it for the internal buttons, which in turn caused sibling
selectors from the theme such as :first-child to apply to both buttons
under certain circumstances. Spotted by Lapo Calamandrei.
As long as we don't have an API for explicitly inverting the bar, it
makes more sense for the progress in vertical orientation to fill from
the bottom.
In the event that a GtkAccelKey was present for the closure but it
contained a keyval of 0 the previous code would show "". After the
recent adjustments, "-/-" would be shown in this case.
It turns out to be a pretty common case, so fix the logic to stop using
'0' as a magic value to mean "don't have an accel" and add a separate
boolean for that purpose.
This reverts commit 1f5dea9eba,
since it was causeing noticable behaviour changes.
Previously, GTK_DATA_PREFIX=/ ./gtk3-demo would start
gtk3-demo with the Raleigh theme. With that change, it
was starting with no theme at all (i.e. all black).
While regular animations should always be created, transitions should
not. This patch allows to express this by passing NULL as the values to
transition from.
It also adds a gtk_style_context_should_create_transitions() function
that returns TRUE when transitions should be created.
... that actually was both wrong, a performance failure and has been
there since the original checkin.
Updating the cached style data absolutely does not mean clearing all
cached style data first. There's nothing to update then.
This will be useful to not trigger updates all the time when nothing is
happening (ie due to animations being paused or due to them having
reached their final value).
This adds the GtkCssAnimation class and the code needed to hook it into
GtkStyleContext. It takes the values out of the CSS "animation"
properties and does animations. See
http://dev.w3.org/csswg/css3-animations/
for details.
Note that the code for starting and stopping animations with widget
visibility doesn't work yet.
This change is necessary because the old code did not accound for corner
cases (like translucent child windows), which could stop
gtk_widget_queue_resize() to not trigger redraws.
Make the main (and only) entry-point to gtkmodelmenu.c the now-public
gtk_menu_shell_bind_model().
Move the convenience constructors (gtk_menu_new_from_model() and
gtk_menu_bar_new_from_model()) to their proper files.
Remove the private header file.
Simplify the code a bit by making the initial populate part of the
bind() call.
https://bugzilla.gnome.org/show_bug.cgi?id=682831
Add an API to GtkAccelLabel for hardcoding the accel key to be displayed
(ie: allowing us to bypass the GtkAccelGroup lookup).
Use that from the GMenuModel-based GtkMenu construction code instead of
passing around the accel group.
This makes accel labels work in bloatpad again.
This patch effectively removes any hope of automatic runtime accel
changes in GMenuModel-based menus without additional application
support but it leaves the door open for this to be supported again in
the future (if we decide that it's important).
https://bugzilla.gnome.org/show_bug.cgi?id=683738
Add support for a stateful action associated with a submenu. The action
state is set to TRUE when the menu is shown and FALSE when it is
unshown.
This is useful to avoid unnecessary processing for menus that have
frequently-changing content.
A possible future feature is to add support for asynchronously filling
the initial state of the menu by waiting until the action actually emits
its state-change signal to TRUE before showing the menu.
A silly example has been added to Bloatpad to demonstrate the new
feature.
https://bugzilla.gnome.org/show_bug.cgi?id=682630
In gtk_menu_bar_draw, the check for shadow type != none
disables rendering of the background instead of the frame.
The check should be moved down to gtk_render_frame.
Patch by Peter de Ridder,
http://bugzilla.gnome.org/show_bug.cgi?id=670390
A button is highlighted if the private variable in_button is TRUE.
This variable is set when the pointer is over the button and cleared when
it left the button. When a button is hidden while there is the pointer over
it, GTK generates a leave notification event, in_button is set to FALSE.
But when a button is removed from a container but not destroyed, it is
unrealized and loose its window. It cannot receive the leave notification
event and in_button stay TRUE. So when the button get a new parent it is still
highlighted.
https://bugzilla.gnome.org/show_bug.cgi?id=676890
Scroll to the selection when setting it so the selected font is
visible on screen. This is especially useful if an initial font is
set for the user to see it.
https://bugzilla.gnome.org/show_bug.cgi?id=684156
Previously, we would avoid setting the prelight state flag when
button_down was TRUE and draw_indicator = FALSE, which is the normal
case of a GtkToggleButton during a mouse press.
It looks like this behavior was introduced a long time ago with commit
b94e6c0a80. I believe the reason was that
a widget in GTK2 couldn't have more than a single state (e.g.
hover+active) at a given moment.
https://bugzilla.gnome.org/show_bug.cgi?id=684038
Don't hook on the widget style context and set up instead
a widget path for itself. Also use a common style class
for both handles, with an extra top/bottom class for each
handle.
This is to allow animating arrays properly. I'm not really thrilled
about this solution (we leak propertys into the values again...), but
it's the best I can come up with - I prefer it to having N different
array types...
I want to get away from the ability to have 0-length arrays, all css
arrays are single element.
Even if the element is "none", it is still a "none" element.
GtkTextHandle is used to indicate both the cursor position
and the selection bound, dragging the handles will modify
the selection and scroll if necessary.
Backwards text selection is also blocked for touch devices,
so the handles don't get inverted positions and possibly
obscure portions of the selected text.
GtkTextHandle is used to indicate both the cursor position
and the selection bound, dragging the handles will modify
the selection and scroll if necessary.
Backwards text selection is also blocked for touch devices,
so the handles don't get inverted positions (This is more
important though on GtkTextView, as inverted handles may
obscure portions of the selected text, good for consistence
though)
This is a helper object to allow text widgets to implement
text selection on touch devices. It allows for both cursor
placement and text selection, displaying draggable handles
on/around the cursor and selection bound positions.
Currently, this is private to GTK+, and only available to
GtkEntry and GtkTextView.
GtkTextHandle creates temporary override redirect windows, but still
hook to the text widget for events, so those are effectively captured
by GtkScrolledWindow if a text widget is within it
