A small twm patch

[Alex Goncharov]

,--- You/Eeri (Mon, 18 Aug 2008 10:08:44 +0200) ----*
|
| Alex Goncharov:
|   > Based on my long experience with `twm', I would like to suggest
|   > the following small patch to its code.
| 
| Hello Alex,
| 
| being slightly in hurry, nevertheless may I attach some humble comments.

Thanks a lot!

|   > diff -ru twm-1.0.3/src.orig/util.c twm-1.0.3/src/util.c
|   > [...]
|   >      status = XmbTextPropertyToTextList(dpy, &text_prop, &list, &num);
|   > -    if (status < Success || !num || !*list) {
|   > +    if (status < Success || !num || !list || !*list) {
|   >        *winname = NULL;
|   >        return 0;
|   >      }
| 
| Aa a side note, do you have any evidence that injecting '!list' above 
| does anything the '!num'-test already doesn't?  I am in no way ruling 
| out I am overlooking something.

I think I do: I came to this line looking at a SEGV core dump pointing
to this line, with 'list=0'.  (Otherwise, I wouldn't have found it :-)

| The XmbTextPropertyToTextList() documentation states that 'num' in 
| unisono reflects the number of elements in 'list', so if positive and if 
| the same time 'list' is nevertheless zero, we have caught a bug in that 
| function which should be rectified instead.

I wouldn't mind it either.

| It probably is not a good idea to keep disguising this that way.
| (Btw, the exact same if-statement is a dozen lines below in
| I18N_GetIconName().)

That's a good point!  I didn't try to do a real good fix: my purpose
was to find the appropriate people to talk to and try to help identify
and fix the enormously annoying twm crashes, which are unfortunately a
regular thing for me, on top of regular Xorg crashes. (If it happens
once a week, it's plenty for me to try to do something about it).

| Though, nevertheless this if-statement needs correction. The 
| documentation doesn't state anywhere that the set of return values of 
| XmbTextPropertyToTextList() is an ordered set, so 'status < Success' is 
|   not only confusing, it is wrong.

Very well: can "we" do something about it?  "We" means that I am
willing to do what I can, testing and discussing but a truly
X-knowledgeable developer needs to be involved here.

|   > diff -ru twm-1.0.3/src.orig/events.c twm-1.0.3/src/events.c
|   > -	if (Tmp_win->icon_name == NoName) {
|   > +	if (Tmp_win->icon_name !=  Tmp_win->name) {
|   >  	    Tmp_win->icon_name = Tmp_win->name;
|   >  	    RedoIconName();
|   >  	}
| 
| :-)   This looks a very courageous interpretation of the XA_WM_ICON_NAME 
|   window property;

Sure it is -- and I know it's not the best thing to do: I submitted a
problem report to Opera after they released 9.51 this summer and still
didn't set the ICON_NAME property, which I had thought was a 9.2x
deficiency.

| If you ask me, I would suggest to remove this if-statement entirely.  At 
|   least even the traditional variant is arbitrary: if the icon name is 
| missing, the 'class.res_name' or 'class.res_class' seem to be as good 
| candidates for replacing 'NoName' as the 'name' currently is.
| The above if-statement as it originally stands results in icons which 
| stretch from the left to the right edge of a 30" monitor as e.g. often 
| web page generators put the whole document into the HTML-title as well, 
| now ending up rendered in the icon label.

Don't know about this: with the original blocks the icons in my Opera
Icon Manager (yes, I have one in .twmrc) were the size I asked them to
be, with a silly static title.  The changing icon title, matching the
window title, was one of the very few things that I thought Firefox
had advantage over Opera in.  So, I had to modify twm's code to get
the behaviour I wanted.  Not a perfect fix, but made my desktop
environment friendlier.

| Not utilising the XA_WM_ICON_NAME property is maybe 'Opera'-specific 
| peculiarity; maybe Opera is meant never to be iconified.

I haven't heard from Opera in response to my problem report; don't
know why they do it.

| In any case, fortunately the functionality you suggest has not 
| necessarily to be implemented in twm anyways; please find attached a 
| trivial program which, if started in .xinitrc in the background prior 
| to any other X-application, should do you have suggested: intercepts all 
| XA_WM_NAME property calls from each client, and forks them to set their 
| XA_WM_ICON_NAME accordingly.
| Let count this as a counter-suggestion.  :-)

If this works -- and I'll try it later -- that would be a MUCH better
solution than I suggested, a perfect solution, perhaps.  Again, I
mostly wanted to find help in resolving some annoyances.

Thank you very much!

| P.S. Alex, maybe you find it interesting, take a look at
|       http://www1.inf.tu-dresden.de/~ek1/TWM-Tweaked.sh
| this downloads
|       http://www1.inf.tu-dresden.de/~ek1/twm-1.0.4-tweaked-diffs.tar
| and compiles a twm (I mostly added client sloppy focusing; and am nearly 
| finalising the rest by others begun few decades ago).  The man-page is 
| unfortunately not yet updated, so the dot.twmrc file enclosed is the 
| only documentation to these improvements.
| If one keeps the .twmrc as it is, twm will continue running in its
| traditional fashion, though few parameters will result in
|       http://www1.inf.tu-dresden.de/~ek1/Vim-ShapeExtension.png
| Have fun!

I will, thank you.

-- Alex -- alex-goncharov at comcast.net --

/*
 * Before you criticize someone, you should walk a mile in their shoes.
 * That way, when you criticize them, you're a mile away and you have
 * their shoes.
 */