[LAD] pixmap based knob widgets and theme integration.

Olivier Guilyardi list at samalyse.com
Mon Sep 27 14:57:57 UTC 2010


On 09/27/2010 04:23 PM, Patrick Shirkey wrote:

>> Agreed. IMO, for proper scaling and theme support, the only solution is to
>> draw
>> everything in code, with Cairo for instance.
>>
>> Thus, the most obvious possibility is simplified knobs as those designed
>> by
>> Thorwil, which use very few colors.
>>
>> Another solution, for more graphical knobs, would be to expose specific
>> GTK
>> style properties, which themes would have to explicitly support. That
>> could
>> allow for all sort pretty rendering, with theme-specific gradients and so
>> on.
>>
> 
> Yes it does allow for some more advanced control but if you want to get
> really flash and support scaling without all the hassle of integrating an
> svg handler then afaik with gtk you only have that one option of drawing
> the widgets with code.

I was only talking about drawing with code here, no SVG. I was talking about a
more graphical knob, entirely drawn with Cairo such as the one in ardour3 (see
screenshot in the recent thread about knobs).

The widget performing these drawing operations could expose specific/advanced
style properties to customize gradients. Existing themes would then have to be
patched to support these new properties.

> Doing things like 1px borders is with the internals scaled is entirely
> possible.

Yes, actually, that was my point.

>> One thing though, as you seem to be into gtk engine development, is that
>> IIUC,
>> the whole Cairo idea defeats the general principle of engines which seem
>> to rely
>> on the fact that widgets are drawn with gtk_paint_*() functions. Is this
>> correct?
>>
> 
> IIUC, gtk_paint_*() functions are not needed if you use cairo directly.

I know.

> I'm not sure what you are meaning with the engines in this context though.

My point was that widgets drawn directly with Cairo bypass the gtk_paint_*()
drawing abstraction layer, which would forbid engine to provide their own knob
drawing implementation, as it's done for buttons, etc...

Therefore, such Cairo-based knobs wouldn't support the full GTK theming
capabilities.

> Sorry if it has already been discussed I have just started following this
> discussion.

No, this problem with engines hasn't been discussed yet. It has come to my mind
when thinking about strict GTK compliance. I was asking myself if a such knob
could be candidate for inclusion in mainstream GTK.

> I have become more interested in the possibilities available with drawing
> widgets in cairo though. 3d layering ala blender becomes completely
> possible. With enough time one could even go so far as to have a
> completely 3d or even poly dimensional ui. With buttons and layers all
> over the place responding to different actions. Add in multi touch support
> and things become very interesting for the user. Especially in the context
> of musical performance.
> 
> You are really only limited by your imagination and ability to visualise
> and translate those ideas to the dimensional space.
> 
> The more research I do on how to work quickly with blender and inkscape
> the more possibilities open up in front of me for really impressive ui
> design. I highly recommend taking the time to figure out cairo if you are
> interested in taking ui's to another level. There are many online video
> tutorials for how to use the image tools and they are very enlightening
> from a ui design perspective too. Watching professionals build 3d models
> for example shows me how to recreate the same effect in code.
> 
> Of course there is also opengl for the 3d space too and I feel if enough
> time is spent working with both options there will be some very amazing
> interfaces designed over the next decade now that multi touch is available
> to us all.

Agreed, 3D UIs are interesting. What you're saying makes me think about Clutter
http://www.clutter-project.org/

Clutter renders with OpenGL, provides Cairo, Pango, and supports multi-touch
IIRC. I think it was primarily meant for mobiles devices but this is not
restrictive.

--
  Olivier




More information about the Linux-audio-dev mailing list