Cosimo Cecchi [Mon, 21 Nov 2011 18:57:27 +0000 (13:57 -0500)]
notebook: use the current page allocation when computing the redraw area
Instead of taking the first page and trying to adjust the rect with
random padding values, take the current page, as it's always guaranteed
to be at least as tall as inactive tabs.
This fixes some annoying 1px drawing artifacts while switching tabs when
the theme disables notebook padding.
win32: get rid of GdkDragContextPrivateWin32 and related machinery.
This turns GdkWin32DragContext into a proper GdkDragContext subclass.
Because we now correctly initialize GdkWin32DragContext in
gdk_drag_context_new, we no longer crash immediatly when a DnD
operation is initialized (the find_window, drag_status, ... vfuncs
where all pointing to 0x0 instead of their proper win32 implementations).
We now try to consistently refer to GdkDragContext as "context",
GdkWin32DragContext as "win32_context" and the ole2 related
target_drag_context and source_drag_context as "ctx".
Members of GdkWin32DragContext only used by the ole2 DnD codepaths
are now explicitly marked with a ole2_dnd_ prefix.
Cosimo Cecchi [Fri, 18 Nov 2011 16:58:56 +0000 (11:58 -0500)]
frame: make sure to allocate the CSS border width
Similar to GtkNotebook, GtkFrame was only allocating space for the
padding width, and not the border.
This could be seen by just running tests/testframe. With a theme that
renders frame borders, setting xthickness = 0 in the test draws the
button border over the frame border, which is wrong.
This assertion is only hit when dragging from an empty tree view. In
this case, gtk_tree_view_begin_drag() is triggered from gtkdnd.c and not
from gtk_tree_view_maybe_begin_dragging_row(). We actually want to
cancel the drag at this point, but that is not possible with the GTK+
API as far as I can see.
The alternative is to not allowing the drag to start. This could be
done by simply unsetting the tree view as drag source when it is empty
and setting it as drag source again when rows are added. I didn't
choose to go with this for now, since this will likely break third party
code.
Matthias Clasen [Sun, 20 Nov 2011 00:28:48 +0000 (19:28 -0500)]
Improve AtkText implementations
There was some regressions from the recent display line fix;
while fixing it improve the test coverage and make GtkEntry
and GtkTextView return identical results.
Michel Dänzer [Sat, 19 Nov 2011 17:23:27 +0000 (12:23 -0500)]
Fix gdk_cairo_region_create_from_surface on big endian
gdk_cairo_region_create_from_surface doesn't work correctly on PPC.
This is most prominently seen with the GTK window resize grip, the
shape of which is mirrored every eight pixels horizontally.
At the same time, use an A1 surface for the resize grip shape to
eliminates an A8->A1 surface conversion.
Michael Natterer [Fri, 18 Nov 2011 14:14:31 +0000 (15:14 +0100)]
Turn the private #define for the group-shifting modifier into API
Add GDK_MODIFIER_INTENT_SHIFT_GROUP to enum GdkModifierIntent
and handle it in gdk_keymap_get_modifier_mask(). Add an X11
impl of the method and return keymap_x11->group_switch_mask.
Return 0 from the default impl because we don't know.
Michael Natterer [Fri, 18 Nov 2011 11:25:03 +0000 (12:25 +0100)]
Bug 663856 - Make option-foo accelerators use the right symbol
If the keyboard group shifting modifier is *also* a normal
accelerator modifier, we need to special case it when calling
gdk_keymap_translate_keyboard_state(), so we get the right
key symbol for accelerators (for example we want Option-O,
not Option-Ø displayed in menu items). This patch should only
affect quartz where the Alt key both shifts the group and can
be used as accel modifier, and not X11 or Win32 where AltGr
is not used for accelerators.
- fix quartz' gdk_keymap_translate_keyboard_state() to return
the right consumed_modifiers
- add _gtk_translate_keyboard_accel_state() which does the
special casing
- use it everywhere instead of gdk_keymap_translate_keyboard_state()
Render background image if set for checks and options
The default theme engine draws a fallback check/radio image, but
doesn't let you replace this. We now check if a background image
is set and if so render that instead of the default fallbacks.
We now support -gtk-win32-theme-part(class,part,state) in background
and border-image CSS properties. This renders the corresponding
theme part using DrawThemeBackground() and acts as a base for a
CSS based windows theme.
Note that we build the parsing code even on non-win32 so that
all themese will parse the same on all arches. We draw pink instead
of the actual theme parts on non-win32 though.
We want to move to a world where getting style properties can
allocate a new value, depending on the style property context.
In this world we can't expose "peeking" a property, as we neet
to return a ref to the property that is newly created.
So, we move the peek code into get_property and use get_property
from get_valist.
Add GtkStylePropertyContext and use it in when getting style properties
At the toplevel we have _gtk_theming_engine_get, which lets us pass
in a property context with (atm) the size to get the property for.
Then there is a lot of plumbing to push this down into the lower
layers of the style property code until finally hitting
the property resolvers.
I need this because I will be adding a property resolver for win32
theme parts, and they render differently depending on the size
(i.e. they don't scale linearly). The idea is that the code
to get the background properties will pass in the final size
and we will resolve the theme part specification to that particular
size.
If the old non-context calls are used we just hardcode a size
of 100x100.
We used to special handle gradient, but we want to be able to store
other sources (that will eventually resolve to cairo patterns).
For instance, this is needed to handle win32 theme part sources.
Cosimo Cecchi [Wed, 16 Nov 2011 21:01:36 +0000 (16:01 -0500)]
treeview: use gtk_tree_view_ensure_background() consistently
In gtk_tree_view_state_flags_changed() we were setting the background on
the bin_window without the necessary "view" style class, making the
treeview render with the wrong color in some circumstances (such as when
adding an empty treeview in a window, as spotted by Brian Smith).
Kjell Ahlstedt [Wed, 16 Nov 2011 08:03:12 +0000 (09:03 +0100)]
Maintain map/unmap invariants in GtkRecentChooserDialog
We used to explicitly map and unmap the child GtkRecentChooserWidget when
mapping and unmapping the dialog, respectively. Now that GtkContainer actually
unmaps child widgets (instead of avoiding that), we can assume that the
child GtkRecentChooserWidget will be unmapped when we want it to be.
This fixes a warning from gtk_widget_verify_invariants(), as we were mapping
our child widget before calling our parent class' ::map() handler. Bug #659257.
Bastien Nocera [Wed, 16 Nov 2011 18:47:39 +0000 (18:47 +0000)]
gtk: Parse keypad numbers correctly
Try to find keycodes for keysyms at level-0 in the keymap, but don't
fail to parse if we can find those in level-1. This fixes the
parsing of numerical keys on the keypad, which require a shift level
through Num-Lock.
Benjamin Otte [Sat, 12 Nov 2011 04:15:53 +0000 (05:15 +0100)]
treeview: Add _gtk_rbtree_node_get_index()
.. as a replacement for _gtk_rbtree_node_find_parity(). Instead of 1 or
0, the function now returns the index of node in the complete tree
(counting from the root). And this is of course identical to the row
number.
Benjamin Otte [Sat, 12 Nov 2011 02:38:40 +0000 (03:38 +0100)]
widget: Add _gtk_widget_peek_accessible()
This function returns the accessible if it already exists. This way we
can call functions on the accessible from the widget itself instead of
having to rely on signals.