On Fri, Mar 28, 2008, Adilson Oliveira wrote:
> 1) Right click.
> As you know, right click is very important to windows, as a matter of
> fact, some programs are very hard or even able to operate properly
> without it. In devices like the Samsung Q1, it no big deal as a kind of
> embedded mouse but what about pen only devices? This is usually handled
> by functions like tap-and-hold, which we currently don't have.
Logically, it should be handled all the way from the xorg driver to the
toolkit to your app. So there are two things here:
- implementing right click in Xorg with touchscreen devices
- how to achieve a remote right click in RDP software
* usually this is always mapped one to one: local right click is
remote right click
* what to do if you don't have local right click
Perhaps you want to focus on supporting the target use case that right
click is supported locally and is passed through before providing some
sort of right click emulation when no right click is available locally.
Would you absolutely have to emulate right click, the classical thing
is usually keyboard modifier + click, but since you're focusing on
keyboard-less, it's harder; I don't see any other option than gestures
or measuring double click time to emulate right click or double click;
you could also have a button in the UI to switch all future clicks or
only the next click to right click(s).
This sounds like something we'd better do in Xorg instead of each
individual app though. :-/
> 2) Display space and paging.
> One idea was to keep the marquee and use
> it's menu do perform this function but tests indicated that to be
> cumbersome and that takes too much space if you consider devices with
> 800x400 resolution specially as the marquee + the desktop borders + the
> windows menu bar + the application's tool bar + menus + header leaves
> almost no space left for the data itself so I decided would be best to
> reclaim this space by using the whole screen as it was before.
Agreed, but this might still be the most user friendly option when the
screen is large enough. Also, it needs not to be a static marquee bar;
it could as well be a floating mini toolbar which you can move around.
For example if could show a single button saying "Exit full screen" in
a tiny font (or "Show menu", or "Menu"). This could be moved like a
floating applet / widget / gadget by the end user if it hides some
info.
> automatic paging triggered when the cursor hits the borders.
I like the idea for paging, but it would be nice to keep an area where
touching actually shows the menu for a little while; for instance, the
top 5 pixels could be used to trigger the menu to show for 5 seconds
and the next 5 pixels at the top could mean scrolling towards the top.
--
Loïc Minier
--
Ubuntu-mobile mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
