Re: Sugestions about how to handle rdp sessions on UME
Just a quick update: Adilson Oliveira escreveu: > * long touch = right click Done. > * tripple tap = toggle panning or Works but feel weird. > * tap-and-drag = drag Tap and drag also works but conflicts with some text marking dragging operations. I'll see if doubletap-drag is feasible. []s Adilson. -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
Re: 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 > 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. > 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, of course. []s Adilson. -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
Re: Sugestions about how to handle rdp sessions on UME
Dustin Spicuzza escreveu: > Right-click: > > My touchscreen uses the evtouch driver, and the way it implements right > click is it waits for you to double click somewhere, and it then > simulates a right click instead. I think then a triple click simulates a > double click... but, in any case, it works rather well. Implementing > something like that at the X server level or driver level would probably > be the way to go -- and the code for doing that would be pretty simple > to do. > Hi I was checking the evtouch driver yesterday and the idea is OK but I'm thinking in a way to make it a little more compatible with the usual way to do things, trying not to translate one type of click into other. The evtouch don't expose the full state machine provided by evlib. If so, things like long touch and one-and-half tap can make a better interface in my opinion, emulating the way other OSs work. For instance, to solve my own problem with rdesktop: * long touch = right click * tripple tap = toggle panning or * tap-and-drag = drag This won't be too hard to do. []s Adilson. -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
Re: Sugestions about how to handle rdp sessions on UME
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 Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
Re: Sugestions about how to handle rdp sessions on UME
Right-click: My touchscreen uses the evtouch driver, and the way it implements right click is it waits for you to double click somewhere, and it then simulates a right click instead. I think then a triple click simulates a double click... but, in any case, it works rather well. Implementing something like that at the X server level or driver level would probably be the way to go -- and the code for doing that would be pretty simple to do. Dustin -- Innovation is just a problem away Adilson Oliveira wrote: > Hello. > > I've being implementing the ability to start rdp sessions on UME using > tsclient and rdesktop. > There are 2 issues I would like to discuss: > 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. > 2) Display space and paging. > As you know, the real state available on this kind of device is limited. > To help with that a paging function was added so one can open a session > with a bigger resolution than physically supported by the device and > page this viewport as necessary. This helps but brings an issue on how > to move the viewport. Again, on the Q1 or using a mouse it's easy as one > can use a combination of keys or both mouse buttons to do that but using > a stylus makes the things complicated as every click on the remote > desktop is valid for the rdp session and as such we can't use it to > trigger the paging function. 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. > So, I would like to hear your ideas on: > a) How to implement the right click > b) How to trigger the paging mode > Both without having a keyboard or a mouse-like device. > One idea I had was implement long click to trigger the right click menu > and automatic paging triggered when the cursor hits the borders. > Any takers? > > Thanks. > > Adilson. > > > -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
Sugestions about how to handle rdp sessions on UME
Hello. I've being implementing the ability to start rdp sessions on UME using tsclient and rdesktop. There are 2 issues I would like to discuss: 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. 2) Display space and paging. As you know, the real state available on this kind of device is limited. To help with that a paging function was added so one can open a session with a bigger resolution than physically supported by the device and page this viewport as necessary. This helps but brings an issue on how to move the viewport. Again, on the Q1 or using a mouse it's easy as one can use a combination of keys or both mouse buttons to do that but using a stylus makes the things complicated as every click on the remote desktop is valid for the rdp session and as such we can't use it to trigger the paging function. 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. So, I would like to hear your ideas on: a) How to implement the right click b) How to trigger the paging mode Both without having a keyboard or a mouse-like device. One idea I had was implement long click to trigger the right click menu and automatic paging triggered when the cursor hits the borders. Any takers? Thanks. Adilson. -- Ubuntu-mobile mailing list Ubuntu-mobile@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
