| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
glib will use the correct marshaller automatically. And as a side
effect, we also get all glib optimizations, like a va marshaller.
|
|
|
|
|
|
|
| |
This keeps the credits section from making the dialog grow
when there are lots of credits.
https://bugzilla.gnome.org/show_bug.cgi?id=770458
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were using __VOID for the SHOW_OTHER_LOCATION signal that
uses flags named SHOR_OTHER_LOCATION_WITH_FLAGS.
However, if a signal uses flags the marshal needs to use __FLAGS.
This patch addresses this using VOID__FLAGS as the marshaler parameter.
Thanks to Jan Steffens for pointing this out.
https://bugzilla.gnome.org/show_bug.cgi?id=770550
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
-ftrack-macro-expansion=0 doesn't like if statements without braces when
evaluating indentation levels.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Set a small max-width on entries used for editing cells, so they
adapt to small columns and don't overlap the next column.
https://bugzilla.gnome.org/show_bug.cgi?id=770374
|
|
|
|
| |
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=764413
|
|
|
|
|
|
|
| |
Translate move_to_rect parameter into xdg_positioner requests, and use
the generated xdg_positioner to create the popup.
https://bugzilla.gnome.org/show_bug.cgi?id=769937
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=769937
|
|
|
|
|
|
| |
We'll use it from more places later.
https://bugzilla.gnome.org/show_bug.cgi?id=769937
|
|
|
|
|
|
| |
This makes the protocol log less spammy.
https://bugzilla.gnome.org/show_bug.cgi?id=769937
|
|
|
|
|
|
|
|
| |
Only set input, opaque and window geometry regions once per commit.
They are double buffered anyway, so the last one would only take effect
either way; this way reading protocol logs are much more pleasent.
https://bugzilla.gnome.org/show_bug.cgi?id=769937
|
|
|
|
|
|
|
| |
Don't expose the xdg_shell struct as it is not yet a stable type that
will stay the same.
https://bugzilla.gnome.org/show_bug.cgi?id=769937
|
|
|
|
|
|
|
| |
Use our the 'tiled' entry from our new 'state' enum sent via
xdg_surface.configure.
https://bugzilla.gnome.org/show_bug.cgi?id=769937
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=769937
|
| |
|
|
|
|
| |
We have this framework, lets use it.
|
|
|
|
| |
Some platforms simply don't have window icons (such as Wayland).
|
|
|
|
|
|
|
| |
Otherwise, we may end up showing clickable arrows that don't
do anything.
https://bugzilla.gnome.org/show_bug.cgi?id=770332
|
|
|
|
| |
This is a bit of a gotcha, so better document it.
|
|
|
|
|
|
|
|
|
| |
There is annoying interference between formatting the value
(for which we set the number of digits to show) and the small
frame-to-frame value changes that we do for autoscrolling.
To work around this, turn off the digits-based rounding entirely
and format the value ourselves with ::format-value.
|
|
|
|
|
| |
The adjustments need to have step-increment and page-increment
set up, or keynav and autoscrolling will not work.
|
|
|
|
| |
We allow it everywhere else, and there is nothing wrong with it.
|
| |
|
| |
|
| |
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=770026
|
|
|
|
|
|
| |
This way these axes may be used in detail by the implementors of pad GActions.
https://bugzilla.gnome.org/show_bug.cgi?id=770026
|
|
|
|
|
|
| |
It might not be entirely clear what the boolean return value means.
https://bugzilla.gnome.org/show_bug.cgi?id=770026
|
|
|
|
|
|
|
|
|
|
|
| |
And rename it to "Touch and Drawing Tablets", since it's no longer about
"axes" really.
As for pad support in the demo, just keep it "simple", make the
controller handle all pad devices, and make all the actions have the
same callback.
https://bugzilla.gnome.org/show_bug.cgi?id=770026
|
|
|
|
|
|
|
| |
This allows applications to provide descriptions of the actions performed
by each pad feature. pass the GtkPadActionEntry labels for this.
https://bugzilla.gnome.org/show_bug.cgi?id=770026
|
|
|
|
|
|
|
|
| |
The wayland tablet protocol allows notifying the compositor with
descriptions of the actions performed by each tablet element. This
API call allows to hook up in to this wayland-specific feature.
https://bugzilla.gnome.org/show_bug.cgi?id=770026
|
|
|
|
|
|
| |
We can return the node path on those too, so do that.
https://bugzilla.gnome.org/show_bug.cgi?id=770026
|
|
|
|
|
|
| |
We now send all the set of button/ring/strip/group_mode events.
https://bugzilla.gnome.org/show_bug.cgi?id=770026
|
|
|
|
|
|
|
|
|
| |
These devices are kind of an strange case. Their "master" device is
the keyboard, because they share toplevel focus with it, regardless
of stylus focus. Nonetheless, they are only expected to send the
GdkEventPad* set of events.
https://bugzilla.gnome.org/show_bug.cgi?id=770026
|
|
|
|
|
|
|
|
| |
This is a subclass of GdkWaylandDevice that implements GdkDevicePad,
all pad features are looked up from the info obtained through the
tablet v2 interface.
https://bugzilla.gnome.org/show_bug.cgi?id=770026
|
|
|
|
|
|
|
| |
All pad interfaces and features are poked, we just now need
exposing those.
https://bugzilla.gnome.org/show_bug.cgi?id=770026
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This GdkEventController is a helper object to handle pad events,
it allows setting a mapping to action names, to be triggered in
the given action group.
In order to help on places where advanced mapping/configurability
of pad features is not desirable, this controller also allows
passing a NULL pad device, meaning it will listen on all pads,
and/or passing -1 on mode/index, so an action applies to all
modes/features (eg. strips/rings).
https://bugzilla.gnome.org/show_bug.cgi?id=770026
|
|
|
|
|
|
| |
No real handling is yet performed, to be done through a GdkEventController
https://bugzilla.gnome.org/show_bug.cgi?id=770026
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is an interface meant to be implemented by the "pad" devices.
This device-specific interface exposes the mapping of all pad features,
it allows retrieving:
- The number of buttons/rings/strips
- The number of groups
- The number of modes a group has
- Whether a given button/ring/strip belongs to a given group
https://bugzilla.gnome.org/show_bug.cgi?id=770026
|
|
|
|
|
|
|
|
|
|
| |
We want the same treatment for those, the event will be emitted on the
toplevel, which will then decide what to do with the event.
It just doesn't make much sense to propagate those up/down the hierarchy,
when we want specifically one action being triggered from those.
https://bugzilla.gnome.org/show_bug.cgi?id=770026
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GDK_PAD_BUTTON*,RING and STRIP will be emitted respectively when
pad buttons, rings or strips are interacted with. Each of those
pad components belong to a group (a pad can contain several of
those), which may be in a given mode. All this information is
contained in the event.
GDK_PAD_GROUP_MODE is emitted when a group in the pad switches
mode, which will generally result in a different set of actions
being triggered from the same buttons/rings/strips in the group.
https://bugzilla.gnome.org/show_bug.cgi?id=770026
|