Re: Notification: incoming/912
Dominik, I saw that you closed that bug. I agree - for the loosing windows part. The ignoring _NET_WM_DESKTOP part is still an open bug, IMO. Matthias -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Notification: incoming/912
On Fri, Aug 16, 2002 at 04:33:19PM +0200, Matthias Clasen wrote: Dominik, I saw that you closed that bug. I agree - for the loosing windows part. The ignoring _NET_WM_DESKTOP part is still an open bug, IMO. I disagree on this one. The old window manager can not know how many desktops the user has configured in fvwm (and actually not even fvwm knows it because it's a dynamic thing the users does, not a fixed setting). So dumping windows on any other but the default desktop may well cause them to be lost forever. Maybe an option to the -replace option is in order. I think fvwm should pick up the number of desktops from _NET_NUMBER_OF_DESKTOPS (left behind by the previous wm) and falling short of that it could at least put windows on the the closest available desktop (i.e. if you find a toplevel with _NET_WM_DESKTOP=20 but fvwm is configured with a fixed set of 4 desktops, put the toplevel on desk 4...) Out of interest, does fvwm implement the following aspect of EWMH ? The Window Manager should honor _NET_WM_DESKTOP whenever a withdrawn window requests to be mapped. If yes, how does it handle invalid desktop numbers there ? Matthias -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Notification: incoming/912
On Thu, 2002-08-08 at 19:26, Dominik Vogt wrote: When fvwm takes over from metacity, it seems to ignore the _NET_WM_DESKTOP properties left behind by metacity. Worse, windows which are not on the first desk sometimes get completely lost - they don't appear on any desk, but switching back to metacity makes them reappear at the right position. Could you point me to the spec and the specific place that states how the _NET_WM_DESTOP property should be handled? I'd assume the window manager is resposible of deleting this property from the client window and map all windows on all desks when it terminates. How else should the WM find out about windows that are not mapped when it starts and that are never mapped by the application? Yes, the leaving WM is responsible for mapping all windows (actually I think this is automatic as part of save-set handling). The CVS version of the EWMH 1.2 draft (still not available online...) specifies that the _NET_WM_DESKTOP and _NET_WM_STATE properties should be cleared upon withdrawal of a window, but left in place in case of loosing ownership of the manager selection, so that the next wm can pick them up. Matthias -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: SGI Xinerama API
Very interesting link, I wasn't aware of the xinerama sourceforge project. To add to your speculation regarding the relations between the xinerama apis: Since the sourceforge project leader and the x org xinerama task force chair are the same person and Mark V of xfree86 is also a sourceforge project member, I guess there is hope for 2), 3) and 4) to converge. Matthias -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: a naive Xinerama question
By the way, Matthias, is there anything that has to be done to make FvwmGtk Xinerama compatible? Well, its been a long time since I last looked at that code... compatible is perhaps not the right term here. Any X application should be Xinerama compatible, since after all its just an extension that can be ignored. If you ask for Xinerama-aware, then the answer would probably be: make gtk+ Xinerama-aware. Which won't happen before gtk+ is extended for multiple screens/displays. Which won't happen before gtk+ 2.2. Matthias -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: a naive Xinerama question
But it would certainly be a useful addition to the Xinerama extension to send EnterXineramaHead and LeaveXineramaHead events - IIRC X extensions can introduce new events. If these events contain the a head number, interested applications can then easily maintain information about the set of heads the pointer is in (even for the pathological case of overlapping heads). Well, this *can* be a useful addition if we find a real case when it is needed. Than we can try to persuade Mark Vojkovich to add this functionality to X (BTW, what is interesting -- he also uses fvwm). But there must be some real, hard arguments, otherwise this definitely wouldn't pass the X Xinerama group. All the same reasons why you want to get enter and leave events on the root window in multi-screen scenarios, I guess. Of course, the application with the strongest interest in such information is the window manager, but toolkits could also use it as a low-overhead way to find the necessary information for e.g. restricting menus to be completely onscreen (or rather onxineramascreen). In fact, I would thing that enter/leave notification would be a very natural feature and I can't think of any possible reasons for the X Xinerama group to not accept it. Matthias -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
