27 Sep
2010
27 Sep
'10
7:41 p.m.
On 09/27/2010 06:30 PM, pete shorthose wrote:
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.
Knob plugins, that sounds like a lot of overhead/complexity..
Well, that's quite what I thought. It really looks like knobs aren't
engine-friendly anyway.
--
Olivier
On 27/09/10 14:46, Olivier Guilyardi wrote:
Yes, maybe, but sorry that doesn't sound like a viable option to me.
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. 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.
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. 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.