26 Sep
2010
26 Sep
'10
10:35 p.m.
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.
there are obvious limits to what you can achieve with this kind of
thing, 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).
cheers,
pete.
27 Sep
27 Sep
1:44 p.m.
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.
3:46 p.m.
On 09/27/2010 01:44 PM, Patrick Shirkey wrote:
Agreed. IMO, for proper scaling and theme support, the only solution is to draw
everything in code, with Cairo for instance.
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.
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?
--
Olivier
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.
[...]
> 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.
4:23 p.m.
On Mon, September 27, 2010 6:46 am, Olivier Guilyardi wrote:
On 09/27/2010 01:44 PM, Patrick Shirkey wrote:
Agreed. IMO, for proper scaling and theme support, the only solution is to
draw
everything in code, with Cairo for instance.
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.
Yes it does allow for some more advanced control but if you want to get
really flash and support scaling without all the hassle of integrating an
svg handler then afaik with gtk you only have that one option of drawing
the widgets with code.
Doing things like 1px borders is with the internals scaled is entirely
possible.
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.
[...]
> 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. 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?
IIUC, gtk_paint_*() functions are not needed if you use cairo directly.
I'm not sure what you are meaning with the engines in this context though.
Sorry if it has already been discussed I have just started following this
discussion.
I have become more interested in the possibilities available with drawing
widgets in cairo though. 3d layering ala blender becomes completely
possible. With enough time one could even go so far as to have a
completely 3d or even poly dimensional ui. With buttons and layers all
over the place responding to different actions. Add in multi touch support
and things become very interesting for the user. Especially in the context
of musical performance.
You are really only limited by your imagination and ability to visualise
and translate those ideas to the dimensional space.
The more research I do on how to work quickly with blender and inkscape
the more possibilities open up in front of me for really impressive ui
design. I highly recommend taking the time to figure out cairo if you are
interested in taking ui's to another level. There are many online video
tutorials for how to use the image tools and they are very enlightening
from a ui design perspective too. Watching professionals build 3d models
for example shows me how to recreate the same effect in code.
Of course there is also opengl for the 3d space too and I feel if enough
time is spent working with both options there will be some very amazing
interfaces designed over the next decade now that multi touch is available
to us all.
--
Patrick Shirkey
Boost Hardware Ltd.
4:58 p.m.
On 09/27/2010 04:23 PM, Patrick Shirkey wrote:
I was only talking about drawing with code here, no SVG. I was talking about a
more graphical knob, entirely drawn with Cairo such as the one in ardour3 (see
screenshot in the recent thread about knobs).
The widget performing these drawing operations could expose specific/advanced
style properties to customize gradients. Existing themes would then have to be
patched to support these new properties.
I know.
Agreed. IMO,
for proper scaling and theme support, the only solution is to
draw
everything in code, with Cairo for instance.
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.
Yes it does allow for some more advanced control but if you want to get
really flash and support scaling without all the hassle of integrating an
svg handler then afaik with gtk you only have that one option of drawing
the widgets with code. Doing things like 1px borders is with the internals
scaled is entirely
possible.
Yes, actually, that was my point.
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?
IIUC, gtk_paint_*() functions are not needed if you use cairo directly. I'm not sure what you are meaning with the engines
in this context though.
My point was that widgets drawn directly with Cairo bypass the gtk_paint_*()
drawing abstraction layer, which would forbid engine to provide their own knob
drawing implementation, as it's done for buttons, etc...
Therefore, such Cairo-based knobs wouldn't support the full GTK theming
capabilities.
Sorry if it has already been discussed I have just
started following this
discussion.
No, this problem with engines hasn't been discussed yet. It has come to my mind
when thinking about strict GTK compliance. I was asking myself if a such knob
could be candidate for inclusion in mainstream GTK.
I have become more interested in the possibilities
available with drawing
widgets in cairo though. 3d layering ala blender becomes completely
possible. With enough time one could even go so far as to have a
completely 3d or even poly dimensional ui. With buttons and layers all
over the place responding to different actions. Add in multi touch support
and things become very interesting for the user. Especially in the context
of musical performance.
You are really only limited by your imagination and ability to visualise
and translate those ideas to the dimensional space.
The more research I do on how to work quickly with blender and inkscape
the more possibilities open up in front of me for really impressive ui
design. I highly recommend taking the time to figure out cairo if you are
interested in taking ui's to another level. There are many online video
tutorials for how to use the image tools and they are very enlightening
from a ui design perspective too. Watching professionals build 3d models
for example shows me how to recreate the same effect in code.
Of course there is also opengl for the 3d space too and I feel if enough
time is spent working with both options there will be some very amazing
interfaces designed over the next decade now that multi touch is available
to us all.
Agreed, 3D UIs are interesting. What you're saying makes me think about Clutter
http://www.clutter-project.org/
Clutter renders with OpenGL, provides Cairo, Pango, and supports multi-touch
IIRC. I think it was primarily meant for mobiles devices but this is not
restrictive.
--
Olivier
28 Sep
28 Sep
7:28 a.m.
Am Montag, den 27.09.2010, 16:57 +0200 schrieb Olivier Guilyardi:
My point was that widgets drawn directly with Cairo
bypass the
gtk_paint_*()
drawing abstraction layer, which would forbid engine to provide their
own knob
drawing implementation, as it's done for buttons, etc...
Therefore, such Cairo-based knobs wouldn't support the full GTK
theming
capabilities.
In Gtk+3 many GDK functions are replaced by cairo.
gtk_widget_draw() will take any cairo surface then.
http://live.gnome.org/GnomeGoals/GTKRenderingCleanup
1 p.m.
On 09/28/2010 07:28 AM, hermann wrote:
Am Montag, den 27.09.2010, 16:57 +0200 schrieb Olivier
Guilyardi:
Okay, it says "All GtkStyle drawing functions (gtk_paint_box(), etc) have been
changed to take a #cairo_t instead of a window and a clip area. ::draw
implementations will usually just use the cairo context that has been passed in
for this."
I'm not a gtk engine wizard, but the problem is still here IIUC.
If you draw directly with Cairo within your widget, your bypass the drawing
"driver" layer, for example used by ClearLooks which overloads the old
gtk_draw_*() functions in clearlooks_style_class_init():
http://clearlooks.cvs.sourceforge.net/viewvc/clearlooks/clearlooks/src/clea…
Whether gtk or a specific engine draw internally with Cairo or not doesn't
change the situation.
I suppose that the only solution would be to add some knob drawing primitives to
the GtkStyle class itself. That would allow gtk engines developers to provide
their own knob drawing implementation, and also separate the rendering code from
the knob logic.
But that might be a lot of trouble.
--
Olivier
My point was that widgets drawn directly with
Cairo bypass the
gtk_paint_*()
drawing abstraction layer, which would forbid engine to provide their
own knob
drawing implementation, as it's done for buttons, etc...
Therefore, such Cairo-based knobs wouldn't support the full GTK
theming
capabilities.
In Gtk+3 many GDK functions are replaced by cairo.
gtk_widget_draw() will take any cairo surface then.
http://live.gnome.org/GnomeGoals/GTKRenderingCleanup
1:59 p.m.
On Tue, September 28, 2010 4:00 am, Olivier Guilyardi wrote:
On 09/28/2010 07:28 AM, hermann wrote:
There is a couple of things about knobs that don't translate well to a
mouse and are still fairly cumbersome with multitouch.
I can't get away from the feeling that knobs on a screen are as bad as
screws. They just don't translate intuitively.
Wouldn't it be more productive to find ways to make sliders more visually
expressive?
They are perfectly suited to a single point cursor and multi touch.
For example instead of a knob why not have an inset light strip in the
shape of a half circle? ie. a curved slider. It will take up as much space
as a knob but can be easily manipulated with mouse or finger.
With a 3d space sliders can be made to do some amazing things. In addition
there are other control options that become available like pinch, tap,
swipe and shake gestures.
Why constrain ourselves to a concept we know is a pain for the user if it
is also gonna be a pain for the developer to implement? If we are going to
go to all that trouble why not make it something the user will truly
appreciate and increase their productivity.
--
Patrick Shirkey
Boost Hardware Ltd.
Am Montag, den 27.09.2010, 16:57 +0200 schrieb
Olivier Guilyardi:
Okay, it says "All GtkStyle drawing functions (gtk_paint_box(), etc) have
been
changed to take a #cairo_t instead of a window and a clip area. ::draw
implementations will usually just use the cairo context that has been
passed in
for this."
I'm not a gtk engine wizard, but the problem is still here IIUC.
If you draw directly with Cairo within your widget, your bypass the
drawing
"driver" layer, for example used by ClearLooks which overloads the old
gtk_draw_*() functions in clearlooks_style_class_init():
http://clearlooks.cvs.sourceforge.net/viewvc/clearlooks/clearlooks/src/clea…
Whether gtk or a specific engine draw internally with Cairo or not doesn't
change the situation.
I suppose that the only solution would be to add some knob drawing
primitives to
the GtkStyle class itself. That would allow gtk engines developers to
provide
their own knob drawing implementation, and also separate the rendering
code from
the knob logic.
But that might be a lot of trouble.
My point was that widgets drawn directly with
Cairo bypass the
gtk_paint_*()
drawing abstraction layer, which would forbid engine to provide their
own knob
drawing implementation, as it's done for buttons, etc...
Therefore, such Cairo-based knobs wouldn't support the full GTK
theming
capabilities.
In Gtk+3 many GDK functions are replaced by cairo.
gtk_widget_draw() will take any cairo surface then.
http://live.gnome.org/GnomeGoals/GTKRenderingCleanup
3:35 p.m.
On 09/28/2010 01:59 PM, Patrick Shirkey wrote:
There is a couple of things about knobs that don't
translate well to a
mouse and are still fairly cumbersome with multitouch.
I can't get away from the feeling that knobs on a screen are as bad as
screws. They just don't translate intuitively.
Well, I recently tried the TouchOSC iPhone app, which allows you to build custom
UIs by assembling knobs, sliders, buttons, etc... and assign them to OSC messages.
The knobs are just brilliant, it's very intuitive I think. It's touch though,
not multi-touch.
Wouldn't it be more productive to find ways to
make sliders more visually
expressive?
An interface full of sliders can be confusing and ugly. Knobs + sliders, that
brings balance I believe.
They are perfectly suited to a single point cursor and
multi touch.
For example instead of a knob why not have an inset
light strip in the
shape of a half circle? ie. a curved slider. It will take up as much space
as a knob but can be easily manipulated with mouse or finger.
Isn't that what Thorwil's designs, already discussed, propose? They precisely
are circular sliders *and* level meters. The exact same thing goes with TouchOSC.
With a 3d space sliders can be made to do some amazing
things. In addition
there are other control options that become available like pinch, tap,
swipe and shake gestures.
Pinching... That's interesting. But pinching usually requires a large
widget/element, such as a photo, web page. If the widget is too small, you won't
get as much precision as a single-touch slider, be it circular or linear.
Why constrain ourselves to a concept we know is a pain
for the user if it
is also gonna be a pain for the developer to implement? If we are going to
go to all that trouble why not make it something the user will truly
appreciate and increase their productivity.
Yes, but the productivity of a musician isn't only about tools efficiency. It's
also about inspiration, which isn't necessary rational. That said I agree with
you about innovation, a creative UI might exactly be what a creative person need.
Actually, I work a lot on Android these days, and I reckon there's lot of new
possibilities with touch interfaces. And that's right, do this with a 3D scene,
and now you got something :)
--
Olivier
4:15 p.m.
On Tue, September 28, 2010 6:35 am, Olivier Guilyardi wrote:
It doesn't have to be. You just need to start with at least one point on
the widget. In fact it could work well with a mouse too.
The widget could look something like a circle with a cross in it. When you
click and drag up the cross opens up and when you click and drag down the
cross closes. This would provide a circular image with a
rectangular/slider single axis movement.
Yes, I'm drooling at the possibilites ;-)
--
Patrick Shirkey
Boost Hardware Ltd.
On 09/28/2010 01:59 PM, Patrick Shirkey wrote:
I missed the earlier discussion, sorry.
There is a couple of things about knobs that
don't translate well to a
mouse and are still fairly cumbersome with multitouch.
I can't get away from the feeling that knobs on a screen are as bad as
screws. They just don't translate intuitively.
Well, I recently tried the TouchOSC iPhone app, which allows you to build
custom
UIs by assembling knobs, sliders, buttons, etc... and assign them to OSC
messages.
The knobs are just brilliant, it's very intuitive I think. It's touch
though,
not multi-touch.
Wouldn't it be more productive to find ways
to make sliders more
visually
expressive?
An interface full of sliders can be confusing and ugly. Knobs + sliders,
that
brings balance I believe.
They are perfectly suited to a single point
cursor and multi touch.
For example instead of a knob why not have an
inset light strip in the
shape of a half circle? ie. a curved slider. It will take up as much
space
as a knob but can be easily manipulated with mouse or finger.
Isn't that what Thorwil's designs, already discussed, propose? They
precisely
are circular sliders *and* level meters. The exact same thing goes with
TouchOSC.
With a 3d
space sliders can be made to do some amazing things. In
addition
there are other control options that become available like pinch, tap,
swipe and shake gestures.
Pinching... That's interesting. But pinching usually requires a large
widget/element, such as a photo, web page. If the widget is too small, you
won't
get as much precision as a single-touch slider, be it circular or linear.
Why constrain
ourselves to a concept we know is a pain for the user if
it
is also gonna be a pain for the developer to implement? If we are going
to
go to all that trouble why not make it something the user will truly
appreciate and increase their productivity.
Yes, but the productivity of a musician isn't only about tools efficiency.
It's
also about inspiration, which isn't necessary rational. That said I agree
with
you about innovation, a creative UI might exactly be what a creative
person need.
Actually, I work a lot on Android these days, and I reckon there's lot of
new
possibilities with touch interfaces. And that's right, do this with a 3D
scene,
and now you got something :)
10:10 p.m.
On Tue, September 28, 2010 7:15 am, Patrick Shirkey wrote:
On Tue, September 28, 2010 6:35 am, Olivier Guilyardi wrote:
It doesn't have to be. You just need to start with at least one point on
the widget. In fact it could work well with a mouse too.
The widget could look something like a circle with a cross in it. When you
click and drag up the cross opens up and when you click and drag down the
cross closes. This would provide a circular image with a
rectangular/slider single axis movement.
Yes, I'm drooling at the possibilites ;-)
I just thought of another method in this vein. Pinch to increase volume
ans as the volume increases the widget becomes extruded... Tap to decrease
volume and double tap to mute.
Or on a similar note, stroke two/three fingers repeatedly to increase
volume. Pinch and hold to decrease ;-)
--
Patrick Shirkey
Boost Hardware Ltd.
On 09/28/2010 01:59 PM, Patrick Shirkey wrote:
I missed the earlier discussion, sorry.
There is a couple of things about knobs that
don't translate well to a
mouse and are still fairly cumbersome with multitouch.
I can't get away from the feeling that knobs on a screen are as bad as
screws. They just don't translate intuitively.
Well, I recently tried the TouchOSC iPhone app, which allows you to
build
custom
UIs by assembling knobs, sliders, buttons, etc... and assign them to OSC
messages.
The knobs are just brilliant, it's very intuitive I think. It's touch
though,
not multi-touch.
Wouldn't it be more productive to find ways
to make sliders more
visually
expressive?
An interface full of sliders can be confusing and ugly. Knobs + sliders,
that
brings balance I believe.
They are perfectly suited to a single point
cursor and multi touch.
For example instead of a knob why not have an
inset light strip in the
shape of a half circle? ie. a curved slider. It will take up as much
space
as a knob but can be easily manipulated with mouse or finger.
Isn't that what Thorwil's designs, already discussed, propose? They
precisely
are circular sliders *and* level meters. The exact same thing goes with
TouchOSC.
With a 3d
space sliders can be made to do some amazing things. In
addition
there are other control options that become available like pinch, tap,
swipe and shake gestures.
Pinching... That's interesting. But pinching usually requires a large
widget/element, such as a photo, web page. If the widget is too small,
you
won't
get as much precision as a single-touch slider, be it circular or
linear.
Why
constrain ourselves to a concept we know is a pain for the user if
it
is also gonna be a pain for the developer to implement? If we are going
to
go to all that trouble why not make it something the user will truly
appreciate and increase their productivity.
Yes, but the productivity of a musician isn't only about tools
efficiency.
It's
also about inspiration, which isn't necessary rational. That said I
agree
with
you about innovation, a creative UI might exactly be what a creative
person need.
Actually, I work a lot on Android these days, and I reckon there's lot
of
new
possibilities with touch interfaces. And that's right, do this with a 3D
scene,
and now you got something :)
10:19 p.m.
On Tue, Sep 28, 2010 at 4:10 PM, Patrick Shirkey
<pshirkey(a)boosthardware.com> wrote:
I just thought of another method in this vein. Pinch
to increase volume
ans as the volume increases the widget becomes extruded... Tap to decrease
volume and double tap to mute.
Or on a similar note, stroke two/three fingers repeatedly to increase
volume. Pinch and hold to decrease ;-)
clearly, you touch geeks don't read createdigitalmusic carefully enough:
"Using the trackpad for a live control surface is a bad idea at least
it was for me. My last gig I ended up having to perform a track which
my live set was not setup for. A drop of sweat hit the track pad and
made it functionally useless, it was a nightmare- I ened up having to
stop the music to clean it off- This is also the reason some other
touch surfaces fail in a live setting- like Stanton’s Da Scratch. "
29 Sep
29 Sep
3:54 a.m.
On Tue, September 28, 2010 1:18 pm, Paul Davis wrote:
On Tue, Sep 28, 2010 at 4:10 PM, Patrick Shirkey
<pshirkey(a)boosthardware.com> wrote:
Nah, we just record our sets before we go live and pretend we are doing
something in front of the audience. It makes it easier to get drunk and
pick up when you can spend the whole gig posing and preening ;-)
I thought of couple more:
Rub a button and it swells while increase volume tap and hold or pinch to
decrease. In this case the button could also pulsate when at different %'s
of the scale and throb when at 0 gain. I'm not going to say what happens
if you go over unity or maintain the level at unity for prolonged
periods...
A 3d stick attached to a central pivot point rotating around the pivot.
A central light source with a wheel on the side. As the wheel is scrolled
the light glows brighter/softer.
All of these interactions can be achieved with single mouse pointer and
modifiers. Don't even require multitouch so far.
--
Patrick Shirkey
Boost Hardware Ltd.
I just thought of another method in this vein.
Pinch to increase volume
ans as the volume increases the widget becomes extruded... Tap to
decrease
volume and double tap to mute.
Or on a similar note, stroke two/three fingers repeatedly to increase
volume. Pinch and hold to decrease ;-)
clearly, you touch geeks don't read createdigitalmusic carefully enough:
"Using the trackpad for a live control surface is a bad idea at least
it was for me. My last gig I ended up having to perform a track which
my live set was not setup for. A drop of sweat hit the track pad and
made it functionally useless, it was a nightmare- I ened up having to
stop the music to clean it off- This is also the reason some other
touch surfaces fail in a live setting- like StantonÂ’s Da Scratch. "
28 Sep
28 Sep
3:18 p.m.
Am Dienstag, den 28.09.2010, 13:00 +0200 schrieb Olivier Guilyardi:
On 09/28/2010 07:28 AM, hermann wrote:
Okay, . .
Am Montag, den 27.09.2010, 16:57 +0200 schrieb
Olivier Guilyardi:
Okay, it says "All GtkStyle drawing functions (gtk_paint_box(), etc) have been
changed to take a #cairo_t instead of a window and a clip area. ::draw
implementations will usually just use the cairo context that has been passed in
for this."
I'm not a gtk engine wizard, but the problem is still here IIUC.
If you draw directly with Cairo within your widget, your bypass the drawing
"driver" layer, for example used by ClearLooks which overloads the old
gtk_draw_*() functions in clearlooks_style_class_init():
http://clearlooks.cvs.sourceforge.net/viewvc/clearlooks/clearlooks/src/clea…
Whether gtk or a specific engine draw internally with Cairo or not doesn't
change the situation.
I suppose that the only solution would be to add some knob drawing primitives to
the GtkStyle class itself. That would allow gtk engines developers to provide
their own knob drawing implementation, and also separate the rendering code from
the knob logic.
But that might be a lot of trouble.
--
Olivier
My point was that widgets drawn directly with
Cairo bypass the
gtk_paint_*()
drawing abstraction layer, which would forbid engine to provide their
own knob
drawing implementation, as it's done for buttons, etc...
Therefore, such Cairo-based knobs wouldn't support the full GTK
theming
capabilities.
In Gtk+3 many GDK functions are replaced by cairo.
gtk_widget_draw() will take any cairo surface then.
http://live.gnome.org/GnomeGoals/GTKRenderingCleanup The GdkGC and GdkImage objects, as well as all the
functions using
them are gone. This includes the gdk_draw_ family of functions like
gdk_draw_rectangle() and gdk_draw_drawable(). As GdkGC is roughly
equivalent to cairo_t and GdkImage was used for drawing images to
GdkDrawables, which cairo supports automatically, a transition is
usually straightforward.
url: http://live.gnome.org/GnomeGoals/GDKtoCairo
I guess that the engines need to be rewrite for GTK+3 anyway, and when
your goal is to include a knob in GTK mainstream, it could be a good
point to do it in the upcoming GTK+3, then it could be done with cairo
and produce a well nice looking and full featured module witch could
supported by engines from beginning on. :-)
greats hermann
3:32 p.m.
On Tue, Sep 28, 2010 at 7:00 AM, Olivier Guilyardi <list(a)samalyse.com> wrote:
I'm not a gtk engine wizard, but the problem is
still here IIUC.
Most custom widgets for GTK suffer from this problem. Its not a new
thing. The GTK docs and even the GTK "team" have never really
advocated that all widgets should draw themselves with gdk_draw_*(),
at least not to an extent that has resulted in this being the case.
The problem is that there really is a conflict here:
On the one hand:
1) the desire for a generic, powerful graphics language/API to
draw widgets with (e.g. Cairo)
and on the other
2) the desire to push all widget drawing through a themeable
layer which necessarily reduces the complexity of the graphics API
(e.g. gdk_draw_*())
I don't think that these can be reconciled.
--p
3:42 p.m.
On Tue, Sep 28, 2010 at 9:31 AM, Paul Davis <paul(a)linuxaudiosystems.com> wrote:
On Tue, Sep 28, 2010 at 7:00 AM, Olivier Guilyardi
<list(a)samalyse.com> wrote:
I just asked about this on the GTK+ IRC channel, and indeed, there are
conflicting opinions on this issue within the GTK development team.
I'm not a gtk engine wizard, but the problem
is still here IIUC.
3:50 p.m.
On Tue, September 28, 2010 6:31 am, Paul Davis wrote:
On Tue, Sep 28, 2010 at 7:00 AM, Olivier Guilyardi
<list(a)samalyse.com>
wrote:
I have to agree. The latter is for quick generic ui development and the
former is for those who are more technically inclined or have a
specific/unique concept they are tasked with presenting.
IMO a better generic widget to save space and allow for knob like
interaction would be a vertical/horizontal wheel. Something like a mouse
wheel would work. It would also be much easier to draw and would scale
well too.
--
Patrick Shirkey
Boost Hardware Ltd.
I'm not a gtk engine wizard, but the problem
is still here IIUC.
Most custom widgets for GTK suffer from this problem. Its not a new
thing. The GTK docs and even the GTK "team" have never really
advocated that all widgets should draw themselves with gdk_draw_*(),
at least not to an extent that has resulted in this being the case.
The problem is that there really is a conflict here:
On the one hand:
1) the desire for a generic, powerful graphics language/API to
draw widgets with (e.g. Cairo)
and on the other
2) the desire to push all widget drawing through a themeable
layer which necessarily reduces the complexity of the graphics API
(e.g. gdk_draw_*())
I don't think that these can be reconciled.
4:02 p.m.
On 09/28/2010 03:31 PM, Paul Davis wrote:
On Tue, Sep 28, 2010 at 7:00 AM, Olivier Guilyardi
<list(a)samalyse.com> wrote:
I'm not a gtk engine wizard, but the problem
is still here IIUC.
Most custom widgets for GTK suffer from this problem. Its not a new
thing. The GTK docs and even the GTK "team" have never really
advocated that all widgets should draw themselves with gdk_draw_*(),
at least not to an extent that has resulted in this being the case. The problem is that there really is a conflict here:
On the one hand:
1) the desire for a generic, powerful graphics language/API to
draw widgets with (e.g. Cairo)
and on the other
2) the desire to push all widget drawing through a themeable
layer which necessarily reduces the complexity of the graphics API
(e.g. gdk_draw_*())
I don't think that these can be reconciled.
I was not advocating that all widgets should draw themselves with GtkStyle. Take
a chart, or some advanced scientific widget for example. But since the knob can
be considered as a primitive, a simple and polyvalent widget, I was wondering
how far it could go about being themable, and become a true generic widget.
I see a lot about Cairo in the GTK+3 docs, but I'm not sure what's happening
with GtkStyle. For instance, the author of the Nodoka engine claims GTK+3,
compatibility, and looking at the source I see that he's overloading the same
draw* functions as ClearLooks.
Anyway, to come back a bit to reality, I think that the whole engine thing is
designed for rectangular shapes. It seems like circular ones are out of the scope.
That said, what is this prolooks library you're using in Ardour3? Isn't it some
sort of low-level rendering engine?
--
Olivier
27 Sep
27 Sep
5:42 p.m.
Am Montag, den 27.09.2010, 15:46 +0200 schrieb Olivier Guilyardi:
On 09/27/2010 01:44 PM, Patrick Shirkey wrote:
Oh, I do, that's exactly what we do in libgxw, use GTK Stock Icon Themes
to draw the Knobs and draw the Indicator with Cairo.
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.
[...]
7:13 p.m.
On 09/27/2010 05:42 PM, hermann wrote:
Am Montag, den 27.09.2010, 15:46 +0200 schrieb Olivier
Guilyardi:
Stock icons for knobs? In libgxw I saw a custom background pixmap. Sorry but I
don't see how this is themable.
--
Olivier
On 09/27/2010 01:44 PM, Patrick Shirkey wrote:
Oh, I do, that's exactly what we do in libgxw, use GTK Stock Icon Themes
to draw the Knobs and draw the Indicator with Cairo. 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.
[...]
7:32 p.m.
Am Montag, den 27.09.2010, 19:13 +0200 schrieb Olivier Guilyardi:
On 09/27/2010 05:42 PM, hermann wrote:
Yes, you can define the stock icon's to use in a gtkrc file, define your
theme :
style "skin_icons"
{
stock["bigknob"] = {{"knob3.png"}}
stock["smallknob"] = {{"smallknob3.png"}}
stock["eqslider"] = {{"eqslider.png"}}
}
class "GxKnob" style "skin_icons"
class "GxEQSlider" style "skin_icons"
the knob have the used icon size (witch is free) then.
You could easy change them during runtime.
also all other widgets in this library are them-able with a gtkrc style
file.
for example
style "fastmeter"
{
GxFastMeter::clr-bottom = "#003808"
GxFastMeter::clr-middle = "#00ff00"
GxFastMeter::clr-top = "#ff0000"
GxFastMeter::over = "#ff0000"
}
style "selector"
{
fg[NORMAL] = { 0.32, 0.8, 0.16 }
GtkRange::trough-border = 2
GtkRange::stepper-size = 8
GtkRange::stepper-spacing = 2
GxRegler::value-border = { 2, 0, 0, 0 }
font_name = "sans 7.5"
xthickness = 10
ythickness = 1
}
class "GxFastMeter" style:highest "fastmeter"
class "GxSelector" style:highest "selector"
regards hermann
Am Montag, den 27.09.2010, 15:46 +0200 schrieb
Olivier Guilyardi:
Stock icons for knobs? In libgxw I saw a custom background pixmap. Sorry but I
don't see how this is themable.
--
Olivier On 09/27/2010 01:44 PM, Patrick Shirkey wrote:
Oh, I do, that's exactly what we do in libgxw, use GTK Stock Icon Themes
to draw the Knobs and draw the Indicator with Cairo. 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.
[...]
7:44 p.m.
On 09/27/2010 07:32 PM, hermann wrote:
Am Montag, den 27.09.2010, 19:13 +0200 schrieb Olivier
Guilyardi:
On 09/27/2010 05:42 PM, hermann wrote:
Yes, you can define the stock icon's to use in a gtkrc file, define your
theme : Am Montag, den 27.09.2010, 15:46 +0200 schrieb
Olivier Guilyardi:
Stock icons for knobs? In
libgxw I saw a custom background pixmap. Sorry but I
don't see how this is themable.
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. When it came to
supporting
themes, it was all about vector drawing, especially with Cairo.
[...]
Oh, I do, that's exactly what we do in libgxw, use GTK Stock Icon
Themes
to draw the Knobs and draw the Indicator with Cairo.
style "skin_icons"
{
stock["bigknob"] = {{"knob3.png"}}
stock["smallknob"] = {{"smallknob3.png"}}
stock["eqslider"] = {{"eqslider.png"}}
}
class "GxKnob" style "skin_icons"
class "GxEQSlider" style "skin_icons"
the knob have the used icon size (witch is free) then.
You could easy change them during runtime.
Wow, that's quite cool. You did prove me wrong :)
--
Olivier
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.
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.
5:40 p.m.
On 27/09/10 12:44, Patrick Shirkey wrote:
limits to what you can achieve with a composite widget, not cairo alone.
when you mix methods you
gain the advantages and disadvantages of both at once.
sorry, i wasn't very clear. we were thinking about a themeable combo
knob. with pixmaps that's easy. supply
a pixmap animation that can look like what ever you want. for cairo..
how do you do that since the design
is in code?. there is no file format containing a design specification
nor an interpretor to load it. note i'm not
talking about a native cairo knob that respects themes here. i'm talking
about the combo widget.
tbh, i think that the best way to handle knob themes may well be to
sidestep the issue entirely. provide a plugin
API, and have the widget load plugins that do all the drawing. then
interested parties can do what ever the
hell they like provided they write the code and ship the plugin
themselves. a gtk theme author might then just specify a
plugin if they cared about how the knobs looked with the the rest of
their widgets. similar to the way theme
engines work but for a 3rd party widget library. ship some sensible
defaults/examples and leave people to it.
cheers,
pete.
On Sun, September 26, 2010 1:35 pm, pete shorthose
wrote:
i've not seen this myself. if you shoot me the code i'd be happy to have
a look.
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
28 Sep
28 Sep
12:52 p.m.
On Mon, September 27, 2010 8:39 am, pete shorthose wrote:
On 27/09/10 12:44, Patrick Shirkey wrote:
limits to what you can achieve with a composite widget, not cairo alone.
when you mix methods you
gain the advantages and disadvantages of both at once.
sorry, i wasn't very clear. we were thinking about a themeable combo
knob. with pixmaps that's easy. supply
a pixmap animation that can look like what ever you want. for cairo..
how do you do that since the design
is in code?. there is no file format containing a design specification
nor an interpretor to load it. note i'm not
talking about a native cairo knob that respects themes here. i'm talking
about the combo widget.
IIUC, you can write your own function to load a pixmap defined in a
specific folder or xml etc... Then just draw it in the background layer of
the widget. I did something similar with a custom mouse cursor in python
recently. The code is about 5 lines in the end. I can post it if you are
interested.
On Sun, September 26, 2010 1:35 pm, pete
shorthose wrote:
i've not seen this myself. if you shoot me the code i'd be happy to have
a look.
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
tbh, i think that the best way to handle knob themes
may well be to
sidestep the issue entirely. provide a plugin
API, and have the widget load plugins that do all the drawing. then
interested parties can do what ever the
hell they like provided they write the code and ship the plugin
themselves. a gtk theme author might then just specify a
plugin if they cared about how the knobs looked with the the rest of
their widgets. similar to the way theme
engines work but for a 3rd party widget library. ship some sensible
defaults/examples and leave people to it.
The way they handle this in ex. cocoa is expand the borders of the image.
I'm not sure if they provide complete support in for a circular image or
an image with a gradient though.
I haven't seen this in cairo but it is certainly possible to write a
custom widget for that purpose if the need arose.
The trade off is how much time you want to spend on it I guess.
--
Patrick Shirkey
Boost Hardware Ltd.
5101
days inactive
5104
days old
linux-audio-dev@lists.linuxaudio.org
25 comments
5 participants
participants (5)
-
hermann -
Olivier Guilyardi -
Patrick Shirkey -
Paul Davis -
pete shorthose