On Tue, Apr 15, 2008 at 11:10:52PM +0400, Evgeniy Zhemchugov wrote:
> Dear fvwm developers,
>
> I'm using FVWM as a windows manager and Pidgin (it was called Gaim
> previously) as an IM client. I would like to bind a key to bring the
> Pidgin conversation window on top. However, Pidgin uses only the
> WM_WINDOW_ROLE hint to differentiate between its windows and Pidgin
> developers claim that they do the right thing (see
> http://developer.pidgin.im/wiki/Using
> Pidgin#WhydoesPidginusethesameWM_CLASSforeverywindow). Since FVWM
> doesn't support WM_WINDOW_ROLE hint, that leaves windows of
> applications respectful to the GTK+ documentation indistinguishable.
They can still be distinguisehd by their names, which is the
primary purpose of window names. The WM_WINDOW_ROLE property is
used in combination with the SM_CLIENT_ID property to uniquely
identify a window for session management purposes.
In other words, the WM_WINDOW_ROLE identifies the role of a window
*in the context of a specific instance* of an application. It is
*not* meant to distinguish between windows of different
applications, or between windows of different instances of one
appication. For example, windows library may generate dynamic
role names the windows created by an instance of an application
(e.g. "win1", "win2", "win3"), or it may give the same role name
to the main windows of all applications ("main window").
To sum it up, the pidgin/gaim folks' reasoning is wrong. They
completely misunderstood the purpose of the WM_WINDOW_ROLE and
WM_CLASS properties, and claiming that everybody else is wrong
does not help the matter. However, since the gaim windows seem to
have different window names, these can be used to distinguish the
windows (but I'm not able to create a "conversation" window, and
I have no idea what pidgin/gaim does and how to configure it to
show such a window).
> For that reason I have created a patch that adds WM_WINDOW_ROLE to the
> list of window properties used to uniquely identify the window. The
> patch was created against FVWM's today cvs. I'm not sure if it is
> complete in sense that all places where window is being tested to
> match user-supplied string are covered.
>
> For the modules, I have patched only FvwmIdent (to make it show the
> WM_WINDOWSS_ROLE value) and FvwmScript (since it didn't compile
> otherwise).
>
> I have been working with patched FVWM for about two weeks now and
> everything seems fine. However, I have not tested the modules (with
> except of FvwmIdent) since I use none of them.
Basically, adding flexibility to fvwm is good, but I'm reluctant
to apply such a large patch just because the developers of *one*
application are misunderstanding the ICCCM2.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
