Hi All, I see a nice healthy discussion on these DEs - please can someone with actual experience give me some guidance.
As an Ububtu user, I am following this list because F17 will have "native" multiseat support. My staff run 1 (and only 1) application in Linux: A proprietary GIS package, to do spatial data capture. Nothing else.
I've been using Ubuntu 6.06 only because multiseat was stable. I believe that Gnome messed that up so lately I've been using single seat boxes with Ubuntu 11.10, but the screen focus is annoyingly different. Yes I have tried different "preference" settings.
So, my questions are:
Does XFCE work in multiseat mode (or must it too wait for the F17 drivers/methodology) Which screen-focus methodology does XFCE use? (Like the older Gnome, or the newer Gnome)
More on Screen Focus: The GIS package is NOT a GUI package, but rather a bunch of commands you can string together in BASH-syntax-like scripts that run within the package. I make heavy usage of one command that allows you to position the mouse somewhere on the graphics output screen, and then either click, or touch a key on the keyboard. This command then returns "button X Y" which you can trap, and then do further processing in your script. In other words, I now have a 104-button mouse. In the older Gnomes, when my script requested an input from the graphics locator, the focus would automatically drop to the graphics window, so touching the keyboard instead of clicking the mouse would send the "keypressed-X-Y" to the mouse-input que, and not the keyboard buffer. On the newer Gnomes, this is extremely erratic, and touching the keyboard instead of clicking the mouse sometimes (and not always) puts that key depression into the keyboard buffer (to create later havoc), but hangs my script until the operator manually focusses to the graphic screen and then does the mouse-point-key-depression "click".
Extremely annoying, so I was wondering if any of you had in-depth knowledge of where this screen-focus issue might arise from, or whether XFCE was suitable for multiseat configurations.
TIA, Zoltan
On 03/28/2012 11:55 PM, Zoltan Szecsei wrote:
Does XFCE work in multiseat mode (or must it too wait for the F17 drivers/methodology) Which screen-focus methodology does XFCE use? (Like the older Gnome, or the newer Gnome)
This probably isn't the best place to ask, partially because Fedora is so Gnome-centric. Your best bet is to go to the XFCE support forum at http://forum.xfce.org/index.php and ask there.
On 2012/03/29 09:06, Joe Zeff wrote:
On 03/28/2012 11:55 PM, Zoltan Szecsei wrote:
Does XFCE work in multiseat mode (or must it too wait for the F17 drivers/methodology) Which screen-focus methodology does XFCE use? (Like the older Gnome, or the newer Gnome)
This probably isn't the best place to ask, partially because Fedora is so Gnome-centric. Your best bet is to go to the XFCE support forum at http://forum.xfce.org/index.php and ask there.
Hi Joe, Thanks for the link.
I chose this list because there already was some discussion on the DE vs DE, it was neither a Gnome nor XFCE specific list, and had the key ingredient of upcoming multiseat support (F17).
I will try the XFCE list if this fizzles out.
Thanks again and kind regards, Zoltan
Does XFCE work in multiseat mode (or must it too wait for the F17 drivers/methodology)
I've run multiple XFCE sessions at once as *different* users on the same box to different displays. That works - and to be honest - that ought to work on any desktop.
Trying to do multiple as one user ends in tears.
Which screen-focus methodology does XFCE use? (Like the older Gnome, or the newer Gnome)
If you mean the window focus policy - its configurable. Mind you most things in xfce are 8)
More on Screen Focus: The GIS package is NOT a GUI package, but rather a bunch of commands you can string together in BASH-syntax-like scripts that run within the package. I make heavy usage of one command that allows you to position the mouse somewhere on the graphics output screen, and then either click, or touch a key on the keyboard. This command then returns "button X Y" which you can trap, and then do further processing in your script. In other words, I now have a 104-button mouse.
Well sort of, but you are asking for problems if it's just using Xtest hackery to do this. When you click on a window the focus processing takes a moment of time and you really should be waiting for the target window to become mapped before firing input at it.
In the older Gnomes, when my script requested an input from the graphics locator, the focus would automatically drop to the graphics window, so touching the keyboard instead of clicking the mouse would send the "keypressed-X-Y" to the mouse-input que, and not the keyboard buffer. On the newer Gnomes, this is extremely erratic, and touching the keyboard instead of clicking the mouse sometimes (and not always) puts that key depression into the keyboard buffer (to create later havoc), but hangs my script until the operator manually focusses to the graphic screen and then does the mouse-point-key-depression "click".
Extremely annoying, so I was wondering if any of you had in-depth knowledge of where this screen-focus issue might arise from
The relevant question is probably how those tools work and how they should work. You can select a window to be focussed via the X protocol so you can use command line tools in the script to set focus, at least assuming the window manager isn't immediately overriding it as is likely to occur in the non click-to-focus modes that Gnome favours. However there are ways and means for that too.
If you are using Xfce then you can use "wmctrl" which may be what you want to actually sort the focussing out. It may also work in Gnome 3.
You might also find Zenity worth looking at for some of this kind of work where you are nailing GUI and scripts stuff together. It provides a shell script interface to pop up all sorts of standard gtk dialogues, selectors etc.
Alan
Hi Alan, Thanks for your thoughts. Please see my comments interspersed with yours. Regards, Zoltan
On 2012/03/29 13:10, Alan Cox wrote:
Does XFCE work in multiseat mode (or must it too wait for the F17 drivers/methodology)
I've run multiple XFCE sessions at once as *different* users on the same box to different displays. That works - and to be honest - that ought to work on any desktop.
Good. That's how I do it with (older) Gnome - by editing xorg.conf and creating extra sessions in gdm.conf-custom
Trying to do multiple as one user ends in tears.
not surprised :-)
Which screen-focus methodology does XFCE use? (Like the older Gnome, or the newer Gnome)
If you mean the window focus policy - its configurable. Mind you most things in xfce are 8)
errr... I did mention I did try these user accessible settings (in Gnome). I was looking for comments regarding strategy changes between the older and newer Gnome, or between XFCE & Gnome.
More on Screen Focus: The GIS package is NOT a GUI package, but rather a bunch of commands you can string together in BASH-syntax-like scripts that run within the package. I make heavy usage of one command that allows you to position the mouse somewhere on the graphics output screen, and then either click, or touch a key on the keyboard. This command then returns "button X Y" which you can trap, and then do further processing in your script. In other words, I now have a 104-button mouse.
Well sort of, but you are asking for problems if it's just using Xtest hackery to do this. When you click on a window the focus processing takes a moment of time and you really should be waiting for the target window to become mapped before firing input at it.
Target window never fires up (in this case) - this thought is however not relevant as it used to work 100% correctly on older Gnomes, hence my request insinuating "focus strategy" type differences in the DEs
In the older Gnomes, when my script requested an input from the graphics locator, the focus would automatically drop to the graphics window, so touching the keyboard instead of clicking the mouse would send the "keypressed-X-Y" to the mouse-input que, and not the keyboard buffer. On the newer Gnomes, this is extremely erratic, and touching the keyboard instead of clicking the mouse sometimes (and not always) puts that key depression into the keyboard buffer (to create later havoc), but hangs my script until the operator manually focusses to the graphic screen and then does the mouse-point-key-depression "click".
Extremely annoying, so I was wondering if any of you had in-depth knowledge of where this screen-focus issue might arise from
The relevant question is probably how those tools work and how they should work. You can select a window to be focussed via the X protocol so you can use command line tools in the script to set focus, at least assuming the window manager isn't immediately overriding it as is likely to occur in the non click-to-focus modes that Gnome favours. However there are ways and means for that too.
This is a thought I never considered. Will explore it.
If you are using Xfce then you can use "wmctrl" which may be what you want to actually sort the focussing out. It may also work in Gnome 3.
You might also find Zenity worth looking at for some of this kind of work where you are nailing GUI and scripts stuff together. It provides a shell script interface to pop up all sorts of standard gtk dialogues, selectors etc.
Nice thought - thanks.
Alan
Target window never fires up (in this case) - this thought is however not relevant as it used to work 100% correctly on older Gnomes, hence my request insinuating "focus strategy" type differences in the DEs
Actually I suspect its very relevant - if you've got timing dependancies in your approach then you will get problems such as those you describe.
Alan
-
Alan Cox -
Joe Zeff -
Zoltan Szecsei