28 Sep
2010
28 Sep
'10
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