Commit Graph

47362 Commits

Author SHA1 Message Date
1f87c1cc0b app: improve code of extract_accels_from_menu()
sub_model is clearer than "m". And we don't use the key, so we can pass
NULL instead.

https://bugzilla.gnome.org/show_bug.cgi?id=764846
2016-04-10 16:54:07 +02:00
687d3eb48f app: use g_set_object()
https://bugzilla.gnome.org/show_bug.cgi?id=764846
2016-04-10 16:54:07 +02:00
29971b0cc9 app: don't use deprecated function
gtk_application_add_accelerator() is deprecated, but was still used
inside IGNORE_DEPRECATIONS's.

https://bugzilla.gnome.org/show_bug.cgi?id=764846
2016-04-10 16:54:07 +02:00
399e8db336 app: improve doc of gtk_application_get_window_by_id()
https://bugzilla.gnome.org/show_bug.cgi?id=764846
2016-04-10 16:54:07 +02:00
40e40b7ffc app: improve doc of gtk_application_set_accels_for_action()
When reading the API for the first time I didn't know what was the
"detailed" action name.

https://bugzilla.gnome.org/show_bug.cgi?id=764846
2016-04-10 16:54:07 +02:00
48afd8a5f0 app: avoid code duplication for setting accels
The implementation of the deprecated functions is now based on the
non-deprecated gtk_application_set_accels_for_action().

https://bugzilla.gnome.org/show_bug.cgi?id=764846
2016-04-10 16:54:06 +02:00
8fc1ca1ef2 Fix gtk_scrollable_get_border annotation
https://bugzilla.gnome.org/show_bug.cgi?id=764540
2016-04-10 15:56:29 +02:00
99e92a60f2 Updated Bulgarian translation 2016-04-10 16:49:27 +03:00
fe80230985 quartz: zoom/rotate change compile/runtime check from 10.7 to 10.8
The zoom/rotate change for quartz does not build on 10.7. This change
adds zoom/rotate support in quartz only for 10.8 and following. The
problems is described here:
https://bugzilla.gnome.org/show_bug.cgi?id=760276 and here
https://trac.macports.org/ticket/51052
NSEventPhaseMayBegin was only introduced in 10.8 although documentation
says it is introduced in 10.7. Tests on 10.7 indicate that the phase
property for the Magnify event is not supported at all on 10.7
2016-04-09 18:05:59 -04:00
7dc588c4d3 Add a note about GDK_AXIS_X/Y
These axes mmay or may not be present, best to ignore them.
2016-04-09 17:38:03 -04:00
0d64582688 wayland: Keyboard don't have x/y
These axes are not very useful in the first place, but on a
keyboard they just don't make any sense at all.
2016-04-09 17:31:39 -04:00
1b0c6e4aa1 Mention geometry handling changes in release notes 2016-04-09 17:04:57 -04:00
abff6e23c0 inspector: simplify some code 2016-04-09 15:48:34 -04:00
9044f78751 Move GdkDeviceTool into its own files 2016-04-09 15:48:34 -04:00
6db7de3f7b app: fix indentation
And add missing curly braces.
2016-04-09 18:54:42 +02:00
af1c873bca inspector: Use GdkAxes instead of GdkAxisUse 2016-04-09 12:14:33 -04:00
d83ad00f9e inspector: Add an origin mark to the slowdown scale
Makes it easier to get back to the original speed.
2016-04-09 11:56:08 -04:00
e6c408c08a inspector: Give the font scale an entry
This matches what Matt did for the slowdown.
2016-04-09 11:56:08 -04:00
b3dc473057 docs: trivial fixes in GtkApplication-related documentation 2016-04-09 09:45:33 +02:00
a970ba5ef6 animatedstyle: don't share styleanimations
Because of our port of css animation and css transition to
progress tracker, we should not think of animated styles as
immutable objects that can map any timestamp to css values.
Rather, timestamps can correspond to different values depending
on the value of GTK_SLOWDOWN over the course of the animation.

To keep animated styles and style animations totally immutable,
we will not share styleanimations between animatedstyles, and
make a new copy of a styleanimation for each timestamp.
2016-04-08 16:09:30 -07:00
7b68bdb831 animatedstyle: just ref current style if timestamp the same 2016-04-08 16:09:30 -07:00
6a88ac3b4c animatedstyle: fail to create new style if timestamp goes backwards
With slowdown factor, we will only we be able to handle timestamps
that monotonically increase.
2016-04-08 16:09:30 -07:00
2800b00e1d cssanimation: port to progress tracker 2016-04-08 16:09:30 -07:00
50e057e025 csstransition: port to progress tracker 2016-04-08 16:09:30 -07:00
511f138328 entry: port to progress tracker 2016-04-08 16:09:30 -07:00
d57ebe2de7 progressbar: port to progress tracker 2016-04-08 16:09:30 -07:00
5237b7a6b0 scrolledwindow: port indicator fade to progress tracker 2016-04-08 16:09:30 -07:00
dc8b80cd32 popover: port to progress tracker 2016-04-08 16:09:30 -07:00
7ad64a20aa switch: port to progress tracker 2016-04-08 16:09:30 -07:00
2ff62595ed revealer: port to progress tracker 2016-04-08 16:09:30 -07:00
62b224a8df stack: skip first frame for animations
Not the ideal solution for this problem, but in practice leads to
much better performance on lower end hardware.

Stack does a double draw on the first frame of its animation, of
both the old contents (into a cairo surface) and the new contents.
Homogeneous stacks only need to reallocate contents on the first
frame.

On lower powered hardware where our frames will be a good deal
slower than the refresh rate anyway, we can assure a smother
experience by waiting a frame to start tweening where frame duration
will be more consistent.
2016-04-08 16:09:30 -07:00
3909f818c4 stack: port to progress tracker 2016-04-08 16:09:30 -07:00
46b120b35e inspector: add slider to control slowdown factor 2016-04-08 16:09:29 -07:00
f2979323bf progresstracker: add GTK_SLOWDOWN environment variable
As we consolidate widgets to use progress tracker, this will allow
us to control the speed of all animations in a centralized place
2016-04-08 16:09:29 -07:00
e71d09e9cb progresstracker: simple struct to track animation progress 2016-04-08 16:09:29 -07:00
f1cbd9ca13 demos: Show slider/rotation axes in "Event axes" demo 2016-04-08 17:34:29 +02:00
057ae4ace0 wayland: Propagate slider/rotation axes from tools to devices 2016-04-08 17:34:29 +02:00
b3ca11a6cb test: do not remove files on distclean
bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=764686
2016-04-08 17:00:12 +02:00
83e775147f wayland: do not update shadows for child windows
glade-previewer places a gtkwindow inside another toplevel gtkwindow,
updating the shadow width for the client induces a busy loop where the
parent will grow continuously until it crashes gnome-shell/mutter.

To avoid the loop, do not update the shadow width if not dealing with a
toplevel window.

Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=761651
2016-04-08 16:59:36 +02:00
d3a3d0673f gdkevents: Fix GDK_AVAILABLE_IN annotation
These functions have just been added. An oversight prior to merging
wayland tablet.
2016-04-08 15:09:36 +02:00
6628ffd686 wayland: Check the tablet manager before creating a wp_tablet_seat
This makes things non-crashy if the compositor doesn't provide wp_tablet_manager
2016-04-06 17:29:11 +02:00
48239ad720 gtk3-demo: Add tool information to "Event axes" demo
Print tool type and serial, if found.
2016-04-06 16:12:13 +02:00
cd1604ae1c wayland: Hook tablets to GdkSeat
Those are now also grabbed togetther with other master pointers,
so everything is able to interoperate on eg. popups triggered by
other devices.
2016-04-06 16:12:13 +02:00
fb32f11e3d wayland: Translate pen buttons into button events
up/down already take GDK_BUTTON_PRIMARY, we translate BTN_STYLUS(2)
into GDK_BUTTON_MIDDLE/SECONDARY.
2016-04-06 16:12:12 +02:00
4f6bc82052 Wayland: Translate wl_tablet.down/up into button events
These are sent with button=GDK_BUTTON_PRIMARY, axes must be also
included in these events, in addition to motion ones.
2016-04-06 16:12:12 +02:00
0f6be24e28 Wayland: Translate tool axes in motion events
On wayland, such axes are per-tool, we must update device capabilities
on the fly as new tools enter proximity, first the slave device so
it matches the current tool, and then the master device so it looks
the same than the current slave device.
2016-04-06 16:12:12 +02:00
72884a274c Wayland: Implement proximity/crossing/motion event emission on tablets
Each tablet will update its own GdkWaylandPointerData separately. This
commit only adds plain motion event emission so far, no axes are managed
yet.
2016-04-06 16:12:12 +02:00
7cc0850a5a Wayland: Add initial support for drawing tablets
Only the management of tablets and tools is added so far. No tablet events
are yet interpreted.

As it's been the tradition in GTK+, erasers are split into their own device,
whereas the rest of the tools are meant to be routed through the
GDK_SOURCE_PEN device. Both pen/eraser devices are slaves to a master
pointer device, separate to wl_pointer's. This is so each tablet can
maintain its own cursor/positioning accounting.

Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
2016-04-06 16:12:12 +02:00
d4d032795d build: Bump wayland-protocols dependency to 1.3
Needed for tablet support
2016-04-06 16:12:12 +02:00
45b4d765c0 wayland: Refactor master pointer data into a separate struct
This will enable multiple "pointers" to have separate data here.
Will come out useful when adding support for tablets, as they
will have a separate cursor for all purposes.
2016-04-06 16:12:12 +02:00