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.
Instead of GtkDrawingArea, since that calls in realize
gtk_style_context_set_background(). We don't want that to happen, given
that we do all the painting ourselves in _draw().
