Re: FVWM: style doesn't work with the xzoom program
On 15 January 2013 10:32, Pierre Frenkiel wrote: > hi everynody, > I have a lot of "style" settings, and up to now all worked perfwctly. > Today, I added a line for xzoom > > Style "xzoom" NoTitle, NoHandles, Sticky > > but these settings are ignored for all xzoom windows. > > Any idea? On FreeBSD: [~] » xprop WM_NAME(STRING) = "xzoom x2" _NET_WM_DESKTOP(CARDINAL) = 2 WM_ICON_NAME(STRING) = "xzoom" [~] » So there you go: Style xzoom* whatever It's a bit naughty this window doesn't have a Class or resource value, mind. But that's OK. -- Thomas Adam
Re: FVWM: style doesn't work with the xzoom program
Thomas Adam writes: > On 15 January 2013 18:41, Dan Espen wrote: >> Thomas Adam writes: >> >>> On 15 January 2013 10:32, Pierre Frenkiel wrote: hi everynody, I have a lot of "style" settings, and up to now all worked perfwctly. Today, I added a line for xzoom Style "xzoom" NoTitle, NoHandles, Sticky but these settings are ignored for all xzoom windows. Any idea? >>> >>> What does FvwmIdent tell you about the name/class/resource of such a window? >> >> If I recall, 2 things can cause a bad style match, > > Three; you missed one. :P > >> first, as you suggest, the windows may not have an intuitive >> name/class/resource. >> That we can see with FvwmIdent. >> >> The other is that the window is created with some other name and then >> gets it's name/class/resource later. I forget how we diagnose that, >> is it FvwmDebug? > > BugOpts DisplayNewWindowNames Duh. Looked at BugOpts twice, and here it says: "This can help in finding the correct strings to use in the Style command." Talk about needing a page magnifier. > Note that a window's class cannot be changed once the window is > mapped; only in the WithDrawn state. I've mentioned this a few times > before on this list; only one or two GTK apps that I know of decide to > change their title after the window has been mapped; transitioning > from FVWM's default of "NoName" to something else -- but that won't be > what's happening with XZoom. > > The third one is that style line ordering matters a great deal in the > config file. Well, yeah, but... -- Dan Espen
Re: FVWM: style doesn't work with the xzoom program
On 15 January 2013 18:41, Dan Espen wrote: > Thomas Adam writes: > >> On 15 January 2013 10:32, Pierre Frenkiel wrote: >>> hi everynody, >>> I have a lot of "style" settings, and up to now all worked perfwctly. >>> Today, I added a line for xzoom >>> >>> Style "xzoom" NoTitle, NoHandles, Sticky >>> >>> but these settings are ignored for all xzoom windows. >>> >>> Any idea? >> >> What does FvwmIdent tell you about the name/class/resource of such a window? > > If I recall, 2 things can cause a bad style match, Three; you missed one. :P > first, as you suggest, the windows may not have an intuitive > name/class/resource. > That we can see with FvwmIdent. > > The other is that the window is created with some other name and then > gets it's name/class/resource later. I forget how we diagnose that, > is it FvwmDebug? BugOpts DisplayNewWindowNames Note that a window's class cannot be changed once the window is mapped; only in the WithDrawn state. I've mentioned this a few times before on this list; only one or two GTK apps that I know of decide to change their title after the window has been mapped; transitioning from FVWM's default of "NoName" to something else -- but that won't be what's happening with XZoom. The third one is that style line ordering matters a great deal in the config file. -- Thomas Adam
Re: FVWM: style doesn't work with the xzoom program
Thomas Adam writes: > On 15 January 2013 10:32, Pierre Frenkiel wrote: >> hi everynody, >> I have a lot of "style" settings, and up to now all worked perfwctly. >> Today, I added a line for xzoom >> >> Style "xzoom" NoTitle, NoHandles, Sticky >> >> but these settings are ignored for all xzoom windows. >> >> Any idea? > > What does FvwmIdent tell you about the name/class/resource of such a window? If I recall, 2 things can cause a bad style match, first, as you suggest, the windows may not have an intuitive name/class/resource. That we can see with FvwmIdent. The other is that the window is created with some other name and then gets it's name/class/resource later. I forget how we diagnose that, is it FvwmDebug? Oddly, can't find Fedora package for xzoom. -- Dan Espen
Re: FVWM: style doesn't work with the xzoom program
On 15 January 2013 10:32, Pierre Frenkiel wrote: > hi everynody, > I have a lot of "style" settings, and up to now all worked perfwctly. > Today, I added a line for xzoom > > Style "xzoom" NoTitle, NoHandles, Sticky > > but these settings are ignored for all xzoom windows. > > Any idea? What does FvwmIdent tell you about the name/class/resource of such a window? -- Thomas Adam
FVWM: style doesn't work with the xzoom program
hi everynody, I have a lot of "style" settings, and up to now all worked perfwctly. Today, I added a line for xzoom Style "xzoom" NoTitle, NoHandles, Sticky but these settings are ignored for all xzoom windows. Any idea? best regards, -- Pierre Frenkiel
Re: FVWM: Meaning of the right-hand field of the popup window list
On 15 January 2013 09:15, Sian Mountbatten wrote: > On 2013-01-15 09:14, Thomas Adam wrote: >> >> >> Yes, I understand that, but its size is definitely NOT its position. >> The bug is that windowlist.c knows nothing of shaded windows when >> reporting their geometry. >> >> Will commit a fix for this in a bit unless someone else does it first. >> >> -- Thomas Adam > > Ok, but that doesn't explain the negative height and zero width. Where does > that come from? The *actual* size of the window. -- Thomas Adam
Re: FVWM: Meaning of the right-hand field of the popup window list
On 15 January 2013 09:01, Sian Mountbatten wrote: > On 2013-01-15 09:00, Thomas Adam wrote: >> >> On 15 January 2013 08:52, Sian Mountbatten > It does, thank you >> Thomas. But how can a window have negative height and >>> >>> zero width? >>> I may say that the windows in the list shown with negative height are >>> shaded. Does that >>> affect the geometry? >> >> Because the geometry of a window includes its *position*. >> >> -- Thomas Adam > > Yes, I understand that, but its size is definitely NOT its position. The bug is that windowlist.c knows nothing of shaded windows when reporting their geometry. Will commit a fix for this in a bit unless someone else does it first. -- Thomas Adam
Re: FVWM: Meaning of the right-hand field of the popup window list
On 15 January 2013 08:52, Sian Mountbatten > It does, thank you Thomas. But how can a window have negative height and > zero width? > I may say that the windows in the list shown with negative height are > shaded. Does that > affect the geometry? Because the geometry of a window includes its *position*. -- Thomas Adam
Re: FVWM: Meaning of the right-hand field of the popup window list
On 2013-01-15 08:47, Thomas Funk wrote: Can anybody explain the meaning of the numbers of the last field. http://www.fvwm.org/doc/unstable/commands/WindowList.html "The format of the geometry part is: desk(layer): x-geometry sticky, where desk and layer are the corresponding numbers and sticky is empty or a capital S. The geometry of iconified windows is shown in parentheses." Hope this helps. Regards, Thomas It does, thank you Thomas. But how can a window have negative height and zero width? I may say that the windows in the list shown with negative height are shaded. Does that affect the geometry? Regards -- Sian Mountbatten Specialisto pri Algol 68
Re: FVWM: Meaning of the right-hand field of the popup window list
> Can anybody explain the meaning of the numbers of the last field. http://www.fvwm.org/doc/unstable/commands/WindowList.html "The format of the geometry part is: desk(layer): x-geometry sticky, where desk and layer are the corresponding numbers and sticky is empty or a capital S. The geometry of iconified windows is shown in parentheses." Hope this helps. Regards, Thomas
