CVS domivogt: * Menu drawing fix.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/08/25 06:22:42 Modified files: . : ChangeLog fvwm : Makefile.am menuitem.h menus.c windowlist.c modules: ChangeLog modules/FvwmButtons: Makefile.am modules/FvwmForm: Makefile.am modules/FvwmIconBox: Makefile.am modules/FvwmIconMan: Makefile.am modules/FvwmIdent: Makefile.am modules/FvwmPager: Makefile.am modules/FvwmScript: Makefile.am modules/FvwmWinList: Makefile.am Log message: * Menu drawing fix. * Linking error fix. * Some general cleanup. -- 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: xview program resize delay
On Fri, Aug 23, 2002 at 02:08:48PM -0700, elliot sowadsky wrote: Hmmmon the 20020817 snap, i'm finding that on opening new windows, i'm getting blocked from focusing windows. No matter what i click into, it wont take focus. Turns out i need a Modifierclick to get focus after a map. Using clicktofocus mode. Please try a newer snapshot. If it still happens, strib down your config file to the bare minimum to make it happen and post it along with exact instructions to make it happen. Traced this to focus.c __check_allow_focus xview appears to want to refuse focus in order to get focus. (?) xview window often has sf == NULL. Hence __check_allow_focus returns True and xview window doesnt get focus. I added if (sf == NULL) return False; // xview may have this condition and now xview is getting focus. I dont get itbut it seems to work. Ahem, this effectively prevents that any window not using the WM_TAKES_FOCUS protocol ever gets focus unless another window is already focused. Also, on WindowList ShowPage, it shows the page being viewed rather than the page each window is on. I use sprintf(loc,%d ,((t-frame_g.x) + Scr.Vx)/Scr.MyDisplayWidth); Oops :-) Fixed. I have a 1-D pager, so i only show one number. I also always show it to the left of the title. Well, this has to wait a bit longer. Perhaps I'll implement some kind of format string that gives detailed control over the layout. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- 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: MenuFace TiledPixmap (patch)
On Sat, Aug 24, 2002 at 04:12:18PM -0400, Suzanne Skinner wrote: Developers, Here's a patch for the MenuFace TiledPixmap bug that I submitted yesterday :-) Actually, that patch removes only the symptom, not the root cause of the problem. The parts not covered by the sub menu should have never been cleared in the first place. I'll commit a fix. --- fvwm/menus.c.orig Sat Aug 24 13:45:58 2002 +++ fvwm/menus.c Sat Aug 24 13:48:36 2002 @@ -4155,6 +4155,8 @@ /* be smart about handling the expose, redraw only the entries * that we need to */ if (pevent == NULL || +(ms (ST_FACE(ms).type == PixmapMenu || +ST_FACE(ms).type == TiledPixmapMenu)) || (pevent-xexpose.y (MI_Y_OFFSET(mi) + MI_HEIGHT(mi)) (pevent-xexpose.y + pevent-xexpose.height) MI_Y_OFFSET(mi))) Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- 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]
ChangleLog format request
I think it would be better to not use regexp or shell patterns a
la
* fvwm/foo.[ch]:
or
* fvwm/{fvwm,events}.c:
in the ChangeLog files. This makes it hard to search for specific
changes in the file.
Bye
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
--
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: CVS domivogt: * Fixed TitleAt... styles.
On Fri, Aug 23, 2002 at 09:37:08PM -0500, Dave Trollope wrote: Hi, Sometime back I reported that some make files were badly created putting -lfvwm in the wrong pace on the LDADD line, and I asked for feedback. I got none, so here is the patch! This patch fixes the LDADD variable in a number of places because -lfvwm must be before the Xft library. Dominik, please apply this to the node. This was created against 2.5.3 Done, but not a single chunk of the patch applied to CVS automatically. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- 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]
CVS domivogt: * Updated for 2.5.3 release.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/08/25 06:27:22 Modified files: . : ChangeLog NEWS configure.in Log message: * Updated for 2.5.3 release. -- 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]
CVS domivogt: * Updated for 2.5.4-devel.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/08/25 06:38:53 Modified files: . : ChangeLog NEWS configure.in Log message: * Updated for 2.5.4-devel. -- 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]
CVS domivogt fvwm-web: * Updated web for 2.5.3.
CVSROOT:/home/cvs/fvwm Module name:fvwm-web Changes by: domivogt02/08/25 06:39:24 Modified files: . : ChangeLog download.html index.html generated : AUTHORS.html FAQ.html NEWS.html Log message: * Updated web for 2.5.3. -- 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]
fvwm-2.5.3 has been released
Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- 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]
CVS domivogt: * Style switches (and only switches) can be reversed with a '!' prefix.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/08/25 07:17:58 Modified files: . : ChangeLog NEWS fvwm : style.c Log message: * Style switches (and only switches) can be reversed with a '!' prefix. -- 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: dynamism in FvwmButtons
On 03 Jun 2002 18:43:55 +0200, Dominik Vogt wrote: On Wed, May 29, 2002 at 09:22:16PM +, Mikhael Goikhman wrote: On 29 May 2002 20:59:58 +, Mikhael Goikhman wrote: SendToModule FvwmButtons ChangeButton button-id Title/Icon value button-id may be as it is now, number starting from 0 or +x+y. I will also add a syntax similar to 2/3 meaning the button number 3 in the container number 2. Should the syntax start counting from 0 or 1? One addition. Id will be optionally specified in any button, i.e.: *FvwmButtons: (Id current_time, Title 14:00) SendToModule FvwmButtons ChangeButton current_time Title 14:01 I wonder if there is a better method than the SendToModule stuff with a different syntax for all modules. It shouldn't be too difficult to ose the usual *ModuleName: ... syntax, e.g. *FvwmButtons: (button id, Icon foo.xpm, Title bar) I tried to examine this approach, but this does not seem to work well. The idea could be this. If a new button definition has the existing id, instead of creating a new button the existing one is modified. Ideally, it should be irrelevant whether the modification line is issued before FvwmButtons is started or after, but this seems difficult to implement. The following: *FvwmButtons: (Id dyna-button1, Icon icon.xpm, Padding 2 2) ... # either statically or dynamically: *FvwmButtons: (Id dyna-button1, Text text, Icon) should be equivalent to: *FvwmButtons: (Id dyna-button1, Text text, Padding 2 2) It involves the geometry changes with minimal redraws... This would be nice to have, but I am not sure how many people need this. Another problem with this approach other than difficulty to implement is that if the change is done often, for example, every minute, we end up with thousands of module config lines to be stored and processed on a new module startup. So for now, there is a clear division between the static configuration using *FvwmButtons: lines and dynamical changes using SendToModule actions. I will commit the initial step soon. Regards, Mikhael. -- 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: fvwm-2.5.3 has been released
All in place now. - J -- 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]
CVS domivogt: * Major menu code clean up.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/08/25 11:41:56 Modified files: . : ChangeLog fvwm : menus.c menus.h Log message: * Major menu code clean up. -- 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]
configure.in glitch
There's a small glitch in the configure script in current CVS (see attachment). Suzanne -- [EMAIL PROTECTED] - http://www.igs.net/~tril/ --- configure.in.orig Sun Aug 25 14:26:31 2002 +++ configure.inSun Aug 25 14:26:37 2002 @@ -160,7 +160,7 @@ dnl ewmh smr_SWITCH(ewmh, Extended WM Hints Support, on, HAVE_EWMH) -if test x$enable_ewmh != no; then +if test x$enable_ewmh != xno; then with_ewmh=yes problem_ewmh= else
CVS migo: * FvwmButtons: new button option Id
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: migo02/08/25 22:45:13 Modified files: . : ChangeLog configure.in libs : Picture.c Picture.h modules: ChangeLog modules/FvwmButtons: FvwmButtons.1 FvwmButtons.c FvwmButtons.h Makefile.am button.c button.h icons.h parse.c Added files: modules/FvwmButtons: dynamic.c dynamic.h Log message: * FvwmButtons: new button option Id * FvwmButtons: new dynamical messages ChangeButton and ExpandButtonVars * configure: applied the --disable-ewmh fix * added const in several places to make API more clear -- 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: FVWM: Re: .fvwm2rc syntax guide?
On Sat, Aug 24, 2002 at 05:39:10PM -0400, parv wrote: in message [EMAIL PROTECTED], wrote [EMAIL PROTECTED] thusly... So here is a little suggestion to improve the man page: Insert a section (at the beginning) which deals with the basic configuration faqs - and show examples right there. man pages are there for reference. their function is not to be a collection of FAQ's, tutorials what not. they can, however, point to other resources which may provide the help that a beginner may need. Exactly. So we're back to the issue that we need a tutorial. the default F1 key binding (for fvwm help) could/should point to such tutorials FAQ's instead of a man page then. Or maybe not. The F1 key is overloaded already by the various help systems. speaking of which, is there any plan in near future to remove GlobalOpts ... - Style pointers? It may not be in the near future. But the GlobalOpts command *will* be removed in 3.0. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: .fvwm2rc syntax guide?
On Sat, 24 Aug 2002 19:15:05 -0700 Rainer Koehler [EMAIL PROTECTED] wrote: So here is a little suggestion to improve the man page: Insert a section(at the beginning) which deals with the basic configuration faqs - and show examples right there. Most important: Let this section be organized by *the point of view of a beginner* who just wants to change color of background, change the root menu, change the window styles. If he passed that he will have enough starting enegery to go through the rest of the man page. ;-) So, why don't you go ahead and write something like that? [...] Also, I don't think the fvwm developers would be very good at writing a tutorial for beginners. Concidering myself a newbie I'd like to do that. The only problem is: a newbie knows the problems - but can't provide the solutions. I don't think you'll spam the man page if you insert a short section for the main issues beginners have. And, my favorite way to do it is nearly already done: Look at man FvwmIconMan, Configuration Options Reference Chart. Add one single column to it with an example command and there you go. Look, isn't fvwm2 worth it to forget maybe tine a little bit about the guide lines of man pages and follow the wishes of many beginners to fvwm2 - since they'll all start typing m-a-n instead of querying goole for some tutorial? Please excuse my passion - it's just the passion for fvwm2. 'bye Felix -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
FVWM: Colorset updates and tear-off menus
If a colourset used in Menustyle * is updated while a torn-off root menu is on the screen FvwmConsole spits out the following: [FVWM][menustyle_update]: ERROR menu style * is in use [FVWM][menustyle_update]: ERROR menu style * is in use and the colour of the menu is not updated, although the next menu to be posted gets the correct colours. I'm using the snapshot from yesterday (24:th). Is it worth pulling down the latest 2.4.3 (saw it was released today)? //Marcus -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Colorset updates and tear-off menus
I'm using the snapshot from yesterday (24:th). Is it worth pulling down the latest 2.4.3 (saw it was released today)? I mean 2.5.3 (obvioulsly) //Marcus -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED] -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
FVWM: FixedSize and maximising
I have the following lines set: # and some special for TK tear-off menus Style Menu NoButton 2, NoButton 4, NoHandles, FixedSize it's still possible to maximise those windows (through the menu or using FvwmConsole and so on) Shouldn't FixedSize inhibit maximising? //Marcus -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: .fvwm2rc syntax guide?
On Sat, Aug 24, 2002 at 07:15:05PM -0700, Rainer Koehler wrote: Fvwm and its documentation are open source, if there's something you don't like, fix it. If you are able to edit your fvwm2rc, you should be able to write a little text about it, you don't need a degree in computer science for that. Agreed - Except that it's a bit difficult to accurately document something in terms someone else can understand when the documetor doesn't understand it. For example, I've seen the following examples for FvwmTaskBar : From the fvwm webpage : Style FvwmTaskBar NoTitle,BorderWidth 4, HandleWidth 4,Sticky, StaysOnTop,WindowSkipList,CirculateSkip # taskbar *FvwmTaskBar: Back #c3c3c3 *FvwmTaskBar: Fore black *FvwmTaskBar: TipsBack bisque *FvwmTaskBar: TipsFore black *FvwmTaskBar: Geometry +0-0 *FvwmTaskBar: Font -adobe-helvetica-medium-r-*-*-14-*-*-*-*-*-*-* *FvwmTaskBar: SelFont -adobe-helvetica-bold-r-*-*-14-*-*-*-*-*-*-* *FvwmTaskBar: StatusFont fixed From the FvwmTaskBar 2.6 man page on my system : Style FvwmTaskBar NoTitle,BorderWidth 4, HandleWidth 4,Sticky, StaysOnTop,WindowSkipList,CirculateSkip # taskbar *FvwmTaskBarBack #c3c3c3 *FvwmTaskBarFore black *FvwmTaskBarTipsBack bisque *FvwmTaskBarTipsFore black *FvwmTaskBarGeometry +0-1 *FvwmTaskBarFont -adobe-helvetica-medium-r-*-*-14-*-*-*-*-*-*-* *FvwmTaskBarSelFont -adobe-helvetica-bold-r-*-*-14-*-*-*-*-*-*-* *FvwmTaskBarStatusFont fixed I am in no way singling out FvwmTaskBar - I just happened to be working with it lately. The second example works, the first doesn't (as far as I can tell). This is typical of what I'm apparently misunderstanding. It appears that fvwm plays very loose and fast with the config file in terms of syntax? Or am I just missing something? It appears that there's always more than one way to do anything, which I guess has its merits, but is almost always initially more confusing than a tightly controlled syntax. For example, do all of the parts of a function or menu definition need to be in one place (immediately under the AddToFunc or AddToMenu), or can they be spread around. If the latter, what's the advantage? It seems like you'd want them all grouped together anyway, just organizationally. I tend to look on config files in general much like source code - Make them modular, organized and as easy to read as possible. I've seen a couple of replies to my original post that I've yet to read carefully and digest, so I'll not waste bandwidth here asking questions they may answer. However, I do have one concerning FvwmTaskBar (no, make that two) : 1. With BorderWidth and HandleWidth set to 1 or 0, the taskbar doesn't occupy the full width of the screen. Is there a way to force this? 2. When I configure a Popup StartMenu, is there a way to accurately control where it appears on screen, in regard to the Start button? If I understood MenuStyle a bit better, maybe the answer is there (PopupOffset, or whatever it's called)...? OK - One more (general) question : Is there a way to globally turn off mouse pointer warping so that it never warps to a menu, window, whatever? That's one behavior I _really_ would like to get rid of, particularly on popup menus. Thanks. -- +-+ | Len Philpothttp://philpot.org/ | | [EMAIL PROTECTED] [EMAIL PROTECTED] (alt) | +-+ -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: .fvwm2rc syntax guide?
On Sat, Aug 24, 2002 at 10:14:47AM -0400, Dan Espen wrote: Len Philpot [EMAIL PROTECTED] writes: Is there a concise, authoritative guide to the proper syntax, organization and such of .fvwm2rc contents somewhere? What I see in the fvwm man page often conflicts with what's in the sample system.fvwm2rc file Please point out the conflicts so that they can be repaired. I've done so on FvwmTaskBar, at least to a small degree, in another post. At this point, I'm not sure how much is inconsistency and how much is just misunderstanding on my part. For example, the MenuStyle line in the system.fvwm2rc that was installed on my system was in the old style, according to the man page. I was trying to basically get the WIN look, with a couple of things changed. However, I couldn't figure out the precedence, so my changes never took effect. Usually, the menu would revert back to the default look (I presume). For menus, this works: MenuStyle * BorderWidth 10 I suspect you are having problems with the borders on windows. Perhaps you missed this in the man page: Right now, I think my issues are more with an understanding of the fundamental syntax of the config file, not the actual values in it. It's looking more and more to me that conceptually, the config file is a bit like Perl in that there are implied values, multiple syntaxes, shorthand notations, etc. Is this correct? If so, that's something that's always given me the willies, personally. I tend to like a specified way of doing something, but that's my preference. Once I understand this, I'm sure I'll settle on one way. Until then, it's a bit confusing. For example, in your MenuStyle example above, what's the asterisk for? All styles? I guess not, since that doesn't make sense, given the context. Should it be in quotes: *? I've seen it that way as well here and there. I understand about quoting values containing spaces, but how about without them? Is there a definite order to options? Is it case-sensitive? Fvwm may be speedy and small, but the amount of configuration possible is massive. Hence the extremly large man page, and difficulty getting started. What I'm thinking of would be along the lines of what we've all seen in programming tutorials : skeleton diagrams with placeholders showing how everything is specified, in what order, what case, with what punctuation, what's mutually exclusive, what's dependent on each other, etc., etc. Then some simple examples that build on each other, instead of a massive .fvwm2rc that can walk and talk and do the jitterbug. Also, make the examples dovetail with FAQs on how and what can be done. Someone else mentioned what I think is a very good idea: Supply a few different config file samples that contain the same content, but with a differnt look and feel (native, Win95, CDE, etc.). That way, a newbie such as myself could see what does and doesn't change. Just my $0.02. -- +-+ | Len Philpothttp://philpot.org/ | | [EMAIL PROTECTED] [EMAIL PROTECTED] (alt) | +-+ -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: .fvwm2rc syntax guide?
On 25 Aug 2002 16:18:42 -0500, Len Philpot wrote: Agreed - Except that it's a bit difficult to accurately document something in terms someone else can understand when the documetor doesn't understand it. For example, I've seen the following examples for FvwmTaskBar : From the fvwm webpage : Style FvwmTaskBar NoTitle,BorderWidth 4, HandleWidth 4,Sticky, StaysOnTop,WindowSkipList,CirculateSkip # taskbar *FvwmTaskBar: Back #c3c3c3 *FvwmTaskBar: Fore black *FvwmTaskBar: TipsBack bisque *FvwmTaskBar: TipsFore black *FvwmTaskBar: Geometry +0-0 *FvwmTaskBar: Font -adobe-helvetica-medium-r-*-*-14-*-*-*-*-*-*-* *FvwmTaskBar: SelFont -adobe-helvetica-bold-r-*-*-14-*-*-*-*-*-*-* *FvwmTaskBar: StatusFont fixed From the FvwmTaskBar 2.6 man page on my system : Style FvwmTaskBar NoTitle,BorderWidth 4, HandleWidth 4,Sticky, StaysOnTop,WindowSkipList,CirculateSkip # taskbar *FvwmTaskBarBack #c3c3c3 *FvwmTaskBarFore black *FvwmTaskBarTipsBack bisque *FvwmTaskBarTipsFore black *FvwmTaskBarGeometry +0-1 *FvwmTaskBarFont -adobe-helvetica-medium-r-*-*-14-*-*-*-*-*-*-* *FvwmTaskBarSelFont -adobe-helvetica-bold-r-*-*-14-*-*-*-*-*-*-* *FvwmTaskBarStatusFont fixed There is no such version 2.6. The man pages on the web are for fvwm 2.4.x. You seem to use 2.2.x which is very old. Of course, you should contact the man pages matching your version. In 2.4.x both syntaxes should work, but the one in the man page is preferable. I think +0-0 is a more correct geometry than +0-1, but 2.2.x may have some bugs about this. I am in no way singling out FvwmTaskBar - I just happened to be working with it lately. The second example works, the first doesn't (as far as I can tell). This is typical of what I'm apparently misunderstanding. It appears that fvwm plays very loose and fast with the config file in terms of syntax? Or am I just missing something? It appears that there's always more than one way to do anything, which I guess has its merits, but is almost always initially more confusing than a tightly controlled syntax. For example, do all of the parts of a function or menu definition need to be in one place (immediately under the AddToFunc or AddToMenu), or can they be spread around. If the latter, what's the advantage? It seems like you'd want them all grouped together anyway, just organizationally. I tend to look on config files in general much like source code - Make them modular, organized and as easy to read as possible. I've seen a couple of replies to my original post that I've yet to read carefully and digest, so I'll not waste bandwidth here asking questions they may answer. However, I do have one concerning FvwmTaskBar (no, make that two) : 1. With BorderWidth and HandleWidth set to 1 or 0, the taskbar doesn't occupy the full width of the screen. Is there a way to force this? Yes, use the latest stable or unstable versions. 2. When I configure a Popup StartMenu, is there a way to accurately control where it appears on screen, in regard to the Start button? If I understood MenuStyle a bit better, maybe the answer is there (PopupOffset, or whatever it's called)...? Yes, you may do this accurately in 2.5.1+, scan NEWS file. In 2.4.x, you may do this too using Rectangle or Mouse hint (there are examples in fvwm-themes), but not as accurately as in 2.5.x. OK - One more (general) question : Is there a way to globally turn off mouse pointer warping so that it never warps to a menu, window, whatever? That's one behavior I _really_ would like to get rid of, particularly on popup menus. Globally, no. If you bind a menu to a key, it altomatically selects the first selectable menu item (and thus warps the pointer), but after working with such menu the original pointer position is restored. It is good when you work with keyboard only. If you bind a menu to a mouse it does not warp. For example, in the following if you press Ctrl-Shift-F10 it warps, but Ctrl-Shift-Mouse1 does not: Key F10 A CS Menu MenuFvwmRoot Rectangle 1x1+10+10 0 0 Mouse 1 R CS Menu MenuFvwmRoot Rectangle 1x1+10+10 0 0 What exactly annoys you about menus and windows? Provide configurations. Regards, Mikhael. -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: .fvwm2rc syntax guide?
On 25 Aug 2002 16:38:44 -0500, Len Philpot wrote: On Sat, Aug 24, 2002 at 10:14:47AM -0400, Dan Espen wrote: Len Philpot [EMAIL PROTECTED] writes: Is there a concise, authoritative guide to the proper syntax, organization and such of .fvwm2rc contents somewhere? What I see in the fvwm man page often conflicts with what's in the sample system.fvwm2rc file Please point out the conflicts so that they can be repaired. I've done so on FvwmTaskBar, at least to a small degree, in another post. At this point, I'm not sure how much is inconsistency and how much is just misunderstanding on my part. For example, the MenuStyle line in the system.fvwm2rc that was installed on my system was in the old style, according to the man page. I was trying to basically get the WIN look, with a couple of things changed. However, I couldn't figure out the precedence, so my changes never took effect. Usually, the menu would revert back to the default look (I presume). I hope when you install the version that corresponds to the man pages, the man pages may just magically start to work. At least I hope so. :) For menus, this works: MenuStyle * BorderWidth 10 I suspect you are having problems with the borders on windows. Perhaps you missed this in the man page: Right now, I think my issues are more with an understanding of the fundamental syntax of the config file, not the actual values in it. It's looking more and more to me that conceptually, the config file is a bit like Perl in that there are implied values, multiple syntaxes, shorthand notations, etc. Is this correct? If so, that's something that's always given me the willies, personally. I tend to like a specified way of doing something, but that's my preference. Once I understand this, I'm sure I'll settle on one way. Until then, it's a bit confusing. I would not say the syntax is fundamentally weak, i.e. supports all kinds of errors or different ways of doing the same. In some places (usually some exotic modules) the syntax is very unforgivable without enough error messages. There is also a lot of backward compatibility stuff, this is probably why you think there are several ways of doing the same. For example, in your MenuStyle example above, what's the asterisk for? All styles? I guess not, since that doesn't make sense, given the context. I think the man page entry for MenuStyle (and other commands in the COMMANDS FOR MENUS section) explains what asterisk means. Should it be in quotes: *? I've seen it that way as well here and there. I understand about quoting values containing spaces, but how about without them? There are some places (usually modules, again) when you should strictly write it without quotes or, instead, with quotes depending on what the man page says. But for the core fvwm, the rule is usually simple. There is a concept of word (or token). This is either something without spaces and other delimiters or something that is in quotes (there are 3 pairs of quotes). So, * and * are the same, but * and * are not, because spaces are only significal when in quotes. Is there a definite order to options? Do you mean the order of commands or the order of options in a command? Almost in all cases (unless the man pages says otherwise) if a command has multiple optional options, their order does not matter. Of course, the order of mandatory parameters does matter. Example: the order of options in commands Style, MenuStyle (forget the obsolete syntax of MenuStyle), ButtonStyle, TitleStyle, WindowList, BusyCursor does not matter. If some option in these commands is not specified there is a good default. Some commands depend on the result of other commands, in this case the order of commands matters. Otherwise it does not matter. Simple, no? :-) Is it case-sensitive? It is preferable to stick to the case used in the man pages to be sure. But a lot of places are case-insensitive for convenience. Fvwm may be speedy and small, but the amount of configuration possible is massive. Hence the extremly large man page, and difficulty getting started. What I'm thinking of would be along the lines of what we've all seen in programming tutorials : skeleton diagrams with placeholders showing how everything is specified, in what order, what case, with what punctuation, what's mutually exclusive, what's dependent on each other, etc., etc. Then some simple examples that build on each other, instead of a massive .fvwm2rc that can walk and talk and do the jitterbug. Also, make the examples dovetail with FAQs on how and what can be done. Unfortunately there is a problem with who will do this. Do you want to help with this? Someone else mentioned what I think is a very good idea: Supply a few different config file samples that contain the same content, but with a differnt look and feel (native, Win95, CDE, etc.). That way, a newbie such as myself could see what does and doesn't change. But if
Re: FVWM: .fvwm2rc syntax guide?
f [EMAIL PROTECTED] net writes: On Sat, 24 Aug 2002 19:15:05 -0700 Rainer Koehler [EMAIL PROTECTED] wrote: So, why don't you go ahead and write something like that? [...] Also, I don't think the fvwm developers would be very good at writing a tutorial for beginners. Concidering myself a newbie I'd like to do that. The only problem is: a newbie knows the problems - but can't provide the solutions. You can ask the questions here and collect the answers. I'm always surprised how patiently the developers answer the same questions over and over again (except that after a while, all my keybindings stop working :-) Questions with concrete wishes are much easier to answer than I fiddled with the config file for hours and it didn't work. I don't think you'll spam the man page if you insert a short section for the main issues beginners have. And, my favorite way to do it is nearly already done: Look at man FvwmIconMan, Configuration Options Reference Chart. Add one single column to it with an example command and there you go. Hmm, I think the same table for fvwm itself would be sevaral pages long, but I agree, it would be a good idea to have something like that. Look, isn't fvwm2 worth it to forget maybe tine a little bit about the guide lines of man pages and follow the wishes of many beginners to fvwm2 - since they'll all start typing m-a-n instead of querying goole for some tutorial? Well, I consider someone who knows about man and is willing to use it no longer a real newbie :-) Another post here raised suspicion that someone read the manpage on the web and tried to apply it to the fvwm on his system (without success because he uses a different version). So maybe it would be better to write it in HTML. For many, it might be easier to write something in HTML than to write a manpage. But the format doesnt really matter, what's missing is the content! I would vote for splitting the manpage into some kind of introduction or a tutorial and a reference manual, but so far, only the reference part exists. Please excuse my passion - it's just the passion for fvwm2. I think we share that passion, that's why I get a bit angry when someone complains about the manpage without giving the impression that he is willing to do something about it. Cheers, Rainer -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
