From: Chris R. <cj...@tr...> - 2008-01-23 15:55:39
|
We are using Rdesktop 1.5 with SeamlessRDP to publish a Windows (W2K3/TS) Taskbar (explorer.exe with NoDesktop=1) to all users. With drive mapping, sound, printers etc - it really does work phenomenally well. But! When using the Windows Taskbar to run Windows applications, these applications show up on both the KDE 3.5 taskbar AND the Windows taskbar. I would like to prevent these applications from showing up on the KDE taskbar, in order to reduce confusion amongst my users (and the resulting support calls). I have tried running rdesktop with kstart --skiptaskbar, but this only hid the initial rdesktop session, not the applications running within it. I have read the Rdesktop man page and have searched the web - but to no avail. I do appreciate that the SeamlessRDP functionality is fairly experimental, and that this is probably a limitation with which I will have to live; but if anyone does have any ideas, I would love to hear them! Many thanks, Chris. |
From: Chris R. <cj...@tr...> - 2008-01-24 09:04:35
|
On Wednesday 23 January 2008 23:16, Lloyd Hazlett wrote: > http://www.fontis.com.au/rdesktop > Are you using the windows taskbar to provide an easy way for users to run > multiple Windows applications? Yes! > If so, perhaps the connection sharing > feature of our patch could help you. We launch rdesktop through a wrapper > script which handles setting up a master connection or otherwise launching > in slave mode as required, and this lets us create KDE start menu entries > for all the Windows applications the users need. Thanks for your response. I did implement your patches on our pilot system a few months ago. It worked perfectly for most applications, via the wrapper script you provided. I was very impressed with it and would certainly recommend that people try it. The issue we had was with our main accounting/invoicing system - once your patch had been applied, I was unable to get keyboard focus on the initial login dialog. Literally I could click into the box, but when I typed the keystrokes went to the desktop (or terminal window, if started from one). I got around this by caching the login details on the Windows server and thereafter it worked fine. This issue was not replicated on any other software I ran; so presumably was a quirk of that specific application. Unfortunately, there was another issue with this application (not related to your patch) in that it often has a secondary window/dialog. If you minimised the application in that state, it would not restore cleanly. I.e. the background window would be active and nothing would induce the foreground window to become the active one. This issue was not related to your patch, but of course it necessitated having the Windows taskbar; in order to be able to restore the application from a minimised state. > Then rather than having > two taskbars to confuse them, everything appears as native KDE > applications, since the Windows apps also sit correctly in the KDE taskbar. I would love to get rid of the Windows taskbar, as you say it is confusing for users. Unfortunately I cannot think of any way around it. I suspect that all our issues are around some quirky Windows programming in the client application but, as closed source software, and as the developer's only Linux customer, I'm not going get anywhere that way. Thanks again for your response. Chris. |
From: Chris R. <cj...@tr...> - 2008-01-29 11:11:50
|
On Monday 28 January 2008 22:33, Lloyd Hazlett wrote: > I'd like to continue to work on this with you off-list if you wouldn't mind > - if I send you an updated version would you be able to test it for us with > your app? If we can get this fixed then we'll re-roll the patches for > everyone. How can I refuse? I'll send you an email. Thanks, Chris Roberts |