distict WM_CLASS for different servers

[Thomas Orgis]

Am Sat, 30 Sep 2006 12:05:37 -0400
schrieb Scott Tringali <scott.tringali at etnus.com>: 

> I'll take a look at this - there's better way to do it without adding 
> global variables.  I just have to figure out what it is.
> 
> I'm also not sure this will do what you want, since there are other 
> top-level windows that you haven't changed yet.

Eh, I wanted to group all editor windows... with "other top level windows" do you mean dialogs from menu or warning windows?
I indeed have a prob with the occasional "file modified externally" (or the like) message popping but being hidden behind the main nedit windows (due to some clicking, desktop switching, whatever...) and me wondering why nedit doesn't react.
And this is strange... when I do 

nc <non-existing file>

The dialog

WM_CLASS(STRING) = "Warning", "NEdit"

pops up, but when I don't answer id and switch to another window (thus hiding the dialog), I cannot un-hide the dialog!
I have to set it to "top" layer to be able to see it again.

Apart from this being some fluxbox bug, being able to group these windows, too, would be a possibility. On the other hand, grouping a one-line-two-buttons dialog results in it bein expanded to full main window size in fluxbox.
Also, I definetely do not want to group the search dialog, because that hides the text that I search in.

I have this behaviour on konqueror (the KDE web browser), I just grouped it by "konqueror" WM_CLASS and this results in the search dialog being put into the same tabbed window group so that I cannot see the website I am searching in.

But for beingfully compilant, all windows seem to have to have the WM_CLASS set according to binary name or user choice.
That would mean that I'd have to start from the beginning to distinguish the editor windows from the random dialog...
But, hey - That'd be even better, in fact: I can set the layer of these dialogs that disappear behind editor windows to "top" and they won't disappear anymore!

But I don't see a good way for this in this ICCCM - it seems to assume one window / one kind of window per X application.
I'd like an extra field for for identifying a window inside an application.
Window titles / WM_NAME are not working since set after creating window (apparently) and would be crude anyway.

Is see that the current use of WM_CLASS really follows the idea to identify a window by function inside nedit. Actually, all I really want is that and the ability to distinguish differently named servers.

Does someone see room for that in the ICCCM? I don't and I think that's a flaw of the ICCCM or X for that matter...
So, being limited to WM_CLASS as only reliable data field for identifying by window manager and also being limited to two strings in that field with one of them static for Xresources usage, I think that the idea that I expressed in my patch seems like the only solution, with some user control added:


1. normal behaviour: follow the ICCCM convention, so normally

WM_CLASS(STRING) = "nedit", "NEdit"

or

WM_CLASS(STRING) = "user-defined", "NEdit"

for _all_ nedit windows (-name option, env var).


2. user option for being able to idenfity every kind of nedit window, then:

WM_CLASS(STRING) = "windowtype", "NEdit"

like it is currently, or when -svrname was specified:

WM_CLASS(STRING) = "windowtype:servername", "NEdit"


But anyway, we have to separate WM_CLASS from the XtName that is used to identify the different windows in nedit to be able to reliably work in all of these cases.

What do you think about this?


Alrighty then,

Thomas.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://www.nedit.org/pipermail/discuss/attachments/20061004/ff6aee0e/attachment.bin