- Jun 24, 2016
-
-
Carlos Garnacho authored
This code is going from g-s-d, the remaining bits should be adopted by g-c-c.
-
Carlos Garnacho authored
It is now entirely unused.
-
Carlos Garnacho authored
So it works again.
-
Carlos Garnacho authored
So it can be used in test-wacom
-
Carlos Garnacho authored
-
Carlos Garnacho authored
Some improvements to fit better with the new design: - "no configured ..." page for both stylus/tablet sections - the navigation buttons are now children of GtkRevealers, so size doesn't popup - Empty placeholder in several containers have been removed.
-
Carlos Garnacho authored
The "area" setting has a different treatment in the gsettings-desktop-schemas tablet schema, the 4 double values express the padding (in unitless 0..1 range) on each of the sides of the tablet. It's been done so we don't rely on input/output units, which we might have not the luxury to access. Besides that, the dependency on GsdWacomDevice has been cleared.
-
Carlos Garnacho authored
-
Carlos Garnacho authored
-
Carlos Garnacho authored
This feature now belongs in gnome-shell, not g-s-d. The D-Bus API changed correspondingly.
-
Carlos Garnacho authored
We now use the CcWacomDevice API for this.
-
Carlos Garnacho authored
This function retrieves the GSettings pointing to the configuration of the given button, or NULL if not found.
-
Carlos Garnacho authored
Uses libwacom underneath.
-
Carlos Garnacho authored
We now only care of pad buttons, so this code can be quite simplified.
-
Carlos Garnacho authored
-
Carlos Garnacho authored
The set of actions that can be mapped to an stylus button have been reduced, due to inconsistent semantics in wayland.
-
Carlos Garnacho authored
There's much going on under the hood here: - Styli and tablets are now in split views, as per the mockups. - CcWacomDevice and CcWacomTool are now in use, with the subsequent API use changes. Moreover, using these objects means using the newer schemas in gsettings-desktop-schemas, so there had to be changes in the settings we store too. - We now use CcTabletToolMap, plus listen to tool proximity events, populating the "Stylus" sub-pane with those.
-
Carlos Garnacho authored
This can only be used for tablets that are not display nor system integrated (eg. intuos models). The mapping of tablets with a builtin display remain in g-s-d/GsdDeviceMapper.
-
Carlos Garnacho authored
In the wayland tablet input model, compositor and clients may recognize the different physical styli in use, even if those are used across compatible tablets. This object is intended to be used as a persistent memory of which stylus was used with which tablet. So you 1) can associate tools and devices when such combination happens, and 2) query the styli that were previously used with a tablet when it is detected/ plugged. These associations are stored in two keyfiles in ~/.cache/gnome-control-center/wacom/, one for tablets and other for styli.
-
Carlos Garnacho authored
-
Carlos Garnacho authored
So we can recognize pad devices.
-
Carlos Garnacho authored
-
Carlos Garnacho authored
-
Carlos Garnacho authored
Now that we have tablet support in wayland, we can kind of honor that in the places we're interested.
-
Carlos Garnacho authored
Similar to CcWacomDevice vs GsdWacomDevice, CcWacomTool is meant to replace the GsdWacomStylus object. There is a substantial difference between these two objects, CcWacomTool offers constructor methods, it expects the caller to maintain lifetime otherwise. while GsdWacomStylus objects creation was rather fixed (GsdWacomDevice created all possible styli on initialization). This latter model doesn't help us use all the possibilities wrt wayland configurability.
-
Carlos Garnacho authored
This is a vast oversimplification of GsdWacomDevice. This one has code that is largely unnecessary here (mostly devised for g-s-d), plus it will be even eventually removed from g-s-d (the functionality is moving into compositor domain), so the code sharing argument remains pretty weak. So, CcWacomDevice is thought to take over, just offering the basic API we after all need in the gnome-control-center side.
-
Carlos Garnacho authored
A popover with a CcDrawingArea appears in that case.
-
Carlos Garnacho authored
This is a testing drawing widget that can be used to the a feeling of changes to stylus settings.
-
Carlos Garnacho authored
If the current panel requests setting a custom widget, honor that and place those in the headerbar.
-
Carlos Garnacho authored
If the current panel requests setting a custom widget, honor that and place those in the headerbar.
-
Carlos Garnacho authored
So the panel implementations will be able to set a custom widget in the shell headerbar. It defaults to NULL, so by default headerbars set the plain label with the panel title.
-
Bastien Nocera authored
Now that there's only one type to be added (VPNs). https://bugzilla.gnome.org/show_bug.cgi?id=767614
-
Bastien Nocera authored
We still offered to add Bond, Team, Bridge and VLAN connections even though we don't support them any more. Remove the first page as we only offer to add VPN connections. https://bugzilla.gnome.org/show_bug.cgi?id=767614
-
Bastien Nocera authored
The VPN editor API changed as well. https://bugzilla.gnome.org/show_bug.cgi?id=767614
-
Bastien Nocera authored
The listing of VPN plugins was done using the nm-glib API instead of the new libnm 1.2 one. https://bugzilla.gnome.org/show_bug.cgi?id=767614
-
Felipe Borges authored
According to the mockups at https://wiki.gnome.org/Design/SystemSettings/UserAccounts https://bugzilla.gnome.org/show_bug.cgi?id=767065
-
-
-
- Jun 21, 2016
-
-
Use PpPrinter class for renaming printer asynchronously. https://bugzilla.gnome.org/show_bug.cgi?id=761539
-
Introduce new class that represents printer. https://bugzilla.gnome.org/show_bug.cgi?id=761539
-