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? ;-) Seems logical enough. There's some hand-waving going on regarding the tablet definition language that needs to be sorted out though. Describing where and how large physical elements are sounds awfully like UI layout, so it may make sense to make use of languages that already exist for that purpose.
> * Is it simple enough? Or too simplistic? For the moment, I don't see any problems. But don't underestimate the flexibility requirements. For example, the Cintiq 21UX2 has its touch strips located on the *back* of the tablet. You may run into problems describing the 3D position of elements with most 2D layout languages. > * Is SVG appropriate for that? Do we actually need an accurate image of the > buttons? We probably don't need accurate button images and could get away with simplified representations created "directly" from the tablet definition. I wouldn't be against having something a little less symbolic though :) > * Assuming it makes sense, what unit should be used for the position/size of > elements? This kinda gets at the tablet definition language issues I was mentioning. Using a flat file with real-world units (e.g. centimeters) would be adequate to describe most anything, but would probably be hard to quickly write. Using an XML file could allow you to quickly describe things in relative terms, but would probably be more verbose when trying to get the layout "perfect". > * 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? > I would probably represent the whole tablet. The symmetries are there, but I don't know if it'd be worth the programming work necessary to allow their description. It'd be more worth it to allow partial descriptions to be "included" into tablet definitions (e.g. describe the Intuos3 button layout once, and then include it twice in a half-dozen files), but I still don't know if it'd be enough. > 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. ------------------------------------------------------------------------------ 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
