Re: Manpage fix for 2.5.17: Wait command.
On Sat, 29 Jul 2006 10:50:21 +0200 Dominik Vogt <[EMAIL PROTECTED]> wrote: > On Fri, Jul 28, 2006 at 11:30:19AM +0100, Thomas Adam wrote: > > Scott -- > > > > On Fri, 28 Jul 2006 15:27:22 +1000 Scott Smedley <[EMAIL PROTECTED]> wrote: > > > > > Hi Thomas, > > > > > > > I noticed earlier that there is a discrepency in the FVWM manpage > > > > (2.5.X series is the only one to be fixed) for the Wait command > > > > description. The description says initially that the command waits > > > > of "windowname". This is parly true -- the code in builtins.c > > > > apparently also checks for the window's tile, class and resource > > > > (just like how the style command works). > > > > > > > > I feel this needs to be reflected in its description > > > > > > ... > > > > > > > +.BI "Wait [" windowtitle | windowclass | windowresource "]" > > > > > > Personally, I think it would be prudent to stick with "windowname" here. > > > A novice user might think it appropriate to specify, say, a window > > > resource & then be surprised to learn that some other window with a > > > matching _title_ was matched. > > > > > > That's fine, and it makes sense of course. Quite often a window's name > > (as it appears on the titlebar) is taken from WM_TITLE anyway. > > > > > > > How about: > > > > > > Wait windowname > > > This command is intended to be used in fvwm functions only. It > > > causes execution of a function to pause until a new window > > > matching windowname appears. A window can match windowname on either its > > > title, class or resource. This is particularly useful in > > > "InitFunction" if you are trying to start windows on specific > > > desks or pages: > > > > > > It's still not perfect - any suggested improvements? > > Why not just use the same text as the style command: > > stylename can be a window's name, class, or resource string. It > may contain the wildcards '*' and '?', which are matched in the > usual Unix filename manner. > > Stylename should be replaced by something neutral, maybe just > "window". That works for me, but other than agreeing with it, there's nothing more I can do to correct it. :) -- Thomas Adam -- ThisWindow (thomas_adam) Destroy
Re: Title font color broken
On Tue, Jun 06, 2006 at 03:29:39PM -0400, Dan Espen wrote: > "Serge (gentoosiast) Koksharov" <[EMAIL PROTECTED]> writes: > > On Sun, Jun 04, 2006 at 11:15:29AM +0200, Dominik Vogt wrote: > > > Unfortunately I never got any feedback on this from the person who > > > reported it first. The problem was that in some cases the GC used > > > to draw the title was not set before drawing, but it seems the old > > > code relied on this not being done. > > > > > > I'd be grateful if someone could look into this problem or at > > > least give me a minimal config to reproduce it. > > > > I can confirm Dan's bugreport. And it easily reproducable with minimal > > config: > > > > I compile FVWM like this: > > > > aclocal > > autoheader > > automake --add-missing > > autoreconf > > ./configure --prefix=$HOME/usr --oldincludedir=$HOME/usr/include \ > > --enable-xft --disable-xinerama --enable-iconv --disable-bidi \ > > --enable-perllib --enable-nls --enable-gtk --with-x > > --without-rplay-library \ > > --without-gnome > > make && make install > > > > Then I move entire ~/.fvwm directory somewhere: > > > > $ mv ~/.fvwm ~/usr/src > > > > Create new empty directory: > > > > mkdir ~/.fvwm > > > > Create '~/.fvwm/config' file consisting of two lines: > > > > Style * ForeColor red > > Style * HilightFore red > > > > Launch FVWM and see that titles of both active and inactive windows > > are black, but not red. > > > > I hope you can reproduce it as well and fix this bug. If not, you can > > provide me with instructions what to do next and I'll be more than > > glad to help. > > Dominik posted a patch containing the commit that caused the > problem. He asked for help trying to recreate the original > problem he was trying to patch. > > We could just revert his patch, but the original problem would > remain unsolved. > > I haven't had any time to look into this yet. Fixed. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
CVS domivogt: * Fixed title colour drawing problem.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt06/07/29 16:11:59 Modified files: . : ChangeLog NEWS libs : Flocale.c Log message: * Fixed title colour drawing problem.
CVS domivogt: * NEWS for previous commit.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt06/07/29 15:44:13 Modified files: . : NEWS Log message: * NEWS for previous commit.
CVS domivogt: * Fixed ewmh/initial fullscreen bug.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt06/07/29 15:43:34 Modified files: . : ChangeLog fvwm : ewmh.c ewmh_events.c Log message: * Fixed ewmh/initial fullscreen bug.
Re: Manpage fix for 2.5.17: Wait command.
On Fri, Jul 28, 2006 at 11:30:19AM +0100, Thomas Adam wrote: > Scott -- > > On Fri, 28 Jul 2006 15:27:22 +1000 Scott Smedley <[EMAIL PROTECTED]> wrote: > > > Hi Thomas, > > > > > I noticed earlier that there is a discrepency in the FVWM manpage (2.5.X > > > series is the only one to be fixed) for the Wait command description. The > > > description says initially that the command waits of "windowname". This > > > is parly true -- the code in builtins.c apparently also checks for the > > > window's tile, class and resource (just like how the style command works). > > > > > > I feel this needs to be reflected in its description > > > > ... > > > > > +.BI "Wait [" windowtitle | windowclass | windowresource "]" > > > > Personally, I think it would be prudent to stick with "windowname" here. > > A novice user might think it appropriate to specify, say, a window resource > > & then be surprised to learn that some other window with a matching > > _title_ was matched. > > > That's fine, and it makes sense of course. Quite often a window's name (as > it appears on the titlebar) is taken from WM_TITLE anyway. > > > > How about: > > > > Wait windowname > > This command is intended to be used in fvwm functions only. It > > causes execution of a function to pause until a new window matching > > windowname appears. A window can match windowname on either its > > title, class or resource. This is particularly useful in > > "InitFunction" if you are trying to start windows on specific desks > > or pages: > > > > It's still not perfect - any suggested improvements? Why not just use the same text as the style command: stylename can be a window's name, class, or resource string. It may contain the wildcards '*' and '?', which are matched in the usual Unix filename manner. Stylename should be replaced by something neutral, maybe just "window". > That's better. I still think it is wise to specify in the syntax for the > command the fact that one can have: windowname, windowclass, windowresource > -- and while I realise this forces a slight amount of Xlib knowledge onto the > user, it does clarify the list of options one can use to that command. When > I first read it I was confused, since it did (to me) read as though the > window's name was only considered. > > > > > Note that in the function example accompanying the Wait command's > > > description, I have taken the liberty of replacing the function's use of > > > the "Desk" command with "GotoDesk" since this is now the preferred > > > command to use. > > > > Ok. > > > > > ThisWindow (thomas_adam) Destroy > > > > ThisWindow (thomas_adam) Wait godo :) Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
CVS domivogt: * Removed reference to 1.x-commands at beginning of the "Style" command in the
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt06/07/29 03:49:07 Modified files: fvwm : fvwm.1.in Log message: * Removed reference to 1.x-commands at beginning of the "Style" command in the man page.
