This will hopefully help resolve the circular dependency between
libgtk linking against inspector/libgtkinspector and inspector/
needing extract-strings from gtk/.
I didn't preserve the EXEEXT decorations in this operation -
automake gave me stern warnings about it, so I just dropped them
all. Somebody who cross-builds GTK+ will have to reconstruct this.
This prevents some of our generic object implementation tests
from working with gesture objects. Instead, add g_return_if_fail
checks in all the gesture constructors.
Mainly doing s/TARGET/BUBBLE/ on the fully ported widgets, but GtkTreeView
where the double click handler has moved to GTK_PHASE_TARGET so it runs
parallelly to the still existing event handlers.
Previously, there would be globally just a capture and a bubble phase,
with the event just going down the hierarchy once, and the up once.
GTK_PHASE_TARGET actually meaning "run within event handlers", so in
a hierarchy of 3 widgets, emission would be:
Capture(C)
Capture(B)
Capture(A)
Target(A) (if event handlers allow)
Bubble(A)
Target(B) (if event handlers allow)
Bubble(B)
Target(C) (if event handlers allow)
Bubble(C)
This commit changes this behavior and uses GTK_PHASE_TARGET in a less
misleading way, running only on the widget that was meant to receive
the event. And GTK_PHASE_BUBBLE has taken over the execution place of
GTK_PHASE_TARGET, so the emission remains:
Capture(C)
Capture(B)
Capture(A)
Target(A)
Bubble(A) (if event handlers allow)
Bubble(B) (...)
Bubble(C) (...)
As it was, GTK_PHASE_BUBBLE was useful for running event controllers
paralelly to event handlers, without modifying a single line in those.
For those mixed scenarios, Any of the other phases will have to be
used at discretion, or the event handlers eventually changed to chain
up and let the default event handlers in GtkWidget to be run.
The events to those are fed outside the regular event propagation scheme,
through _gtk_window_check_handle_wm_event(), so set the controller to
GTK_PHASE_NONE so events aren't processed first manually, and then
automatically.
Event controllers now auto-attach, and the GtkCapturePhase only determines
when are events dispatched, but all controllers are managed by the widget wrt
grabs.
All callers have been updated.
Go back to respecting GtkMisc::xpad/ypad. Not doing so breaks
the misc-alignment reftest. As long as we still derive from
GtkMisc, we may as well do this.
The icontheme lookup code has a special-case that prefers builtin icons
if the theme name is "hicolor". This is problematic for our reftests,
which run in a barebones environment with not settings.
Drop the ref on the action muxer in finalize, and also make sure
shutdown() tears down the muxer setup done in startup().
When GtkApplication adds itself to a muxer, it causes the muxer to take
a ref on the GtkApplication. This has to be undone in shutdown() to make
sure the GtkApplication doesn't end up holding a ref on itself.
https://bugzilla.gnome.org/show_bug.cgi?id=730383
And handle the fact that drawing bounds are now handled by this API and
the corresponding gtk_widget_get_clip().
Also add _gtk_widget_supports_clip() function to check if a widget has
been ported to the new world.
Now that labels and images no longer use x/yalign in their code,
we need to make gtk_misc_set_alignment set the h/valign for these
widgets, to keep it stumbling along until its final demise.
https://bugzilla.gnome.org/show_bug.cgi?id=730613
Those get in the middle more than help on these widgets, the widget
is already packed with clickable areas and having handles (and their
invisible clickable area around) hovering above don't help, plus the
purpose in most likely numeric values is a bit doubtful.
All touch events are either consumed by the up/down panels, or
the swipe gesture, all GtkEntry handling of touch events on the text
window is avoided, so handles to not appear anymore.
the "bubble" phase used to run before event handlers before GTK_PHASE_TARGET
was added, in order to keep phases in the expected order, move GTK_PHASE_BUBBLE
to be run (still invariably) after event handlers.
The only behavioral change should be wrt widgets wanting mixed event handler/
gesture handling, they could previously attach the gesture to the bubble phase
and check for gtk_gesture_is_active() in the event handler to bail out, they'll
have to use GTK_PHASE_CAPTURE for that purpose from now on.
The handle is still centered horizontally, but the extra vertical
space wasn't taken into account, leading to misplacing the dragging
point (and the handle) during motion events.
GtkPaned may just capture pointer events because the child widget
doesn't happen to have GDK_TOUCH_MASK set, resort to checking the
device in that case.
Dragging is all handled by a GtkGesturePan now, matching the
paned orientation.
On touch events, a wider area is listened for, so touch events
don't need to be as accurate to initiate dragging, if no dragging
is truly initiated in this case, events are just forwarded for
child widgets to handle.
A pan gesture is used to handle switch dragging, which is only triggered
by horizontal panning movements. A multipress gesture handles the cases
where clicking without dragging happens, just toggling the switch.
A pan gesture is optionally attached if there is only one scrolling direction, the pan
gesture orientation is changed so movements tangential to the scroll direction get
scrolling cancelled (The pan gesture is automatically denied when that happens, and
that state change spreads to the others gestures in the group). If the pan direction
happens in the expected directions, no cancellation happens, and scrolling eventually
takes place.
Multiple calls are supposedly allowed to change the phase (although
unlikely to happen), so remove the g_return_if_fail() checking whether
the controller was already added.
Presses alternatively show and dismiss the popover, the popover is still
always shown invariably after any dragging happens (either text selection,
or dragging a text handle)
Presses alternatively show and dismiss the popover, the popover is still
always shown invariably after any dragging happens (either text selection,
or dragging a text handle)
Similarly to GtkTextView, a GtkGestureMultiPress gesture handles
button/touch presses to initiate one selection mode or other, and
a GtkGestureDrag is used to handle text selection and DnD checks.
The code from button press/release, motion, and grab_notify handlers
has been shuffled into the actions triggered by those gestures.
A GtkGestureDrag is used for color selection, removing also the
need to track the pointer state in widget data. The GDK grab performed
just to set the crosshair cursor has been replaced by a call
to gdk_window_set_device_cursor(), which will be unset if the
drag operation is finished, or cancelled due to the implicit grab
being broken.
When the pointer cursor is updated on CSW, lookup for either a device
cursor, or a global one. It would previously lookup for windows with
a global cursor, and then check if it had a device cursor, which would
skip windows with only device cursors set, and unexpectedly set the
global cursor.
All "exclusive" gestures listen for either pointer events, or
"pointer emulating" touch events, so only a single sequence at
a time can make these run.
This signal will always be paired with a ::pressed signal, unless
the sequence is cancelled, or the controller is reset. the n_press
argument in the signal always matches the ::press signal one, even
if GtkGestureMultiPress::stopped was emitted in between.
The current sequence (as per gtk_gesture_single_get_current_sequence)
is used to find out the coordinates. And only emit ::pressed if the
gesture began through a GDK_BUTTON_PRESS/TOUCH_BEGIN (eg. not due to
an extra touch being lifted)
Just call the controllers on that phase if the default widget handlers
are run.
For compatibility reasons, in the touch event handler, let the pointer
emulating touch be transformed to a pointer event as usual, in order to
have widget handlers a chance to run at all. If they have to be managed
by a controller in that phase, it'll have to be through the default pointer
event handlers.
This phase is meant to run in the default widget handlers, as opposed
to externally as in the bubble/capture phase. This will be most usually
the expected phase for every controller replacing code in event handlers
in GTK+, just so invocation and triggering order is kept unaltered.
That may happen separately from grab-notify, and also due to external
reasons, so ensure all sequences are cancelled if a grab is taken
in some GdkWindows that would obscure events on the controller.
We can end up with _gtk_widget_remove_controller getting called
while we are iterating over the list in _gtk_widget_run_controllers.
To avoid trouble, only mark the event controller as dead by
setting data->controller to NULL, and defer the actual freeing
and list manipulation to the loop in _gtk_widget_run_controllers.
Update other places that operate on controllers to handle
data->controller being NULL.
Make it really sure that the event is only emitted after every gesture
that consumed the button press is done with the sequence.
The event must only be emulated if a gesture in the capture phase happened
to consume the event, be cancelled, and
Sequences may be cancelled within the ::sequence-state-changed handler, which
would change the points hashtable as it's being iterated in this function. So
iterate over a list of sequences and let the hashtable change freely.
The propagation phase property/methods in GtkEventController are gone,
This is now set directly on the GtkWidget add/remove controller API,
which has been made private.
The only public bit now are the new functions gtk_gesture_attach() and
gtk_gesture_detach() that will use the private API underneath.
All callers have been updated.
Within a widget, if a gesture accepts a sequence, it would previously
cancel every other gesture that not in the same group. Change this to
only cancelling gestures that previously claimed the gesture, and let
gestures with state=NONE for that sequence remain like that.
This enables late recognition of gestures, even on the presence of
another gesture group that was more eager at claiming the gesture.
One usecase is user-defined panning gestures on scrolledwindows,
if ::capture-button-press is TRUE (eg. the default), the gesture is
claimed early in order to consume the button press, but that would
tipically make every other gesture group deny the sequence. With
this change, the pan gesture can keep state=NONE, and later claim
the sequence for itself if the panning gesture is recognized.
Also, do not propagate state=DENIED to every gesture in the widget,
that was unintended.
If no match is found with the gesture widget when poking the event
window parents, bail out safely instead of falling in an infinite
loop. This was seen on Mutter.
The utility of those signals is somewhat dubious now that there is
gtk_gesture_group(), so make that the only way to coordinate gestures.
The cooperation model offered by gtk_gesture_group() is flexible
enough,
Listen for notify::sequence-state-changed on the controller, so the
only way to manipulate a sequence state are gtk_gesture_set_sequence_state()
and gtk_gesture_set_state().
Also, make use of gesture groups, so the sequence state is set at once
on all gestures pertaining to a single group. Within a widget, if a sequence
is claimed on one group, it is made to be denied on every other group.
This API eliminates the need for overriding
GtkWidget::sequence-state-changed virtually everywhere. Grouped
gestures share common states for a same GdkEventSequence, so the
state of sequences stay in sync across those.
A multipress gesture is used to control all this, replacing
single/double click custom code, and triggering window dragging
when the multipress is stopped, yet active (ie. the sequence remains
pressed).
This gesture is used by gtk_drag_source_set() to determine
whether dragging moved past the threshold. The gesture events
are handled via the usual ::event callbacks, so we don't mess
up with callers expecting that to happen in a signal handler.
If the sequence gets claimed somewhere else in the event widget
stack, the DnD gesture will be cancelled.
With gtk_gesture_get_point() returning events in
gtk_event_controller_get_widget() coordinates, we no longer need
to compensate for the overshoot here.
GtkEventController may be certainly useful to keep event
handling self-contained in other places than gestures, but
the current widget API is highly related to gestures, so
just using GtkGesture as the argument there will be quite
more convenient. The other places where GtkEventController
make sense as a base object will better provide their own
hooks.
Gestures attached with this phase will expect callers to have it
receive events through gtk_event_controller_handle_event(), but
the gesture will still be notified of sequence state changes,
grabs, etc...
Translate events meant for other widgets/windows, so gtk_gesture_get_point()
always returns coordinates based on the gtk_event_controller_get_widget()
allocation.
If a gesture has denied sequences (so those are presumably handled above/below
the widget), it shouldn't attempt to handle extra touches, even if those end
up matching the expected number of touches.
Gestures should always receive one of such events in order to be activated,
and the propagation mechanism will ensure they do so if the original event
was caught up the widget hierarchy by another gesture that is now declining
the sequence.
If the captured touch begin or button press event have been consumed
for the given sequence, propagate it upwards if the sequence goes from
claimed to denied, so the widgets on the way to the event widget receive
a coherent event stream now that they're going to receive events.
The policy of sequence states has been made tighter on GtkGesture,
so gestures can never return to a "none" state, nor get out of a
"denied" state, a "claimed" sequence can go "denied" though.
The helper API at the widget level will first emit
GtkWidget::sequence-state-changed on the called widget, and then
notify through the same signal to every other widget in the captured
event chain. So the effect of that signal is twofold, on one hand
it lets the original widget set the state on its attached controllers,
and on the other hand it lets the other widgets freely adapt to the
sequence state changing elsewhere in the event widget chain.
By default, that signal updates every controller on the first usecase,
and propagates the default gesture policy to every other widget in the
chain on the second. This means that, by default:
1) Sequences start out on the "none" state, and get propagated through
all the event widget chain.
2) If a widget in the chain denies the sequence, all other widgets are
unaffected.
3) If a widget in the chain claims the sequence, then:
3.1) Every widget below the claiming widget (ie. towards the event widget)
will get the sequence cancelled.
3.2) Every widget above the claiming widget that had the sequence as "none"
will remain as such, if it was claimed it will go denied, but that should
rarely happen.
This behavior can be tweaked through the GtkWidget::sequence-state-changed and
GtkGesture::event-handled vmethods, although this should be very rarely done.
The kinetic scrolling feature is now implemented using a
GtkGestureDrag and a GtkGestureSwipe, plus a GtkGestureLongPress
in order to denying the sequence, so it is possibly handled
underneath.
A controller can be optionally hooked on the capture or the bubble
phase, so the controller will automatically receive and handle events
as they arrive without further interaction.
Now, all captured events run from the toplevel to the deepmost widget,
regardless of GTK+ grabs. This makes captured events more useful to
event controllers if used together in the hierarchy with widgets doing
old fashioned event handling and GTK+ grabs.
This gesture handles any number of clicks, ensuring multiple presses
stay within thresholds and timeouts. When anything of that happens,
the gesture is reset and press count starts from 1 again.
Optionally, the gesture can be given a rectangle, used in in presses > 1
to ensure the consecutive presses happen on user imposed areas.
This gesture implementation recognices swipes on any direction.
The "swipe" signal has the X/Y velocity vector components, so
those can be used for direction guessing and velocity thresholds.
This test just checks that all the icon names that GTK uses are present
in the default icon theme.
As icon names are not checked programmatically and we do not want to run
into missing-icon icons in the code, this test seems necessary.
For now, it's just a stub that tests stock icons.
The change to take out unneeded NULL checks requires some care
at startup: we check both adjustments when any of them changes;
we need to do those checks in the same order in which we create
the scrollbars, otherwise we'll try to get the adjustment of
the vscrollbar when we just set the up the hscrollbars' adjustment.
When the color editor is visible, there is no way for the
application to know about the changes that are happening.
Fix this by emitting property notification for the "rgba"
property.
http://bugzilla.gnome.org/show_bug.cgi?id=708037
This avoids a bunch of policy problems with deciding how to lay
out the window menu under different WMs.
For now, we use the special event _GTK_SHOW_WINDOW_MENU, but we
hope to have this standardized in wm-spec quite soon, as KDE wants
it as well.
To make the icontheme test run successfully when installed,
we need to use the correct test-framework-provided location,
and we need to install the test theme without stripping its
subdirectory structure.
We see an active link when creating the menu, but by the time
the menuitem is activated, we've received a leave notify that
makes the label clear its active link. Instead, give the
menuitems a direct reference to the link that is active when
the menu is created.
Problem pointed out by Tim Baedert
We know the objects in a size group are always widgets, so we
can avoid hard-to-track down problems with weak references by
just cleaning up when the object gets destroyed. There is still
a chance that we show a widget as part of the group after it
has been removed, but size groups simply have no signals that
would let us avoid that.
Add a tab that shows size groups of a widget. The properties
of the size group are available here, as well as the widgets
that are part of the size group. We highlight the widgets in
the application when their row in the inspector is hovered.
In contrast to the flashing, where we blink the widget a
few times, this is explicitly turned on and off.
It will be used for indicating widgets that are part of
a size group, in the next commit.
The focus widget might be unset, just to be set again on a widget inside
the popover. Have the popover wait till the focus is actually moved outside
before dismissing.
Move away from cell editing, and use a popover instead. This makes
it easier to e.g. use a color chooser - there's just not enough room
in a cell for many things.
Much of this code is adapted from tests/prop-editor.c.
The child properties in GtkAssistant are somewhat broken, since
they are not on direct children - but that is no reason to crash
if somebody does ask for child properties of direct children.
When a model is sortable, but the the column is not currently used
for sorting, we want to reserve the space for showing the sort
indicator. But we currently set the icon to 'missing-image', which
is not great to show all over the place. So, just set the opacity
to 0.
With the keybinding, it is possible that users may trigger the
inspector unintentionally. Show a dialog that informs them about
whats going on and gives them a chance to back out.
The warning dialog can be bypassed with the
org.gtk.Settings.Debug inspector-warning setting.
All the globals we care about should appear before doing anything
else, up-front, so a single round-trip after adding the registry
should be more than enough.
Update visual.c to use Windows themes rather than the stock Raleigh theme,
and avoid hardcoding data paths for Windows (and Mac). As the dlfcn.h
functions are only used when Python is enabled, move its inclusion there[*].
Also ensure that variables are declared on the top of the block.
[*] Python support Windows needs to be investigated, as POSIX signal
handling is used there.
https://bugzilla.gnome.org/show_bug.cgi?id=730236
Add project files to build the GtkInspector sources, as gtk-inspector is a
required portion for GTK+. "Install" the
org.gtk.Settings.Debug.gschema.xml gsettings schema file as well, so that
people can trigger GtkInspector as they develop and test their GTK+-based
programs.
Since you can't take grabs on unmapped windows, GtkMenu takes a grab on
the menu in a convoluted way: it first grabs another window, shows the
menu window, and then transfers the grab over to the GtkMenu widget.
For normal menubars, this is perfectly fine, as the first window it grabs
is our toplevel, and that gets picked up in our transient path. For
GtkMenuButton or other spurious uses of gtk_menu_popup, it creates a new
temporary input-only window which it takes the grab on, known as the "grab
transfer window". Since this window isn't a transient-for of our new menu
widget window, the grab isn't noticed when we go to show it, and thus the
menu ends up as a new toplevel.
Add a special hack to GtkMenu and the Wayland backend which lets us notice
this "grab transfer window", and include it in our grab finding path.
It's sort of terrible to have to hack up the widgets instead of just the
backend, but the alternative would be an entirely new window type which is
managed correctly by GDK. I don't want to write that.
The entire UI is constructed with templates, so the wrapper
constructors are never called, except for gtk_inspector_window_new,
which gets called from the GTK+ code.
Show the actions that are added to GtkApplication and
GtkApplicationWindows, as well as action groups that are
inserted elsewhere with gtk_widget_insert_action_group.
https://bugzilla.gnome.org/show_bug.cgi?id=730095
Moving the inspector into libgtk lets use reuse internals without
having to add public API for everything or inventing awkward private
call conventions.
https://bugzilla.gnome.org/show_bug.cgi?id=730095
Add two new icon lookup flags, GTK_ICON_LOOKUP_DIR_LTR and _RTL,
which tell GtkIconTheme to look for icon variants which have a
-ltr or -rtl suffix. GtkIconHelper adds these lookup flags when
looking up icons.
Note that due to the way this overlaps with symbolic icon lookup,
directional variants of symbolic icons must be called -symbolic-rtl, not
-rtl-symbolic.
https://bugzilla.gnome.org/show_bug.cgi?id=729980
Provide API to query the matrix instead of API that applies the matrix
directly. This makes the API more flexible.
See the commits implementing shadows.
This test is a bit brittle because it doesn't properly rely on CSS
properties but needs to use widget style properties to turn of extra
sizing from widgets.
It might break in the future when porting widgets to draw properly.
When forcing regular or symbolic icons, fall back to the default
specified icons. This ensures that when no symbolic icon is present, an
icon will still appear - the regular one.
GTK_ICON_LOOKUP_FORCE_REGULAR and GTK_ICON_LOOKUP_FORCE_SYMBOLIC can be
used to force a regular or symbolic icon to be loaded, even if the icon
names specify a different version.
This is intended to support the CSS property -gtk-icon-style.
The values can be:
"requested" - the style as requested
"regular" - use a regular full-color icon
"symbolic" - use a symbolic icon
The property defaults to "requested", so no changes should be seen
unless CSS overrides it.
It is also inherited, so that using this CSS
.toolbar { -gtk-icon-style: symbolic; }
is enough to force the whole toolbar to use symbolic icons.
The value implements the 2D parts of CSS transforms. See
http://www.w3.org/TR/css3-transforms/
For the specification.
All it does is give us an expressive way to define Cairo matrices (and
their transforms)
This allows using icons from the icontheme as images in CSS. The
reasoning is that this allows to give the image control about how it's
scaled (by using the icon theme's scaling method. So we can get crisp
images at different resolutions.
Replace them by GtkWidget h/valign. The only remaining uses
are those where a size group is involved; they can't be replaced
until GtkLabel stops looking at GtkMisc alignment for size
allocation.
Wayland's mechanism tells us all of our new states, rather than
telling us which ones were added and removed. Add a new private
interface so that we can simply specify the new states as a
bitfield directly rather than having to compute which ones were
added and removed.
Make the relative_to widget the parent for a GtkPopover's
GtkActionGroup. This, for example, makes the menu model of a
GtkMenuButton find action groups attached to the button.
https://bugzilla.gnome.org/show_bug.cgi?id=729915
Returns NULL in case of a duplicated tag name in the tag table. It is
still a programmer error to duplicate a name, but if it happens the
behavior is a little nicer (and hopefully doesn't crash).
https://bugzilla.gnome.org/show_bug.cgi?id=614717
The user doesn't need to check the return value, because if FALSE is
returned it is a programmer error. But it permits a nicer behavior for
gtk_text_buffer_create_tag() in case of failure.
https://bugzilla.gnome.org/show_bug.cgi?id=614717
Instead of manually doing it everywhere, just call set_object (NULL)
from the selection_changed handler. Fix all the set_object() functions
to deal with NULL.
Nice to have a quick way of testing this everywhere.
The implementation is not quite perfect: due to the way text
direction works in GTK+, widgets that appear in the inspector
window while we are flipped will inherit the flipped direction
instead of the fixed direction of the inspector window.
The widget-tree was not safe against object just going away.
Fix this by using row references instead of iters where
necessary, and by using weak refs to clean up when objects
die.
It does not really add much over the sensitive/insensitive rendering
that is already indicating which widget is mapped. At the same time,
set up signal handlers so we can update that when the widget changes.
Not only was the property list connecting to notify::bla for
each property individually, it was also leaking the signal
handlers when the selected object changed. Fix both.
When showing the objects in the tree, use the property name
as the name thats shown in the list. This makes it easier
to differentiate e.g. hadjustment and vadjustment in a
GtkScrolledWindow.
Add a tab that shows available signals for each object. For now,
we only show if each signal has handlers connected or now. More
functionality will be added later.
The list of toplevels also includes hidden combobox popups
and the like, so we have to be a little careful. To ensure
the right choice, we now pick the first visible window
that is not a GtkInspectorWindow.
Instead, we want to let GTK+ open a window whose life-cycle
it can control. We just ensure that all our types are registered
when the module is loaded, so GTK+ can find them.
The positioning of the highlight window was not reliable; instead
just use a after-handler for the draw signal, in the same way that
drag highlights are drawn by GTK+ itself.
And copy the code for grabbing a widget via pointer from testgtk;
that code is known to work.
Quoting the spec:
If the cascaded value of a property is the unset keyword,
then if it is an inherited property, this is treated as
inherit, and if it is not, this is treated as initial.
Spec in question:
http://dev.w3.org/csswg/css-cascade/
Also use unset in the reset-to-defaults.css we use to reset css in
reftests.
In the GTK_IMAGE_ICON_NAME case, instead of keeping around the icon_name,
create a GThemedIcon and use that. This way, we can reuse the code paths
for the GTK_IMAGE_GICON case.
We have to use the internal accessor to the visible flag, instead of
calling gtk_widget_set_visible(), from within the show() and hide()
implementations - otherwise we'll recurse.
https://bugzilla.gnome.org/show_bug.cgi?id=721069
We now use a narrower trough and paint the optional text
beside the trough instead of inside it. This makes for a much
cleaner appearance and more readable text.
The documentation for GtkFileChooser references the button which allows
the user to create new folders as the New Folder button, although the
label actually says Create Folder.
Update the documentation to say Create Folder instead of New Folder.
https://bugzilla.gnome.org/show_bug.cgi?id=729475
This small refactor makes the code more readable when adding more
transition types that have left, right, up, and down variations.
It adds inline boolean functions to tell information about transition
types (avoiding long if clauses) and changes long chains of "else if
(transition_type == ...)" into switch statements. Both are only likely
to get longer as more transition types are added.
https://bugzilla.gnome.org/show_bug.cgi?id=726676
Added GTK_BUILDER_ERROR_INVALID_PROPERTY and GTK_BUILDER_ERROR_INVALID_SIGNAL
error codes
ObjectInfo: Use a GType instead of a char * for the class name.
PropertyInfo: Use a GParamSpec instead of a char * for the property name.
SignalInfo: Use signal id and detail quark instead of a detailed signal name string.
This not only save us a few malloc in each case but lets us simplify the code
and report unknown properties and signals as a parsing error instead of just
printing a warning.
Fixed memory leaks in parse_object(), parse_template() and parse_signal() functions.
Parameters value where strduped before the last posible return and not freed.
...unless they are labeled.
To implement this, keep track of the nesting depth of section boxes,
starting from 0 for the toplevel and the submenu ones, and only
insert unlabeled separators if the depth is at most 1.
When the adjustment changes (due to e.g. a mouse wheel scroll) we update
the prelight. The part that un-prelights the previous prelight was
broken by the the pixel cache, as it called update_prelight in the
middle of the scrolling operation, where the windows were moved
but the tree_view->priv->dy was not changed to the new value. This
caused the updates to the pixel cache to go to the wrong place.
We fix this by fully doing the scroll before we update_prelight().
https://bugzilla.gnome.org/show_bug.cgi?id=728284
GtkMenuTrackerItem::visible was removed a few commits ago.
It is not necessary to bind visible anyway, since the menu
tracker will insert and remove items as their visibility
changes.
Rendering doesn't do much about clipping drawing operations to the window shape,
although invalidation applies the shape to every window, leaving possibly trails
of "overrendered" content. So ensure the shape portions get invalidated too when
the window is moved/resized.
https://bugzilla.gnome.org/show_bug.cgi?id=729095
Now that popovers may snap to any side with enough space, make enough
room on every side when requesting size, so that there's no w/h differences
at the time of setting the child allocation.
https://bugzilla.gnome.org/show_bug.cgi?id=729097
When activating an item using mnemonics GtkRecentChooserMenu does not select a
item before calling the item-activated signal thus
gtk_recent_chooser_get_current_uri() always return the last selected item
instead of the activated one.
Fixes Bug 495105 "Open recent file keyboard shortcuts do not work correctly"
The real reason for the problem that the just reverted change
was supposed to address is that testfilechooser uses show_all
to tease out places where composite dialogs don't properly
protect their internals against unintended showing. Well,
lets do that, then.
In iconic mode, model buttons will be styled like regular icon
buttons, preferring to show only the icon if one is set, falling
back to showing the label.
https://bugzilla.gnome.org/show_bug.cgi?id=727477
When rendering iconic sections, we want to use icons for verbs,
and we want to differentiate these in the menu model, to keep
the icon attribute reserved for nouns.
https://bugzilla.gnome.org/show_bug.cgi?id=727477
Instead of using GtkMenuTracker to flatten the sections into a single
linear menu, handle the sections ourselves by nesting boxes.
Each section gets an inner and outer box. The inner box numbers its
children in the way that the tracker instructs. The outer box
containes the inner box and the separator, if appropriate.
Having the two separate boxes will allow us to change the orientation of
the inner box if we want to pack widgets horizontally within a section.
Add the possibility of a GtkMenuTracker that performs no section
merging. Instead, it will report an item in the form of a separator for
subsections. It is then possible to get a separate tracker for the
subsection contents by using gtk_menu_tracker_new_for_item_link().
We have some API in GtkMenuTracker and GtkMenuTrackerItem that is
specifically designed to deal with submenus.
Generalise these APIs to take a 'link_name' parameter that we always
give as G_MENU_SUBMENU for now. In the future, this will allow creating
trackers for other types of links, such as sections.
Make this a property just like all of the other things and make the APIs
for accessing it non-private (but add a note that they are not intended
to be used).
This is not a great name to use in themes; instead, add the
menuitem class, so themes can use .button.menuitem for styles
that are specific to menuitem-like buttons.
We were not really handling all cases correctly here. We want
the suggested-action style class to only be set on headerbar
buttons, and it should be set on the default widget. Ensure
this by syncing the suggested-action style class with the
default style class. As a side-effect, setting has-default
on an action widget in ui files will now have the expected
effect.
https://bugzilla.gnome.org/show_bug.cgi?id=728846
GtkDialog has convenience API for adding action widgets that are
either placed in the action area or the headerbar. This commit
makes the same functionality available from GtkBuilder ui files
by specifying "action" as the child type.
https://bugzilla.gnome.org/show_bug.cgi?id=728846
When constructing from a menu model, use popovers by default.
This change has the potential to cause some size problems for
applications with big gear menus, so we're doing it early in
the cycle to uncover and fix those.
It may happen that the received clipboard data is empty, but
if it's of type image/bmp, gtk+ will crash:
gdk_property_change: 00030AD4 GDK_SELECTION image/bmp REPLACE 8*0 bits:
... delayed rendering
gdk_selection_send_notify_for_display: 00030AD4 CLIPBOARD image/bmp
GDK_SELECTION (no-op)
_gdk_win32_selection_convert_to_dib: 1252003C image/bmp
Program received signal SIGSEGV, Segmentation fault.
0x749a9f40 in msvcrt!memmove () from C:\Windows\syswow64\msvcrt.dll
Thread 1 (Thread 2248.0x1b34):
target=0xc07b) at gdkselection-win32.c:1292
at gdkevents-win32.c:3498
wparam=8, lparam=0) at gdkevents-win32.c:232
message=773, wparam=8, lparam=0)
at gdkevents-win32.c:263
C:\Windows\syswow64\user32.dll
C:\Users\rugoosse\AppData\Local\virt-viewer\bin\libpangocairo-1.0-0.dll
wparam=0, lparam=-1687549457)
at gdkevents-win32.c:248
C:\Users\rugoosse\AppData\Local\virt-viewer\bin\libpangocairo-1.0-0.dll
https://bugzilla.gnome.org/show_bug.cgi?id=728745
According to what i've been told, modelbuttons are supposed to look
flat, like menu items.
This is basically an improved copy of the menuitem styles.
https://bugzilla.gnome.org/show_bug.cgi?id=728810
This prevents checkmarks in modelbuttons from being styled as buttons
(apparently, modelbuttons apply "focused" to their children, unlike
normal buttons).
https://bugzilla.gnome.org/show_bug.cgi?id=728808
The events are routed through a new slave device with type
GDK_SOURCE_TOUCHSCREEN, minimal tracking of touches is done
to keep the state for each of those.
https://bugzilla.gnome.org/show_bug.cgi?id=728426
The master pointer/keyboard pair should never disappear or be
inconsistent. The seat capabilities are now reflected through
slave devices, those may come and go freely as the seat
capabilities change. This also enables adding further capabilities
to handle eg. touch.
https://bugzilla.gnome.org/show_bug.cgi?id=728426
When making the entire window a drop target, as file-roller does,
we don't want to draw the drag highlight around the CSD window
decorations.
https://bugzilla.gnome.org/show_bug.cgi?id=728526
Please enter the commit message for your changes. Lines starting
This should allow theme developers to use a very small width for
the resize handle, but still let users easily move the handle by
defining a wider resize area.
The additional resize area follows the "margin" style property.
https://bugzilla.gnome.org/show_bug.cgi?id=728073
Binding an object sensitive property with a check button active property will look like this:
<object class="GtkButton" id="button">
<property name="sensitive" bind-source="checkbutton" bind-property="active"/>
</object>
This is based on the original work done by Denis Washington for his GSoC project
This closes Bug 654417 "[GSoC] Add <binding> element to GtkBuilder syntax"
Get monitor on which the most of the window is located (nearest monitor if
window is not on screen), get its work area (area not occupied by taskbar or
any other bars) and use that for maxsize.
Previous default of 30000 meant that windows maximized onto full screen,
even covering the area where taskbar is.
https://bugzilla.gnome.org/show_bug.cgi?id=726592
When selecting a swatch in a GtkColorChooserWidget the previously
selected swatch and the currently selected swatch are not redrawn. This
can leave the old swatch still marked with a checkbox even though a new
swatch has been selected.
Redraw the swatches after changing the selection.
https://bugzilla.gnome.org/show_bug.cgi?id=727487
The documentation for the GtkWidget::size-allocate signal is missing the
description of the "allocation" parameter. Add the missing description
to the parameter.
https://bugzilla.gnome.org/show_bug.cgi?id=726179
Use GSlice to allocate all types of segments:
- char
- toggle
- mark
- pixbuf
- child widget
Char segments are a bit more complicated because the length of the text
is determined at run time and stored in the 'byte_count' field. If the
text is long, GSlice will call the system malloc() anyway, so it's
better to always use GSlice for GtkTextLineSegment.
Toggle segments are also freed in gtktextbtree.c, hence the function
_gtk_toggle_segment_free() (for a later commit it would be nice to
rename those functions with the _gtk_text prefix).
https://bugzilla.gnome.org/show_bug.cgi?id=727908
There is a possible confusion with the sentence:
"@iter is inside a natural-language word"
The iter should be viewed here as the pointed character (i.e. on the
right of the iter), not as a position between two characters.
Instead of improving the documentation, another solution would have been
to change the implementation so it is interpreted as an iter position
inside a word, i.e. between two characters that are part of a
natural-language word. But maybe some applications rely on the current
implementation.
https://bugzilla.gnome.org/show_bug.cgi?id=727908
- As the tests show, some of the functions have a strange and
inconsistent behavior for corner cases.
- Rename test_full_buffer() -> test_search_full_buffer() because
textiter.c is used for other GtkTextIter unit tests.
https://bugzilla.gnome.org/show_bug.cgi?id=727908
We are using the actionbar in the middle of the window, which
is not really what it is designed for. To avoid the unfinished
appearance on the sides, move it into the frame that we have
around the stack below. This fixes the sides, but gives the top
a double stroke. Too bad.
The text view is resizing several times after the window is mapped.
Not setting a hscrollbar-policy of never avoids that, and a
scrollbar still doesn't appear. Magic
The incremental loading was broken by GtkIconHelper - queuing a
redraw is no longer sufficient to cause GtkImage to redraw with
the new pixbuf contents.
Pointed out by Jasper St. Pierre.
The keynav dialog is transient to the example window; since the
example window is now modal, we need to make the keynav dialog
modal as well, so it can receive input.
Problem pointed out by Jasper St. Pierre.
We are keeping references on the widget we are handling as we
are iterating up, but that doesn't protect us against the entire
tree being axed from inside gtk_widget_handle_event.
https://bugzilla.gnome.org/show_bug.cgi?id=727644
Commit d05191a010 change the height
requisition to be completely dependent on the PangoLayout, but that
breaks when the font has special characters with different metrics.
Use the maximum between the two instead.
https://bugzilla.gnome.org/show_bug.cgi?id=728054
The use of border-width-set here was an attempt to differentiate
between explicitly set (from code / ui files) border width from
theme changes. But when we are calling gtk_window_set_border_width
to apply the theme value, the -set property gets set, and all
further theme changes are ignored. This has the effect of only
letting the default value of these properties get applied.
Fix this by unsetting border-width-set after applying theme values.
Because GTK does not invalidate windows that aren't mapped, we cannot
update the pixel cache when the window it handles isn't mapped. So we
add API to call when GDK windows get mapped/unmapped.
https://bugzilla.gnome.org/show_bug.cgi?id=726475
This commit makes it possible for GtkSwitch to indicate when
the underlying state changes with a delay, causing the switch
to temporarily go 'out of sync' with the underlying change.
https://bugzilla.gnome.org/show_bug.cgi?id=725648
This commit adds API for dealing with multi-selection. It is identical
to the flow box API for this purpose. The implementation is still limited
to single-selection, and will be updated in subsequent commits.
* Returns: (transfer none): a #GdkDisplay, or %NULL
* if the display could not be opened
* Returns: (nullable) (transfer none): a #GdkDisplay, or %NULL if the
* display could not be opened
*
* Since: 3.0
*/
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
