[Sugar-devel] [DESIGN] The touchscreen gesture to bring up the Frame...

[Gonzalo Odiard]

>
>
>
>> 3.- It's very easy to hit the Stop button (in an activity) when trying
>> to invoke the frame from the touchscreen.
>>
>> 4.- Other ways to invoke the frame are equally funny: Alt-Shift-F, F5
>> (or is it F6? I never remember)
>>
>>
>  Alt-Shift-F and F6 works. In the new XO > 1-5,  F6 have the frame icon,
> then have a lot of sense.
> In XO-1 and xo-1.5, the frame key is at the top right in the keyboard.
>
> Most keyboards don't have a Frame key. We have to assume that.
> If my memory servers me right, the original XO's design removed the CAPS
> LOCK key for finding it useless and promoting of error and misuse.
>
> I share this concept.
>
> Then there's the Super a.k.a. *Windows*/*Apple* key.  That's also a good
> candidate.
>
>
Yes. Super/Windows/Apple key is a good candidate. Better than CapsLock,
because is already related to applications management in other
environments.



> To make things even more interesting, all Chromebooks have a "Find" key at
> the spot where regular keyboards have CAPS LOCK. It acts as a Super key.
>
>
> <snip>
>
>   b) Probably would be good make some of the keybindings configurable,
> but then we would need lead with the fact than maintain documentation
> or how show to the users what are the keybindings/gestures in use.
>
>
> We would? Perhaps My Settings -> Keybindings would be enough? (Much like
> XFCE)
>
>
Probably. We already have a My Settings -> Frame section. Maybe we can add
the keybing for the frame there?



> (unrelated, why is My Settings modal?)
>

Because interacted in a bad way with the widgets in the frame.
There are a few bugs filled (and fixed) in bugs.sugarlabs.org related to
that.


>   c) The problem with add other gestures is that the finger can interact
> with other objects while doing the gesture. As a example, if you have the
> Paint activity,
> can draw in the canvas. Other collisions can be with scrolling areas
> or the zoom gestures like in ImageViewer.
>
>

There are more information in bug http://bugs.sugarlabs.org/ticket/3981
and a lot more just searching
http://bugs.sugarlabs.org/search?q=gesture&noquickjump=1&ticket=on



> Gtk implemented gestures
> after we implemented them in Sugar, then the situation could be better
> with
> newer Gk versions, but, that imply:
>
>  * Port the gestures support from the sugar toolkit side to the new Gtk
> methods.
>   * Require a newer Gtk, than could be a problem by example in F18.
>
>
> Are the current maintainers familiar with this code? From some of the
> headers (SugarExt for example), I see names I don't recognize.
>
>
All what you see in the module SugarExt is implemented in c and available
to th python code
using gobject-introspection. The gestures code was implemented by Carlos
Garnacho
who is involved in gestures in Gtk too.



> I understand the problem. Android solves it by reserving a piece of the
> screen. Perhaps we could do something like that: A hint to the user that
> there is a Frame to pull from above.
>

Yes. That was



>   We really need have a active Design Team again... any idea is welcomed
>
> How about updating the HIG ? I think any Design work as a community
> project within Sugar Labs, should have to start there.
>
>
Update the HIG would be great.



> Remember, Sugar is a vision, not an implementation.
>
>
I deeply disagree. Is a vision _and_ a implementation.
Kids don't use visions.

Gonzalo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20150410/43b9a7c3/attachment.html>