bugGNUstep - Bugs: bug #13592, All windows of GNUstep...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #13592: All windows of GNUstep applications share same WM_CLASS

Submitted by:  Adam Fedor <fedor>
Submitted on:  Fri 01 Jul 2005 12:48:27 AM UTC  
 
Category:  Backend Severity:  3 - Normal
Item Group:  Change Request Status:  Wont Fix
Privacy:  Public Assigned to:  Fred Kiefer <FredKiefer>
Open/Closed:  Declined

Fri 12 Oct 2007 10:23:39 AM UTC, comment #2:

I am decling this request as the originator never added detail information of what he wanted.
The usage of a window in GNUstep can only be determined via the window level and this may change, whereas the window class of a window is not allowed to change. So one isn't a great match for the other.
What we need to support in GNUstep is a better way to tell the window manager, what a window is being used for. Here we try to use EWMH, which should more or less already work.

Fred Kiefer <FredKiefer>
Project MemberIn charge of this item.
Mon 17 Oct 2005 12:15:28 PM UTC, comment #1:

I am willing to implement a patch here, but based on which data, available to the backend, should the window class be choosen? Should we change the window class, when that property changes?

Fred Kiefer <FredKiefer>
Project MemberIn charge of this item.
Fri 01 Jul 2005 12:48:27 AM UTC, original submission:

Package: gnustep-gui
Version: 0.9.5-1
Tags: forwarded

[If you reply, please keep the CC to nnn@bugs.debian.org]

All windows of the GNUstep applications share the same WM_CLASS
property. This includes even the menu and makes impossible for the user
to configure properly the window manager. If the user decides to make
the menu not a member in the window list then all application windows
will be outside the window list. If a user decides to make the
Inspector of GWorkspace a floating (to stay always over the other
windows) then all windows of GWorkspace will be floating.

Anton Zinoviev

Adam Fedor <fedor>
Project Administrator

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by FredKiefer (Posted a comment)
  • -email is unavailable- added by fedor
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2007-10-12 FredKiefer StatusNone => Wont Fix
        Assigned toNone => FredKiefer
        Open/ClosedOpen => Declined
    2005-07-01 fedor Carbon-Copy- => Added -email is unavailable-

    Back to the top


    Powered by Savane 3.4