No need to subtract focus line width again, since the progressbar is
rendered starting at (0, 0).
This also fixes the entry-progressbar-coloring reftest.
The file "installation" part needed a long-overdue update, especially
as some headers were simply moved into gtk/deprecated and some new headers
were introduced, and a new .gschema.xml file needed to be processed.
Instead of firing a 'quit' signal and expecting the application to do
something that will cause it to quit, just call the new
g_application_quit() API for ourselves.
https://bugzilla.gnome.org/show_bug.cgi?id=670485
This seems a bit "too powerful" and unlikely to be used by most
applications. Remove it from now, until someone comes up with a strong
desire for it.
https://bugzilla.gnome.org/show_bug.cgi?id=670485
Instead of having an input/output GdkWindow, make the widget no-window,
and use a separate input-only window for events, and paint on the parent
window directly.
When a subclass of GtkEntry (e.g. GtkSpinButton) resizes the available
text area (by overriding the get_text_area_size vfunc), we need to
ensure we don't draw a possible progressbar over the part that got
removed from the text area.
This fixes drawing a progressbar in GtkSpinButton and in its subclasses,
such as GimpSpinScale, and makes Mitch happy too!
_gdk_x11_keymap_key_is_modifier() never tries to set min/max_keycode
if they haven't been set before, meaning that until another function
sets those, all the keys will be seen as non-modifiers.
This causes GdkKeyEvents to be wrongly tagged with "->is_modifier = 0"
when in actual fact the key is a modifier. This fixes keyboard
shortcuts captured with GtkCellRendererAccel in "raw" mode thinking
a modifier without any actual keys is a valid shortcut.
https://bugzilla.gnome.org/show_bug.cgi?id=670400
We used to set a flushed boolean whenever we flushing double buffered
areas to the window due to a non-db draw. We then read back from the
window if this was set. This broke when we were doing multiple paints
of the same area after a flush as we were re-reading the window each
time, overdrawing what was previously draw.
Subclasses of GtkEntry could set a larger height request, so we need to
apply the same calculations to the insertion cursors than we do on the
PangoLayout to render it centered under all circumstances.
