Captains Log

Irgendwer hat ja die große Schreierei irgendwelcher Massen erhört. Seitdem braucht man keine Xorg.conf mehr, weil X.Org sich selbst konfiguriert. Bzw. den hald dafür einsetzt. Der wiederrum benötigt dbus, und beides sind Prozesse, die ich persönlich nicht im System laufen haben möchte.
Wie dem auch sei, ich habe das mal ausprobiert, und es kam, wie es kommen mußte: X.Org lief, aber eben ohne deutsche Tastatur. Das ist, und da können mal alle Meckerliesen das Mündchen halten, eine der vielen Situationen, in denen PC Hardware nicht durchdacht ist. Apple hatte das Problem damals zu ADB Zeiten nicht. Heute kommt man dafür auf die Idee auf, eine USB-Tastatur könne doch ein Länderkürzel mitgeben. Das ist ja fast schon... modern. Ähnlich modern wie ATX und die Möglichkeit, einen Rechner softwaregesteuert auszuschalten. Das konnten die guten alten Macs auch schon. Das ist aber ein anderes Thema...

Es stellt sich nach wie vor die Frage, wie man bei einem über hald konfigurierten X denn ein anderes Tastaturlayout einstellt. Die Lösung fand ich über Umwege beim Lesen des Beitrags Good experiences with X.Org autoconfiguration, weil in einem Kommentar auf Xorg 7.4, hald and a German keyboard verlinkt wurde.
Die Antwort kann einfacher und gleichzeitig lächerlich nicht sein: Wenn man keine Xorg.conf mehr pflegt, bearbeitet man einfach eine XML-kodierte policy-Datei für den hald.
Oder man verwendet einfach die gute, alte X.Org Konfigurationsmethode und kann sich hald und dbus sparen.

Okay, my tests with w9wm and with lwm both failed. It appears that no WM actually shows the same wrong behaviour as another one. lwm has big problems with rendering transient windows, e.g. properties boxes from Lotus Notes. Well, it mustn't be lwms fault, actually the Citrix Client tries to do the window placement, too.
Citrix (ICA Client) doesn't work as VNC, it just doesn't draw on a part of the screen, but it tries to interact with the X server. So every window appearing on screen is registered in X and the Window Manager. Which means that, obviously, the Window Manager goes through its list of windows to determine the best place where to place this new window. Actually this new window gets two new locations. What eventually happens is that X thinks that the window is in one place, while ICA Client thinks it's somewhere else.
And, officially, ICA Client is responsible for redrawing all windows it cares for. The client will redraw it's own location of the window and only accept interaction in this area - rendering the the window the WM placed originally somewhere else entirely useless.
What makes matters worse is that this this behaviour isn't always reproducable, thus it's unpredictable. But there seems to be a correlation between the Window Managers window placement policy and Citrix capabilities to correctly mark windows as transient and/or children.
 
Right now working with fvwm again, but fluxbox seems to be promising, too.
 
I would be interested in hearing from you folks if you experience similar or other problems with the ICA client.
 
Update: Using fvwm with Citrix kills the Citrix session the moment the workspace switcher is used. Disabled it.

I have the comfort of working in a Unix Environment, and I don't really care about windows applications at all. That is to say, I need to use Lotus Notus because it's the companies default mailing app. So I need to have access to it. Luckily enough some folks of another team setup some Citrix servers for inhouse use.
It's just a pity that Citrix is the whorst application to use in any Unix environment. Citrix displays windows applications and allows you to interact with them in any way you would expect from a windows application. Including border control. This is the part where it becomes messy, because in Unix, we've a Window Manager to control our windows.
Resize, Iconify, bring to front, put to back, all these functions are controlled from one specific program. Or from the Citrix client, if it's an windows application. Now, ICCCM specified some rules for applications and windows alike, and for some good reason. One of these rules is, that no application should make any assumptions about the window geometry. A rule that nowadays enough Unix apps violate, too. With Citrix you get some unexpected behaviour, e.g. menus that appear in the wrong position, transient windows that are half (or entirely) hidden behind the parent window. The list is long.
The Citrix client crashes in some strange ways and will not redraw the display anymore, requiring the client session on the server to be killed. It happened in Metacity, GNOMEs default window manager, Ion3 and some more I tried. The Citrix-guy always complained to us that we should use a good window manager, without ever being able to specify what a good window manager actually is.
 
I eventually got fed up with the situation. I already used Ion3, discarding the standard GNOME environment supported by our Solaris based Sunray server.
 
First steps towards a fix
Since Citrix does most of the things you expect from a window manager it sounds reasonable to use it without any WM at all. To do so I use Xnest that is bound to one of my workspaces. My .xinitrc looks like this:
 
XNESTDISPLAY=`cat /etc/passwd|grep "^$LOGNAME"|cut -d ":" -f 3`
XNESTGEOMETRY=`xwininfo -root|grep geometry`
Xnest :${XNESTDISPLAY} -br -pn -name Citrix $XNESTGEOMETRY &
 
XNESTDISPLAY is required later on. Since the ica-Client is started by the web-browser after logging in to the citrix website and clicking on the application I want to start, i wrote a small wrapper. This takes care of some strange bug that only seems to appear in some configuration: All launch.ica files are downloaded to /tmp, and since we're on a multiuser machine many files are there. So they are renamed and most Firefoxes and Mozillas seem to be able to issue the right filename to wfica. Not in my configuration, and recently, in some cases, of my colleagues, too.
The wrapper is a simple shell script that checks for XNESTDISPLAY and starts wfica when everything is set. If you want it, just leave a comment.
 
I now have a stable configuration that already works for month. The Citrix client won't crash on me, and no window manager is getting pissed because of some misbehaving application.
Caveat: It's not that easy to Copy+Paste data between an application running inside Citrix and some other Unix app. I decided to take the easy route: Launch a terminal in the Xnest session, open vi with a file called copy+paste. That's it.
 
Two caveats left:

• The terminal - notably dtterm - can neither be moved nor put to foreground, which is sometimes neccessary
• Iconifing a citrix window is a bad idea: Citrix allows this, but it doesn't handle iconified windows on its own.

In the past I didn't much care about those two facts. Yes, it was annoying sometimes, especially when I needed those two or three other inhouse applications. They required me to push and resize windows around the screeens. Something I personally totally hate (exactly the reason why I choose to use ion3).
 
(Hopefully) final solution: Today, while browsing the OpenCSW-Repository I came across lwm, a pretty small "lightweight window manager". I gave it a try and was pretty satisfied with the results. But I was still wondering about the title bar of the window manager, and citrix' own one. I remembered 9wm and it's child w9wm. 9wm had problems rendering fonts in both it's menus, so I tried w9wm. It works fine. It surrounds all windows with just a small border, no titles. I now can create new terminals inside Xnest directly, can move, resize and delete them. And w9wm takes care of windows applications that are in an iconified state.
 
Update: That was pretty fast, but I obviously forgot one test while trying w9wm: Opening another application causes an error with w9wm in which the newly created window is slowly moved across the screen, finally disappearing in a corner. I switched back to lwm that does not cause this error. Will try with this for a longer period of time.
 
Zusammenfassung: Citrix ermöglicht in Unix-Umgebungen den Zugriff und die Interaktion mit Windows-Anwendungen. Leider kümmert es sich selbst um Funktionen, die normalerweise den Window Managern zustehen, was immer wieder zu Problemen führt. Ich führe als Lösung meine Citrix-Session in einem abgeschotteten Xnest aus, und verwende seit heute den minimalen Window Manager w9wm, um die fehlenden Funktionen zu ersetzen. Dies ist hauptsächlich die Möglichkeit, iconifizierte Fenster aufrufen zu können, und mein Termal, das ich für Copy+Paste mit der Unix-Umgebung benötige, in den Vordergrund holen oder mal in der Größe verändern zu können.
Xnest und w9wm sind eine gute Kombination.
 
Update: Ich habe, so wie es aussieht, einen Test vergessen: Wenn man eine weitere Anwendung mit Citrix öffnet (also ein neues Parent Fenster hat), wandert dieses langsam über den Bildschirm und verschwindet schliesslich in einer Ecke. Habe auf lwm umgestellt, der zeigt das Verhalten nicht.