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 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
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 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
Dominik, I think the problem of windows being lost is a metacity bug. It leaves unmapped toplevels with WM_STATE.state == NormalState behind. fvwm won't manage those. See http://bugzilla.gnome.org/show_bug.cgi?id=90369 for details. Matthias -- Visit the official FVWM web page at 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
> So, is the "windows don't appear on any desk" part a bug or not? Yes, I consider that a bug, although I'm not sure if the problem is on Metacitys side or on fvwms. I'll do some more investigation and report back. The current draft of the EWMH is now online, btw. Matthias -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net -- Visit the official FVWM web page at 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 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 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 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 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]
