Tim Janik wrote:
> On Tue, 28 Nov 2006, Tristan Van Berkom wrote:
>
>> /me strays a little offtopic...
>>
>> As someone with a background writing applications for the touchscreen,
>> I'm happy to see there's been an interest over the last year... my
>> personal opinion is that the desktop is not for the touchscreen, and that
>> touchscreen apps are marginally different in the way they interact with
>> the user and will always be highly customized, I think the best thing
>> to do for these corner cases (touchscreen, cellphone keybad driven
>> interfaces etc..) is to make gtk+ more customizable at the
>> widget/object level
>> as much as possible (example add properties to the GtkScale to make is
>> more
>> usable on the touchscreen, but let the developer set those properties).
>
>
> do you have concrete suggestions/patches here?
> "add properties to the GtkScale" is too vague, concrete property
> suggestions
> would help the discussion, especially wtih regards to their relation to
> GtkSettings::touchscreen-mode.
Ok well for instance, in the slider widget that I implemented I needed 3
modes for different purposes throughout the UI, the modes were:
- JUMPY (knob always "snaps to finger position" whenever the finger
presses inside the slider's "trough").
- CATCH (knob will only become "pressed" when there is enter-notify or
button-press inside the knob area, making it possible to
slide your finger along the trough and "catch" the knob)
- NORMAL (same as CATCH, except it does nothing for "enter-notify")
Another thing that is a little vague, and is a good example of why
"touchscreen mode" might not be the most practicle approach, is DnD -
since we've been using treeviews and textviews on the jukebox, we've
been hunting down the obnoxios cases of native DnD support on widgets
and disabling it in any way possible (sometimes set_drag_source/dest(NULL)
does the trick, some widgets we needed to handle events and return TRUE
just to disable them). I'm not saying that DnD doesnt make sence on
the touchscreen, some DnD might, some not... so its obviously more
appropriate in this case to just call gtk_widget_disable_dnd () on that widget.
>> While having a feature that will make virtually any app usable on a
>> touchscreen interface at the flip of a "touchscreen mode" switch sounds
>> kindof cute, I know that its of no value to us ("us" here is:
>> touchtunes.com,
>> the company I write jukeboxes for)... and unless the home pc market is
>> moving from the mouse pointer to the touchscreen, I dont see much value
>> in this feature.
>
>
> it'd be helpful if you outlined *why* this is not going to be of use to
> you.
Why ? well I guess my initial mis-perception here is that: If I am in
touchscreen mode, I will get widget BAR instead of widget FOO as an
implementation of whatever kind of stock widget, where in our particular
case, everything is etched in stone, we dont need any such surprises.
One real concern I have though is, what if we upgrade our gtk+ to a version
sporting touchscreen mode, and then we modify our code to enable
touchscreen mode, but then maybe some widgets we use have builtin context menus,
and now tap-n-hold is enabling them throughout the ui - a problem we never had
before that is now only present with touchscreen mode, now I'll have to
chase through the UI and make sure I disable any unexpeced context menus that
never appeared in the past.
> you seem to not be aware that the reason to add the touchscreen mode
> setting in the first place was to enable/disable gtk patches that were
> necessary to support touchscreens as input device.
> i.e. this is not some abstract hackery, but enables patches needed and
> developed on real world touchscreen devices.
Yes, I've been really really unclear about what touchscreen mode is, I've
heard some abstract jargon about it on irc and I've visited
http://live.gnome.org/GtkStylusMode a few times, and yes I see its as you say,
its a variable that enables/disables some code segments in gtk+ - abstract
hackery ? well that is up to what you think abstract hackery is.
I think essentially (looking at the stylus page) that no touchscreen mode
is needed to hard-code these particular functionalities into gtk+ for
a given "mode", for instance:
- No tooltips (in HEAD)
- Why cant we disable tooltips outside of touchscreen mode ? or even
enable tooltips on some widgets optionally using tap-and-hold, why
cant tap-and-hold be implmented regardless of whether there is a real
touchscreen driving the UI ?
- No right mouse button for context menus etc, implying an implementation of
tap-and-hold
- Again, cant we implement & allow context menus using tap-and-hold outside
of touchscreen mode
- Multi-row selection in GtkTreeView by dragging (in HEAD)
- and another obvious ditto here
I dont think that it should be the choice of gtk+ to enable/disable or
change its behaviour based on one global boolean, that choice should
be open individually for each ambiguity. In otherwords we shouldnt assume
what behaviour is appropriate on what machine setup, we should just make many
individual functionalities possible and let the applications decide.
>> So in closure, yeah "appointed types" sound like an interesting way
>> to have "themable widget implementations" so to speak, the idea doesnt
>> suck, but I hope it is not a solution to a problem that doesnt exist.
>
> again, that proposal is driven by a real world need, and not a
> scientific experiment.
>
>> Also, as an afterthought, hows this alternative:
>> - Add GtkVirtualKeyboard
>
>
> also here, device vendors most probably want highly customized variants.
>
Thats true for the most part, but I think a generalized keyboard could
be good [1], anyway regardless, custom keyboard or not, site independance
and touchscreen vs. mouse pointer independance is something that could
be handled at the application level.
>> - Add properties to some widgets to make them usable on the touchscreen
>
>
> again concrete suggestions would be nice. others have been integrating
> concrete touch screen patches and properties (on widgets, styles,
> GtkSetting)
> already.
Nod, the idea is to add customization to widgets themselves and let
applications decide to set these properties, as opposed to one boolean
setting.
>
>> - Extend GtkAction so that it supports all activatable widgets as
>> proxies
>> (i.e. GtkButton GtkRadioButton GtkHScale etc...)
>> - Use one glade file for the touchscreen, and another glade file for
>> the desktop, use GtkActions for a high level of code abstraction
>> (some code would be optional on the touchscreen, i.e. virtual
>> keyboard
>> handling etc).
>
>
> for gtk, this sounds like something that should rather be done at the
> application level (exchanging glade files).
Thats my point exactly, applications should be able to use the simple
GtkWidget building blocks to build thier UI, if their UI is to be different
on a different site, why not just use a separate description file ?
(ofcourse GtkActions need some work for this to really work)
Remember that this argument/suggestion is offered as an alternative
to using a setting that apperently makes your typical desktop app
"work on a touchscreen", my opinion is simply that this should
be done case-by-case in the application and _not_ in the depths of gtk+.
(the application knows how to behave on a touchscreen, not gtk+ itself).
Well I wrote alot, hope its alright, hitting send - lotsa love !
Cheers,
-Tristan
[1] I've written a few - they typicly support a dynamic
list of keys, a GtkLabel (that can be optionally password protected
and probably has buffer length policing involved), each key supports
a value and a "shifted value" and should ideally be themable.
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
