GNOME.org
 

Re: touchscreen mode (Re: Pluggable widget types and implementations)

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.
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]