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

[Sebastian Silva]

On 09/04/15 12:39, Gonzalo Odiard wrote:
>
>
> (you have to pass your finger thru the rightmost border of the screen
> from top to bottom).
>
>
>
> Not correct. The gesture to show/hide the frame is do a short swipe from
> top border in bottom direction. Not only in the rightmost border,
> all the top border works.
I stand corrected. Confirmed as working in consumer class touchscreen.
>
>  
>
>     2.- Only practical to do on XO (because the screen has a bevel). Most
>     laptops with touchscreen in the market don't have this bevel.
>
>
> I don't understand why that could not work without a bevel. Could you
> explain?
Because I wrongly thought the gesture only worked on the rightmost side
(so you'd use the bevel to guide your finger).

>  
>
>     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.

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)

(unrelated, why is My Settings modal?)

> 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. 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.

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.
> 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.

Remember, Sugar is a vision, not an implementation.

Sebastian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20150409/3297cd8d/attachment.html>