On Thu, Sep 27, 2012 at 11:32:48AM +0200, Olivier Fourdan 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? ;-) > * Is it simple enough? Or too simplistic? > * Is SVG appropriate for that? Do we actually need an accurate image > of the buttons?
I think SVG should work well here. > * Assuming it makes sense, what unit should be used for the > position/size of elements? if you're talking about the tablet description, mm from the tablet origin in standard rotation, with the total size of the tablet provided as well. everything else is then scaling that needs to be done by the renderer. since we're describing a physical tablet, we don't really have any other options than mm. > * 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? There are quite a few tablets, but I would worry about introducing features that are prone to errors. Let each tablet be describe as-is in one file without the need for includes or more complex merging and you're more likely to get clients to get it right. from a pure file-maintainance point of view, button sets that are consistent across a model series can be maintained as separate and merged into the final description file (the one clients would use) on install. having said that, my SVG and SVG renderer knowledge is limited, so all this may be easier than I thought anyway. Cheers, Peter > > I would really like to move forward with this, while at the same > time keeping things simple enough. > > [1] https://bugzilla.gnome.org/show_bug.cgi?id=679062 > > Cheers, > Olivier. ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
