Re: Quite old patch adding new Test condition
On 12 Aug 2005 08:45:07 +, Mikhael Goikhman wrote: I need a tool to check if some settings was set before and act acordingly (eg. I need to check if a variable was set before, to not overwrite it, or check the value of a variable and load apropriate config file). I.e. you need something like these Test conditions: (IsEnvSet var_name) that is false if the value is unset or , or/and: (MatchEnv var_name pattern) It was easy to implement, so I just added these Test conditions. Any comments are welcome. Regards, Mikhael.
Re: Notification: incoming/1291
On 30 Aug 2005 17:20:59 +0300, Evgeny Stambulchik wrote: Mikhael Goikhman wrote: Fine, I would like to apply this patch. Thanks! I have modified the patch slightly, so it only calls frame_get_titlebar_dimensions once, not 8 times. But please fix borders for windows without title (WindowStyle !Title), they are still quite bad with your new patch. Right, but this seems to me a genuine fvwm bug elsewhere related to the X expose events. Try switching focus to/off such a window several times; at the end, when focus is off, the borders are drawn just fine. Ok, I will let Dominik to answer. Without fixing this problem we will need to restore the previous bg.pixmap.g.x = bg.pixmap.g.y = 0; code. To reproduce the problem: BorderStyle TiledPixmap /some/image.xpm WindowStyle !Title, Handles, HandleWidth 20 Then pick and focus/unfocus any window. Regards, Mikhael.
Re: ManualPlacement/Move Patch
On 31 Aug 2005 21:42:20 +, Mikhael Goikhman wrote: This is not enough, To emulate the current logic you should also add: Mouse 1 P N CancelPlacement Mouse 2 P N CancelPlacement I.e. if you started the Move using button 1, then button 2 cancels it and vice versa. Since you can't press button 1 again while dragging using button 1, these binding would be ok although not immediately intuitive. Well, actually these will not be ok if the Move is started on mouse click (not drag) or on key press. So either we conclude your idea can't work or we may try to somehow save it using, say, this extension: Mouse 0 P N PlaceWindow Mouse 1 P(d0) N CancelPlacement Mouse 2 P(d0) N CancelPlacement Mouse 1 P(d1) N PlaceWindow Mouse 2 P(d2) N PlaceWindow Mouse 2 P(c) N CancelPlacement Where dN means dragging using button N and c means mouse click or key press. No, I am not a big fan of such idea, but I am not against either. (I think the current logic about Move cancelation is good.) Regards, Mikhael.
Re: ManualPlacement/Move Patch
On 01 Sep 2005 07:10:25 +0200, Viktor Griph wrote: On Wed, 31 Aug 2005, Mikhael Goikhman wrote: On 31 Aug 2005 21:42:20 +, Mikhael Goikhman wrote: This is not enough, To emulate the current logic you should also add: Mouse 1 P N CancelPlacement Mouse 2 P N CancelPlacement I.e. if you started the Move using button 1, then button 2 cancels it and vice versa. Since you can't press button 1 again while dragging using button 1, these binding would be ok although not immediately intuitive. Well, actually these will not be ok if the Move is started on mouse click (not drag) or on key press. So either we conclude your idea can't work or we may try to somehow save it using, say, this extension: Mouse 0 P N PlaceWindow Mouse 1 P(d0) N CancelPlacement Mouse 2 P(d0) N CancelPlacement Mouse 1 P(d1) N PlaceWindow Mouse 2 P(d2) N PlaceWindow Mouse 2 P(c) N CancelPlacement Where dN means dragging using button N and c means mouse click or key press. No, I am not a big fan of such idea, but I am not against either. (I think the current logic about Move cancelation is good.) I've not changed the logic for dragging of windows. IT's only the interactive movment that my patch affects. I maybe should make that more clear in the manual page. I did see no need to try to change the drag logic, as all feeling on how it should work matches with how it currently does. I.e you hold down the button the drag started with and calcel the movement by pressing any other button. Well, this is not exactly what happens now. If you drag using mouse button 1 or 2, then button 3 places the window, rather than cancels. I suppose Dominik intentionally did it to allow PlacedByButton3 using dragging too. If you want to be able to use some buttons for placing the window evenif it is being dragged it could probably be conficured by also changing PlaceWindow to always place the window and add PlaceWindowInteractive and PlaceWindowDrag as well as CancelPlacementDrag/CancelPlacementInteractive, and maybe also add CancelPlacement for completness, even if it would be the same as -. However, I think that just would comlicate things. But if you think it would be better to be able to define that you want to be able to place a window you are dragging by clicking on another button as well I can try to add that. You see, this is not enough. There should be at least the special notion of the same button that started the drag. The bindings quoted above should be implemented in one or another way (either configurable or hard-coded). I am not sure the flexibility you want to add is either needed or easy to implement (if possible at all). It is like to allow a user to create a new menu feel (key and mouse bindings) using a configuration. The menu code is messy and there are many actions and special cases already without configurable bindings. I don't know whether users want or have the ability to replace the placement feel with some usable alternative. Can you partition the exact current feel into configurable commands and estimate the work needed to implement this? Something along lines: Key Return P A PlaceWindow Key Space P A PlaceWindow Key Escape P A CancelPlacement Key Right P A MoveWindow +10p 0 Key Right P S MoveWindow +100p 0 Key Right P C MoveWindow +1p 0 Key AltP C ToggleSnapAttraction # well, this is a modifier, not a key If you show this is possible, then we may think to add a half-hardcoded command like CancelWithOppositeButton1Or2 to support the drag mode. How should the PlacedByButton n condition be affected by a drag move? I think the flags should be immediately reset on any Move and only set when the placement was not canceled. Also, just for info, I think it is acceptable that currently Pick Move and Move work differently in no window context. The first does interactive Move. The second starts dragging on mouse click and does interactive Move on key click (Enter). I think I have to move the assignment of PlacedByButton to the start of ButonRelease instead of the end of ButtonPress for best functionality. I'll not sublit a new patch for just that until I know if you want the ability to place dragged windows with another button than the drag started with or not. Regards, Mikhael.
Re: FVWM: gtk+ 2.0
On 23 Sep 2005 08:09:07 +, George Krajcsovits wrote: holly molly, that patch is from 2002 ! Was that the last of it ? Ok, I'm joining fvwm-workers now. Please don't top-post on these lists. I may be mistaken, but I don't remember seeing more updated patches. On 9/22/05, Mikhael Goikhman [EMAIL PROTECTED] wrote: On 22 Sep 2005 09:11:14 +, George Krajcsovits wrote: I'm sure this came up before, but the archive search doesn't work for me. Is there a version / CVS branch of fvwm2 that supports gtk+ version 2.0+ ? I have little spare time, but I'd be happy to contribute if needed, after all this is just porting... This is a bit more than just porting. Please start with this thread: http://www.mail-archive.com/fvwm-workers@hpc.uh.edu/msg01344.html We will gladly receive your contribution on fvwm-workers list. Regards, Mikhael.
Re: FvwmTabs module
On 03 Nov 2005 16:03:56 +1100, Scott Smedley wrote: A while back there was some talk about including the FvwmTabs module as part of the Fvwm distribution. Are people still happy for this to happen? You should include it. It is fully ready for this. Regards, Mikhael.
Re: FvwmTabs module
Just to clarify. By ready I didn't mean the functionality (this is something users should decide about), but the fact it is written properly. So that even it requires some external things (tk and more), these are not required in installation time, and the module is still runnable without them. Regards, Mikhael.
Re: TrianglesUseFore patch.
On 14 Nov 2005 01:31:05 +, Malcolm Still wrote: This patch allows users to use their menu foreground colour for submenu triangles, by using the new MenuStyle keyword TrianglesUseFore, e.g.: MenuStyle * TrianglesSolid, TrianglesUseFore I've uploaded the patch to my webspace at: http://rv.sdf-eu.org/trianglesusefore.diff I think this patch is short and good. Can you also patch all other relevant files, like the man page, NEWS? Regards, Mikhael.
Re: FAQ Update: Style lines.
On 06 Dec 2005 13:07:46 +, Thomas Adam wrote: Something that I have been seeing a lot recently, is the question of Style lines, how they're applied, and what things can go wrong. This is more so observed in #fvwm on irc.freenode.net, although I see it a lot on the FVWM Forums. How about the forum site changing title of the pages to FVWM spelling? This would at least eliminate problems for people having occational Style Fvwm* line (meaning to match modules, not browsers). Regards, Mikhael.
Re: fvwm-ewmh pre-announce
On 05 May 2001 06:25:52 +0200, Olivier Chapuis wrote: - We should not do anything that delays 2.4.0 Yes, of course. - In fact, FvwmNetHints needs a change to the configure procedure: the FVWM configure procedure define IMLIB if it found the gdk imlib as FvwmNetHints needs only the imlib (this save a lot of memory). Exactly. I will finish to rename the current IMLIB to GDK_IMLIB. Later we will need both GDK_IMLIB for FvwmGtk and pure IMLIB for fvwm, because we will want to support all image types, not only xpm. 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-ewmh pre-announce
On 05 May 2001 19:37:32 -0700, Danek Duvall wrote: On Sat, May 05, 2001 at 08:01:20PM +, Mikhael Goikhman wrote: Later we will need both GDK_IMLIB for FvwmGtk and pure IMLIB for fvwm, because we will want to support all image types, not only xpm. Please don't make it a requirement, though; I truly dislike having to compile all sorts of extra things for something that should be pretty simple. I only meant that we need to autoconfigure support for both, not only one. You will be able to turn them off, like it is possible with xpm now. 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: Next Focus not cycling?
On 06 May 2001 14:03:09 +0200, Dominik Vogt wrote: On Sun, May 06, 2001 at 02:07:26PM +0300, Tzafrir Cohen wrote: On Sun, 6 May 2001, Dominik Vogt wrote: Tzafrir Cohen wrote: Key Tab A M Next (!Iconify CurrentScreen) Focus Key Tab A MS Prev (!Iconify CurrentScreen) Focus BTW, it should be Iconic condition not Iconify, also there is no CurrentScreen condition, but CurrentDesk or CurrentPage. That's nice. Is there any compiler or such to check for irrelevant conditions? The problem is that there are no irrelevant conditions. When fvwm encounters a string that does not match any of the predefined tokens in a condition, it is taken as the name/class/resource of a window. In the case of the lines above fvwm has looked for windows with the title !Iconify (and has silently ignored the CurrentScreen part). So the correct lines are Key Tab A M Next (!Iconic CurrentPage) Focus Key Tab A MS Prev (!Iconic CurrentPage) Focus (or CurrentDesk instead of CurrentPage). I believe that this is not the problem, as I have tried it also with the simpler condition '(*)'. Believe it or not, it *is* the problem ;-) But what I said was not 100% correct. !Iconify matches any string in title/class/resource except Iconify of course. I guess you did not try the lines I wrote. They do work as expected. The Tzafrir's problem is stopping circulation, not incorrect windows in circulation. Your lines work of course, but only if there are no windows on the way that do not accept focus, like FvwmPager, as I wrote in my messages. If you want to reproduce the Tzafrir's problem, execute in FvwmConsole: Style xclock CirculateHit Exec exec xclock # Yes, conditions are not correct, just to show they are not the problem Key Tab A M Next (!Iconify CurrentScreen) Focus Key Tab A MS Prev (!Iconify CurrentScreen) Focus 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: Notification: incoming/712
On 06 May 2001 13:01:38 -0500, [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] Subject: make install-strip fails Date: Sun, 06 May 2001 13:01:23 -0500 Version: 2.3.32 'make install-strip' fails due to the perl scripts. Could you please check? This is a feature of autoconf/automake, it fails for any shell script. If you take a look at INSTALL.fvwm it recommends make -k install-strip. I moved this bug to no fix section. 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: Icon titles not retracting
On 07 May 2001 13:47:22 +0200, Dominik Vogt wrote: On Mon, May 07, 2001 at 11:39:12AM +0200, fvwm-workers wrote: On Mon, May 07, 2001 at 04:09:32PM +0700, Dmitry Yu. Bolkhovityanov wrote: On 6 May 01 at 15:26, [EMAIL PROTECTED] wrote: On Sun, May 06, 2001 at 01:06:46AM -0500, An Thi-Nguyen Le wrote: Version: 2.3.32 When icons are focused on via the keyboard (e.g., binding 'Next [Iconic] Focus' to a key sequence), the icon title expands (as expected), No, that's not expected at all. Expanding the title should only occur when the pointer enters the icon, it has nothing to do with the focus. It never occured to me that this could be useful. Can you please strip down your config file as much as possible so that this still happens and send it along with step by step instructions so that I can try to reproduce it here? The simple binding you gave does not show the bug for me. When had this changed? Fvwm 2.2.4 had this behaviour at least with AnotherLevel (i.e. the icon title shown expanded while the icon had focus)... and the users got accustomed to it. Hm, now that you say it, I can vaguely remember. Expanding the title when the pointer is over the icon was introduced in 2.3.2. I guess there is some relation to the new feature. Fixed. I don't think this is a good change. We discussed this 2 years ago and agreed (at least Dominik, Matthias and me) that leaving an icon should collapse the icon title. http://www.hpc.uh.edu/fvwm/archive/9904/msg00609.html The opposite behaviour is very annoying if you don't have other focusable windows on a page just to shutdown that long icon title. Dmitry, are you sure you prefer that old behavior? :) I think we should restore the behavior we had for more than 2 years now. We may have an option later if anyone really prefers another one. 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: Notification: incoming/713
On 08 May 2001 09:26:04 -0500, [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] Subject: FvwmButtons with mouse buttons 3 Date: Tue, 08 May 2001 09:26:02 -0500 Full_Name: Cameron Kerr Version: 2.2.4 I would like to have a FvwmButton that responds to inputs from the scroll wheel of my mouse. I would like to use this to change the volume on my system. Idealy, I would do this my specifying the (Mouse 4) or (Mouse 5) option in the call to FvwmButtons. [...] I've currently got mouse 1 to lower the volume, and mouse 3 to increase the volume, thusly, *FvwmButtons(3x1,\ Action (Mouse 1) `Exec exec echo vol Vol + | smixer -s -`,\ Action (Mouse 3) `Exec exec echo vol Vol - | smixer -s -`) Which works perfectly well, except that I can't scroll on it. Starting from 2.3.24 you may do the same for Mouse 4 and Mouse 5. I have moved this bug to existing enhancements section. 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]
Keyboard is locked after canceling window selection
This bug should be related to keyboard grab changes done on 2001-04-15. Execute Move (or similar command) without a window-context, press Escape, woops, the keyboard is locked. The mouse works, so hopefully you will be able to Restart, which restores the keyboard. 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]
FvwmTaskBar core dumps when restarting in FvwmScript-Setup95
After choosing Rebuild Sample 95 from a menu, configuring it and restarting (via FvwmScript-Setup95) the following happens: *FvwmTaskBar: Cause of next X Error. Error: 4 (BadPixmap) Major opcode of failed request: 56 (ChangeGC) Minor opcode of failed request: 0 Resource id of failed request: 0x400072 Leaving a core dump now #3 0x8054e0a in PrintXErrorAndCoredump () at XError.c:59 #4 0x804d7c3 in ErrorHandler (d=0x8059b78, event=0xbfffe708) at FvwmTaskBar.c:2061 #5 0x400b5d87 in _XError () from /usr/X11R6/lib/libX11.so.6 #6 0x400b3141 in _XEventsQueued () from /usr/X11R6/lib/libX11.so.6 #7 0x400a714e in XPending () from /usr/X11R6/lib/libX11.so.6 #8 0x804c3cc in LoopOnEvents () at FvwmTaskBar.c:1385 #9 0x804a75a in EndLessLoop () at FvwmTaskBar.c:389 #10 0x804a66b in main (argc=6, argv=0xb3bc) at FvwmTaskBar.c:350 Can someone else reproduce and take a look into this? 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]
Wait in functions is broken
I don't know when this started. AddToFunc TestFunction I Wait unexisting window TestFunction Now, click or drag using the mouse anywhere. Woops, mouse is mostly locked. The keyboard works well (did I say something similar before?), so you may quit this mode by pressing Ctrl-Alt-Escape. 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: Wait in functions is broken
On 09 May 2001 01:48:44 +0200, Dominik Vogt wrote: On Tue, May 08, 2001 at 09:58:24PM +, Mikhael Goikhman wrote: I don't know when this started. AddToFunc TestFunction I Wait unexisting window TestFunction Now, click or drag using the mouse anywhere. Woops, mouse is mostly locked. The keyboard works well (did I say something similar before?), so you may quit this mode by pressing Ctrl-Alt-Escape. That's not really new. This was always the case if the function used anything else but 'I'. I don't know what to do about that. The pointer must be grabbed during function execution for the reasons I explained in the thread with Paul's deiconify problem. I think I see this thread and I can't find where is explained why the cursor grabbing is needed. What is the date of the message you mention? This locked cursor behaviour is not good. Wait is mostly used in I functions. It is used in many places, including fvwm-themes, FVWM FAQ. In any case I think Wait command may have additional optional parameter timeout and probably one more optional parameter timeout-command. And we should have a built-in command Break, which finishes a function, it may be used in Wait's timeout-command or in conditional commands. 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: Patch to FvwmEvent to use hex
On 08 May 2001 14:34:54 +0100, Tim Phipps wrote: Attached is a patch to make FvwmEvent pass the window-id in hex. Maybe just pass a heximal id in PassId instead of additional PassHexId? I think it is safe. 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: SetEnv not expanding environmental variables itself
On 10 May 2001 09:49:41 -0500, An Thi-Nguyen Le wrote:
Maybe this is documented somewhere.
Yes, in the man page. Enter /environment and press 'n' several times.
You will find everything you wanted to know, including the fact that only
3 commands ImagePath, ModulePath and Restart expand environment variables
$var and ${var} themselves, and for other commands $[var] should be used.
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]
import -frame fails
import utility from ImageMagick without parameters works well. With -frame it behaves strangely now. It worked well some time ago. It seems that import and fvwm do not agree about what is window frame. On my machine import -frame image.gif on xv or xcalc produces an image without client window (it is empty). If trying to capture xterm, it exits with Can't allocate memory error. rxvt being captured does not exit itself, but eats all memory and then is killed by kernel. Tried with ImageMagick-5.2.2 and ImageMagick-5.3.3 - the same problems. Tried with fvwm-2.2.5 and fvwm-2.3.22 - everything is fine. Please comment. 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: import -frame fails
On 15 May 2001 21:21:12 -0400, Dan Espen wrote: Mikhael Goikhman [EMAIL PROTECTED] writes: import utility from ImageMagick without parameters works well. With -frame it behaves strangely now. It worked well some time ago. It seems that import and fvwm do not agree about what is window frame. On my machine import -frame image.gif on xv or xcalc produces an image without client window (it is empty). If trying to capture xterm, it exits with Can't allocate memory error. rxvt being captured does not exit itself, but eats all memory and then is killed by kernel. Tried with ImageMagick-5.2.2 and ImageMagick-5.3.3 - the same problems. Tried with fvwm-2.2.5 and fvwm-2.3.22 - everything is fine. Please comment. I tried an rxvt and an xv with titlebars and pixmap border, both worked fine. ImageMagick 5.1.1, Exceed 6.1. Can you try a more current ImageMagick by a chance? For me import -frame works fine with fvwm-2.3.22 release and no rc. And the same import -frame fails with fvwm-2.3.32 release and no rc. 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: import -frame fails
On 16 May 2001 10:55:23 +0200, Dominik Vogt wrote: On Tue, May 15, 2001 at 10:10:01PM +, Mikhael Goikhman wrote: import utility from ImageMagick without parameters works well. With -frame it behaves strangely now. It worked well some time ago. It seems that import and fvwm do not agree about what is window frame. On my machine import -frame image.gif on xv or xcalc produces an image without client window (it is empty). If trying to capture xterm, it exits with Can't allocate memory error. rxvt being captured does not exit itself, but eats all memory and then is killed by kernel. Tried with ImageMagick-5.2.2 and ImageMagick-5.3.3 - the same problems. Tried with fvwm-2.2.5 and fvwm-2.3.22 - everything is fine. For me it works but does weird things (how do I find out the IM version?). % rpm -q ImageMagick % import -help | head -1 With an rxvt window, the client part of the window is shifted about 23.5 rows upwards and 10 columns to the left before the image is captured. With xterm it is the same. An xv client window is reduced to about 10 pixels in height before capturing. The windows stay in the screwed up state until they get a ConfigureNotify (e.g. after moving or resizing the window). The frame is included in the image in both cases. Yes, it seems that some client windows are resized first depending on the original structure and size. Some clients don't survive this resizing. To me it seems that import is making assumptions about the internal layout of the window manager frame and fiddles with windows of other clients. This looks pretty broken to me, but I will look at what happens in fvwm anyway. 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: Wait in functions is broken
On 10 May 2001 12:35:27 +0200, Dominik Vogt wrote: On Wed, May 09, 2001 at 11:12:26PM +, Mikhael Goikhman wrote: On 09 May 2001 01:48:44 +0200, Dominik Vogt wrote: On Tue, May 08, 2001 at 09:58:24PM +, Mikhael Goikhman wrote: I don't know when this started. AddToFunc TestFunction I Wait unexisting window TestFunction Now, click or drag using the mouse anywhere. Woops, mouse is mostly locked. The keyboard works well (did I say something similar before?), so you may quit this mode by pressing Ctrl-Alt-Escape. That's not really new. This was always the case if the function used anything else but 'I'. I don't know what to do about that. The pointer must be grabbed during function execution for the reasons I explained in the thread with Paul's deiconify problem. I think I see this thread and I can't find where is explained why the cursor grabbing is needed. From the ChangeLog: 2001-03-22 Dominik Vogt [EMAIL PROTECTED] * fvwm/functions.c (execute_complex_function): fixed button presses being passed to other applications with functions that only have immediate actions This locked cursor behaviour is not good. Wait is mostly used in I functions. It is used in many places, including fvwm-themes, FVWM FAQ. No, it's not good at all. So, what do we do about this? A possible solution is to ungrab cursor before some commands (Wait) and then grab again. If there is no solution, I think we should disable this commit, because it is problematic. I run a version with this commit disabled during a week now, so I may do it. 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: Gnome panel and sounds
On 19 May 2001 06:25:52 +0200, Olivier Chapuis wrote: Le Vendredi 18 Mai 2001 21:18, vous avez écrit : I think s/vous/real-name/ would be more informative. :) I also have the following line Style panel GNOMEIgnoreHints because it seems that either panel in GNOME 1.4 does not use GNOME hints correctly (it is first shaded when collapsed) or FVWM has no fully correct GNOME hints support, I can't check right now which one. Fixed, can you confirm I've not GNOME 1.4 on my machine (I've the current GNOME 2 cvs and the panel is far from being compilable o:) Yes, this is fixed, nice. The problem was using 0/1 instead of 1/2 in WindowShade. On/Off works, but accourding to the man page this is as obsolete as 1 and 2. The only non-obsolete arguments for toggle commands (Iconify, Maximize, Stick, WindowShade) are True/False/Toggle. 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]
command parsing problems
The current command parsing is done in this order: 1) Handling the module command (if starting with '*') 2) Getting the first word (command name) 3) Expanding the first word and the entire command separately 4) Handling the internal command This leads to several problems, like: * The command starting with '*' is not a subject for parameter expansion, thus making it impossible to construct module commands or have generic module templates (without an overhead of forking using PipeRead echo) * In module commands extended variables like $[fg.cs1] are not expanded, sometimes making it hard to have functional module configs * Calling function named echo twice does not work, although calling function named print twice works. This just shows how bad is the existing parsing order. The problems are real, for example a sample in FAQ 7.13 does not work now. I am not sure why it worked at all (2 bugs eliminate each other?). Currently I am learning now how hard will be to implement a more correct order without breaking anything: 1) Expanding the entire command 2) Handling the module command (if starting with '*') 2) Getting the first word (command name) 3) Handling the internal command This would fix all 3 problems above together with more inconsistencies, say, a leading '-' (meaning don't expand) would work for all commands. Of course, for backward compatibility single-letter variables in module commands should not be expanded (this is unfortunate, but needed, since FvwmButtons and FvwmForm expect this). However $[] variables is a new invention and there is no reason not to expand them in module commands. Does anyone see any problem if $0 to $9 are expanded in module commands inside functions? I can't think of any except of really exotic examples, in which the raw '$0' could be escaped like in any other place - '$$0'. BTW, I think it is not late yet to reduce expanding collisions and use '%' instead of '$' in the new FvwmButtons constructions: %fg, %right, %width. Or a less conflicting syntax $(fg), like the one already used in FvwmForm. This is not the best time for this reworking, but the existing command parsing problems should be solved (at least FAQ 7.13 sample should work). As usual I will not change anything without a thorough testing first. Any comments are welcome. 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: command parsing problems
On 21 May 2001 18:16:14 +0200, Dominik Vogt wrote: I'm rather reluctant to open this can of worms again this close to 2.4. The problems you mention are not nice, but everything works as it used to right now. I already tried to fix some of this, but was not able to do so without breaking backwards compatibility. May this be a candidate for the ominous 3.0 release? I'd really like to throw away the whole parsing stuff and write it from scratch in a clean, well designed way. Of course that will break a lot of config files :-/ I know about these issues, because I write a lot of config stuff. But I am concerned that fvwm-themes should work with fvwm-2.4.x not fvwm-3.0.x. I see how to fix the space in function name problem, it just requires some duplication - second PeekToken after expand and reevaluation of bif. But this problem is not important, and we may just leave it as is. However the module command processing is way too limiting. I patched execute_function() locally and other problems mentioned by me are fixed. Tomorrow I will patch expand() so it will not expand too much for module commands, then test everything and send the resulting small patch. I want to keep backward compatibility as much as possible. 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: icon raise issue?
On 23 May 2001 20:04:03 +0200, Nils Lohner wrote: When I go over an icon that's partially covered by a window, the icon title is raised, but the icon itself is not (see .jpg) Is this correct behavior? Only icon title raising was intended when it was implemented 2 years ago. So the behaviour is expected. 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: 2001-05-23 snapshot fails to compile
On 24 May 2001 00:02:40 +0200, André Dahlqvist wrote: I just tried compiling the 2001-05-23 snapshot on my Debian/GNU Linux box, and the compilation failed rather quickly with this error message: make[2]: Entering directory `/home/andre/software/fvwm-snap-20010523/fvwm' make[2]: *** No rule to make target `libs/fvwmlib.h', needed by `menus.o'. Stop. make[2]: Leaving directory `/home/andre/software/fvwm-snap-20010523/fvwm' make[1]: *** [all-recursive] Error 1 The last version of fvwm that I have tried to build is 2.3.32, which worked flawlessly. I can confirm that fvwm-snap-20010523 and all snapshots starting from 20010506, when we had Building problem email that Jason asked to ignore, have this problem. fvwm/Makefile.in has libs/header.h dependencies instead of the correct ../libs/header.h. I have no idea why this happened. make dist from cvs has no this problem. Jason, was there something interesting in how you solved the problem then on 20010506? Anyway, creating the tree from scratch should solve this now. 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: About swallowing asfsm
On 24 May 2001 19:02:21 +0200, Fabio Stumbo wrote: I have a little problem: I installed the 2.3.32 version of fvwm (en attendant 2.4 ... ;-) and I discovered that with this version there is no way to have asfsm by FvwmButtons: it just stay on one side, out of the buttons panel. Is this a general problem, or is it just my configuration? Of course, in my fvwm2rc i converted the Buttons configuration in the new format. I have no problems to swallow asfsm, works like with any other window. I used a usual (Swallow asfsm `Exec exec asfsm`). Please post your FvwmButtons config if you still have problems. I also had another (very minor) problem: fvwmevent doesn't play any sound when I use raise/lower with a key, or even clicking on the window bar, whereas it still play the usual sound when I raise/lower using tha taskbar. Any hints? I can't get raise_window/lower_window events in FvwmEvent at all. Not using a module (FvwmTaskBar, FvwmConsole) not in any other way. It seems that lower_window event is not sent at all anywhere in the code. Probably someone else knows more about this. 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: Notification: incoming/715
On 27 May 2001 22:03:16 +0200, Dominik Vogt wrote: On Sun, May 27, 2001 at 01:34:28PM -0500, An Thi-Nguyen Le wrote: [An Thi-Nguyen Le - Sun, 27 May 2001 01:32:43 PM CDT] *FvwmColorset 8 fg blue, bg black, Pixmap snip *FvwmColorset 8 fg red, bg white, Pixmap This even happens when I get the commands correct. :) *FvwmThemeColorset 8 fg blue, bg black, Pixmap *FvwmThemeColorset 8 fg red, bg white, Pixmap Neither command is correct ;-) FvwmTheme does not use new *FvwmTheme... config lines after it has already started. The correct syntax is SendToModule FvwmTheme Colorset ... Actually both syntaxes (module configuration and sending a message) work the same, i.e. fvwm and FvwmTheme are synchronized until FvwmTheme reevaluates the new colorset value. (Propogation of the new value to modules is not synchronized I guess.) And the first syntax is even preferable in most of situations, because after restarting (killing/starting) of FvwmTheme the current value is used. 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: About swallowing asfsm
On 27 May 2001 20:15:08 +0200, Fabio Stumbo wrote: I have no problems to swallow asfsm, works like with any other window. I used a usual (Swallow asfsm `Exec exec asfsm`). Please post your FvwmButtons config if you still have problems. Here is my config. Eventually I got it swallowed using the option UseOld, but I can't understand why: I just tried randomly... :-( [skipped] *FvwmButtons: (2x2, Frame 4, Swallow(UseOld) asfsm `Exec asfsm \ -bp None -bg rgb:4/6/4 -fg rgb:9/9/0 \ -pbg rgb:4/6/4 -pfg rgb:f/f/0 -pbp None -i 60`) I see that in your example, without UseOld asfsm is not swallowed. This seems a problem of asfsm after all. :) The man page of asfsm suggests -i sec to change a scanning interval. But in fact, asfsm with -i starts iconic and immediately deiconifies itself. This confuses FvwmButtons. So either don't use -i or use UseOld or bother asfsm developers to conform to the man page or bother fvwm developers to fix swalowing. A note, if I don't use UseOld and then iconify/deiconify asfsm it is swallowed after this action. I can't get raise_window/lower_window events in FvwmEvent at all. Not using a module (FvwmTaskBar, FvwmConsole) not in any other way. It seems that lower_window event is not sent at all anywhere in the code. Probably someone else knows more about this. That's very strange: with 2.2.4 I had raise/lower working fine in any case. Now (2.3.32) just the taskbar. Together with what you have, it doesn't seem very deterministic, like a copmuter program should be... Don't underestimate a complexity of conditions in large programs. I can only add that I do get raise_window events when I enter gnome panel's subpanel, it asks (version 1.4) to raise itself when entered. I also sometimes enter a mode when usual RaiseLower or Raise generate raise_window. But right now they don't generate it while panel does. And lower_window is simply not sent as I already mentioned. I used for testing: *FvwmEvent-Test: Cmd Exec xmessage # Echo *FvwmEvent-Test: raise_window raise window Module FvwmEvent FvwmEvent-Test #KillModule FvwmEvent FvwmEvent-Test (I also currently have FvwmEvent-Sound with raise_window defined.) I don't consider any of the problems in this message critical for 2.4.0. They may be fixed later. 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: About swallowing asfsm
On 27 May 2001 00:08:21 +, Mikhael Goikhman wrote: On 24 May 2001 19:02:21 +0200, Fabio Stumbo wrote: I also had another (very minor) problem: fvwmevent doesn't play any sound when I use raise/lower with a key, or even clicking on the window bar, whereas it still play the usual sound when I raise/lower using tha taskbar. Any hints? I can't get raise_window/lower_window events in FvwmEvent at all. Not using a module (FvwmTaskBar, FvwmConsole) not in any other way. It seems that lower_window event is not sent at all anywhere in the code. Probably someone else knows more about this. There was a cvs commit that did not generate email (missing email events): * fvwm/stack.c (LowerWindow): (RaiseWindow): restored sending M_RAISE_WINDOW and M_LOWER_WINDOW that was accidentally removed somewhere after 2.2 - fixes missing raise/lower events in FvwmEvent Now, lower_window works well for me, but raise_window is often duplicated. Wait more than 4 seconds, Raise - one raise_window event is sent. Wait less than 3 seconds, Raise - two raise_window events are sent. 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: Wait in functions is broken
On 21 May 2001 13:00:25 +0200, Dominik Vogt wrote: On Fri, May 18, 2001 at 06:01:03PM +, Mikhael Goikhman wrote: On 10 May 2001 12:35:27 +0200, Dominik Vogt wrote: From the ChangeLog: 2001-03-22 Dominik Vogt [EMAIL PROTECTED] * fvwm/functions.c (execute_complex_function): fixed button presses being passed to other applications with functions that only have immediate actions This locked cursor behaviour is not good. Wait is mostly used in I functions. It is used in many places, including fvwm-themes, FVWM FAQ. No, it's not good at all. So, what do we do about this? A possible solution is to ungrab cursor before some commands (Wait) and then grab again. If there is no solution, I think we should disable this commit, because it is problematic. I run a version with this commit disabled during a week now, so I may do it. I have been thinking about this a lot. The main problem is the way 'Wait' is implemented at all. The man page claims that fvwm stays fully functional during a wait which has not been true for a long time. The wait function implements its own inferior version of the event loop which will fail in a lot of cases. For example it does not handle the module queue properly, so modules are not able to issue commands during a wait. Furthermore it expects that DispatchEvent() never handles more than one event. This may be true for MapNotify at the moment, but if HandleMapNotify() would ever check for a matching DestroyNotify() in the future, 'Wait' might miss the MapNotify and hang forever. This solution will work, but it's not trivial to implement: 1) When 'Wait' is called, it inserts the information about the window to wait for in a table. 2) 'Wait' returns immediately. It does not do any event handling. 3) 'Wait' has a special flag in the function table that tells execute_function() to return immediately without finishing the function. Instead it builds a new function with the rest of the actions that would have to be taken as soon as the window appears. Then it returns and tells the function from which it was called to do the same. 4) Finally, function execution ends with a more or less long list of pending commands. The cursor is ungrabbed and fvwm resumes execution in the normal event loop. 5) Whenever a new window is mapped, fvwm checks the list of pending waits for a matching window. For the first matching window it executes the recorded function and deletes it after execution. There are still some problems in this solution that would have to be solved: a) How can ctrl-alt-escape be implemented? b) How can the busy cursor be implemented? c) What happens to function parameters? When leaving the current function they have to be recorded in some way. One way would be to store them in the recorded function somehow (new command?) Alternatively the commands could be executed as usual but instead of executing them the string that would have been executed is recorded. Dominik, do you work on this now? I think this is a good solution, but it requires so many changes in several places that we may need 2.3.33. Can we restore the previous behaviour of Wait in I functions now and release 2.4.0? And this solution may be implemented in 2.4.1 or similar. I think we don't need to fork to 2.5.0/2.9.0 (which is going to be incompatible) immediately after 2.4.0, this may be done later in 2.4.x. 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: fvwm2 = broken wm?
On 29 May 2001 16:29:22 +0200, Andre Bonhote wrote: the sentence in the subject is *NOT* my opinion! that's for sure! i just found a funny lil program called wmfishtime [1] which does nothing than display a clock. when i start it under my fvwm2 [2], it just shows a gray box. in the tarfile, there's also a file called ALL_I_GET_IS_A_GRAY_BOX which refers to the INSTALL file. there it says that my windowmanager sucks because it's broken, i should use -b to run it. i don't really know much about c programming, even less about xwindows-coding. all i found in fishmon.c was this: ... /* actually draw the rgb buffer to screen */ if (!broken_wm) gdk_draw_rgb_image(bm.iconwin, bm.gc, 4, 4, 56, 56, GDK_RGB_DITHER_NONE, bm.rgb, 56 * 3); else gdk_draw_rgb_image(bm.win, bm.gc, 4, 4, 56, 56, GDK_RGB_DITHER_NONE, bm.rgb, 56 * 3); } ... that's it. i don't know what's so bad bout using either of these methods. but the author of this program says my fvwm2 sucks, and i wanted you to know. perhaps there's really a bug or sth you didn't notice. [1]: http://www.ne.jp/asahi/linux/timecop/ http://www.ne.jp/asahi/linux/timecop/software/wmfishtime-1.23.tar.gz This app is broken itself, although funny. :) It ignores delete window protocol, so only Destroy works on it. It lists E and kwm as broken WMs too, but I see nothing broken here. It asks to draw on the icon window not on the main window, so if you iconify wmfishtime (without -b) in normal WMs, you will see an animation. The --broken option should be correctly named --not-in-icon. And I think it should be a default, while --in-icon may be an option. 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: releasing 2.4.0
On 20 May 2001 15:55:09 +, Mikhael Goikhman wrote: Sorry, I should object because there are at least 3 problems: 1) Locking on Wait in I functions, I am still waiting for Dominik's answer. If nothing else I will undo that problematic commit. 2) IMHO import -frame problem should be fixed, it worked previously and it is inaceptable that existing window screenshot functions are broken. 3) There are several problems in function parsing, see my other thread. I will try to fix them all soon. I consider all these fixed. On 21 May 2001, Dominik Vogt wrote: I think the current focus problems and the Wait command have to be fixed first. Are there any focus problems remaining to be fixed? There is a small current Wait problem: in the Wait state if you delete a window and then switch desk and return to the original desk, you see the frame of previously deleted window, moving such unshaded frame deletes it again until a new switch of desks. This only happens in functions: AddToFunc TestFunction I Wait unexisting window TestFunction It is ok by me if this problem is not fixed. Ctrl-Alt-Esc fixes this well. 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: releasing 2.4.0 [some gnome stuff]
On 03 Jun 2001 15:48:32 +0200, Tomas Ogren wrote: Ok, I made some more changes to make it consistent now. The point is: It doesn't matter what layer I request if I do it _before_ mapping the window. Fvwm will still put it on the default layer. As I already said I can't reproduce this. With no arguments the window is initialy placed on the layer 2, with arguments it is iniatily placed on layer 4 and then immediately switches to layer 2, as expected. In case I am not clear, the button Same never does anything for me if I don't press other buttons. I can reproduce what you say only if I have this (and this is expected): Style winhints Layer 4 BTW, this style option Layer once set can't be disabled without Restart... 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: want more than 5 mouse buttons
On 06 Jun 2001 11:55:10 +0200, Dominik Vogt wrote: On Tue, Jun 05, 2001 at 10:37:19PM +, Mikhael Goikhman wrote: On 05 Jun 2001 14:03:25 -0500, [EMAIL PROTECTED] wrote: Message summary for PR#718 From: [EMAIL PROTECTED] Subject: want more than 5 mouse buttons Date: Tue, 05 Jun 2001 14:03:23 -0500 fvwm doesn't seems too support more than 5 mouse buttons, or at least the parser doesn't allow number greater than 5; or it is quiet common now to find mouses with 6 or 7 buttons (2 for the wheels, 3 buttons, and 1 or 2 thumb buttons) The error message is: [FVWM][ParseBinding]:ERRORIllegal mouse button in line 6 R A GnomeButton This is because X itself does not support correctly more than 5 mouse buttons as may be verified in X11/X.h file. I should add that although fvwm does a good thing to ensure that all buttons work correctly and fully, this check is a bit too conservative. If you remove this check (button NUMBER_OF_MOUSE_BUTTONS), and then use this command to map buttons 123 to other values, say, 159: xmodmap -e pointer = 1 5 9 you will see that all I functions and many complex functions bound on mouse button 9 work. However there are small problems, although C, H and D work acceptably ok, M is considered to be C. Also Mouse 9 W does not work in xterm (it works in xcalc), because xterm is, like FVWM, also too conservative and does not accept buttons greater than 5. I myself have a mice with 8 buttons (2 wheels and one thumb, 3 + 2*2 + 1), I can configure X to recognize them all, but this has its own problems, so I ended up to define only 5 (both wheels behave as one), that works with no problems. Since more than 5 mice buttons can't work fully in the current X, I leave it up to Dominik to decide whether it is good to enable for users to use more buttons on their own risk (yes, they only work partially, but work). How are these mouse buttons addressed without the proper X macros? Obviously there are no bits left for a Button6MotionMask. And only Button6Mask and Button7Mask would fit into the free bits. The button number itself is not a problem. You may test yourself after remapping button numbers using xmodmap. The important thing is that it is possible to detect press and release of buttons with numbers greater than 5 and thus support I, C, D, H. Of course, it is impossible to support dragging using mouse buttons greater than 5. I gathered this info by tests only, it may not be full. 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]
problems with BusyCursor Read true, DynamicMenu false
Here is a minimal rc file showing the problem. The cursor is changed to busy-cursor, but is not restored after PipeRead. AddToFunc FuncFvwmMenuDirectory + I PipeRead fvwm-menu-directory --dir $0 --check-subdir --links AddToMenu MyMenu MissingSubmenuFunction FuncFvwmMenuDirectory + My Menu Title + Home Directory Popup $[HOME] + Root Directory Popup / BusyCursor Read true, DynamicMenu false # other combinations work ok Menu MyMenu 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: releasing 2.4.0
On 03 Jun 2001 21:33:48 -0400, Paul D. Smith wrote: %% Dominik Vogt [EMAIL PROTECTED] writes: dv The one that Paul (PDS) reported with in conjunction with dv FvwmAuto. Of course I still hope he'll provide some more details. I posted this on May 1: OK, I think I have more details. If I have mouse-2 bound to my Iconify-and-Compact function: AddToFunc Iconify-and-Compact + C Iconify + C All (CurrentDesk Iconic) RecaptureWindow Mouse 2 I A Function Iconify-and-Compact then I see this behavior. It's very easy to reproduce; create an icon box like IconBox 2 -20 -1 -1, for example (I don't use any of the module icon managers, just the builtin IconBox). Now place an xterm over the icon box. Then iconify the xterm. Then click mouse-2 on the xterm's icon in such a way that the window will appear underneath your mouse cursor when it de-iconifies, even if you don't move it (the mouse). If I change mouse-2 to run just Iconify, I can't make it happen anymore. So, maybe this behavior is no longer supported? It used to work until fairly recently; someone on the workers list suggested it (although I checked and it's not listed in the FAQ). I never heard anything so I assumed it was expected behavior. It is not an FvwmAuto problem, it's RecaptureWindow. I can reproduce what Paul describes without FvwmAuto with FvwmAnimate. Or without FvwmAnimate, but when the original icon is already unfocused. (It is possible to get unfocussed icon under cursor if you enter it during All RecaptureWindow.) But I don't think this problem is critical for 2.4.0. I may help to fix it in 2.4.1. Restoring focus may be done explicitely by adding to Iconify-and-Compact: + C Focus NoWarp # or even: WindowId $w (!Iconic) Focus NoWarp Does anyone think this problem is critical to stop the 2.4.0 release? It also seems that a problem with not focussing of Nautilus is not critical either, it may be fixed by Style Lenience. We should move on. I think we agreed that 2.3.33 is the latest release. I want to change the next version from 2.3.34 to 2.4.0. Any objections? I also think that if we want to move, the code should be fully frozen now. Any non obvious change (even a possible fix) should be voted, anyone is able to veto if he thinks a problem is not critical to start to fix it. 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: can't find mails describing FvwmIconMan pipe problem
On 23 Jun 2001 01:06:36 +0200, Dominik Vogt wrote: I wanted to debug the problem with the dying FvwmIconMan module but can not find anything in the mail archives. Does anybody have the problem description handy? Do you have an estimation for the date of this message? I can't find any dying FvwmIconMan message in my 2001 archive. I only see the message where you ask about what to do with this problem: http://www.hpc.uh.edu/fvwm/archive/0106/msg00023.html 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: can't find mails describing FvwmIconMan pipe problem
On 23 Jun 2001 12:14:33 +0200, Dominik Vogt wrote: On Fri, Jun 22, 2001 at 11:34:05PM +, Mikhael Goikhman wrote: On 23 Jun 2001 01:06:36 +0200, Dominik Vogt wrote: I wanted to debug the problem with the dying FvwmIconMan module but can not find anything in the mail archives. Does anybody have the problem description handy? Do you have an estimation for the date of this message? Some time between January and May. Sorry, I can't be more precise. All I remember is that I noticed the problem during the stress tests I made a while ago, probably when refining the automated test scripts with Dan. Something causes FvwmIconMan to exit under some circumstances because it gets a timeout reading from the pipe, maybe because of a busy cursor grab or something similar. I know I sent a detailed problem description to the mailing list but I can not remember if it ever arrived. Ok, then you should refer to this thread: http://www.hpc.uh.edu/fvwm/archive/0102/msg00162.html http://www.hpc.uh.edu/fvwm/archive/0102/msg00231.html I thought this problem was fixed, but now I see notice that you asked Chris to take a look at the remaining part of the problem. I can't find any dying FvwmIconMan message in my 2001 archive. I only see the message where you ask about what to do with this problem: http://www.hpc.uh.edu/fvwm/archive/0106/msg00023.html Didn't you notice some problem with FvwmIconMan a few weeks ago? At least I thought you had re-discovered the same problem. Sorry, I don't use FvwmIconMan on a regular basis, I only verify from time to time that the FvwmIconMan option, which some of our themes have, work. I reported that I got this, which may or may not be related: [FVWM][PositiveWrite]: ERROR Failed to read descriptor: - data available=N - terminate signal=N I patched some time ago fvwm to print a module name here and I saw that it is generated by my personal FvwmEvent-NewWindow module when I switch themes. The interesting thing is that FvwmEvent-NewWindow module is not killed and remains functional, so this is only a warning (!?) in my case. I turned off this module from StartFunction some time ago, but I may reenable it later to help to fix this tight problem. 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: PATCH: fvwm-2.3.33/acinclude.m4 smr_ARG_WITHLIB needs to check existence of library
On 26 Jun 2001 14:49:53 -0700, Adam J. Richter wrote: If you just do ./configure with fvwm95-2.3.33 on a system that uses ncurses instead of termcap, it will decide that readline wants -ltermcap rather than -lncurses. The reason for this is that configure.in relies on the autoconf macro smr_ARG_WITHLIB setting with_termcap to no if there is no termcap library, but, in fact, smr_ARG_WITHLIB defaults to setting it to maybe, even if the library does not exist. Well, no, smr_ARG_WITHLIB is supposed to return maybe in this case, and ./configure expects this (and not no). Let see if I understand this problem. You have both libtermcap and libncurses installed, fvwm chooses libtermcap to be used together with libreadline, and you don't like this. If this is the case, use: --without-termcap-library --with-ncurses-library (only the first is really needed), like it is suggested in INSTALL.fvwm. No. ./configure is supposed to autodetect these kinds of things when it can if you do not give it arguments. Autodetect what? Please explain. I don't think that prefering termcap over ncurses if both are available is a problem. Am I missing something? Does ./configure (without your patch) say you have ReadLine support? Does make; su; make install pass? Can you use keyboard arrows in FvwmConsole? If the answer on all these questions is yes, there is no any problem. My patch fixes this problem. False, it does not fix anything, but introduces several big problems. How many configurations on how many systems did you test? If you want a patch for probing ncurses before termcap, you should move the appropriated lines in configure.in, but your patch does not do this. 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: PATCH: fvwm-2.3.33/acinclude.m4 smr_ARG_WITHLIB needs to check existence of library
On 26 Jun 2001 16:53:07 -0700, Adam J. Richter wrote: Let see if I understand this problem. You have both libtermcap and libncurses installed, fvwm chooses libtermcap to be used together with libreadline, and you don't like this. Sorry, I misread this question before. That is *not* the problem. The problem is that ./configure ; make all results in a build failure. Termcap is not available on this system, and ./configure acted as if it was anyhow, because the absense of termcap is not automatically detected. I do not care whether this program uses ncurses or termcap if both are available, but if only one is available, it should automatically use that. Ok, now I understand the problem. After I applied my patch, the FvwmConsole program linked correctly (with -lreadline -lncurses instead of -lreadline -ltermcap), and installed without errors. I hope I explained why your patch seemed to work for you. It is a combination of events that works on your system only. I will try to figure out how to use FvwmConsole to attempt the other test you requested. Add this line to your fvwmrc and press Alt-F12 (after restarting): Key F12 A M Module FvwmConsole I believe that ncurses can be configured to install a symlink from /usr/lib/libtermcap.a to /usr/lib/ncurses.a, or at least that older verions of ncurses could, and that this may have hidden the problem before. Yes, this may be a problem. Please investigate whether you have good libtermcap.a and/or libtermcap.so. configure checks that a trivial program containing one call readline() works with -lreadline -ltermcap and decides that termcap library is ok. This is not a perfect check, but it was such since fvwm-2.1.x versions. What build error do you get? BTW, which mailer do you use, it does not add References: and In-Reply-To: headers, so threads are not preserved... 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: PATCH: fvwm-2.3.33/acinclude.m4 smr_ARG_WITHLIB needs to check existence of library
On 26 Jun 2001 20:24:27 -0700, Adam J. Richter wrote:
UPDATE: One thing that I have not noticed before is that I
was running autoconf before ./configure. Just running ./configure on
the pristine sources does seem to detect the absense of libtermcap somehow.
So, this is a more subtle bug, perhaps related to autoconf-2.50. I am
looking into it. The rest of this response applies to doing
autoconf ; ./configure ; make all on the fvwm-2.3.33 sources.
Ok, now you finaly supplied enough information for me to be able to
reproduce the problem. :-)
If I remove libtermcap, run autoconf from autoconf-2.50 package, the
resulting ./configure says (cached) yes for termcap, which is wrong.
But if I run autoreconf instead (which is more correct), everything is ok.
If I then run autoconf (all from 2.50), the problem appears again.
It seems for me that this is a problem in autoconf-2.50, at least this
behaviour is not compatible with autoconf-2.13.
Here is a patch that makes autoconf-2.50 happy in all situations for me:
--- acinclude.m42001/05/14 06:56:30 1.16
+++ acinclude.m42001/06/27 13:18:24
@@ -262,7 +262,7 @@
ifelse($5, , , smr_header=[$5])
smr_ARG_WITHLIB($1,$2,$3)
if test $with_$1 != no; then
-AC_CHECK_LIB($smr_lib, $4,
+AC_CHECK_LIB(${smr_lib}, $4,
smr_havelib=yes,
smr_havelib=no; problem_$1=: Can't find required lib$smr_lib,
ifelse($6, , ${$1_LIBS}, [${$1_LIBS} $6]))
I would not apply it before 2.4.0 unless it is really necessary.
I prefer not to risk, although it seems to work with autoconf-2.13 too.
After I applied my patch, the FvwmConsole program linked correctly
(with -lreadline -lncurses instead of -lreadline -ltermcap), and
installed without errors.
I hope I explained why your patch seemed to work for you. It is a
combination of events that works on your system only.
Your explanation is wrong.
I should agree with you, my explanation is not good.
Still it correctly describes that it is not portable.
Here is exactly what I said, but expressed differently.
The output with your patch on your system (without termcap) seems to be:
checking for main in -lxpm... yes
checking for main in -lrplay... yes
checking for main in -lstroke... yes
checking for main in -ltermcap... no
checking for main in -lncurses... yes
checking with ncurses... checking for main in -lreadline... yes
My output with your patch on my system (I have all libraries) is:
checking for main in -lxpm... no
checking for main in -lrplay... yes
checking for main in -lstroke... yes
checking for main in -ltermcap... no
checking for main in -lncurses... yes
checking with ncurses... checking for main in -lreadline... no
Currently I have no time to investigate why all these no appear after
your patch is applied.
Using main as the function to check for in AC_CHECK_LIB
causes AC_CHECK_LIB to check for the existance of the library without
requiring a specific function, since main is defined in the body of the
test program. This is the convention for achieving this result in autoconf.
A grep of our source tree shows 202 directory trees that use it, covering
just about every category of program you can think of (i.e., not just
kde, gtk-based software or anything like that).
But we have an even better check later in configure, we check that
readline() call works within the library, not only main().
The problem with autoconf-2.50 is related to caching. I find that caching
(which is hard to implement both correctly and effectivelly) usually
causes more problems than solves, it only reduces time a bit.
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: 2.4 release procedure?
On 27 Jun 2001 10:52:38 +0200, Dominik Vogt wrote: To save a bit of time before the 2.4 release on one hand, and to make sure all the dates and release numbers are correct in all the files I suggest that we build fvwm-2.4.0-pre1 now with all the version numbers and supporting files referring to 2.4.0. This build would not be announced on the web page and can only be downloaded from the alpha directory on the ftp server. Does this make sense? Ok, just to be more exact, how about this: * change the developement version from 2.3.34 to 2.4.0 today/tomorrow * change all dates to be 2001-07-01 and versions to be 2.4.0 * ask Jason to repack (unpack/rename/pack) fvwm-snap-20010630.tar.gz to fvwm-2.4.0-pre1.tar.gz and move to alpha directory * optionally add a link to fvwm-2.4.0-pre1.tar.gz in download.html * release a real 2.4.0 several days after that (make_fvwmdist) 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: CVS domivogt: * Fixed RaiseOverUnmanaged vs. RaiseLower.
On 28 Jun 2001 22:05:45 -0500, FVWM CVS wrote: CVSROOT: /home/cvs/fvwm Module name: fvwm Changes by: domivogt01/06/28 22:05:45 Modified files: . : ChangeLog fvwm : events.c stack.c Log message: * Fixed RaiseOverUnmanaged vs. RaiseLower. You committed your experiments with events.c, which you obviously didn't want to commit. I am restoring events.c. We don't want FvwmButtons panels, FvwmTaskBar, gnome panel and others get fantastic positions and xv walk, right? :) cvs diff [files] | less before cvs commit [files] is a good idea. 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: Yet another unclutter problem
On 29 Jun 2001 08:57:43 -0700, Danek Duvall wrote: On Fri, Jun 29, 2001 at 08:39:09AM -0400, Dan Espen wrote: The Next [*] Focus command violates that rule, but unclutter fixes it up. If you want to focus on a new window with either of these focus models, warptowindow should be used. One inconvenient thing about warptowindow is that there's no programmatic way to get back to the original window. So if you want a command to temporarily get you to a different window and then put you back as if nothing had happened, warping the pointer doesn't work so well. Specifically, I like to bring up FvwmConsole with a single keystroke. I get focus in the new window immediately, type whatever I need in it, and when I hit ^D to get out of it, my focus returns to the window I was in before (because the mouse hasn't moved). Is there a better way of doing this? If I correctly understand the question, here is how to achieve this: Style * StickyFocus Style FvwmConsole GrabFocus Key F12 A M FvwmConsole The second way, which also achieves this (in 2.2.x it works differently): AddToFunc StartFvwmConsole + I FvwmConsole + I Wait FvwmConsole + I Next (FvwmConsole) Focus # Focus NoWarp if 2 non-sticky FvwmConsole I only post tested examples. 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: 2.4 ready to be released
On 02 Jul 2001 19:46:22 +0200, Olivier Chapuis wrote:
I have found a little problem in the tar ball and I've no solution
to solve it.
I do not know why but modules/FvwmScript/Scripts/FvwmScript-Setup95
is in the tarball (only the .in version should be in it).
FvwmScript-Setup95 is removed (normal) and build (not normal at all)
when we do a make dist. When building fvwm FvwmScript-Setup95 is
not rebuild from FvwmScript-Setup95.in. So, FvwmScript-Setup95
will work only if the prefix=/usr/local (or an other recent
version of fvwm is installed with this prefix ...).
Oh, true. Both rpms suffer from this problem, i.e. they have broken
Setup95. So new users will get the initial menu with a non-working item.
The only fix I see is to do the following:
gunzip fvwm-2.4.0-pre2.tar.gz
tar -delete -vf fvwm-2.4.0-pre2.tar
fvwm-2.4.0/modules/FvwmScript/Scripts/FvwmScript-Setup95
gzip fvwm-2.4.0-pre2.tar
Good hack, but then this should be done by everyone who does
cvs update -r version-2_4_0.
This is really only a partial fix since it does not seems that
FvwmScript-Setup95 is rebuild at the second configure even
if Makefile's are modified (say by changing the prefix).
Note that modules/FvwmScript/Scripts/Makefile.am is really
similar to modules/FvwmForm/Makefile.am but FvwmForm-Setup is not
in the tarball, however, if you do
./configure; make; ./configure --prefix=/foo; make; make install
FvwmForm-Setup is not rebuild at the second make and so
does not work ... (need a make clean before the second make;
work also for FvwmScript-Setup95)
I may fix these rebuilding problems too.
Guess it's time to put the Champagne in the Refrigerator :o)
I have only one or two Hoegaarden in my frigerator but
I do not think that this problem should stop the procedure.
I think we will see others small problems in the next few days,
and it will be good to release 2.4.1 in a short time.
Well, the only true error is inclusion of FvwmScript-Setup95 into the
tarball, others are not critical, make clean fixes them for now,
so I will see whether they are worthy fixing too.
I don't know whether 2.4.0 is announced yet, I suppose it is not.
I will fix this error and retag changed files.
Then I will make distclean2; cvs update -r version-2_4_0; make distcheck2,
on other machine, rename and upload fvwm-2.4.0-pre3.tar.{gz,bz2} files and
Jason will rename them to fvwm-2.4.0.tar.{gz,bz2} tommorow.
Anyway, nothing critical happened. We may continue a celebration. :)
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]
fvwm-2.4.0-pre3 is uploaded
Jason please move fvwm-2.4.0-pre3.tar.{gz,bz2} to the testing directory.
I tested the package more than once. It would be nice if Olivier verified
that there are no problems with the package.
In any case, the instructions posted by Dominik are valid with one minor
correction. The release time is immediately after July, 03 20:00 GMT.
Then please:
* rename these packages to fvwm-2.4.0.{gz,bz2}, move to the proper place
* in fvwm-web cvs dir apply fvwm-web-2.4.0.patch and cvs commit
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.4.0-pre3 is uploaded
On 03 Jul 2001 09:16:43 +0200, Dominik Vogt wrote:
On Tue, Jul 03, 2001 at 12:03:14AM -0500, Jason L Tibbitts III wrote:
MG == Mikhael Goikhman [EMAIL PROTECTED] writes:
MG Jason please move fvwm-2.4.0-pre3.tar.{gz,bz2} to the testing
MG directory.
It's there.
MG In any case, the instructions posted by Dominik are valid with one
MG minor correction. The release time is immediately after July, 03 20:00
MG GMT.
It's nearly 2001.07.03 05:00 UTC now, which means I'll do the release at
15:00 CDT (my local time). Unless UTC and GMT aren't currently
coincident. (This stuff makes my brain hurt.)
I will mail out the announcement (docs/ANNOUNCE) at that time,
... or unless the package is screwed up - which is the case. It
bears the release number 2.4.0.1 since I already changed the
ChangeLog, configure.in and NEWS.
Did you download 2.4.0-pre3? :)
It has no 2.4.0.1 anywhere, because as I said I did it from
cvs update -r version-2_4_0. The files that you mention have version
after symbolic version-2_4_0, so this is not included in the package.
Also, the fvwm-web patch does
not have the correct date anymore. Forthermore, the dates in the
module man pages do not match the intended release date anymore.
I have to redo everything from scratch (*groan*). Can somebody
tell me the cvs command to move the 2.4.0 tag to the current file
versions?
% cvs tag -F version-2_4_0 [files]
I think that pre3 is just good to be a release. Trust me. But if you want
to have an additional headache, which I really wanted not to cut from you,
you may decide differently. :)
Web patch may be redone. It is ok by me that the date is July 1, since we
didn't have a single code change since then, so pre-2 is not different.
As I wrote this, I got an email about pre4. But the tag is not moved,
so cvs update -r version-2_4_0 is still pre3. So either pre4 is not
synchronized with cvs tag version-2_4_0 or pre4 is the same as pre3.
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: CVS migo: * do not include FvwmScript-Setup95 file into distribution
On 03 Jul 2001 09:55:44 +0200, Dominik Vogt wrote: On Mon, Jul 02, 2001 at 10:18:25PM -0500, fvwm-workers wrote: * rpm/fvwm.spec.in: add files todo-2.4 and todo-3.0 to rpm Argh! Why did you do that?! Okay, I'l make *another* tarball (pre5). Because we don't include any ChangeLog (we have several ones) into rpm documentation. These files is for users that want some change history. 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.4.0-pre3 is uploaded
On 03 Jul 2001 10:16:20 +0200, Dominik Vogt wrote:
On Tue, Jul 03, 2001 at 07:59:02AM +, Mikhael Goikhman wrote:
On 03 Jul 2001 09:16:43 +0200, Dominik Vogt wrote:
On Tue, Jul 03, 2001 at 12:03:14AM -0500, Jason L Tibbitts III wrote:
MG == Mikhael Goikhman [EMAIL PROTECTED] writes:
MG Jason please move fvwm-2.4.0-pre3.tar.{gz,bz2} to the testing
MG directory.
It's there.
MG In any case, the instructions posted by Dominik are valid with one
MG minor correction. The release time is immediately after July, 03
20:00
MG GMT.
It's nearly 2001.07.03 05:00 UTC now, which means I'll do the release at
15:00 CDT (my local time). Unless UTC and GMT aren't currently
coincident. (This stuff makes my brain hurt.)
I will mail out the announcement (docs/ANNOUNCE) at that time,
... or unless the package is screwed up - which is the case. It
bears the release number 2.4.0.1 since I already changed the
ChangeLog, configure.in and NEWS.
Did you download 2.4.0-pre3? :)
It has no 2.4.0.1 anywhere, because as I said I did it from
cvs update -r version-2_4_0. The files that you mention have version
after symbolic version-2_4_0, so this is not included in the package.
Also, the fvwm-web patch does
not have the correct date anymore. Forthermore, the dates in the
module man pages do not match the intended release date anymore.
I have to redo everything from scratch (*groan*). Can somebody
tell me the cvs command to move the 2.4.0 tag to the current file
versions?
% cvs tag -F version-2_4_0 [files]
I think that pre3 is just good to be a release. Trust me. But if you want
to have an additional headache, which I really wanted not to cut from you,
you may decide differently. :)
I'd really prefer if you didn't take that this lightly. It's no
fun to double and triple check each step I make and I don't think
it's a good idea to change the set of distributed files 6 hours
before the release (see todo-2.4 and todo-3.0).
The list of distributed files is defined in Makefile.am, I didn't change
it. This change didn't actually add todo-2.4 and todo-3.0 to rpm
because they are not distributed with dist, it was harmless.
Web patch may be redone. It is ok by me that the date is July 1, since we
didn't have a single code change since then, so pre-2 is not different.
As I wrote this, I got an email about pre4. But the tag is not moved,
so cvs update -r version-2_4_0 is still pre3. So either pre4 is not
synchronized with cvs tag version-2_4_0 or pre4 is the same as pre3.
The tag has been move for all files that were changed.
Ok, I see that you tagged a new tag version_2_4_0; tag version-2_4_0
is not moved.
Here is that may be done to synchronize these tags:
% cvs tag -r version_2_4_0 -F version-2_4_0
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: rpm packages for 2.4.0
On 02 Jul 2001 03:29:06 +0300, Mikhael Goikhman wrote: I have created 2.4.0 rpms from the tagged cvs version in a usual place: http://fvwm-themes.sourceforge.net/rpm/ With rpm it is easier, if 2.4.0-1 is not good, 2.4.0-2 is created. I quickly tested all these rpm packages, they work well for me. Olivier should update the remaining packages. This url now contains updated 2.4.0-2 rpms. 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: Announce in ~40 minutes
On 03 Jul 2001 14:23:41 -0500, Jason L Tibbitts III wrote: I haven't seen any indications to the contrary, so I'm going to announce in about 40 minutes unless I hear differently. Is it safe to assume that what's in the pre-5 tarball is the final source? Yes, fvwm-2.4.0-pre5 is the final source. 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]
Congratulations regarding 2.4.0 release
Hurray! :-) Let me thank anyone with whom I worked and anyone else for being patient with me. It was a real fun to work on fvwm. My special thanks - to our hero Dominik. Hey, I love you, man. :-) And my wife permits me, she uses fvwm on her desktop too. :P Let not forget our pets. They deserved natural tuna in water and additional portion of Wiskas (or whatever their best delicacies are). Warmest greetings to everyone who is happy together with me. :) 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]
Man pages on the web
I want to adapt run_man2html.sh to man2html which is included with man on some linux systems. It is in fact cgi script that generates http headers too (which are stripped). I am leaving the current functionality, so run_man2html.sh auto-detects man2html and works with what is installed. The output is different from what we have now by the following: * it looks more like html, not man, i.e. pre is not used globally * real bold and italic used instead of colors (colors may be added too) * subsection index is generated with proper links inside the document * links to http://, ftp:// and mail address strings are added * other minor differences, say the date inside the man page is displayed There are several problems, but they may be fixed by adding pre-filters and post-filters using pipe. I added colors using style, looks ok for me in browsers supporting css, but they may be turned off completely if real bold and italic are used. I would give it a try, then we may compare, discuss. 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: Man pages on the web
On 04 Jul 2001 12:06:38 -0400, Dan Espen wrote: Mikhael Goikhman [EMAIL PROTECTED] writes: I want to adapt run_man2html.sh to man2html which is included with man on some linux systems. It is in fact cgi script that generates http headers too (which are stripped). I am leaving the current functionality, so run_man2html.sh auto-detects man2html and works with what is installed. The output is different from what we have now by the following: * it looks more like html, not man, i.e. pre is not used globally * real bold and italic used instead of colors (colors may be added too) * subsection index is generated with proper links inside the document * links to http://, ftp:// and mail address strings are added * other minor differences, say the date inside the man page is displayed There are several problems, but they may be fixed by adding pre-filters and post-filters using pipe. I added colors using style, looks ok for me in browsers supporting css, but they may be turned off completely if real bold and italic are used. I would give it a try, then we may compare, discuss. run_man2html currently uses man2html. On my system, thats currently man2html version 1.2. man2html 1.2 uses bold and italic by default. I didn't like the way it looked and added the arguments: -belem 'font color=cyan' -uelem 'font color=yellow' man2html 1.2 will generate headers by default, but I wanted more control so I added -bare. By all means, go ahead and see what improvements you can make. man2html on my system is complitly different, it is cgi, i.e. almost has no command line options. It is shipped together with man(1). There are probably many man2html-like scripts all with different functionality, I just used what is installed. I don't like the man2html I have. I added so many work-arounds that it probably would be easier (not really) to rewrite it from stratch in perl. Anyway, I think it is now ok as the web page, but this is questionable. One may like empty space on the left, other may think empty space only uses real estate of the browser and does not add anything. I have no problems if we return to the previous format, just wanted to show an alternative. 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: Bug or Feature?
On 04 Jul 2001 06:43:53 -0500, [EMAIL PROTECTED] wrote: new message incoming/734 From: [EMAIL PROTECTED] Subject: Bug or Feature? Full_Name: Marc-Jano Knopp Version: 2.4.0 ... It looks like a bug, but it could also be a feature... Some icons (apparently with only few colors) have a border around them, while others do not. I could not see any option for setting the icon border, but maybe I'm blind... A few examples can be found here: http://mjk.c64.org/ns4.xpm- no border http://mjk.c64.org/ebay2.xpm - border http://mjk.c64.org/willget2.xpm - border http://mjk.c64.org/YellowBlueRedGeometry.xpm - no border If it's not a bug: what am I doing wrong? It is a feature. Any transparent icons be without border. A transparency is defined by presence or absence of None color. For example in ebay2.xpm replace # with None. If the icons is not really transparent, but you want it without border, you should add one color None, don't forget to increase color number. 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: [patch] checking whether trivial gnome compilation passes fails
On 04 Jul 2001 04:44:52 -0500, [EMAIL PROTECTED] wrote: new message incoming/733 From: [EMAIL PROTECTED] Subject: [patch] checking whether trivial gnome compilation passes fails Full_Name: Adrian Bunk Version: 2.4.0 ... .. checking whether trivial gnome compilation passes... no ... config.log says: ... In file included from configure:5913: /usr/local/include/gnome.h:14: gtk/gtk.h: No such file or directory In file included from /usr/local/include/gdk_imlib.h:5, from /usr/local/include/gnome.h:15, from configure:5913: /usr/local/include/gdk_imlib_types.h:1: gdk/gdk.h: No such file or directory ... The problem is the moved location of the GTK header files in the latest versions of GTK. The following patch fixed it for me (and FVWM compiled and runs successfully): --- acinclude.m4.oldWed Jul 4 09:37:46 2001 +++ acinclude.m4Wed Jul 4 09:38:10 2001 @@ -888,7 +888,7 @@ AC_MSG_CHECKING(whether trivial gnome compilation passes) my_CPPFLAGS=$CPPFLAGS my_LIBS=$LIBS - CPPFLAGS=$CPPFLAGS $GNOME_INCLUDEDIR + CPPFLAGS=$CPPFLAGS $GNOME_INCLUDEDIR $GTK_CFLAGS LIBS=$LIBS $GNOME_LIBDIR $GNOMEUI_LIBS AC_TRY_RUN([ #include gnome.h I don't know. This is almost the stock gnome.m4, so many gnome programs will fail on your system. If `gnome-config --cflags gnorba gnomeui` does not return the correct gtk include dir like -I/usr/include/gtk-1.2, gnome instalation is flawed. But it seems that this patch is safe. 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: Notification: incoming/731
On 05 Jul 2001 20:45:15 +0200, Marc-Jano Knopp wrote: [windows on page 0 vanish from pager when selecting page 1 in pager] BTW, while I tried to reproduce what you initially wrote, I was able to do this twice (of course, not with instructions you gave), but I can't reproduce it anymore. It included 7 interactive commands in FvwmConsole including GotoPage, but it requires some specific window stack. Okay, I attached a reduced version of my ~/.fvwm as a tar.bz2, which extracts into the directory .fvwm.bug. It seems you didn't attach, or I didn't get anything. cd mv .fvwm .fvwm-$(date) # backup your original .fvwm cp -a .fvwm.bug .fvwm startx # start X11 - click with mouse 1 on the root window, and select 'Modules | Pager' - click with mouse 2 (middle mouse button) on the title bar of the pager and select '(Un)Stick' to make it sticky - click with mouse 1 on the root window, and select 'Terminal' - now click on the page to the right of the current page in the pager et voila! - the terminal window vanishes from the pager - fix bug :-) Ctrl-Alt-Backspace rm -r .fvwm cp -a .fvwm-$(date) .fvwm FYI, this may be done without (re)moving directories and shutting down X. Just execute in FvwmConsole (tilde is expanded by Restart) the command: Restart env FVWM_USERDIR=~/.fvwm-test fvwm2 Restart env FVWM_USERDIR=~/.fvwm fvwm2 Or if you write relocable config (i.e. use $. in all Read commands), even: Restart fvwm2 -f ~/.fvwm-test/.fvwm2rc Restart fvwm2 -f ~/.fvwm/.fvwm2rc The second pair is an example only, the first should be used to be sure. 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: Latest cvs commits breaks build (FreeBSD)
On 06 Jul 2001 06:00:18 -, Andre Goeree wrote: Configuration Information [Automatically generated, do not change]: uname output: FreeBSD mandark.attica.home 4.3-STABLE FreeBSD 4.3-STABLE #4: Tue Jul 3 21:40:50 CEST 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CUSTOM i386 Description: After the latest cvs update, the following error occures: [EMAIL PROTECTED] make build install strip cd fvwm gmake What is it, some ports system? If yes, how does it work regarding cvs? cd . aclocal aclocal: /usr/local/share/aclocal/sdl11.m4: 11: duplicated macro `AM_PATH_SDL' gmake: *** [aclocal.m4] Error 1 *** Error code 2 INFO: automake: version 1.4 fvwm: 2.4.1 Repeat-By: cd /srcdir/fvwm ./configure gmake clean I can't reproduce any problems on systems I have. I don't have sdl11.m4 though. Try this in the top directory: % autoreconf % automake -a % ./configure [params] % make 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: Regarding fvwm-2.4 RPM
On 07 Jul 2001 10:38:03 +0700, Dmitry Yu. Bolkhovityanov wrote: First, the package is named fvwm, not fvwm2, which prevents it from being a drop-in replacement for RedHat's RPM. Should our rpm be a drop-in replacement for the RedHat's rpm? In fact both may coexist happily together. Then a user has 2 fvwm versions 2.2.x and 2.4.x and may use one or another or uninstall RedHat's one. Think about this, if we follow your path and have fvwm2 package which is compatible with the current RedHat's rpm, we end up with rpm incompatible with the SuSE one, which includes icons together with fvwm2 rpm, unlike RedHat, which has them in a separate package. It will also be incompatible with the Mandrake one, which adds a menu entry to some place. The only good solution for us is to have the rpm, which is fully distribution independent and let distributions to do what they want. Optionally we may add more distribution specific rpms, which use the same distribution independent file naming convention (this is important). It -provides the fvwm capability, which is a bit wrong, since there's no fvwm binary inside. The fvwm rpm provides fvwm capability, I don't see anything wrong. rpm -ql fvwm | grep fvwm | grep -v fvwm2 | wc -l gives 100 files. rpm -ql fvwm | grep fvwm2 | wc -l gives only 5. Sounds reasonable? Additionaly, some people still use fvwm-1.24, and naming the current version simply fvwm will confuse them (since recommended rpm -Uvh will remove fvwm-1). Well, by this logic, some people still use RedHat's fvwm2-2.2.x; if we name it fvwm2-2.4.x, this will uninstall an older rpm and confuse people. From the developers point of view 1.x is not preferable over 2.2.x, both are old versions of the same program. Is it possible to rename the package to fvwm2? (Yes, fvwm2-2.4 looks a bit weird, but it is an existing practice). This practice is not good. There is only one supported fvwm version, the package with it should be called fvwm. If a distribution for some reason wants to keep fvwm-1.24r, it may call the package fvwm1-1.24r, which _is_ an existing practice for many other packages. Second, the fvwm-2.4.0-2.rh7.rpm doesn't include any config files in proper places, so that when a freshly installed fvwm2 is run, it complains: [FVWM][main]: ERROR Cannot read startup file, tried: /export/viper/rabbit/.fvwm/.fvwm2rc /export/viper/rabbit/.fvwm2rc /usr/share/fvwm/.fvwm2rc /usr/share/fvwm/system.fvwm2rc /usr/etc/system.fvwm2rc BTW, it should also try /etc/X11/system.fvwm2rc and/or /etc/X11/fvwm2/system.fvwm2rc (see FHS section 3.7.5.2). Ok, I may change sysconfdir to be /etc instead of /usr/etc. But this is not really important, because we suggest to use /usr[/local]/share/fvwm for all system wide configs, not /etc. Compare with emacs package, it also does not search in /etc. The rpms that we provide are clean, they don't include any current distribution additions. If you install from tarballs make install does not install any config file, rpm does the same. Initial rc files are not needed for most of people, who may: * use their existing rc files * create initial rc files using FvwmForm-Setup (try an initial menu) * create initial rc files using FvwmScript-Setup95 (also in menu) * install fvwm-themes rpm and run fvwm-themes-start instead of fvwm2 If nobody else bothers, I can make appropriate patch for spec file. Feel free to suggest changes, but I would keep them clean, not to be RedHat specific or Mandrake specific or SuSE specific and so on. If you want to help, you may create libstroke and libstroke-devel rpms for RedHat 6.x and 7.x, which RedHat does not package. By comparison, Mandrake, Polish(ed) and now SuSE do package it. 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: CVS migo: * changed version from 2.4.0.1 to 2.4.1
On 09 Jul 2001 10:37:58 +0200, Dominik Vogt wrote: * changed version from 2.4.0.1 to 2.4.1 I wonder how we should number our releases at the moment. We need some way to have betas with a leading 2.4... since we can't expect to make a Xinerama release without any betas in between. Well, there are several possible choices: * use 2.4.0.1 (is this understandable that this is beta?) * use 2.4.1 for beta (not much different from the previous) * use 2.4.1-0.20010920 or 2.4.1-beta1 (I would stick to numeric x.y.z) * use temporary names 2.5.x for betas, then return to 2.4.1 We may also fork a branch, do 2.5.x betas and then merge to 2.4.1. But if the plan now is to do stable 2.4.1, forking is not really needed. So my vote is to change to 2.5.0 with or without fork accordingly to the needs, then release next stable 2.4.x, but never 2.6.x. Probably the real incompatible fork may be done in 2.9.x later. 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: bug in fvwm24_convert of version 2.4.0
On 10 Jul 2001 13:34:41 +0200, Moritz Barsnick wrote: I'm not on the list and can't followup properly (In-Reply-To: because no message IDs are displayed in the web archive. You may find all needed information to create manually both In-Reply-To: and References: in the html source if you like to be nice to others. :-) Werner wrote: At least with my perl 5.005_03, $HOME isn't defined within the script (but is set in my environment). Perl has a different syntax. This patch should work: I already applied more full patch on Date: Sun, 08 Jul 2001 04:46:21 -0500. I now see another problem when less than 2 params given. I will fix it. So there should be an $ARGV = 2 || die $ARGV[0] requires two arguments; This line has 3 perl bugs. :) The correct syntax would be: @ARGV == 1 || die $0 requires two arguments; But it was intended to have 0, 1 or 2 arguments anyway, not only 0 and 2. It should work now as intended. 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: bug in fvwm24_convert of version 2.4.0
On 10 Jul 2001 15:35:36 +0200, Moritz Barsnick wrote: BTW (OT), I thought it was now desired to always prefix a '$' when accessing a variable as a scalar. Only when accessing a single array element: $ARGV[0]. The arguments are passed using array @ARGV. Without braces an undefined scalar $ARGV is used. 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: libstroke-0.5
On 13 Jul 2001 11:38:17 -0700, Dmitry Derevyanko wrote: I don't know if this has been mentioned before, but here goes. some macro names have been changed in libstroke-0.5: MAX_POINTS - STROKE_MAX_POINTS MIN_POINTS - STROKE_MIN_POINTS MAX_SEQUENCE - STROKE_MAX_SEQUENCE SCALE_RATIO - STROKE_SCALE_RATIO BIN_COUNT_PERCENT - STROKE_BIN_COUNT_PERCENT fvmw-2.4 won't compile with libstroke-0.5 unless those are changed. Ok, it should now be compiled with old and new libstroke. 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: Notification: incoming/739
On 13 Jul 2001 13:06:05 -0500, [EMAIL PROTECTED] wrote: new message incoming/739 From: [EMAIL PROTECTED] Full_Name: Bernhard Simon Version: 2.4.0 CVS_Date: N/A OS: AIX 3.2.5 X_Server: N/A fvwm/menus.c fails to compile cc -DHAVE_CONFIG_H ... -O -c menus.c menus.c, line 1066.8: 1506-045 (S) Undeclared identifier XK_Page_Up. menus.c, line 1072.8: 1506-045 (S) Undeclared identifier XK_Page_Down. On AIX 3.2.5 only XK_Prior and XK_Next are defined in /usr/include/X11/keysymdef.h Fixed. 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: Notification: incoming/740
On 13 Jul 2001 13:15:34 -0500, demthu!fvwm.org!fvwm-bug wrote: new message incoming/740 From: [EMAIL PROTECTED] Subject: fvwm-2.4.0 fails to build on Digital UNIX V4.0E Full_Name: Bernhard Simon Version: 2.4.0 CVS_Date: N/A OS: Digital UNIX V4.0E X_Server: N/A fvwm/module_interface.c fails to compile cc -DHAVE_CONFIG_H ... -O -c module_interface.c cc: Warning: module_interface.c, line 1646: # not in column 1 \ is ignored, skipping to end of line. (ignoretokens) #define is_valid_first_alias_char(ch) (isalpha(ch)) --^ cc: Warning: module_interface.c, line 1647: # not in column 1 \ is ignored, skipping to end of line. (ignoretokens) #define is_valid_alias_char(ch) (is_valid_first_alias_char(ch) \ --^ Same problem on ULTRIX V4.5 Fixed. Remark: There seems to be a problem with FvwmIconBox on Digital UNIX V4.0E. FvwmIconBox disappears (process dies) when trying to deiconify (double click on an icon in the Box) a window. There is a similar report (Id 736). Note: On AIX 3.2.5 this works as expected. Do you get the same error message as in #736? I.e.: FvwmIconBox: Cause of next X Error. Error: 2 (BadValue) Major opcode of failed request: 53 (CreatePixmap) Minor opcode of failed request: 0 Resource id of failed request: 0x0 Leaving a core dump now 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]
FvwmIconBox exits (Was: Re: Notification: incoming/740)
On 16 Jul 2001 08:51:27 +0200, Bernhard Simon wrote: Remark: There seems to be a problem with FvwmIconBox on Digital UNIX V4.0E. FvwmIconBox disappears (process dies) when trying to deiconify (double click on an icon in the Box) a window. There is a similar report (Id 736). Do you get the same error message as in #736? I.e.: FvwmIconBox: Cause of next X Error. Error: 2 (BadValue) Major opcode of failed request: 53 (CreatePixmap) Minor opcode of failed request: 0 Resource id of failed request: 0x0 Leaving a core dump now Mikhael, sorry, FvwmIconBox only exits. I cannot find any core or error messages in /var/dt/Xerrors. Do you have an idea what I can do next to help finding the problem? I suppose you don't have limit coredumpsize 0. I can suggest to add debug statements to FvwmIconBox and try to determine what causes it to exit. Or you may hope that someone else can reproduce this problem and fix it. 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: Notification: incoming/739
On 15 Jul 2001 15:15:24 +0200, Dominik Vogt wrote: On Sun, Jul 15, 2001 at 12:41:29AM +, Mikhael Goikhman wrote: On 13 Jul 2001 13:06:05 -0500, [EMAIL PROTECTED] wrote: new message incoming/739 From: [EMAIL PROTECTED] Full_Name: Bernhard Simon Version: 2.4.0 CVS_Date: N/A OS: AIX 3.2.5 X_Server: N/A fvwm/menus.c fails to compile cc -DHAVE_CONFIG_H ... -O -c menus.c menus.c, line 1066.8: 1506-045 (S) Undeclared identifier XK_Page_Up. menus.c, line 1072.8: 1506-045 (S) Undeclared identifier XK_Page_Down. On AIX 3.2.5 only XK_Prior and XK_Next are defined in /usr/include/X11/keysymdef.h Fixed. Hm, is there a way to provide these macros via configure so that we won't have to remember this pitfall each time? There isn't much to it: #include X11/keysydef.h #ifndef XK_Page_Up #define XK_Page_UP XK_Prior #endif #ifndef XK_Page_Down #define XK_Page_Down XK_Next #endif FYI, keysymdef.h does not do anything good, keysym.h does. Ok, I implemented some generic mechanism for this kind of things. This should be used with great care not to break anything. 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: Notification: incoming/741
On 17 Jul 2001 07:53:16 -0400, Keith Spainhour wrote: Using Java 1.3.1 and Java 1.4 Beta, all Java Windows, (JFrame, JWindow) begin with (B and then the window title. Sun claims this is a FVWM bug. I have not seen this on any other window manager. Here is a url to a picture of a window: http://www.employees.org/~keiths/WindowTest.gif This is my fault. I sent you the wrong test source code. I'm running a number of test cases for Sun. Anyway attached is the correct source code that produced the image listed in my previous email. With the updated source I get the correct title without (B prefix. I even tried some valid values of LANG as Tim suggested with no effect. I may reproduce a prefix in recent gnome apps with some LANG or LC_ALL. This may be related to the fact that I (and Brad) have jdk-1.3, while you use more recent version. Also with my swing 1.3, setSize has no effect. Can you try java 1.3 by a chance? It does not seem to use locale. Please configure fvwm with --enable-multibyte and report results. 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: CVS migo: * changed version from 2.4.0.1 to 2.4.1
On 19 Jul 2001 08:41:05 -0400, Dan Espen wrote: Olivier Chapuis [EMAIL PROTECTED] writes: But we want also to add new features to 2.4.x: at least Xinerama support and maybe fvwm-ewmh merging. I think, as Dan suggest in an other thread, that we should open a new branch for these. Here one reason for this: Say that we release 2.4.1 in a few weeks as a bug fix release, then we begin to add new features to the 2.4 branch with version 2.4.2. Then if we found a serious bug in 2.4.1 we will have some problems to release 2.4.2 at once (since 2.4.2 will be beta). I suggested opening 2 branches, one for Xinerama, the other for fvwm-ewmh. So I think that if we want to add new feature to 2.4 we need a new branch: 2.5 (We may even want to release 2.6 at some point). I do not think that a sequence like 2.5.0, 2.5.1, 2.4.2 would be confusing: 2.4.2 will only contains back port of new features from the 2.5 branch (the linux kernel use this method). Moreover, if we do not want to release 2.6.0 at all and do not want to have a devel branch without a stable release at the end we can open 2.9 now, do the work we want to do for 2.4.x in 2.9 and back port it. But I think that 2.5 is better. I don't think numbering the branch 2.5 is a good, mainly because I don't think we should start a 2.5 series that will take 2 years to release. If we name the branches instead of numbering them, we can easily create merged source trees to test all or some of the branches. When any one of the branches becomes stable, it can be merged into 2.4.x and released. Do you suggest this for 2.4.x releases or for later ones as well? So a new named branch should be created for any new feature (or a set of features). For example, 2.4.2 requires 2 named branches, 3.0 requires at least 20 named branches accourding to todo-3.0 and mail archives. What should a developer do? I suppose, have the source trees for all N branches and install them in N locations. Should we release beta version for every branch? If not, how the beta branch becomes stable? What should a user do with all these betas if we do release betas for every branch? Managing N branches (creating, commiting, merging, installing, running) is a nightmare. If the same developers and users work on / test all branches, having more than one beta branch has only disadvantages in my opinion. Correct me if I miss something. If this works, please describe how. An other advantage of a 2.5 branch is that doing 3.0.0 can take some years. So at some point it will be may be good to release 2.6 with some important feature from 2.9 but compatible with 2.4. I hope we NEVER create an incompatible release. Well, any software theory suggests for evolving projects to do full or partial refactoring from time to time. And to break compatibility without thinking twice if this improves the project. At the end the user benefits from a better program, even he should learn new things. We tried hard to keep 2.4 compatible with 2.2, I don't think this should be necessarily continued to 3.0. 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: man page formatting
On 21 Jul 2001 19:26:09 +0200, Dominik Vogt wrote: The recent fixes in the man page for Solaris etc. (\f...) broke the bold typeface of the reformatted sections. For example: .TP .BI Menu menu-name [ position ] [ double-click-action ] was changed to .IP Menu \fImenu-name\fP [ \fIposition\fP ] [ \fIdouble-click-action\fP ] The Menu, [ and ] parts of the old version are bold while they are not in the new one. Of course this can be fixed by adding more \fB...\fP pairs, but I'd *really* prefer to find a way to do that without \f... Isn't there a way to split the .BI lines into several? Any ideas are welcome. I suggest the following style for all commands: .B Menu .I menu-name .BI[ position ] .BI[ double-click-action ] .B Popup .I popup-name .BI [ position ] .BI [ default-action ] I.e. use .B for command, .I for mandatory parameters, .BI for optional. I also think, the spaces in braces are not really needed: .BI [ position ] This syntax is more readable in my opinion. I may do all these changes. 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: CVS domivogt: * First version of Xinerama support.
On 21 Jul 2001 14:29:27 -0500, FVWM CVS wrote: Log message: * First version of Xinerama support. I don't think that HAS_XINERAMA is ever defined (because XINERAMA_CPPFLAGS is nowhere used) and thus parts of the xinerama code are ever compiled in, although it is reported as such. It is also buggy. Windows get Y coordinate -9, i.e. disappear, when trying to move them... I don't have any real hardware xinerama setup, but X supports it. 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: CVS domivogt: * First version of Xinerama support.
On 22 Jul 2001 16:49:43 +, Mikhael Goikhman wrote: Yes, Xinerama support is on after configure; make install. The same problem happens with configure --disable-xinerama. BTW, I can't reproduce the problem with WindowShade now. Only interactive Move is problematic. 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]
New web mirror
I wanted to setup a web mirror when we were in an uncertainty period during the flood, but due to reasons not related to me, it is available only now. The mirror's url is: http://fvwm.sourceforge.net/ or simply fvwm.sf.net, it is updated every 4 hours from cvs. 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: 2.3.21 sed creating fvwmbug may fail
On 29 Jul 2001 16:44:20 +0100, Will Partain wrote: The sed script creating fvwmbug may fail if you happen to have CFLAGS including a comma, e.g. CFLAGS = -O -Wl,-R/usr/local/lib I'm guessing it would be slightly safer to use '|' as the delimiter. Also, it's safer to remove the fvwmbug if the sed fails than to leave it (typically zero-length) lying around. There may be other instances in the source where similar paranoia would make sense. Diffs below. Regards, I will remove this Makefile rule, the second (manual) stage is not really needed, everything may be done in the first (automatical) stage. BTW, 2.3.21 is more than a year old, 2.4.0 is much better. 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]
Version string (Was: make rpm-dist fails)
On 30 Jul 2001 03:50:33 +0930, Alex Wallis wrote: I just updated my cvs and make rpm-dist fails with the following error... sed: -e expression #3, char 71: Unknown option to 's' Name field must be present in package: (main package) Version field must be present in package: (main package) Release field must be present in package: (main package) Summary field must be present in package: (main package) Group field must be present in package: (main package) License field must be present in package: (main package) make[1]: Leaving directory `/home/awol/cvs/fvwm/rpm' Tarballs and bzips seem to build okay. Ok, this is fixed. But then I get: error: line 15: Illegal char '-' in version: Version: 2.4.1-beta1 It seems that rpm does not like '-' in a version string. I can understand the reasoning; '-' is used at the left of the version to separate it from the package name and at the right - to separate it from the revision. There are more reasons to only use numeric x.y.z for a version string. For example, some tools like /bin/sort, configure in fvwm-themes, package managers may consider 2.4.1-beta1 version more recent than 2.4.1. I think the common practice is to change a version string only after a final release (not just stable), I see no reason for us not to do this. I.e. the version in configure.in is 2.4.1. If there is a need to release a non-final version, the tarball is named fvwm-2.4.1-beta1.tar.gz, but the version is still 2.4.1. There is no confusion, just like there is no confusion in daily snapshots as long as they are renamed propertly. With rpm it is even siplier, nothing should be renamed, make rpm-dist by default creates fvwm-x.y.z-0.20010730; the release starting with 0 is used by convention for a non-final version, the final release is greater than 1. So, IMHO we should put only numeric values x.y.z in configure.in, in this case 2.4.1. Removing postfixes will also remove some pressure from you in the following releases (to change version only at the last moment and not before). You will even be able to use make_fvwmdist.sh again. Another (stupid) reason is that having 2.4.0-pre1 version creates module subdir 2.4.0-pre1 even if there is no a single change from 2.4.0 subdir. 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]
ButtonStyle Vector enhancements
I have applied a small patch that adds 2 more colors to button vectors. There is a thread with this feature request and some discussion: http://www.hpc.uh.edu/fvwm/archive/0105/msg00294.html There are now 4 colors from a colorset, 0 to 3: shadow, hilight, bg, fg. So something like this is possible: ButtonStyle 8 Vector 10 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] \ [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ButtonStyle 0 Vector 10 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] \ [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] The first color in Vector is not used, so it is good to be always 2 (bg). As I mentioned in the linked thread, lines are more suitable for a relief shadow drawing, to draw using fg and bg colors shapes are more suitable. Probably later it makes sense to have pseudocommands: MoveToPoint, LineToPoint, RectangleToPoint, CircleOfRadius and so on. Currently there is only a LineToPoint functionality. Any suggestions are welcome. This may be done (or not) after we open the next branch for beta features. 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: A pair of questions regarding FVWM setup
On 04 Aug 2001 16:15:37 +0700, Dmitry Yu. Bolkhovityanov wrote:
First, is it possible to do a Windows-3.1-like windows and menus? The
problem with borders is that in case of BorderStyle -- flat handles are
invisible even without HiddenHandles. The accompanying problem with menus
is that there's only BorderWidth flag, without an ability to switch
3D-ness off (with Nops too). Both seems to be caused by lack of
BorderColor concept. Am I missing something?
Windows have BorderColor concept. Style * [Hilight]BorderColorset.
Menus have BorderColor concept (kind of) using MenuStyle MenuColorset
and ActiveColorset; you may specify sh and hi colors in these colorsets.
I don't remember how should look windows-3.1 windows and menus, so I can't
say whether something is missing to fully or partially emulate the look.
It is hard to believe someone is interesting in microsoft solutions. :)
Second, is it possible to create an if-then-else construct in a
function? I tried to emulate the behaviour of Win9x's TaskBar, which can be
described as:
if (Iconic || !Raised)
{
Iconify Off
Raise
Focus
}
else
{
Iconify On
}
(i.e. deiconify if iconified, otherwise raise of not raised, otherwise
iconify).
We discussed adding shell abilities to fvwmrc two years ago and the
decission was not to do this, since preprocessors and PipeRead can do it.
But if-else construct does not seem too hard to implement. If we do this
we may have if, else, endif commands, so braces are not needed.
if (Iconic || !Raised)
Iconify Off
else
if (!Iconic)
Iconify On
endif
endif
This only seems complex, in fact it is simple. There is a list of boolean
conditions (one for each level of if) and the current command is
executed or skipped depending on the last boolean. (if, else, endif)
commands only manipulate this list of booleans (push, not, pop).
But this can't be done with a syntax of if-then; if-then, since the
following happens:
AddToFunc Deiconify-Raise-Focus
+ I Iconify Off
+ I Raise
+ I Focus
AddToFunc Deiconify-or-Raise-or-Iconify
+ I Current (Iconic) Deiconify-Raise-Focus
+ I Current (!Raised) Raise
+ I Current (Raised, !Iconic) Iconify On
but by the time the last line is reached, the window will *always* be raised
and deiconified. Is this fixable somehow?
Well, with some hacks everything is possible, including your example. :)
SetEnv MyCondition 0
Current (Iconic || !Raised) SetEnv MyCondition 1
PipeRead `if [ $[MyCondition] == 1]; echo Iconify Off; echo Raise; \
echo Focus; else echo Iconify On; fi`
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: ButtonStyle Vector enhancements
On 02 Aug 2001 12:47:30 +0700, Dmitry Yu. Bolkhovityanov wrote: On 1 Aug 01 at 15:34, [EMAIL PROTECTED] wrote: I have applied a small patch that adds 2 more colors to button vectors. There is a thread with this feature request and some discussion: http://www.hpc.uh.edu/fvwm/archive/0105/msg00294.html There are now 4 colors from a colorset, 0 to 3: shadow, hilight, bg, fg. So something like this is possible: ButtonStyle 8 Vector 10 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] \ [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ButtonStyle 0 Vector 10 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] \ [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] The first color in Vector is not used, so it is good to be always 2 (bg). As I mentioned in the linked thread, lines are more suitable for a relief shadow drawing, to draw using fg and bg colors shapes are more suitable. Probably later it makes sense to have pseudocommands: MoveToPoint, LineToPoint, RectangleToPoint, CircleOfRadius and so on. Currently there is only a LineToPoint functionality. Any suggestions are welcome. This may be done (or not) after we open the next branch for beta features. This would be a very useful feature. I don't know the reasons of the He wanted to emulate Blackbox WM window look, emulating TWM/CTWM window look would be interesting too. guy in referred thread, but the case when it is useful is buttons in Win9x style -- those should grow with title font size, and pixmap buttons are absolute unsuitable here. But win-95 buttons have colors unrelated to the window colorsets (active and inactive), so unless there is a way to specify other colors in Vector, this will not help you. Actually, it is a good idea to have ButtonColorset, HilightButtonColorset in addition to the current Colorset, HilightColorset in Style. And Vector may have a syntax to choose between the window's colorset (current colors numbers 0,1,2,3) and the button's colorset. The current decoration code is totaly ignorant of colorsets, and I prefer if someone more knowledgeable starts to change it. Just two notes. First, in addition to lines/rects/circles a filled polygon is needed (to draw all those [X] and alikes). I only meant a filled polygon, otherwice it's already possible using lines. Second, IMHO, names of the commands should be as short as possible -- like lineto, rectto, etc. Otherwise definitions will look just too heavy. These long names were not supposed to be a syntax, I have no problem if the syntax is mnemonic (one char per command, like 'l' for line, 'r', 'c'). BTW, is it currently possible to lift the pen with AddButtonStyle, i.e. draw two disjoint shapes? You use 2 AddButtonStyle commands, one draws the first shape and the second draws the second. The result is summed. 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: What to do for next release?
On 02 Aug 2001 21:29:19 +0200, Dominik Vogt wrote: On Mon, Jul 30, 2001 at 12:23:48AM +, Mikhael Goikhman wrote: On 29 Jul 2001 02:28:52 +0200, Dominik Vogt wrote: I have been thinking about the plans for the next release and about the long way we had to go for 2.4. Dan is absolutely right when he wants to find a way to establish a shorter release cycle. 2.4 took to much time and I doubt I have the endurace for such an herculean effort again. There are a *lot* of things that were postponed until after 2.4 that could be done now. All the small enhancement requests and bug fixes alone may justify another release. I believe 2.4 got out of hand because we tried to do everything at once at first and then there were too many dependencies in the code to be resolved so that we could not release although we wanted to. It may be better to plan for a 2.6 release that comes up with many small enhancements, bug fixes and maybe even some of the bigger but less disruptive features. A new stable release within half of a year semms to be a good plan to me. What do you think? If we already go for 2.6 in some months, maybe grab cvs before Xinerama commits and release 2.4.1 based on it? The current one may become 2.5.0. This is somewhat similar to what I and Olivier suggested previously. I think I don't understand what you are saying. What do you mean with maybe grab cvs before Xinerama commits and release 2.4.1 based on it? What I mean is this. If we go for 2.6 in some months, maybe we leave 2.4.x branch for fatal bugs only, move to 2.5.x betas and release 2.6.0 with Xinerama, EWMH support (both need a deep testing) and probably other not very big features just like you suggest. If you ask how to do this technically, this is another question, first we should agree whether we (you) want Xinerama in 2.4.1 or 2.6.0. 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]
Pegasus Mail
Dmitry, you use Pegasus Mail. I don't know whether you noticed, but this mailer is the only one (there is also /bin/mail) that does not support threads. When you get dozens of emails daily, threads are essential. Most mailers (I can list 20) support In-reply-to: header (used to show threads), some also support References: header (this is used by mail archives to add links to related messages, usually to all parents). Take a look at http://www.hpc.uh.edu/fvwm/archive/0107/threads.html . You always start a new thread although most of messages are Re: ones. Is it an option to change your mailer to a more standard-compliant one? I can suggest pine for DOS, but there are more (I didn't use any though). I know it may be a pain. But it was your decision (a bad decision :) ) to use a non free software, patching a free program to set In-reply-to: header in replies should not take more than an hour. P.S. I remember pmail in 1993, a nice colorfull pseudographics text toy. 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: Pegasus Mail
On 05 Aug 2001 13:48:04 +0200, Dominik Vogt wrote: On Sat, Aug 04, 2001 at 01:31:56PM +, Mikhael Goikhman wrote: Dmitry, you use Pegasus Mail. I don't know whether you noticed, but this mailer is the only one (there is also /bin/mail) that does not support threads. When you get dozens of emails daily, threads are essential. Most mailers (I can list 20) support In-reply-to: header (used to show threads), some also support References: header (this is used by mail archives to add links to related messages, usually to all parents). Take a look at http://www.hpc.uh.edu/fvwm/archive/0107/threads.html . You always start a new thread although most of messages are Re: ones. Perhaps you should consider using mutt. It can even identify the If you press 'h' in your mutt, you will see that I am using mutt. correct thread without one of those headers (I guess it's using the subject). Although it's not perfect (such mails are always shown as a reply to the first mail in the thread), at least you get the mails sorted into threads: Jul-29 To fvwm-workers What to do for next release? Jul-30 To fvwm-workers |- Aug-02 To fvwm-workers | `- Aug-04 To fvwm-workers | `- Aug-04 To fvwm-workers `* The last line shows a reply without thread information (indicated by the asterisk). I know that mutt guesses that a message belong to a thread by its subject and adds it to the end of thread. But this does not help for comunication. Consider a not very complex tree: 1350 Jul-22 Dominik Vogt(2.9K) Some subject 1351 Jul-22 Mikhael Goikhman(3.7K) |- 1352 Jul-22 Dan Espen (2.7K) | |- 1353 Jul-22 Mikhael Goikhman(1.3K) | | `- 1354 Jul-22 Dominik Vogt(6.7K) | `- 1355 Jul-22 Dmitry Yu. Bolkhovi (7.5K) `* 1356 Jul-22 Dominik Vogt(4.9K) `- There is no any chance to know whether 1355 is a reply to Dominik, Dan or me (and if to me, to which message) if a mailer does not supply this info. It is unfortunate that someone uses closed non-standard mailer, that breaks a thread into 2 threads exponentially every time a message is sent. I would just patch it and not whine. Now I can only suggest to switch. 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]
Proposing a new if-else syntax
On 05 Aug 2001 13:34:02 +0200, Dominik Vogt wrote:
How about this enhancement to conditional commands:
Next (conditions) { false-action } true-action
This would allow an else case in all conditional commands
without the need to store a return code of these commands. For
example:
AddToFunc ToggleWindow
+ I Next ($0) { Exec $0 } Close
This may work, but is this the best possible solution? This syntax is not
very readable and having else-command before then-command does not make it
better. As before there is still a limit to one command in both branches,
so you are forced to create small functions without a real need. It also
adds a problem of escaping curly brackets in else-command when needed.
What about parsing of nested conditional commands, braces in braces? :)
It seems that an idea of 2 commands on the same line is not very good.
Here is my revised proposal that solves all problems described above.
There are 2 constructs, one is long and one is short, both may be mixed:
if Next (conditions) {
then-commands, one per line
}
else {
else-commands, one per line
}
if Next (conditions) then-command
else else-command
Other one-or-zero-window commands may be used instead of Next as well:
Prev, Current and None. The default if not specified is Current.
The rules are similar to C, else belongs to the last if, braces may
be used to change this. else part is optional. Indentation is optional.
The { may only appear in if or else line, } should be on its own.
The syntax seems to be unambiguous, but a more formal proof is needed.
Here is a long example demostrating the syntax that may be used with
FvwmEvent add_window:
# when a new window appears do the following with it
if (Netscape: *) {
# this Certification logic is from my real config
if (Netscape: Certificate Authority Is Expired) {
WarpToWindow 310p 330p
FakeClick depth 0 wait 200 press 1 wait 100 release 1
}
# warp to Question, so Find dialog does not lose focus
if (Netscape: Question) WarpToWindow 20p 70p
elsif (Netscape: Find) {
if Next (Netscape: my page) {
Next (Netscape: Find) AnimatedMove 40 40
}
}
}
elsif (Terminal) {
AnimatedMove +100 -0 # gnome-terminal lacks position
WarpToWindow 50 10p
}
elsif (Annoying Window) {
Delete # try to delete it nicely first
if Next (Annoying Window) Destroy
}
elsif (Unimportant Window) Lower
elsif WindowId $w (!AllowsFocus) {
if WindowId $w (XClock) {
# force only one xclock, close all previous ones
WindowId $w Layer +1
All (XClock, Layer) Close
WindowId $w Layer -1
}
# individual window Style implementation is only in plans
Style (Id $w) CirculateSkip
}
For a comparision, try to implement the same logic using the suggested
Next (conditions) { else-command } then-command syntax, and count how
many functions you should create. Which one is more readable?
There are 5 new commands if, else, elsif, { and } in this
proposal. No existing command syntax is changed, which is an advantage.
The problem here is psychological, we all know that to add a command, some
prefix like + should be used. We got used to a limiting syntax. :)
Other news is that now a command may be ignored if it's in false branch.
Here are some problems to think about, some are easily solvable, some not.
If someone forgets to close a brace he gets an error at the end of file.
FvwmConsole may handle and show the level of if in the prompt.
What happens if modules try to send command groups concurently. They
will be mixed, just like now if modules try to define menus and functions
concurently bad things happens. So this is not really a new problem.
It should be thought more of course. But implementing this is not hard.
The commands { and } used to group other commands may be used in other
places too if we accept this idea.
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: Proposing a new if-else syntax
On 06 Aug 2001 10:01:51 +0100, Tim Phipps wrote: I think we can already do conditional code using self modifying functions: Ah yes, I forgot, I use self modifying functions in fvwm-themes to implement a state. But I would prefer functions to be used on purpose, to define an interface with parameters that can be called from any place. Using functions to implement state variables and switch is not ok. :) But then you'll end up doing a while command, then a switch, then a break and I think you've got youself a new language to learn. I think the SCWM approach is better if this is what you want i.e. put a real interpreter in there (I'd prefer TCL since I already know it) so that people don't have to learn a new language and we don't have to design and test it. If you ask me, I would place a real interpreter language, tcl is fine. But this does not seem possible. This would require an absolutely new syntax. I am ready to rewrite hundreds of kilobytes of fvwm-themes configs, but I fear that some others have problems to rewrite their. I only suggested my version of if-else implementation (which I think is good to have anyway), because I felt it is a better solution than the two alternative commands on the same line, suggested previously. 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: Patch for possible if-else syntax
On 08 Aug 2001 14:57:41 +0200, Dominik Vogt wrote: On Wed, Aug 08, 2001 at 04:45:34AM +, Mikhael Goikhman wrote: In any way, this solution is more clean and extendible than the Dominik's one and it does not change any existing syntax. Hm. I'd really prefer a solution that is *not* extensible. I thought there was a common consensus that we don't want to implement a scripting language in fvwm. Are not scripting language and extensible solutions orthogonal? Maybe we speak about different meanings of extensible solution, or you really prefer to solve all new and old problems separately? For example, if there is a need to do the following 1) Add an alternative command to conditions 2) Try several file names to Read 3) Determine that a module was not started 4) Determine a timeout in some commands you suggest to alter a syntax of Next, Read, Module, ModuleSynchronous and others, instead of identifying that all these problems are actually one if-else problem and implementing an extensible solution, like command statuses and Otherwise, without a need to change any existing syntax? With this solution, solving more similar problems is done by adding a line. Or another example of extensible solution. We currently only need a command status True/False, so we go with Boolean by adding it to many places. But tomorrow we will need another Boolean, so we should add it to the same places again. An extensible solution would suggest that we will need more than a Boolean in the future and do it in the first place. So, if there are no objections I will apply the merged patch implementing this new command. And BTW, it has sense (not yet) to call this command outside of functions. Read myfile1 quiet Otherwise Read myfile2 quiet Otherwise Echo Error: No myfile1 or myfile2 found That's the best example I could think of why global variables are *not* the way to go. Whenever a command is executed outside a function, there is a chance that another command gets executed first and screws up the return code. You are right, there is a common problem with synchronizing commands from the same stream in concurrent environment. But there are no problems if these commands are Read from a file, because another command can't get executed until the file is finished. So I still think that Otherwise outside of functions is useful, although it is almost useless interactively. 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: Patch for possible if-else syntax
On 08 Aug 2001 21:29:50 +0200, Dominik Vogt wrote:
On Wed, Aug 08, 2001 at 08:14:01PM +0700, Dmitry Yu. Bolkhovityanov wrote:
On Wed, 8 Aug 2001, Dominik Vogt wrote:
Is it really necessary to pass function return codes through
global variables? If we do this now we will regret it some day.
That's just a logical consequence of current CMD_fff calling
convention. I really investigated if globals can be avoided, but there is
*no* per-call structure to hold the return value.
That's why I wanted avoid function return codes. Every return
in each CMD_... function would have to be touched.
And yes, there is an obvious case when this solution would break
-- if someday fvwm will allow concurrent execution of functions (AFAIK,
currently it does so in an interrupt fashion, so that saving/restoring
the state in execute_complex_function() is enough).
What do you mean with if someday? Fvwm already supports
asynchronous execution, e.g. when modules send commands.
I think Dimitry meant asynchronous execution of _complex_ functions.
I myself often call complex functions simply functions as opposed to
functions that are commands.
Anyway, there is a fairly simple solution to save the patch: add
another parameter to the macros in fvwm.h:
#define F_CMD_ARGS XEvent *eventp, Window w, FvwmWindow *tmp_win, unsigned
long context,char *action, int *Module, Bool *ret_rc
#define F_PASS_ARGS eventp, w, tmp_win, context, action, Module, ret_rc
#define F_EXEC_ARGS char *action, FvwmWindow *tmp_win, XEvent *eventp,
unsigned long context, int Module, Bool *ret_rc
#define F_PASS_EXEC_ARGS action, tmp_win, eventp, context, *Module, ret_rc
(sorry for the long lines).
The *ret_rc would be pre-initialised with True just like the
globals in the patch. Only conditional commands ever set it to
False. Now, only the few direct calls of CMD_... functions that
do not pass the arguments via one of the macros have to be
modified. This would be good enough for me.
The patch became much longer, because all references to
old_execute_function and some other functions should be altered.
I attach the patch for reviewing. Changes other than in conditional.c and
functions.c are less interesting. The patch is somewhat different from
Dmitry's, but implements the same thing. Complex functions return the
status of the last inner command. Probably some things may be tuned.
Regards,
Mikhael.
Index: fvwm/add_window.c
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/add_window.c,v
retrieving revision 1.226
diff -u -r1.226 add_window.c
--- fvwm/add_window.c 2001/06/23 18:30:15 1.226
+++ fvwm/add_window.c 2001/08/09 14:55:53
@@ -1497,7 +1497,7 @@
if (!IsRectangleOnThisPage(tmp_win-frame_g, Scr.CurrentDesk))
{
SET_STICKY(tmp_win, 0);
- handle_stick(Event, tmp_win-frame, tmp_win, C_FRAME, , 0, 1);
+ handle_stick(Event, tmp_win-frame, tmp_win, C_FRAME, , 0, NULL, 1);
}
}
@@ -1516,7 +1516,7 @@
Event.xbutton.y = (tmp_win-frame_g.height1);
Event.xbutton.subwindow = None;
Event.xany.window = tmp_win-w;
-CMD_Resize(Event , tmp_win-w, tmp_win, C_WINDOW, , 0);
+CMD_Resize(Event , tmp_win-w, tmp_win, C_WINDOW, , 0, NULL);
}
/** window colormap **/
Index: fvwm/builtins.c
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/builtins.c,v
retrieving revision 1.313
diff -u -r1.313 builtins.c
--- fvwm/builtins.c 2001/08/01 15:22:51 1.313
+++ fvwm/builtins.c 2001/08/09 14:55:57
@@ -1861,7 +1861,7 @@
if (!*s)
return;
Scr.cur_decor = decor;
- old_execute_function(s, NULL, Event, C_ROOT, -1, 0, NULL);
+ old_execute_function(s, NULL, Event, C_ROOT, -1, NULL, 0, NULL);
Scr.cur_decor = NULL;
}
@@ -1968,7 +1968,8 @@
fw-frame_g.height -= fw-decor-title_height;
fw-decor = NULL;
old_execute_function(
- ChangeDecor Default, fw, eventp, C_WINDOW, *Module, 0, NULL);
+ ChangeDecor Default, fw, eventp, C_WINDOW, *Module, NULL, 0,
+ NULL);
}
}
}
@@ -3267,7 +3268,8 @@
usleep(20);
UngrabEm(GRAB_BUSY);
}
-old_execute_function(stroke_action, tmp_win, eventp, context, -1, 0, NULL);
+old_execute_function(
+ stroke_action, tmp_win, eventp, context, -1, NULL, 0, NULL);
}
}
Index: fvwm/commands.h
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/commands.h,v
retrieving revision 1.1
diff -u -r1.1 commands.h
--- fvwm/commands.h 2001/03/24 15:15:21 1.1
+++ fvwm/commands.h 2001/08/09 14:55:57
@@ -114,6 +114,7 @@
void CMD_None(F_CMD_ARGS);
void CMD_Nop(F_CMD_ARGS);
void CMD_OpaqueMoveSize(F_CMD_ARGS);
+void CMD_Otherwise(F_CMD_ARGS);
void CMD_Pick(F_CMD_ARGS);
void CMD_PipeRead(F_CMD_ARGS);
void
Re: Patch for possible if-else syntax
On 09 Aug 2001 17:35:57 +0200, Dominik Vogt wrote: I'd rather rewrite the syntax 20 commands than extend the command parser in such a way. Currently it is *the* worst piece of fvwm code: not extensible, hard to understand, undpredictable, buggy. I am not sure why do you think so. I see no reasons. It is actually not hard to understand if you understood the original smaller patch. Granted, I didn't tested it fully, only maybe 5-6 cases, But if you don't use the new stuff (command Otherwise or last status $?) there should not be any reduction in stability. This may wait for 2.5.0. You are right: it can only work inside complex functions and Read files and fail from modules and the command line. I guess then my proposal is still the most sound one: easy to implement, the patches are limited to a single file, helps with the most basic needs some users have and does not encourage difficult to implement enhancement requests. In my eyes, we can only think about scripting support in the command parser if we are prepared to throw away the whole code in functions.c and write it from scratch - which explicitly means that the most central part of fvwm becomes incompatible to older versions. Concurrent command execution is already broken within + command. This is an old problem, which probably can be solved if we store all global data last_* separately for every module pipe. Will this be a solution? Dominik, you once said that a lot of harm was done by many small patches each implementing its own inconsistent syntax. The enhancement you suggest is powerful, of course, you may write a whole if-else program in one line using nested conditions. But I don't feel this is a good syntax to introduce. I would not introduce any new syntax as radical as this without thinking about consistency with other command syntaxes. The solution that does not introduce any new syntax, but solves more than one problem is more preferable to me. After 2.5.0 we may think and change syntax. Anyway, I have no any willing to force my solution without your agreement. 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: fvwmrect.h
On 14 Aug 2001 08:59:49 -0400, Dan Espen wrote: Tim Phipps [EMAIL PROTECTED] writes: Hi All, I can't find fvwmrect.h in the snapshots. The mail archive has it being added on 01/08/06. Do you have a sticky flag set somewhere? This file was missing for a while, but its in the libs directory now. I understand that Tim still has no cvs access... He speaks about snapshots. Tim, until tomorrow you may get it from: ftp://ftp.fvwm.org/pub/fvwm/devel/sources/libs/fvwmrect.h 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-menu-directory doesn't escape special chars
On 24 Aug 2001 11:41:22 +0100, Tim Phipps wrote: Description: fvwm-menu-directory produces syntax errors from fvwm when it tries to create a menu with a file that has two %'s in its name. It also doesn't handle * very well. @ and ^ in directory names needs fixing too but not in file names. Repeat-By: touch 1amp 1%perc 1*star touch 'doublequote' touch 2%perc% 2amp 2*star* mkdir 1^circ [EMAIL PROTECTED] 2^circ^ [EMAIL PROTECTED]@ touch 1^circ/file [EMAIL PROTECTED]/file 2^circ^/file [EMAIL PROTECTED]@/file Fix: Replace with etc. ^ is difficult with submenus as some shells interpret it as a |. It should be \ escaped by the time fvwm Exec's fvwm-menu-directory. Which unix shell interprets ^ in quotes specially? I fixed the problems above and some more, except for ^ and @ in Popup (they work in Menu with --reuse). I think it should be fixed in fvwm. Currently when MissingSubmenuFunction is called the argument is not passed correctly. Double ^^ and @@ are not converted to single ones as should be. Also if Popup my name contains spaces, 2 parameters are passed. The whole name may be read in $*, but $* is not good for fvwm-menu-directory (unlike $0 .. $9 if you use $* you should know how the function is called), the best solution is to implement what the man page says: I.e. the name is passed to the function as its first argument and can be referred to with $0. 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: Q about fvwm relations with RedHat
On 30 Aug 2001 13:13:24 +0700, Dmitry Yu. Bolkhovityanov wrote: I've noticed that RedHat, both 7.2beta (Roswell (UFO?:)) and RawHide still contain 2.2.5. So, they probably should be pushed to move to 2.4. The question is: are there any existing contacts between fvwm team and RedHat? If not, I can mail [EMAIL PROTECTED] (listed as last person who touched the .spec file), or maybe somebody else, having more experience in this area, is willing to do it? Yes, please do it if you think they should be pushed. I don't know. You may mention that all our rpms are built by make rpm-dist release=1. Please also mention that if they decide to use another namespace, i.e. build rpm non-compatible with ours, they should package fvwm-themes too, otherwise we should suggest users to replace their fvwm rpm with ours. 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]
Going to a vacation
I am going to a vacation for 3 weeks, flying out of the home. I will have a pretty limited internet access. BTW, I am still running with a patch implementing command statuses and new Otherwise command. So far there were no conflicts. Keep a good work. 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]
Creating rpms for RedHat Linux
I am not sure when I will be able to return to creating rpms, so please someone with RedHat systems create rpms for 2.4.2. Creating rpms is as trivial as running one make command once you setup the required environment, i.e. rpm-build installed, all devel libraries needed for building fvwm installed, and in case of old rpm-build on RH 6.x the user has permissions to write to /usr/src/redhat directory (newer rpm-build uses $HOME/redhat for this purpose). It is suggested that you use a stock RedHat 6.x and RedHat 7.x. You may use a non-stock system, but ensure that you don't have standard utilities like perl in /usr/local/bin or ~/bin, so resulting rpms work for all users not only on your system. Test your rpm on an other system. Here are the exact instructions: Install GTK+, ncurses, readline, libstroke rpms and their devel parts. Use rpms from http://fvwm-themes.sourceforge.net/rpm/support/ if needed. You should get support for all features except for gnome-libs, rplay and multibyte that are disabled (you may enable multibyte at your own risk). Get fvwm-2.4.2.tar.bz2 and unpack it. Alternativelly using cvs execute: cvs update -r version-2_4_2 If you have RH 6.1 or RH 6.2 system: * run: make rpm-dist release=1 * upload fvwm-2.4.2-1.i386.rpm and fvwm-2.4.2-1.src.rpm If you have RH 7.0 with updates for glibc and gcc or RH 7.1 system: * run: make rpm-dist release=1.rh7 * upload fvwm-2.4.2-1.rh7.i386.rpm Upload rpms (after testing that they work) to ftp://upload.sf.net/incoming . Unfortunately ftp port is closed now, so just upload to any place you can and notify Olivier and me about this. I prefer Olivier to do all the rest. 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: ~/.fvwm2rc not the default
On 27 Sep 2001 19:36:31 -0500, [EMAIL PROTECTED] wrote: Message summary for PR#789 From: [EMAIL PROTECTED] Subject: ~/.fvwm2rc not the default Full_Name: Neil Zanella Version: 2.4.2 When I start fvwm2 from a nondecorated window and do not specify a file name my $HOME/.fvwm2rc is not read. Instead, some other system.fvwm2rc by redhat is used. Are you sure you start the correct fvwm2 executable? There is no way a redhat config is used if you run a non-redhat fvwm2. You may run fvwm2 -version and strace fvwm2 21 | grep open to get more information about a version and config files read. The same applies to when I click restart from a menu. If I say fvwm2 -f $HOME/.fvwm2rc though, the file is found and used, but not upon restarting. If you have Restart fvwm2 command in your menus, this is expected. Just like the man page in 2.4.x versions says, replace all Restart fvwm2 in your fvwm2rc with simply Restart, so you restart the same WM. According to the manual $HOME/.fvwm2rc should be searched first. Well, $HOME/.fvwm/.fvwm2rc is searched first. Other than that I can't explain why some system.fvwm2rc is used in your case (which one, BTW?), you didn't supply enough information. 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: Multi-Pixmap Titlebars (patch)
On 03 Oct 2001 22:06:56 -0400, Suzanne Britton wrote: I've been tinkering with the FVWM 2.4.2 source code lately, trying to rectify one of its few remaining lacks of themability :-) I've developed a patch which adds a new type of TitleStyle. You can specify up to six pixmaps for the titlebar in each state: main, under text, left of text, right of text, far left, and far right (the first two are tiled, the rest aren't). This allows FVWM to do a quite pleasing rendition of themes like Eazel-Blue and Crux (though without the fancy borders). The config syntax looks like this currently: TitleStyle Fancy state main pixmap far left left of text under text right of text far right You can specify no pixmap at any position by substituting '-' for a pixmap filename. The main pixmap will be tiled over any resulting empty spaces. I wanted to work on titlebar inhancements, because a titlebar is not configurable in FVWM as opposed to other window managers. But I didn't have a good design to start with it (and I am not an X programmer anyway). Your solution seems to be complete enough and does a minimal change. Some notes about a bloatness. I don't remember we had a consensus not to extend a titlebar functionality. If I missed it, please post a thread url. Instead I remember at least 5 user requests to be able to define a colorful pixmap that still leaves text readable. So users definitely would like your patch. (And fvwm-themes is the biggest user for that reason.) Tim suggested to move all fancy decorations to FvwmDecor module, but I am not sure how serious is this suggestion (i.e. who can implement this). Dominik and some others agreed that TitleStyle/ButtonStyle/BorderStyle commands should be dropped in favor of per-window styles using colorsets. But this does not mean the current configurability of these commands should be dropped, so, when such transformation happens your extended titlebar implementation could be reused together with the existing one. Bearing in mind that the patch is currently buggy (titleunder pixmap often doesn't update properly), unpolished, and the work of a complete FVWM/X programming newbie, you can find it attached to this e-mail and apply it to 2.4.2 via patch -p0 patchfile from the top source dir. You also have to #define FANCY_TITLEBARS in config.h to activate any of the new code. Would there be any interest in integrating this into the main source tree? I am interesting to support an inclusion of this or updated patch. I have some questions, I am not sure what the correct answer should be. How is UseTitleStyle option of ButtonStyle affected? Is the main pixmap used in this case? How the continuation problem is solved? I mean, if some pixmaps are not defined will the main pixmap started again and again or one continued pixmap be used? What happens if a text is wider than a titlebar?.. 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: Multi-Pixmap Titlebars (patch)
On 03 Oct 2001 22:06:56 -0400, Suzanne Britton wrote: I've been tinkering with the FVWM 2.4.2 source code lately, trying to rectify one of its few remaining lacks of themability :-) I've developed a patch which adds a new type of TitleStyle. You can specify up to six pixmaps for the titlebar in each state: main, under text, left of text, right of text, far left, and far right (the first two are tiled, the rest aren't). This allows FVWM to do a quite pleasing rendition of themes like Eazel-Blue and Crux (though without the fancy borders). The config syntax looks like this currently: TitleStyle Fancy state main pixmap far left left of text under text right of text far right Should not the order for consistency be the following: TitleStyle state Fancy ... You can specify no pixmap at any position by substituting '-' for a pixmap filename. The main pixmap will be tiled over any resulting empty spaces. I can't apply your patch right now. I have more questions: * In http://www.igs.net/~tril/fvwm/glenwood.jpg do you use transparent pixmaps for * text? The same question about far *. It is not critical if all pixmaps should be non-transparent, but if only Main pixmap is fully destructive, it may be replaced by a general colorset later (TiledPixmap, [Resizable]Pixmap, complex gradient, solid color), while all other pixmaps would be only partially destructive. * Currently a titlebar text noticeably flickers in some configurations. How is a flickery with your patch? Just for a curiosity how hard is to update your patch to do the following: * Use named parameters for pixmaps with only one mandatory Main? * Use optionally Main pixmap as resizable instead of tiled. * Add optionally Button (LeftButton/RightButton) pixmaps that would be used instead of Main in ButtonStyle UseTitleStyle. This is needed if buttons are configured separately from a titlebar like in fvwm-themes. I am not sure the following are needed in practice, but to think about: * Use optionally LeftMain and RightMain instead of Main. Probably only useful with Centered text. * Optionally undefined under text pixmap is skipped (like other non-main pixmaps) instead of retiled. Options may be given after -- like in other TitleStyle styles. What I said is only thoughts. I am trying to find a reasonable optimum. 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: A small question regarding titles and borders
On 07 Oct 2001 12:29:49 +0700, Dmitry Yu. Bolkhovityanov wrote: How to specify a shadow thickness for raised/sunk titles and borders? There's no shadow thickness flag in TitleStyle/BorderStyle commands, and there's no thickness attribute in colorsets. On the other hand, at least Kendrick Vargas' screenshot shows a sunk title with thickness of 1 instead of default 2. So, how? You can't, it is hardcoded to 2 when raised/sunk. I didn't see Kendrick's config, but it is clear to me that he uses flat, not sunk title, everything is pixmap based. I.e. it only works with TitleStyle Height 19 in his case. As for borders, the shadow/hilite colors depend on the border width and some more flags, also hardcoded. And it is not symmetrical at different sides. Borders are hardly configurable. 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]
