I have been poking at getting indirect XDMCP working on OpenSuse 11.3 with gdm with no success. Has anyone gotten this working? I did see that recently gdm was rewritten and there were some complaints that not all features were brought over to the new version.
Firewall is off on the inside network, gdm.schemas was edited..which looks like it replaced the custom.conf file. I put the lines into custom.conf anyway just to be safe. Xaccess looks good for indirect connections (*), yast2 security has remote connections allowed.
If anyone got it working, step by step instructions are appreciated.
I hate to think that 1975 xdm is going to be greeting our users on shiny new OpenSuse 11.3. :)
Friday, May 28, 2010
Wednesday, May 19, 2010
Ideas Welcome, Low Level Mouse Events
My current project is related to Accessibility. Certain parts of the accessibility modules will help me and are being tested.
One requested idea is to make use of a 5 button mouse. By default the 5 button mouse works per the defaults: Thumb1 does a Back, and Thumb2 does a Forward.
The special need that we have is to eliminate the need to use the keyboard in combination with the Left mouse button. I'm trying to map it like this:
Thumb1 = Hold_Shift_L + Regular_Left_Mouse_Button + Release_Shift_L
Thumb2 = Hold_Control_L + Regular_Left_Mouse_Button + Release_Control_L
This would let them make non-continuous selections and shifted selections without the keyboard. It seems like imwheel is the closest software package for this purpose, but it seems incapable of sending a physical mouse click after another mouse click. Can anyone confirm this is true?
What I tried in the .imwheelrc file is this:
".*"
#,Thumb1,H|E|L|L|O
,Thumb1, Shift_L|Left|-Shift_L
The commented line works great, click Thumb1 and the string appears in the current window. You also can issue a Control-A to select all, works great. But when you attempt to simulate a mouse click, it doesn't seem to understand how to do that. The line below the commented line above to me should work, but doesn't work. I also tried Button8 instead of Left and that also does not work.
Anyone know of another program or technique that could provide this functionality?
Thanks!
One requested idea is to make use of a 5 button mouse. By default the 5 button mouse works per the defaults: Thumb1 does a Back, and Thumb2 does a Forward.
The special need that we have is to eliminate the need to use the keyboard in combination with the Left mouse button. I'm trying to map it like this:
Thumb1 = Hold_Shift_L + Regular_Left_Mouse_Button + Release_Shift_L
Thumb2 = Hold_Control_L + Regular_Left_Mouse_Button + Release_Control_L
This would let them make non-continuous selections and shifted selections without the keyboard. It seems like imwheel is the closest software package for this purpose, but it seems incapable of sending a physical mouse click after another mouse click. Can anyone confirm this is true?
What I tried in the .imwheelrc file is this:
".*"
#,Thumb1,H|E|L|L|O
,Thumb1, Shift_L|Left|-Shift_L
The commented line works great, click Thumb1 and the string appears in the current window. You also can issue a Control-A to select all, works great. But when you attempt to simulate a mouse click, it doesn't seem to understand how to do that. The line below the commented line above to me should work, but doesn't work. I also tried Button8 instead of Left and that also does not work.
Anyone know of another program or technique that could provide this functionality?
Thanks!
Friday, May 14, 2010
Client Based RDP & GNOME Icon Launching
RDP Architecture Change
For many years we have integrated MS Windows applications into our GNOME desktop and delivered them to our thin clients. Various techniques have been used to do so, at first we used UIS (Unix Integration Services) which was wonderful but is no longer available. We used Citrix to deliver applications as well. Because the RDP protocol added high color support a few years ago, this now is becoming our primary delivery technique. It's always been our goal to run as little as possible on physical thin client hardware and keep as much on the server as possible. The more that you run at desktops, the greater the chance that you will have to touch them with updates. It also is harder to troubleshoot and resolve problems when it's offloaded from a server. So what we have done is run rdesktop on the server and this has worked great. Rdesktop talks with Windows and then the presentation is delivered to the thin clients with X. For most applications to date performance has been appropriate. But there are some things that are now making this design not work as well as we would like:
Rdesktop runs on the HP Thin clients fine, but obviously when you do so that then creates a more client/server environment and condition where if you want to make a change to that software package you are going to have to touch desktops. While rdesktop isn't changing heavily, an example of what might happen is the users finding a keysym problem after deployment that requires a change to the configuration files. When rdesktop is on the server, such a change takes 2 minutes.
The other problem is how to make an icon launched from the GNOME server initiate rdesktop running locally on the thin clients. The user account doesn't exist on the thin client and is simply running an X server and then using XDMCP to connect to the server.
What has been devised is a technique that seems like it will work well. The thin clients basically have 2 user accounts, 'root' and an account of 'user' with an ID of 1000. I set up an account called 'user' with ID of 1000 on both of the GNOME desktops and then have granted sudo permissions for all other users to have access to the rsh command as 'user'. When they click on the icon, it will sudo the rsh command and pass to the thin client instructions on all of the command line arguments to run and then initiate a local copy of rdesktop to display :0.
Performance is much faster running in this manner; X and PULSE are completely removed from the loop and the Windows servers now have a straight RDP hop right to the thin client as seen in the diagram below:
Full screen video works well with this design,sound is much less prone to breakups and applications are much faster. We continue to test this design, but it's showing promise.
GNOME Icon Launching
During the debugging stage of Evolution I have noticed certain user techniques which have been unknown to me and I have taken steps to improve the user experience. When a user clicks on an Evolution icon our launch script automatically kills any running sessions of that software and starts a new one. The reason it's designed this way is:
Users Click On Icons Multiple Times To "Speed It Up".
I guess the theory is that an icon is like a water pump. The harder you pump, the faster and more likely you are to get water? Users have been double and triple clicking on the icon. Each click was then halting and restarting Evolution. Nice. So what they see is Evolution blinking multiple times until they stop clicking and then finally it opens.
I installed a small script that I called 'gun slinger' that counts the number of seconds since the last click of certain icons and ignores repeated and quick clicking. Here is the popup they see :)
Users Use The Shortcut Icon To Replace The Window List GUI
Instead of finding an already running process in their window list, they just click on the shortcut icon again. If they have something maximized over the top of Evolution, they have no idea how to bring it to the front and have just been clicking on the shortcut again.
I installed a bit of code in the launch script for Evolution that if it detects an already running session, it uses wmctrl to give it a window manager hint. It comes to the front, un-minimizes and flips the cube to the right side to try and get them to run the already running session. They then get this dialog:
All of these techniques are being logged to a file and I'm seeing how many people have been doing this all along. I'm hoping these two steps will eliminate abnormally shutting down Evolution and also reduce the likelyhood of damaged files and perception of instability.
For many years we have integrated MS Windows applications into our GNOME desktop and delivered them to our thin clients. Various techniques have been used to do so, at first we used UIS (Unix Integration Services) which was wonderful but is no longer available. We used Citrix to deliver applications as well. Because the RDP protocol added high color support a few years ago, this now is becoming our primary delivery technique. It's always been our goal to run as little as possible on physical thin client hardware and keep as much on the server as possible. The more that you run at desktops, the greater the chance that you will have to touch them with updates. It also is harder to troubleshoot and resolve problems when it's offloaded from a server. So what we have done is run rdesktop on the server and this has worked great. Rdesktop talks with Windows and then the presentation is delivered to the thin clients with X. For most applications to date performance has been appropriate. But there are some things that are now making this design not work as well as we would like:
- More and more users are getting dual and triple screens to do wide screen work with lots of real estate. This is a lot of data to push over X.
- Certain CAD applications are becoming more sophisticated and are doing lots of movements and zoom that should deliver reasonable response times.
- More applications are starting to deliver sound and video from Windows.
- Products such as Aqua Connect allow you to deliver Mac OS X applications from servers which also require faster response times.
Rdesktop runs on the HP Thin clients fine, but obviously when you do so that then creates a more client/server environment and condition where if you want to make a change to that software package you are going to have to touch desktops. While rdesktop isn't changing heavily, an example of what might happen is the users finding a keysym problem after deployment that requires a change to the configuration files. When rdesktop is on the server, such a change takes 2 minutes.
The other problem is how to make an icon launched from the GNOME server initiate rdesktop running locally on the thin clients. The user account doesn't exist on the thin client and is simply running an X server and then using XDMCP to connect to the server.
What has been devised is a technique that seems like it will work well. The thin clients basically have 2 user accounts, 'root' and an account of 'user' with an ID of 1000. I set up an account called 'user' with ID of 1000 on both of the GNOME desktops and then have granted sudo permissions for all other users to have access to the rsh command as 'user'. When they click on the icon, it will sudo the rsh command and pass to the thin client instructions on all of the command line arguments to run and then initiate a local copy of rdesktop to display :0.
Performance is much faster running in this manner; X and PULSE are completely removed from the loop and the Windows servers now have a straight RDP hop right to the thin client as seen in the diagram below:
Full screen video works well with this design,sound is much less prone to breakups and applications are much faster. We continue to test this design, but it's showing promise.
GNOME Icon Launching
During the debugging stage of Evolution I have noticed certain user techniques which have been unknown to me and I have taken steps to improve the user experience. When a user clicks on an Evolution icon our launch script automatically kills any running sessions of that software and starts a new one. The reason it's designed this way is:
- Regular users cannot be expected to understand how to kill applications with a GUI or to look at process lists. People have no idea what this means or how to do it.
- Users understand reboots, and if they had a local computer would just reboot it. Obviously, they can't reboot the servers. Hundreds of other people would not be pleased. :)
- There are 15 hours of the day and weekends when someone from IT is not here to kill processes that are stuck or not responding.
- The regular GNOME dialog that comes up when an application is not responding very often does not halt all related processes. Yeah it might get evolution.bin, but it very likely will leave the data-server and alarm processes happy churning away.
- Very often users log off without closing Evolution correctly and sometimes just turn off their thin clients. This leaves processes behind on the server.
Users Click On Icons Multiple Times To "Speed It Up".
I guess the theory is that an icon is like a water pump. The harder you pump, the faster and more likely you are to get water? Users have been double and triple clicking on the icon. Each click was then halting and restarting Evolution. Nice. So what they see is Evolution blinking multiple times until they stop clicking and then finally it opens.
I installed a small script that I called 'gun slinger' that counts the number of seconds since the last click of certain icons and ignores repeated and quick clicking. Here is the popup they see :)
Users Use The Shortcut Icon To Replace The Window List GUI
Instead of finding an already running process in their window list, they just click on the shortcut icon again. If they have something maximized over the top of Evolution, they have no idea how to bring it to the front and have just been clicking on the shortcut again.
I installed a bit of code in the launch script for Evolution that if it detects an already running session, it uses wmctrl to give it a window manager hint. It comes to the front, un-minimizes and flips the cube to the right side to try and get them to run the already running session. They then get this dialog:
All of these techniques are being logged to a file and I'm seeing how many people have been doing this all along. I'm hoping these two steps will eliminate abnormally shutting down Evolution and also reduce the likelyhood of damaged files and perception of instability.
Subscribe to:
Posts (Atom)