27 Sep
2010
27 Sep
'10
6:30 p.m.
On 27/09/10 14:46, Olivier Guilyardi wrote:
On 09/27/2010 01:44 PM, Patrick Shirkey wrote:
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.
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. When it came to supporting
themes, it was all about vector drawing, especially with Cairo.
[...]
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.
> 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.
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.