- It is not possible anymore to trigger text DnD through touch, pressing
and dragging from within the selection will instead extend it. Text
shrinking is still available through the handles
- The selection mode for touch is per-word, char-level manipulation is
still available through the handles.
- Tapping within the selection will bring in text handles, and toggle
text selection popover.
This mode could also shrink the selection, plus the starting point would
seem somewhat arbitrary (actually dependent on the dragging direction of
the last selection).
Made this mode more consistent by only allowing it to extend the selection,
only in one direction for each operation, and so it keeps the current
selection as a minimum.
Instead of passing a GdkEvent and let the function figure out whether the
selection should be extended, let that to the caller and just pass a
boolean here.
Using the parent widget context is a leftover of the pre-popover
implementation, which used GdkWindows directly. This will make the context
reflect widget state, at the expense of changing the selector paths
that used to match the handles.
Checking the return value was valid for most gestures, but
GtkGestureLongPress, where the first press triggers internally an action,
but does nothing for the sequence to be claimed/denied, FALSE was eventually
returned, and the button/sequence functions would be incorrect when
::pressed is emitted.
So check that the sequence is being handled by the gesture, this is more
desirable than the return value as it's independent of sequence state,
and still will be FALSE for the cases we want to catch here.
When a RTL paragraph is not set to wrap, the right margin is not respected
because of the margins counted twice so we replace
display->width by PIXEL_BOUND (extents.width), the same quantity
without the margins.
https://bugzilla.gnome.org/show_bug.cgi?id=741702
GtkIconTheme doesn't scale icons beyond the size specified in the theme
anymore. This can result in arbitrarily large menu items when a theme
only provides large icons.
Force icons to always be 16x16 to ensure that menu items always have the
same height.
https://bugzilla.gnome.org/show_bug.cgi?id=741259
Since the support for GL support in the GDK Windows backend has landed in
master, we need to build it in the Visual Studio builds. Update the
projects for that and "install" the public header that was added.
This adds support for OpenGL to the GDK Windows backend using the WGL API
calls, which enables programs that uses the GTK+ GLArea widgets to work on
Windows as well.
This also adds a simple utility function to query for the version of OpenGL
that is supported by the Windows system, like the one provided by the X11
backend.
Many thanks to Alex (and Emmanuele, who started the OpenGL integration in
GTK+) who offered advice and help along the way, as well as the X11 and
Wayland backend for this work to refer to and to model upon.
https://bugzilla.gnome.org/show_bug.cgi?id=740795
As the alignments, strides and image formats may be different across
platforms, make the texture upload a vfunc to allow backends to override
the GL commands for uploading textures for the software implementation for
gdk_gl_texture_from_surface(), if necessary.
Suggested by Alex to avoid copying non-trivial portions of code which would
then add maintainenace burden.
https://bugzilla.gnome.org/show_bug.cgi?id=740795
This drops the maybe_allocate_buffers that re-allocates buffers
at any point. Instead we just set have_buffers to FALSE and have
the buffers re-created when needed.
This also makes the buffer creation code imdeponent and makes it
clean up no longer needed buffers in order to handle being called
multiple times due to the above.
We also ensure we re-allocate the buffers when we're resizing
and the buffers are already created.
We can't combine multiple draws into one for the software fallback,
because each quad has a different texture. And we generally don't
want to make a larger single texture because then we would have
to upload more data.
On creation, we call action_removed() in case the action was missing
from the start. Because we just created the action, 'can_activate' will
always be FALSE here and this function will therefore always do nothing.
We do want the visibility state to be updated though, for the case where
the action is missing but the item should still be visible from the
start.
Update the visibility directly instead of trying to call
action_removed().
https://bugzilla.gnome.org/show_bug.cgi?id=735122
We were only properly setting the "is-visible" flag to TRUE for menu
items with associated actions and not (for example) on submenus.
This was fine because the code for building GtkMenus from models
(correctly) assumed that submenus should always be visible and never
checked the property.
This is not true for the Mac OS code, which actually checked the
property and found it to be false for submenus.
Initialise the property to TRUE so that we get the correct value
reported for items that don't have actions.
https://bugzilla.gnome.org/show_bug.cgi?id=735122
All popover sides have extra margins to possibly hold the tail, this is
accounted for in gtk_popover_get_rect_coords(), and should be accounted
for too in the tail position calculation.
This fixes the gtk_render_frame_gap() warnings seen when a popover is
pushed far too close to window sides.
After b49c7c3421 we were no longer doing a
full revalidate after GTK_CSS_CHANGE_SOURCE changes.
This fixes spurious failures of widgets not properly updating when
changing the theme.
