[LAD] pixmap based knob widgets and theme integration.

[pete shorthose]

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.

>   When it came to supporting
> themes, it was all about vector drawing, especially with Cairo.
>
> [...]
>
>    
>>> another possibility that was briefly discussed for use with
>>> phat was that of a composite widget with different layers that
>>> could be drawn separately, one on top of the other. eg render an SVG
>>> or pixmap as a background on the first pass, then draw something
>>> with cairo (a value indicator..) on top.
>>>        
> Yes, I did mention this SVG idea, but it was pointed out that it won't work
> because some lines/borders need to be 1px or so, no matter what the scale factor is.
>
> [...}
>
>    
>>> there are obvious limits to what you can achieve with this kind of
>>> thing,
>>>        
>> Like what exactly? Pretty much only what the mind can think of. Anything
>> you can achieve in inkscape or gimp will be possible with cairo. That is
>> much more than most widgets will ever need.
>>      
> Agreed. 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.

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.

for the time being, i'm sticking with pixmaps and blender.
> 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.
> 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.

cheers,
pete.