[bugs #6875] Use of _KDE_NET_WM_WINDOW_TYPE_OVERRIDE instead of _NET_WM_WINDOW_TYPE_UTILITY == BAD

[Fred Kiefer]

This mail is an automated notification from the bugs tracker
 of the project: GNUstep.

/**************************************************************************/
[bugs #6875] Latest Modifications:

Changes by: 
                Fred Kiefer <FredKiefer@gmx.de>
'Date: 
                Sun 11/30/2003 at 15:04 (GMT)

            What     | Removed                   | Added
---------------------------------------------------------------------------
         Assigned to | None                      | FredKiefer
              Status | Open                      | Analyzed


------------------ Additional Follow-up Comments ----------------------------
I can understadn that this behaviour annoys you. The reason for the current 
solution in GNUstep is that it was the only combination of settings that worked 
for me when testing it with 5 different window managers. Now there is a new 
one, where it wont work any more. 
I am open to any new solution, given that we keep on working on the previous 
environments. I don't want any discussion of "your window manager is more 
broken than my", or "All real GNUstep users use window manager XXX".

But back to the actual problem. The KDE override flag is a KDE specific hack 
that should be ignored by all other window managers. These should use the 
second atom, which is type menu. Not too bad for a menu? As you can see from 
the code I did try utility here as well, but this failed for some of my window 
managers. Sorry, I should have documented which one, now I cannot remember 
anymore.

The basic problem here is that the EWMH have a different concept behind their 
window type flags than OpenStep with the window levels. In OpenStep the setting 
of the level should not influence the window decoration at all. But we have to 
make do the best we can and the concept of specifing the usage of a window 
instead of giving all the separate attributes independend is a good one. The 
next problem is that EWMH has been implemented very differently and the 
interpretation from Interface seems to differ from what KDE, GNOME and other 
do. I wont say that Interface is wrong, it is just that EWMH does not say, what 
the different window types should result in.
I will raise a question on this issue on the Freedesktop mailing list, but for 
the moment being a change in Interface would be the easiest solution.






/**************************************************************************/
[bugs #6875] Full Item Snapshot:

URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=6875>
Project: GNUstep
Submitted by: 0
On: Sun 11/30/2003 at 02:36

Category:  Backend
Severity:  5 - Average
Item Group:  Bug
Resolution:  None
Assigned to:  FredKiefer
Status:  Analyzed


Summary:  Use of _KDE_NET_WM_WINDOW_TYPE_OVERRIDE instead of 
_NET_WM_WINDOW_TYPE_UTILITY == BAD

Original Submission:  The use of the atom _KDE_NET_WM_WINDOW_TYPE_OVERRIDE for 
GNUstep application menus, rather than _NET_WM_WINDOW_TYPE_UTILITY, to avoid 
problems under KDE causes these same problems (i.e. borders on windows) under 
non-KDE, EWMH-compliant window managers.  Like Interface :-)



File: source/gnustep/core/back/Source/x11/XGServerWindow.m



Follow-up Comments
------------------


-------------------------------------------------------
Date: Sun 11/30/2003 at 15:04       By: FredKiefer
I can understadn that this behaviour annoys you. The reason for the current 
solution in GNUstep is that it was the only combination of settings that worked 
for me when testing it with 5 different window managers. Now there is a new 
one, where it wont work any more. 
I am open to any new solution, given that we keep on working on the previous 
environments. I don't want any discussion of "your window manager is more 
broken than my", or "All real GNUstep users use window manager XXX".

But back to the actual problem. The KDE override flag is a KDE specific hack 
that should be ignored by all other window managers. These should use the 
second atom, which is type menu. Not too bad for a menu? As you can see from 
the code I did try utility here as well, but this failed for some of my window 
managers. Sorry, I should have documented which one, now I cannot remember 
anymore.

The basic problem here is that the EWMH have a different concept behind their 
window type flags than OpenStep with the window levels. In OpenStep the setting 
of the level should not influence the window decoration at all. But we have to 
make do the best we can and the concept of specifing the usage of a window 
instead of giving all the separate attributes independend is a good one. The 
next problem is that EWMH has been implemented very differently and the 
interpretation from Interface seems to differ from what KDE, GNOME and other 
do. I wont say that Interface is wrong, it is just that EWMH does not say, what 
the different window types should result in.
I will raise a question on this issue on the Freedesktop mailing list, but for 
the moment being a change in Interface would be the easiest solution.












For detailed info, follow this link:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=6875>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/