Sugestions about how to handle rdp sessions on UME
Loïc Minier escreveu:
> 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
As I stated in a previous email, evtouch can be modified to expose
better the libtouch's state machine so long touch and tap-and-drag can
be used. This is not a big job as it would require just extend evtouch.
> 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. :-/
Yep. See above.
>> 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
>> 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.
The only current problem with the idea of a dynamic sort of marquee is
that rdesktop is pure X so making something like that, albeit possible,
brings some problems as work only with X primitives is a royal PITA
and ugly. To overcome this, some ideas are:
a) Create a GTK UI to wrap around rdesktop: Maybe overkill for now but
may be proven useful in the future but at the current state of the
Maemo/Hildon affairs, I'm not sure if it's worthing invest the time.
b) Embed the rdesktop window in a shell. A small program (maybe tsclient
itself?) would run rdesktop embedded into it's X window.
c) Have some sort of small lib that will not interface the application
per se but can be used to display all sorts of information and interact
with the user if necessary.
That's what I came up for now but other suggestions are aways welcome,
Ubuntu-mobile mailing list
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile