On Thu, Sep 27, 2012 at 1:56 PM, Ping Cheng <pingli...@gmail.com> wrote: > On Thu, Sep 27, 2012 at 2:32 AM, Olivier Fourdan <ofour...@redhat.com> wrote: >> Hi all, >> >> We have been discussing the need for an OSD window for some time. >> >> For GNOME, I made a simple implementation (see bug 679062 [1]) which seems >> to works quite well, but could be greatly improved with a more accurate >> representation of the actual device. >> >> I believe the requirements would be: >> >> * Format should allow for rotation along with the tablet orientation, and >> scale to match monitor's geometry >> * Button should change aspect when pressed (so a static image is not >> sufficient) >> * Description should be generic enough so that it can be (re)used in >> different apps/desktops if necessary >> * Description should include at the very least the button name matching the >> libwacom's buttonsX denomination, position, size and label location >> >> Expectations: >> >> * Keep it simple for developers to implement the code, >> * Keep it simple for artists to contribute new buttons/layouts when needed >> >> In the past we discussed the possibility to use the following formats for >> that representation: >> >> * json (http://www.json.org/) >> pro: fairly common and standard >> cons: not necessarily natural for artists >> * xkb_layout format >> pro: already have a sample impl, in GNOME for keyboard layouts >> cons: not exactly a standard and even less natural for artists >> >> Possible solution: >> >> * A set of buttons in SVG format - SVG in vector graphics so it can be >> easily scaled/rotated and can be modified using CSS (see gtk+ symbolic >> icon's routine) so it should be possible to create an image of the same >> button being pressed. >> * Tablet definitions include a description of the buttons present on the >> device which includes: >> >> - Button name >> - Button position >> - Button size >> - Label position >> - Button image (is name of the corresponding SVG file) >> >> Advantage: >> >> * When different models of the same type of tablet use the same buttons, no >> need to recreate the SVG images, >> * The same SVG image of e.g. touchring button can be resused in a popup >> small OSD showing current mode when changing mode. >> * If someone does a purely symbolic representation fo the buttons, the SVG >> images could be simply ignored: From the button name, an apps can get the >> flags, deduce if it's a regular button, a toushstrip or a touch ring, its >> size and thus draw accordingly without even using the SVG image. >> >> Question: >> >> * Does any of the above makes sense? ;-) > > Yes, it makes sense to me. I have no Gnome design or impl experience. > So, I can not tell which format is better. But your OSD video looks > good. > > Can I assume? > > 1. OSD can and will be enabled for tablets with and without LED, as > long as the tablet supports expresskeys; > > 2. OSD can be disabled in g-c-c; > >> * Is it simple enough? Or too simplistic? > > I like simple solutions. > >> * Is SVG appropriate for that? Do we actually need an accurate image of the >> buttons? > > The images displayed in your video are very good. We know if they are > for the square or round buttons. > >> * Assuming it makes sense, what unit should be used for the position/size of >> elements? > > I guess it depends on the size of the screen? For opaque tablets, such > as Intuos and Bamboo series, your video of mapping it to the > screen/primary monitor is very good. For LCD tablets, such as Cintiq > series, OSD would be displayed close to the actual buttons, I think. > >> * Should the representation be per tablet, or per side of tablet, ie one >> description for the left buttons with their relative position, same for >> right, top, etc? > > Per side of tablet since users would most likely use different > settings for different side. Talking about per side, rotation should > be considered for all sides if there are more than one set of buttons. > >> I would really like to move forward with this, while at the same time >> keeping things simple enough. > > I am with you. I hope we can get something simple and straightforward > in Gnome soon. > > Ping > > BTW, this code from [1] does not fit what I understood > > + * - First ring (group 0) uses LED 0 > + * - Second ring (group 1) uses LED 1 > + * - First touchstrip (group 2) uses LED 1 > + * - Second touchstrip (group 3) uses LED 0 > > There are two cases, tablet has one set of expresskeys; and tablet > has two sets of expresskeys. > > If there is only one set of expresskeys, ring or touchstrip will and > can only use LED 0; > If there are two sets of expresskeys, the left set (i.e., your first > ring/touchstrip) uses LED 1; the right set, your second > ring/touchstrip, uses LED 0. > > [1] https://bugzilla.gnome.org/attachment.cgi?id=214732&action=edit
Not to get off-topic, but do we want to consider revising this interface to make it more logical? Having the "first" ring/strip being controlled by the "second" LED control (and vice versa) rubs me the wrong way. I'd consider it a bug, except that its the documented behavior. I'm not sure it qualifies as a "grave error" that Dmitry would allow to be changed, but it'd make more sense to fix it in the kernel than to rely on libwacom to describe the quirk. Jason --- When you're rife with devastation / There's a simple explanation: You're a toymaker's creation / Trapped inside a crystal ball. And whichever way he tilts it / Know that we must be resilient We won't let them break our spirits / As we sing our silly song. ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
