Re: [LAD] pixmap based knob widgets and theme integration.

From: Olivier Guilyardi <list@email-addr-hidden>
Date: Mon Sep 27 2010 - 20:41:21 EEST

On 09/27/2010 06:30 PM, pete shorthose wrote:
> On 27/09/10 14:46, Olivier Guilyardi wrote:
>> On 09/27/2010 01:44 PM, Patrick Shirkey wrote:
>>
>>> On Sun, September 26, 2010 1:35 pm, pete shorthose wrote:
>>>
>>>> WRT the recent discussion about pixmap knob widgets and theme
>>>> conformance (that i can't reply to since i wasn't on the list
>>>> at the time, sorry)
>>>>
>> AFAICS, no one mentioned themable pixmap knobs.
>
> not in the same breath, no. i read the archive on the web recently and
> just remembered pixmap
> knobs and theme conformance being mentioned.
> thought i'd point out that it might be possible to theme pixmaps to some
> extent.

Yes, maybe, but sorry that doesn't sound like a viable option to me.

>> IMO, for proper scaling and theme support, the only solution
>> is to draw
>> everything in code, with Cairo for instance.
>>
>
> you can do some nice things with vector gfx. the trend in interface
> aesthetics has been away from gratuitous eyecandy
> for a while anyway. i don't personally like fully abstract 2D UIs with
> floating elements though. it seems to me that we are
> optimised to process 3D objects in the real world and that we can make
> use of that to aid the navigation of virtual
> interfaces by implementing them as distinct objects with an internally
> consistent, psuedo 3d geometry.
> which doesn't need fake screws, vents, scratches and the like. it seems
> NI and apple would agree if you look at
> their recent designs.

That's an interesting point. I generally tend to dislike (and disapprove)
virtual reality, that is: digital systems trying to behave like (and thus
replace) real phenomenons and objects.

The fact that a UI can remind the user of real world objects doesn't mean that
it should look and feel realistic. I think this can actually be confusing. The
computer screen is not reality, but it can symbolize some elements that are
familiar to the user. That can help.

I personally quite like the abstract 2D UIs. But, abstract/allegoric 3D
interfaces should be possible too, without all the screws as you mention.

> if cairo is unaccelerated, it's gonna be more expensive though. phasex
> had performance problems with just pixmap knobs
> when it received a global expose event. some of that was mitigated via
> backingstore (on supporting Xorg setups)
> but if you consider the effects of automation, all those knobs whizzing
> around... if you are going with a complex
> vector design and are not going to quantize and cache frames, you might
> want to profile the results.

Good point..

> for the time being, i'm sticking with pixmaps and blender.

Actually, I don't have anything against pixmaps. I just find them off-topic when
it comes to theming (except maybe if themes bundled some knob pixmaps..)

The thing that could have been extremely useful to me in the past is to have an
SVG source to work on, something well designed and meant to be quickly
customized by developers. This SVG file + a set of scripts to generate the knob
frames could allow developers to customize their app, give it some personality.

Actually, the SVG file isn't so much needed. A python script could draw the
frames with Cairo, and dump the result into the frames pixmap used by the
PhatKnob. This script could accept arguments for the size, color gradients, etc...

>> 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.
>>
> i mentioned knob plugins in my last post. which could work like theme
> engines for the knob. which isn't properly
> catered for by theme engine primitives.

Knob plugins, that sounds like a lot of overhead/complexity..

>> 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?
>>
>>
> fraid not. cairo serves as a replacement for the underlying draw
> functions, but the theme engines draw more than simple lines.
> the style is implemented IN the engine and modified (to some extent) and
> applied by the gtkrc that uses it. cairo just draws
> what it's told to.

Well, that's quite what I thought. It really looks like knobs aren't
engine-friendly anyway.

--
  Olivier
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Tue Sep 28 00:15:01 2010

This archive was generated by hypermail 2.1.8 : Tue Sep 28 2010 - 00:15:01 EEST