This can cause lagging when scrolling as it causes us to repaint
on every scroll event. This wasn't historically a great problem,
but with smooth scrolling we get a lot more events, so this
now creates visible lagging on slower machines.
Don't handle mouse button events greater than 5 so
they can bubble up to be used by the application.
This was causing nautilus list view to not go forward
and backwards when pressing the extra mouse buttons
designated for that.
Fixes bug 673441
Signed-off-by: Nelson Benitez Leon <nbenitezl@gmail.com>
This is not ideal, we should have a real classic windows theme,
but at least its better than everything being pink, which is what
happens otherwise when theming is not enables.
gtk_application_set_app_menu(), gtk_application_set_menubar():
Mention that you probably want to call this in the startup signal
handler. If you do it earlier you will likely get a warning about
a missing D-Bus connection, because doing it earlier does not
make sense anyway.
Since we check for !list->next (and !list->prev for RTL) to set the
GTK_REGION_LAST flag, we have to filter out invisible columns before
looping; if we don't do that we might end up assigning GTK_REGION_LAST
to an invisible column.
https://bugzilla.gnome.org/show_bug.cgi?id=672937
When a homogeneous grid has no visible children, we were
accidentally doing a division by zero. Instead, just bail
out early in this case, there is nothing to allocate anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=672763
We want to use Alt+Print for screenshot keybindings, so we have to avoid
translating it into SysRq, since that's what the keymap would dictate.
After talking with Owen, it sounds like doing this generically would be
a lot of work and quite hairy code, so hardcoding this should be OK.
https://bugzilla.gnome.org/show_bug.cgi?id=671006
When we are re-setting the same text for internal reasons
(e.g. when applying the mnemonics-visible change upon Alt press),
we should not needlessly loos the selection.
https://bugzilla.gnome.org/show_bug.cgi?id=671588
If gtkbox is the only object having a reference on one of its child
and that we try to remove it from its container, we endup having a
warning when disconnecting a signal after having unparented the
widget.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@linux.intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=670176
We only support the preview state for checkboxes for GtkButton
because it gave problems when used in treeview where the prelight
state affects all checkboxes in the row.
When GtkPrinterFunc always returns FALSE, for example when looking for
a non existent printer, if print list is done for all backends or print
backend status is UNAVAILABLE, gtk_enumerate_printers() finishes with an
empty backend list and destroy function is never called. We need to
check the backend list again after calling list_printers_init for all
backends and finish the enumeration if it's empty.
https://bugzilla.gnome.org/show_bug.cgi?id=672125
As we don't give out information about the group or level when
giving back keycodes, we should prioritise group-0, level-0, followed by
level-0 only, and then any keycodes.
This fixes "q" being pressed when the Wacom tablet code in
gnome-settings-daemon is supposed to generate an "a" ("uk" keymap
in group-0, "fr" in group-1).
https://bugzilla.gnome.org/show_bug.cgi?id=671065
When the scrolled window has a frame (and the scrollbar is within the
bevel), we should take into account the CSS border/padding of the frame
and offset the scrollbars junction rendering with it.
It seems XP doesn't handle drawing non-alpha theme parts
on alpha destinations. We fix this by using alpha bitmaps only when
needed.
However this means any non-drawn area by the theme part is now draw
black, so we must take more care to only draw where the theme part draws,
so we find the theme part size when available.
We now store the symbolic colors as a GtkCssValue which means that
we can reuse the color when resolving and storing the color in
the computed values in the style context.
Additionally we keep a last_resolved GtkCssValue cache in the
GtkSymbolicColor, and if resolving the color returns the same as
last time we reuse the old value. This further increases sharing
of Css Values.
va_copy() is not universally available, and we already have a G_VA_COPY
macro that emulates the behaviour of va_copy() when it's not available, or
simply calls va_copy() if it's there
Also, in places where we're computing a new CssValue based on an
old one, make sure that if nothing changes we're returning a reference
to the old one, rather than creating a new identical instance.
Some people destroy their widgets in ::response, so trying
to access dialog internals from the class handler that is
running afterwards has the potential to cause problems.
Instead, we can reset the ::show-editor property every
time we map the dialog.
Without any extra supporting code, just adding GTK_SMOOTH_SCROLL_MASK to
the event mask for GtkTextView makes GEdit do the right thing and scroll
smoothly. Lovely.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
https://bugzilla.gnome.org/show_bug.cgi?id=671488
Scroll events report normalized deltas in terms of an abstract
'scroll unit' now, so our job is to determine a suitable scroll
unit here. Since we are changing the value of the adjustment,
the allocation of the widget does not factor into this at all.
When doing homogeneous allocation in the presence of
overlapping spanning children, we need to avoid uneven
line allocations, otherwise, the final homogenization
will blow up the size request of the grid.
https://bugzilla.gnome.org/show_bug.cgi?id=671170
In particular gtksettings.h and gtkstylecontext.h needed to be included
in lots of places now.
Also, I order the includes alphabetically in a bunch of headers.
Support long press for customizing, and short press for
selecting/activating. This is simpler than the generic
press-and-hold support in the multitouch branch; we don't
display any feedback, and the timeout is currently hardcoded
to 1 second.
Previously we kept a Selector object for every "simple selector" (term
from CSS spec). Now we keep one for every match operation. So given the
selector
".a b:focus"
we will have 4 elements:
- pseudoclass ":focus"
- element "b"
- match any desendant (the space)
- class ".a"
Each of those is represented by a "selector class" which is basically
the collection of vfuncs for this selector.
If delta_x/y information is provided in scroll events, use it
to modify the underlying adjustment in steps proportional to
the deltas provided.
If the child widget of a scrolledwindow doesn't set
GDK_SMOOTH_SCROLL_MASK, regular scroll events will be dispatched,
and still handled by these 2 widgets.
If the touch sequence happens on a window with GDK_TOUCH_MASK set,
a GdkTouchGrabInfo is created to back it up. Else a device grab is
only created if the sequence emulates the pointer.
If both a device and a touch grab are present on a window, the later
of them both is obeyed, Any grab on the device happening after a
touch grab generates grab-broken on all the windows an implicit
touch grab was going on.
Touch events don't generate crossing events themselves, so
do not rely on these to determine whether the button release
happened within the event window.
This widget is too narrow to make touch interaction tricky enough, so
don't add the penalty of having the slider run farther from the touch
coordinates if it happens to miss the slider.
This is so submenus stay open as the parent menu item is
pressed/released, since the user would typically lift the
finger in order to select a submenu item.
This makes kinetic scrolling work with viewports where the
content does not otherwise select for button or touch events,
such as testscrolledwindow's label.
Kinetic scrolling is only done on touch devices, since it is
sort of meaningless on pointer devices, besides it implies
a different input event handling on child widgets that is
unnecessary there.
If the scrolling doesn't start after a long press, the scrolling is
cancelled and events are handled by child widgets normally.
When clicked again close to the previous button press location
(assuming it had ~0 movement), the scrolled window will allow
the child to handle the events immediately.
This is so the user doesn't have to wait to the press-and-hold
timeout in order to operate on the scrolledwindow child.
The innermost scrolled window always gets to capture the events, all
scrolled windows above it just let the event go through. Ideally
reaching a limit on the innermost scrolled window would propagate
the dragging up the hierarchy in order to keep following the touch
coords, although that'd involve rather evil hacks just to cater
for broken UIs.
