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

From: Patrick Shirkey <pshirkey@email-addr-hidden>
Date: Mon Sep 27 2010 - 14:44:56 EEST

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)
>
> there are a couple of ways that you might achieve this.
> the crux gtk theme engine includes some pixmap recolouring code
> (or used to at any rate). it recolours areas of a pixmap that
> only contain green values to one specified in the gtkrc.
> this might conceivably be stolen and incorporated
> to provide some measure of theme conformance for pixmap
> based widgets (knobs wheels and potentially sliders).
>
> this method places specific constraints on the source pixmaps used,
> constraints that are easily adhered to when creating pixel art
> (which the crux pixmaps were) but procedurally generated rasters
> (vector or 3d renders) of the kind that are likely to be used with
> a pixmap widget might pose more of a problem since lighting and
> anti aliasing probably induce a variety of colours.
> still, i expect you could get something to work with a bit of effort.
> (imagemagick or scriptfu in the gimp may help there).
>
> 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.
>

Well I have found that this will only work with recent gtk (it may have
been fixed by now) if the widget is not being updated often. There was a
memory bug in wither the font or vector functions when drawing text on top
of a dynamically rendered and frequently updated layer.

There are ways around this but they require a bit of flexibility and I
didn't have the time when I was working on my code to figure it out. One
of the methods would have just minimised the bug but not actually fixed
it. That required redrawing only the parts of the widget that need to be
updated.

> 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.

> but you could get some complex effects on a knob while still
> maintaining procedural control over the size, colour and shape of the
> vector elements. (tick marks around the knob, value indicator size
> and colour etc). IIRC we discarded the idea due to it's complexity.
> we wanted a generally configurable knob and the vector elements would
> need anything from extensive widget options right up to a full blown
> markup language to describe them (not a problem for app specific
> widgets).
>

Drawing with cairo is pretty easy once you get the hang of it. It helps if
you have some working knowledge of gimp or inkscape so you can visualise
the steps required to create the effects. Do you have examples of the kind
of visuals were you interested in creating?

-- 
Patrick Shirkey
Boost Hardware Ltd.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Mon Sep 27 16:15:01 2010

This archive was generated by hypermail 2.1.8 : Mon Sep 27 2010 - 16:15:02 EEST