Re: Documentation (was: Re: FVWM: How do I start modules automatically?)
On 01:39 12 Aug 2002, Dominik Vogt <[EMAIL PROTECTED]> wrote: | On Sat, Aug 10, 2002 at 11:44:35AM +1000, Cameron Simpson wrote: | > What kind of infrastructure did you have in mind? | > I'm personally very fond of POD as a source format for most stuff, since | > it's unassuming and very easy to edit and read, and readily generates | > other formats. Does require perl though. | | I'm a complete newbie inrespect to documentation formats. Some | basic requirements are: | | - Must be convertible to various other formats (man page, ps, |html and possible GNU Texinfo) and must look good in these |formats. It does all these, except texinfo, but it will emit latex if you really care. | - The tools must works on any system and should run out of the |box. if they have perl, definitely. |Everybody must be able to edit the documentation. Yes. It's damn near plain text with very simple and unintrusive markup. | - The format should be reasonably easy to edit without any tools |other than a text editor. Yep. That's what I like about it. | Perl is no problem, we already use it. Cool. Will have to address the 2nd half of your message later. Meanwhile, "man perlpod" will describe the format for you. Here's a shell script with its own manual page inlined (I pull it out and format with a script): http://www.zip.com.au/~cs/scripts/lz Here's the HTML page that makes. http://www.zip.com.au/~cs/man/lz.1.html The manual page looks exactly like a regular manual page. The leading hashes aren't part of the format - they're just shell comments to hide the POD from the shell. Typical pod is: =head1 A Heading Here's an example paragraph that will be filled (line flowed) by whatever backend format gets used. Here's a reference to the fvwm(1) manual page. Here's some literal (unfilled) text: DestroyFunc foo AddToFunc foo Next Here's the next paragraph with a B word. Very user friendly. -- Cameron Simpson, DoD#743[EMAIL PROTECTED]http://www.zip.com.au/~cs/ Academics get paid for being clever, not for being right. - Donald Norman -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: this morning's fvwmrc hack - menus matching key ops
On 23:41 10 Aug 2002, Dominik Vogt <[EMAIL PROTECTED]> wrote: | > Thus today's exercise. Two functions, KeyFn and MouseFn to set a key or | > mouse mapping and also record it in a menu: | > | > # KeyFn menu desc keyname context mods "cmd-and-args" | > DestroyFunc KeyFn | > AddToFunc KeyFn "I" Key $2 $3 $4 $5 | > + "I" AddToMenu $0 "$1" $5 | > | > # MouseFn menu desc button context mods "cmd-and-args" | > DestroyFunc MouseFn | > AddToFunc MouseFn "I" Mouse $2 $3 $4 $5 | > + "I" AddToMenu $0 "$1" $5 | | Nice idea. Here's an enhancement that displays the key binding | in the right column of the menu: | | + "I" AddToMenu $0 "$1($4-$2)" $5 | | Replace with a real tab. Heh. I was trying to find the right syntax for _exactly_ that change. Applied. Thanks! -- Cameron Simpson, DoD#743[EMAIL PROTECTED]http://www.zip.com.au/~cs/ Here's a great .sig I wrote, so good it doesn't rhyme. Jon Benger <[EMAIL PROTECTED]> -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
FVWM: Re: The "great focus policy rewrite"
Hi ! > All the problems you describe should be gone now. YES !! the ClickToFocus is working again !! THANKS !! the 2+2 extra buttons are still there. cheers, Giuseppe. PS great work, as usual ! ;-) -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
FVWM: Re: The "great focus policy rewrite"
On Mon, Aug 12, 2002 at 10:22:04AM +0200, Giuseppe Della Ricca wrote: > Hi ! > > > All the problems you describe should be gone now. > > YES !! the ClickToFocus is working again !! THANKS !! > > the 2+2 extra buttons are still there. Hm. Could you send me your config file please? Bye Dominik ^_^ ^_^ -- Dominik Vogt, mail: [EMAIL PROTECTED], phone: 0721/91374-382 Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
FVWM: Re: The "great focus policy rewrite"
Hi !
> Hm. Could you send me your config file please?
Sure !
Cheers,
Giuseppe.
##
# FVWM - F? Virtual Window Manager, Version 2.x (fvwm2) Configuration File
#
Read ConfigFvwmDefaults
##
# PATH Setup
#
ModulePath ${HOME}/libexec/fvwm/2.5.3
ImagePath \
${HOME}/include/X11/pixmaps:\
${HOME}/include/X11/icons
# COLORS and FONTS
#
CleanupColorsets
Colorset 0 Foreground black, Background grey90
Colorset 1 Foreground black, Background grey80
Colorset 2 Foreground black, Background grey60
Colorset 3 Foreground black, Background grey40
# Set the fore and back border colors for the window that has focus
Style * HilightColorset 1, HilightBorderColorset 1
# Set fore/back border colors for all other windows
Style * Colorset 2, BorderColorset 1
# Set title style
TitleStyle LeftJustified
TitleStyle ActiveUp TiledPixmap Active.xpm
TitleStyle ActiveDown TiledPixmap Active.xpm
TitleStyle Inactive TiledPixmap Inactive.xpm
# Set border style
BorderStyle Active TiledPixmap Active.xpm
BorderStyle Inactive TiledPixmap Inactive.xpm
# Set border width
Style * BorderWidth 5, HandleWidth 5
# Set colors/font for pop-up menus
MenuStyle * Fvwm, Animation
MenuStyle * MenuColorset 1
MenuStyle * ActiveColorset 0, HilightBack
MenuStyle * GreyedColorset 3
MenuStyle * Font -adobe-times-bold-r-*-*-14-*-*-*-*-*-*-*
# Set fonts to use on title bar and icon label
Style * Font -adobe-times-bold-r-*-*-20-*-*-*-*-*-*-*
Style * IconFont -adobe-helvetica-bold-r-*-*-11-*-*-*-*-*-*-*
# ICON Setup
#
# Auto Place Icons is a nice feature (Left Top Right Bottom)
Style * IconBox 768x0+0-1
# If you don't want icons for some or all windows (or all of them!)
#Style * NoIcon
# If you want ALL icons to follow you around the desktop (Sticky)
#Style * StickyIcon
# FOCUS Setup
#
# Does the window with focus control the colormap, or the one under the mouse
ColormapFocus FollowsFocus
#ColormapFocus FollowsMouse
# Uncomment this to force you to click in a window to give it focus
Style * ClickToFocus
#Style * MouseFocus
# MISC Setup
#
# click/release must occur in )
#ButtonStyle * Vector 8 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL
PROTECTED]
# Horizontal Line with arrowheads on left and right ( <-> )
#ButtonStyle * Vector 12 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL
PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL
PROTECTED]
# Vertical Line with arrowheads on top and bottom
#ButtonStyle * Vector 12 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL
PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL
PROTECTED]
# Diagonal Line with arrowheads on top and bottom ( / )
#ButtonStyle * Vector 11 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL
PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
# Diagonal Line with arrowheads on top and bottom ( \ )
#ButtonStyle * Vector 12 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL
PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL
PROTECTED]
#
# the number "2"
#ButtonStyle * Vector 12 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL
PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL
PROTECTED]
##
# MENU Setup
#
# This defines the most common window operations
DestroyMenu Window-Ops
AddToMenu Window-Ops"Window Ops" Title
+ "Move%mini.move.xpm%"Move
+ "Resize%mini.resize.xpm%"Resize
+ "Raise%mini.raise.xpm%" Raise
+ "Lower%mini.lower.xpm%" Lower
+ "(De)Iconify%mini.iconify.xpm%" Iconify
+ "(Un)Stick%mini.stick2.xpm%" Stick
+ "(Un)Maximize%mini.maximize.xpm%"Maximize-Func
+ "" Nop
+ "Delete%mini.bomb.xpm%" Delete
+
Re: FVWM: Re: The "great focus policy rewrite"
On Mon, Aug 12, 2002 at 11:11:41AM +0200, Giuseppe Della Ricca wrote: > Hi ! > > > Hm. Could you send me your config file please? > > Sure ! Fixed. Bye Dominik ^_^ ^_^ -- Dominik Vogt, mail: [EMAIL PROTECTED], phone: 0721/91374-382 Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
FVWM: Re: Re: The "great focus policy rewrite"
Hi Dominik, > > > > Hm. Could you send me your config file please? > > > Sure ! > Fixed. thanks again ! cheers, Giuseppe. -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
FVWM: Own mouse pointers: define hot spot?
Hi, I created an xpm file as a new mouse pointer. This works fine. But can you tell me how to define the hotspot? I guess I should be able do it with a graphics application like the gimp and define it inside the xpm file. But up to now I don't find any command to do it. Could you tell me how you do it? Thank You, Felix -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Own mouse pointers: define hot spot?
On Mon, Aug 12, 2002 at 04:07:04PM +0200, Felix Kater wrote: > Hi, > > I created an xpm file as a new mouse pointer. This works fine. But can > you tell me how to define the hotspot? > > I guess I should be able do it with a graphics application like the gimp > and define it inside the xpm file. But up to now I don't find any > command to do it. Could you tell me how you do it? I've never found out how to create an xpm with a hotspot. But you can trick fvwm into using the correct hotspot by using a larger image and shifting it so that the hotspot is in the middle of the picture. E.g. if your image looks like this: *xx.. xx... x.x.. ...x. x * = hotspot x = black . = transparent Pad it like this: . . . . *xx.. xx... x.x.. ...x. x Bye Dominik ^_^ ^_^ -- Dominik Vogt, mail: [EMAIL PROTECTED], phone: 0721/91374-382 Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Own mouse pointers: define hot spot?
Dominik Vogt writes: > On Mon, Aug 12, 2002 at 04:07:04PM +0200, Felix Kater wrote: > > Hi, > > > > I created an xpm file as a new mouse pointer. This works fine. But can > > you tell me how to define the hotspot? > > > > I guess I should be able do it with a graphics application like the gimp > > and define it inside the xpm file. But up to now I don't find any > > command to do it. Could you tell me how you do it? > > I've never found out how to create an xpm with a hotspot. But you > can trick fvwm into using the correct hotspot by using a larger > image and shifting it so that the hotspot is in the middle of the > picture. E.g. if your image looks like this: Heres how to create an XPM with a hotspot (from the XPM docs): The Values-string is a single string that must contain four integers that correspond to the width and height of the pixmap, the number of colors in the pixmap, and the number of characters per pixel in the color specification. The string can optionally specify the hotspot coordinates and the word XPMEXT if the pixmap includes an Extensions-string. The format of the string is as follows: width height ncolors cpp [x_hotspot y_hotspot] [XPMEXT] The hotspot is available to the program thru the XpmAttributes structure. -- Dan Espen E-mail: [EMAIL PROTECTED] 444 Hoes Lane Room RRC 1C-214 Phone: (732) 699-5570 Piscataway, NJ 08854 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Own mouse pointers: define hot spot?
On Mon, Aug 12, 2002 at 11:11:40AM -0400, Dan Espen wrote: > Dominik Vogt writes: > > On Mon, Aug 12, 2002 at 04:07:04PM +0200, Felix Kater wrote: > > > Hi, > > > > > > I created an xpm file as a new mouse pointer. This works fine. But can > > > you tell me how to define the hotspot? > > > > > > I guess I should be able do it with a graphics application like the gimp > > > and define it inside the xpm file. But up to now I don't find any > > > command to do it. Could you tell me how you do it? > > > > I've never found out how to create an xpm with a hotspot. But you > > can trick fvwm into using the correct hotspot by using a larger > > image and shifting it so that the hotspot is in the middle of the > > picture. E.g. if your image looks like this: > > Heres how to create an XPM with a hotspot (from the XPM docs): > > The Values-string is a single string that must contain four integers > that correspond to the width and height of the pixmap, the number of > colors in the pixmap, and the number of characters per pixel in the > color specification. The string can optionally specify the hotspot > coordinates and the word XPMEXT if the pixmap includes an > Extensions-string. > > The format of the string is as follows: > width height ncolors cpp [x_hotspot y_hotspot] [XPMEXT] > > > The hotspot is available to the program thru the XpmAttributes > structure. Could you put that in the FAQ? Bye Dominik ^_^ ^_^ -- Dominik Vogt, mail: [EMAIL PROTECTED], phone: 0721/91374-382 Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
FVWM: FvwmButtons
Hmmm, is there any way to get a FvwmButtons-bar to cover 10% of the screen in width? I would like something like this: *FvwmButtons: Geometry 10%x$[vp.height]-0+0 Regards, Johan Svedberg -- |Mail address |Home telephonenumber|E-mail address | |Johan Svedberg |+46 (0)90 - 49 139 |[EMAIL PROTECTED]| |Hästhagsvägen 2|| | |S-905 96 Umeå |Cellular telephonenumber|WWW address | |Sweden |+46 (0)70 - 639 49 82 |http://www.acc.umu.se/~winkle| -- -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Own mouse pointers: define hot spot?
Dominik Vogt writes: > On Mon, Aug 12, 2002 at 11:11:40AM -0400, Dan Espen wrote: > > Dominik Vogt writes: > > > On Mon, Aug 12, 2002 at 04:07:04PM +0200, Felix Kater wrote: > > > > Hi, > > > > > > > > I created an xpm file as a new mouse pointer. This works fine. But can > > > > you tell me how to define the hotspot? > > > > > > > > I guess I should be able do it with a graphics application like the gim > p > > > > and define it inside the xpm file. But up to now I don't find any > > > > command to do it. Could you tell me how you do it? > > > > > > I've never found out how to create an xpm with a hotspot. But you > > > can trick fvwm into using the correct hotspot by using a larger > > > image and shifting it so that the hotspot is in the middle of the > > > picture. E.g. if your image looks like this: > > > > Heres how to create an XPM with a hotspot (from the XPM docs): > > > > The Values-string is a single string that must contain four integers > > that correspond to the width and height of the pixmap, the number of > > colors in the pixmap, and the number of characters per pixel in the > > color specification. The string can optionally specify the hotspot > > coordinates and the word XPMEXT if the pixmap includes an > > Extensions-string. > > > > The format of the string is as follows: > > width height ncolors cpp [x_hotspot y_hotspot] [XPMEXT] > > > > > > The hotspot is available to the program thru the XpmAttributes > > structure. > > Could you put that in the FAQ? Sure. I haven't checked that Fvwm actually uses the hotspot if defined. I'll check if you haven't done so already. -- Dan Espen E-mail: [EMAIL PROTECTED] 444 Hoes Lane Room RRC 1C-214 Phone: (732) 699-5570 Piscataway, NJ 08854 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Own mouse pointers: define hot spot?
On Mon, Aug 12, 2002 at 11:49:54AM -0400, Dan Espen wrote: > Dominik Vogt writes: > > Could you put that in the FAQ? > > Sure. > > I haven't checked that Fvwm actually uses the hotspot if defined. > I'll check if you haven't done so already. As far as I remember, I implemented hotspot handling with the pixmap cursors a while ago. From cursors.c: if (!PImageLoadCursorPixmapFromFile( dpy, Scr.Root, path, &source, &mask, &x, &y)) ^^ hotspot coords ... Scr.FvwmCursors[index] = XCreatePixmapCursor( dpy, source, mask, &(colors[0]), &(colors[1]), x, y); Bye Dominik ^_^ ^_^ -- Dominik Vogt, mail: [EMAIL PROTECTED], phone: 0721/91374-382 Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: FvwmButtons
On Mon, Aug 12, 2002 at 06:01:47PM +0200, Johan Svedberg wrote: > Hmmm, is there any way to get a FvwmButtons-bar to cover 10% of the > screen in width? I would like something like this: > > *FvwmButtons: Geometry 10%x$[vp.height]-0+0 Yes, by calling a shell script: piperead 'echo echo *FvwmButtonsGeometry $$['$[vp.width]'/10]x'$[vp.height]'-0+0' Bye Dominik ^_^ ^_^ -- Dominik Vogt, mail: [EMAIL PROTECTED], phone: 0721/91374-382 Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Own mouse pointers: define hot spot?
Dominik Vogt wrote: > On Mon, Aug 12, 2002 at 11:49:54AM -0400, Dan Espen wrote: > > Dominik Vogt writes: > > > Could you put that in the FAQ? > > > > Sure. > > > > I haven't checked that Fvwm actually uses the hotspot if defined. > > I'll check if you haven't done so already. > > As far as I remember, I implemented hotspot handling with the > pixmap cursors a while ago. From cursors.c: > > if (!PImageLoadCursorPixmapFromFile( > dpy, Scr.Root, path, &source, &mask, &x, &y)) > ^^ hotspot coords > ... > Scr.FvwmCursors[index] = XCreatePixmapCursor( > dpy, source, mask, &(colors[0]), &(colors[1]), x, y); > > I can confirm that fvwm (2.4.7) honors cursor hotspots. On Solaris, I use the "dticon" utility to create most of the cursors I use. Dticon lets you set a cursor's hotspot with a mouse click on its enlarged image. Gregg Dameron -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
FVWM: AnotherLevelUp FVWM configuration
Can I continue to thank FVWM developers for your efforts and congratulate you in your successes in maintaining and evolving FVWM -- probably the best window manager in the world? :-) Annoucement: AnotherLevelUp fvwm configuration now works with FVWM 2.4 and 2.5. See http:www.cs.man.ac.uk/~jtl/ALU for details. The process of upgrading AnotherLevelUp has revealed some `undocumented features changes' in FVWM. I thought the FVWM developers may find it useful if I report them here, each in a separate email. Best wishes, John Latham - Dr. John Latham, Room 2.113, Department of Computer Science, University of Manchester, Oxford Road, Manchester, M13 9PL, U.K. TEL: (0|+44) 161 275 6250FAX: (0|+44) 161 275 6204 EMAIL: [EMAIL PROTECTED] http://www.cs.man.ac.uk/~jtl - -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
FVWM: Wait comand behaviour changed
This is not actually an undocumented feature change, but it is understated! :-) Fvwm 2.2.4 man page says: ``Fvwm remains fully functional during a wait.'' Fvwm 2.4.8 man page says ``Fvwm remains partially functional during a wait.'' I spotted the one word difference after a few hours tracking down the cause of a very strange behaviour. Presumeably, you have optimised away some threads that had a memory/CPU overhead, and perhaps never imagined anybody would be using Wait in a clever (=stupid!) way. Alas, in AnotherLevelUp I was using Wait in a multi-threaded way, waiting for an effect from a form which prompts the user to save his/her current preferences, if they have been changed since last saved; when he/she asks for a new set of preferences to be loaded. So we had a Wait active at the same time as a form that needed user interaction. In 2.4 this does not work as all the window events seem to be disabled during a Wait, all mouse clicks act on the root window only. It probably serves me right! I have rewritten it to work in a different, and single threaded, way. Is it worth writing some hints in the man page indicating what sort of things do not work during a Wait -- or am I likely to be the only person daft enough to try abusing Wait in this way? :-) Best wishes, John Latham -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
FVWM: Cannot maximize while iconified?
I had a bit of configuration that maximised an iconified window and then de-iconified it. This stopped working in 2.4: the maximise was seeming to have no effect. When I swapped the order round it works okay. I wanted to do the maximise while the window was iconified so that there was less `flickering' on the screen, but it is not a major issue. While on this matter, can anyone suggest a better way of achieving the effect I want? It is for the middle mouse button when clicked on the task bar window buttons. If I move along the task bar pressing the middle mouse button on each window button then I want to see each window in turn maximised, with all the others returned to normal, and a second click on the last button returns that window to normal too. Viz:Unmaximise the previous maximised window. Move to the desktop / page where this window is. Maximise / demaxmimise it, and focus it. After much fiddling I previously arrived at: *FvwmTaskBarAction Click2 Focus,Iconify 1,Prev [!FvwmTaskBar Maximized !Iconic] Maximize 100 97,Maximize 100 97,Iconify -1,Focus Since 2.4 I have had to swap the last Maximize and Iconify to make it work again: *FvwmTaskBarAction Click2 Focus,Iconify 1,Prev [!FvwmTaskBar Maximized !Iconic] Maximize 100 97,Iconify -1,Maximize 100 97,Focus Best wishes, John Latham -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
FVWM: Multi-byte fonts, and locale(?)
With 2.4.6 (a la Red Hat 7.3 rpm) I got: [FVWM][GetFontSetOrFixed]: WARNING -- can't get fontset fixed, trying 'fixed' This was followed by some other font problems, e.g. the FvwmPager and FvwmButtons. (And FvwmTaskBar...) Red Hat have enabled multi-byte fonts in their 2.4.6 RPM, and I note such is not a default compile option of 2.4. Is that the basis of the problem? I wanted to get AnotherLevelUp to work okay with a standard Red Hat fvwm RPM, so grepping for clues through old emails on this list I tried putting SetEnv LANG C SetEnv LC_CTYPE "" early in the configuration. This seemed to get rid of some font problems, although not the above error message presumeably because that occurs before the SetEnv. (I could set LANG to C in the Xclients, etc, but it is not worth it just to get rid of one benign error message, and I have a FVWM version specific mechanism for the FVWM config commands in AnotherLevelUp, so the SetEnv is put in only for 2.4.*.) The same behaviour was exhibited in 2.4.8 (after I remembered to enable multibyte). It all works fine with 2.5.2, no need to alter locale. :-) Would I be right in summarising that the 2.5 series has multi-byte fonts sorted `properly', whereas they are still `dodgey' in 2.4 and hence they were disabled by default; and Red Hat was `wrong' to enable them in their distributed RPM? Or am I missing something? Best wishes, John Latham -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
FVWM: Non iso8995-1 fonts and the TaskBar
FvwmTaskBar crashes, quietly without any trace, in 2.4.6 as shipped by Red Hat 7.3 (multi-byte is enabled) and also in 2.4.8 when compiled with multibyte option, but not otherwise. The task bar just refused to appear, and left no error message not even a core dump. Don't ask me how I figured out this was with the setting that caused the problem *FvwmTaskBarFont -*helvetica-medium-r-*-*-12-*-*-*-*-*-*-* and changing it to the following makes it work okay: *FvwmTaskBarFont -*helvetica-medium-r-*-*-12-*-*-*-*-*-iso8859-1 I assume it was picking up some font encoding that FvwmTaskBar cannot handle -- does that make sense? This behaviour was still happening after I changed to POSIX locale (see previous message): it seems you need BOTH the posix locale and the iso8859-1 to make it work in 2.4, if multi-byte is emabled. Similarly, FvwmPager was using the wrong font until I put the iso8859-1 spec on that too. At least it wasn't crashing! All this seems to work fine on 2.5.2, no need for locale change or iso8859-1 specification. This all makes me think I could do with learning a *bit* more about X fonts and their relationships to locales. Can anyone suggest a good (implies short...) summary on the matter? Best wishes, John Latham -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
FVWM: Internal window border line
Fvwm2.2.4 (and previous) placed a single pixel width black box around the internal window, just inside the border. This has disappeared by 2.4.6, and I cannot find any reference to it in the man page. It's not a big issue, but it does mean some combinations of window decorations look quite different to how they used to -- particularly if the internal window has a similar colour to the border. Could I suggest that you make it an optional BorderStyle? I imagine the box may have disappeared when the new Raised/Flat/Sunk BorderStyle flags apeared. Best wishes, John Latham -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
FVWM: Menu items left highlighted
If menus are decorated with a horizontal gradient, then quite often some menu items are left raised after the mouse pointer has scanned over them. In 2.4.8 they usually are flattened again after a short delay, although not always. In 2.4.6 they appear to be left raised for longer, but that could be just an impression. The problem remains in 2.5.2. An example MenuStyle is: MenuStyle * mwm MenuStyle * Font *helvetica*medium-r*12* MenuStyle * Greyed grey35 MenuStyle * Foreground #FF MenuStyle * MenuFace HGradient 128 2 #E50070 30 #1A80F0 70 #E50070 This is only a cosmetic problem, but it was not present in 2.2.4 and earlier. Best wishes, John Latham -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
FVWM: No focus on start up?
After start up, the mouse pointer is always resting over an xterm in my set up. Often, but not always, this xterm does not have the focus and I have to move the pointer out of it and back in again. This also happens every time after a restart when the mouse pointer is resting over a window. In 2.2 and previous, the window under the mouse would always get the focus in both these situations. I have tried this with sloppy and follow-mouse focus, on 2.4.6, 2.4.8 and 2.5.2. Maybe the last window created (e.g. Pager or buttons) gets the focus instead of the one under the mouse after the restart has finished? A possible conection: if I PipeRead from FvwmTalk something which destroys and creates windows (e.g. Pager, Buttons) then after the PipeRead in 2.2 FvwmTalk still has the focus with sloppy and follows policy, whereas is loses it with click focus (as you would expect). However, in 2.4 and 2.5 FvwmTalk has lost the focus regardless of policy. (Of course, FvwmTalk has changed so this could be a red herring). Or, if I select a menu item, which does a PipeRead that causes a new window to be started (e.g. xbiff), the new window ends up with the focus even though the mouse is left where it was when it selected the (sub-sub) menu, say now over an xterm. In 2.2 the xterm would now get the focus (this is with follow mouse/sloppy focus of course). I have some PipeReads which are executed via InitFunction and RestartFunction. So, if PipeRead has changed its behaviour in this way, then that could be the real cause of the start up / restart non-focus problem. Bottom line: has something like a ``recheck focus policy and current mouse position'' operation gone AWOL from the end of a PipeRead? :-) Perhaps deliberately changed then -- is that really the best functionality? I would suggest a good principle: with follows mouse/sloppy focus, if the mouse is over a window that can take focus then that window has the focus -- at least by the time Fvwm becomes `quiescent' again. Best wishes, John Latham -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
FVWM: Application resizing failure
I have a certain application, written in Perl/Tk, which does not work properly with 2.4.6 or 2.4.8; but did work okay with 2.2.4 and previous, and *does* work okay with 2.5.2. The problem: when a certain button is pressed in a Perl/Tk window: a text box is removed from the window then a new one is added then some text inserted into this new text box then the text box is removed then another new one is added then some text is inserted into this third text box then the size of the third text box is set Out of context this sounds like a crazy thing to want, but trust me it is sensible (the window is running a command for the user, first discarding the old output, then showing standard error during the run, then standard output after finishing, and resizing to suit the new output text right at the end). This results in several window resizes, and on 2.4.6 and 2.4.8 the geometry ends up wrong. Either it ends up being the smallest that was asked for (i.e. without the text box) or correct in width but smallest in height! The resizes can happen quite quickly, but I have tried adding in 2 seconds sleeps between each stage, and it makes no difference. I could try to write a minimal example program if that would help. As I said it works okay again in 2.5.2, but I guessed it might be an unknown bug that has been accidentally fixed, on the grounds that you would have wanted to fix it in 2.4.8 too. True? Best wishes, John Latham -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
FVWM: PipeRead and mouse grab
I have a function that used to work under 2.2, but does not under 2.4.8 nor 2.5.2. It is part of a window print capture form: *CaptureButton continue "Capture" ^M *CaptureCommand CaptureCommand "$(file)" "$(Options)" AddToFunc CaptureCommand + "I" Current [Capture] Iconify + "I" PipeRead "exec xwd -out \"$0\" $1" + "I" Prev [Capture] Iconify A message from xwd complains that it cannot grab the mouse. It works fine if I use an Exec instead of PipeRead, except for the obvious timing: I want the Capture form to disappear while I grab the window image. If there is a good reason for PipeRead being less liberal with X resources than Exec is, would it be feasible to offer a version of Exec that does not start a separate thread / process? Or, to offer a WaitExec command that waits for the most recently started Exec? Best wishes, John Latham -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
FVWM: Where is focus during PipeRead from FvwmButtons?
I use PipeRead a lot as a `synchronised' Exec. I get the impression its behaviour has changed fundamentally since 2.2, in what happens to everything else during a PipeRead. I wonder if this is related to the change of behaviour of the Wait command? Say I press a FvwmButton button which pops up a menu, I select an item which invokes a function including a PipeRead in it. While this PipeRead is running, I click on another FvwmButton button. In 2.2, after a delay, the menu associated with the second button pops up. In 2.4.8, after a delay, the *root* menu pops up! In 2.5.2 the press of the second FvwmButton button is ignored. Personally, I prefer the 2.2 behaviour, but the 2.5 one is acceptable. What 2.4 does is quite frightening -- I have accidentally started all sorts of options from the root menu! I assume the 2.4.8 behaviour is a bug caused by some change since 2.2. Is the 2.5 behaviour deliberate (e.g. to plug the 2.4 bug)? Is the 2.2 behaviour considered bad, or deliberately dumped on the altar of some better gain, or just unintentionally lost? Best wishes, John Latham -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: PipeRead and mouse grab
On Mon, Aug 12, 2002 at 06:35:09PM +0100, John Latham wrote: > I have a function that used to work under 2.2, but does not under 2.4.8 nor > 2.5.2. It is part of a window print capture form: > > *CaptureButton continue "Capture" ^M > *CaptureCommand CaptureCommand "$(file)" "$(Options)" > > AddToFunc CaptureCommand > + "I" Current [Capture] Iconify > + "I" PipeRead "exec xwd -out \"$0\" $1" > + "I" Prev [Capture] Iconify > > A message from xwd complains that it cannot grab the mouse. It works fine if I > use an Exec instead of PipeRead, except for the obvious timing: I want the > Capture form to disappear while I grab the window image. > > If there is a good reason for PipeRead being less liberal with X resources > than Exec is, That's necessary to display the watch cursor while a function executes. Unfortunately we missed the implications about starting applications that need to grab the mouse and forgot to mention it in big bold letters in the NEWS and man page. > would it be feasible to offer a version of Exec that does not > start a separate thread / process? Or, to offer a WaitExec > command that waits for the most recently started Exec? You mean "starts the process syncronously". This has been discussed a few times. The solution is PipeRead again. Try this: AddToFunc CaptureCommand + I BusyCursor read off + I Current (Capture) Iconify + I PipeRead "exec xwd -out \"$0\" $1" + I Prev (Capture) Iconify + I BusyCursor read on Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Menu items left highlighted
On Mon, Aug 12, 2002 at 06:30:59PM +0100, John Latham wrote: > If menus are decorated with a horizontal gradient, then quite often some menu > items are left raised after the mouse pointer has scanned over them. In 2.4.8 > they usually are flattened again after a short delay, although not always. In > 2.4.6 they appear to be left raised for longer, but that could be just an > impression. The problem remains in 2.5.2. > > An example MenuStyle is: > > MenuStyle * mwm > MenuStyle * Font *helvetica*medium-r*12* > MenuStyle * Greyed grey35 > MenuStyle * Foreground #FF > MenuStyle * MenuFace HGradient 128 2 #E50070 30 #1A80F0 70 #E50070 > > This is only a cosmetic problem, but it was not present in 2.2.4 and earlier. After a bit of experimenting, I could reproduce the problem. I'll take care of it. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: No focus on start up?
On Mon, Aug 12, 2002 at 06:32:53PM +0100, John Latham wrote: > After start up, the mouse pointer is always resting over an xterm in my set > up. Often, but not always, this xterm does not have the focus and I have to > move the pointer out of it and back in again. This also happens every time > after a restart when the mouse pointer is resting over a window. In 2.2 and > previous, the window under the mouse would always get the focus in both these > situations. I have tried this with sloppy and follow-mouse focus, on 2.4.6, > 2.4.8 and 2.5.2. For me it works as usual, but it always was always a bit random. > Maybe the last window created (e.g. Pager or buttons) gets the focus instead > of the one under the mouse after the restart has finished? > > A possible conection: if I PipeRead from FvwmTalk something which destroys and > creates windows (e.g. Pager, Buttons) then after the PipeRead in 2.2 FvwmTalk > still has the focus with sloppy and follows policy, whereas is loses it with > click focus (as you would expect). However, in 2.4 and 2.5 FvwmTalk has lost > the focus regardless of policy. (Of course, FvwmTalk has changed so this could > be a red herring). I recommend to use FvwmConsole instead of FvwmTalk. > Or, if I select a menu item, which does a PipeRead that causes a new window to > be started (e.g. xbiff), the new window ends up with the focus even though the > mouse is left where it was when it selected the (sub-sub) menu, say now over > an xterm. In 2.2 the xterm would now get the focus (this is with follow > mouse/sloppy focus of course). > > I have some PipeReads which are executed via InitFunction and RestartFunction. > So, if PipeRead has changed its behaviour in this way, then that could be the > real cause of the start up / restart non-focus problem. > > Bottom line: has something like a ``recheck focus policy and current mouse > position'' operation gone AWOL from the end of a PipeRead? :-) Perhaps > deliberately changed then -- is that really the best functionality? It was not reliable in 2.2.x and screwed up some more advanced functions. Therefore I rewrote the code keeping track of the focus during function execution to be more reliable, at the cost of some small changes in focus handling. > I would > suggest a good principle: with follows mouse/sloppy focus, if the mouse is > over a window that can take focus then that window has the focus -- at least > by the time Fvwm becomes `quiescent' again. See above. It's almost always easy to restore the focus with the "Focus" command explicitly in your scripts. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Where is focus during PipeRead from FvwmButtons?
On Mon, Aug 12, 2002 at 06:36:13PM +0100, John Latham wrote: > I use PipeRead a lot as a `synchronised' Exec. I get the impression its > behaviour has changed fundamentally since 2.2, in what happens to everything > else during a PipeRead. I wonder if this is related to the change of behaviour > of the Wait command? > > Say I press a FvwmButton button which pops up a menu, I select an item which > invokes a function including a PipeRead in it. While this PipeRead is running, > I click on another FvwmButton button. > > In 2.2, after a delay, the menu associated with the second button pops up. > > In 2.4.8, after a delay, the *root* menu pops up! > > In 2.5.2 the press of the second FvwmButton button is ignored. > > Personally, I prefer the 2.2 behaviour, but the 2.5 one is acceptable. What > 2.4 does is quite frightening -- I have accidentally started all sorts of > options from the root menu! > > I assume the 2.4.8 behaviour is a bug caused by some change since 2.2. Is the > 2.5 behaviour deliberate (e.g. to plug the 2.4 bug)? Is the 2.2 behaviour > considered bad, or deliberately dumped on the altar of some better gain, or > just unintentionally lost? It's not a bug, it's the watch cursor. Again, disable it with BusyCursor Read off before your PipeRead calls. I'm sorry that it gives you so much trouble. The change in cursor shape was intended to give better feedback that fvwm isn't accepting input at the moment. We had hoped that the watch cursor would be self explaining. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Internal window border line
On Mon, Aug 12, 2002 at 06:30:07PM +0100, John Latham wrote: > Fvwm2.2.4 (and previous) placed a single pixel width black box around the > internal window, just inside the border. This has disappeared by 2.4.6, and I > cannot find any reference to it in the man page. It's not a big issue, but it > does mean some combinations of window decorations look quite different to how > they used to -- particularly if the internal window has a similar colour to > the border. Could I suggest that you make it an optional BorderStyle? I > imagine the box may have disappeared when the new Raised/Flat/Sunk BorderStyle > flags apeared. That hasn't changed. I can only guess that the AnotherLevel default was changed. Try this: BorderStyle -- !NoInset Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Application resizing failure
On Mon, Aug 12, 2002 at 06:34:27PM +0100, John Latham wrote: > I have a certain application, written in Perl/Tk, which does not work properly > with 2.4.6 or 2.4.8; but did work okay with 2.2.4 and previous, and *does* > work okay with 2.5.2. > > The problem: when a certain button is pressed in a Perl/Tk window: > a text box is removed from the window > then a new one is added > then some text inserted into this new text box > then the text box is removed > then another new one is added > then some text is inserted into this third text box > then the size of the third text box is set Um, I don't see where this involves any resizing. > Out of context this sounds like a crazy thing to want, but trust me it is > sensible (the window is running a command for the user, first discarding the > old output, then showing standard error during the run, then standard output > after finishing, and resizing to suit the new output text right at the end). > > This results in several window resizes, and on 2.4.6 and 2.4.8 the geometry > ends up wrong. Either it ends up being the smallest that was asked for (i.e. > without the text box) or correct in width but smallest in height! The resizes > can happen quite quickly, but I have tried adding in 2 seconds sleeps between > each stage, and it makes no difference. I can't say anything good about it without seeing the configuration requests from the application. > I could try to write a minimal example program if that would help. Please do. > As I said it works okay again in 2.5.2, but I guessed it might be an unknown > bug that has been accidentally fixed, on the grounds that you would have > wanted to fix it in 2.4.8 too. True? Sounds like a good candidate to be fixed in Tk. Fvwm usually just does what the application requests in exactly that order. For example, I have a similar problem with xemacs since 2.3.x, but fvwm is really doing everything right. Instead, xemacs chokes on its own events. It's timing dependent. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Wait comand behaviour changed
On Mon, Aug 12, 2002 at 06:24:58PM +0100, John Latham wrote: > This is not actually an undocumented feature change, but it is understated! > :-) > > Fvwm 2.2.4 man page says: ``Fvwm remains fully functional during a wait.'' > > Fvwm 2.4.8 man page says ``Fvwm remains partially functional during a wait.'' It's just a better description of what actually happens. The Wait command itself was not changed in any relevant way. > I spotted the one word difference after a few hours tracking down the cause of > a very strange behaviour. Presumeably, you have optimised away some threads > that had a memory/CPU overhead, and perhaps never imagined anybody would be > using Wait in a clever (=stupid!) way. > > Alas, in AnotherLevelUp I was using Wait in a multi-threaded way, There is no multi threading in fvwm. > waiting for > an effect from a form which prompts the user to save his/her current > preferences, if they have been changed since last saved; when he/she asks for > a new set of preferences to be loaded. So we had a Wait active at the same > time as a form that needed user interaction. In 2.4 this does not work as all > the window events seem to be disabled during a Wait, all mouse clicks act on > the root window only. Event processing continues as usual. The modules can receive and send data to and from fvwm, but fvwm ignores all module input until the wait finishes. As this was the same in 2.2.x, I'm not sure what was changed. In general: Wait + using modules = bad. > It probably serves me right! I have rewritten it to work in a different, and > single threaded, way. Good idea. TH Wait command is really just meant to wait for a window that appears quickly. Any other use is asking for trouble. You can easily achieve the same benefits with FvwmEvent, but without the bad side effects. > Is it worth writing some hints in the man page indicating what sort of things > do not work during a Wait -- or am I likely to be the only person daft enough > to try abusing Wait in this way? :-) I'll add something. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: AnotherLevelUp FVWM configuration
On Mon, Aug 12, 2002 at 06:24:00PM +0100, John Latham wrote: > Can I continue to thank FVWM developers for your efforts and congratulate you > in your successes in maintaining and evolving FVWM -- probably the best window > manager in the world? :-) Sure :-) And we would be even more grateful if you'd limit the number of questions to five per day. I had so looked forward to have a quiet evening ;-) > Annoucement: AnotherLevelUp fvwm configuration now works with FVWM 2.4 and > 2.5. See http:www.cs.man.ac.uk/~jtl/ALU for details. Great! > The process of upgrading AnotherLevelUp has revealed some `undocumented > features changes' in FVWM. I thought the FVWM developers may find it useful if > I report them here, each in a separate email. Thanks for your help. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Cannot maximize while iconified?
On Mon, Aug 12, 2002 at 06:26:12PM +0100, John Latham wrote: > I had a bit of configuration that maximised an iconified window and then > de-iconified it. This stopped working in 2.4: the maximise was seeming to have > no effect. When I swapped the order round it works okay. I wanted to do the > maximise while the window was iconified so that there was less `flickering' on > the screen, but it is not a major issue. >From the ChangeLog (pre 2.4): 2000-06-15 Dominik Vogt <[EMAIL PROTECTED]> * fvwm/builtins.c (WindowShade): * fvwm/move_resize.c (Maximize): (resize_window): don't maximize/shade/resize iconified windows No idea why I did this. I'll revert back to the old way. > While on this matter, can anyone suggest a better way of achieving the effect > I want? It is for the middle mouse button when clicked on the task bar window > buttons. If I move along the task bar pressing the middle mouse button on each > window button then I want to see each window in turn maximised, with all the > others returned to normal, and a second click on the last button returns that > window to normal too. > > Viz:Unmaximise the previous maximised window. > Move to the desktop / page where this window is. > Maximise / demaxmimise it, and focus it. > > After much fiddling I previously arrived at: > > *FvwmTaskBarAction Click2 Focus,Iconify 1,Prev [!FvwmTaskBar Maximized > !Iconic] Maximize 100 97,Maximize 100 97,Iconify -1,Focus You shouldn't use comma separated action lists anymore. Each of the commands might be applied to a different window, screwing up the whole desktop. It's safer to use a complex function. Also, the brackets around contitions are obsolete. This is no problem with the configuration, but should anyone ever look at this config (s)he shouldn't be encouraged to use brackets. Instead, use parentheses. Now to answer the question. This setup should work more reliable: Style FvwmTaskBar WindowListSkip, CirculateSkip *FvwmTaskBarAction Click2 Silent Function TB2Func SetEnv TB2FuncWin 0 AddToFunc TB2Func + I WindowId $w (!maximized) TB2Activate + I WindowId $[TB2FuncWin] (maximized, !iconic) TB2Deactivate + I WindowId $w (!maximized, iconic) TB2Activate2 + I SetEnv TB2FuncWin $w AddToFunc TB2Activate + I Iconify on AddToFunc TB2Activate2 + I Focus + I Maximize on 100 97 + I Iconify off AddToFunc TB2Deactivate + I Maximize off The only problem is that this setup doesn't work well if you iconify a window while it's maximized. > Since 2.4 I have had to swap the last Maximize and Iconify to make it work > again: > > *FvwmTaskBarAction Click2 Focus,Iconify 1,Prev [!FvwmTaskBar Maximized > !Iconic] Maximize 100 97,Iconify -1,Maximize 100 97,Focus Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
FVWM: Re: Documentation
We already use the pod documentation format in FVWM in perl tools: * fvwm-menu-directory * fvwm-menu-headlines * fvwm-menu-xlock * fvwm-perllib * all perllib classes * FvwmPerl I would probably say more yes than no to use pod in all documentation, but I don't see a lot of reasons for this. Pod is pretty rich, but not as rich as the man page format. As for me, both the man page format and pod are easy to write and read. There are a lot of small things in pod (say, no center-justification in man pages) that I don't like, it is just not configurable enough. I myself even have somewhere a patched Pod::Man that fixes some annoyances, like converting "run fvwm(1)" to "run the fvwm manpage", but it's not an option for everyone to install it. Also fvwm-perllib fixes one bug in pod2man. There is no easy way to define a plain-unformatted-lines text without first padding it with at least one space, this looks ugly in SYNOPSYS and other places. This padding feature is often misused, for example the pod used in Pod::Parser class itself hardcodes the 12 spaces indentation, which is bad if the output is html, not just man pages. Of course if I would not be a pod fan, I would not create fvwm-perllib that uses it in several interesting ways. Regards, Mikhael. -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Wait comand behaviour changed
On 23:21 12 Aug 2002, Dominik Vogt <[EMAIL PROTECTED]> wrote: | On Mon, Aug 12, 2002 at 06:24:58PM +0100, John Latham wrote: | > This is not actually an undocumented feature change, but it is understated! | > :-) | > Fvwm 2.2.4 man page says: ``Fvwm remains fully functional during a wait.'' | > Fvwm 2.4.8 man page says ``Fvwm remains partially functional during a wait.'' [...] | > I spotted the one word difference after a few hours tracking down the cause of | > a very strange behaviour. Presumeably, you have optimised away some threads | > that had a memory/CPU overhead, and perhaps never imagined anybody would be | > using Wait in a clever (=stupid!) way. | > Alas, in AnotherLevelUp I was using Wait in a multi-threaded way, | | There is no multi threading in fvwm. Hmm. But more than one active Wait is not an insane idea. | Event processing continues as usual. The modules can receive and | send data to and from fvwm, but fvwm ignores all module input | until the wait finishes. As this was the same in 2.2.x, I'm not | sure what was changed. In general: Wait + using modules = bad. On this kind of topic: what about a FvwmButtons Swallow whose client never appears? I'd imagine this is unrelated to FVWM itself and that the module is simply monitoring a stream of events from FVWM, or does the module get to preempty something off FVWM's event queue to do a swallow? Why do I ask? I swallow a wmflame in my button, but not on a VNC desktop (because it means constant VNC traffic, which I explcitly don't want). Now, instead of being smart and using piperead to conditionally generate the swallowing button, I always generate the button but conditionally fire up the wmflame. Is this likely to cause me trouble? It seems to work ok so far. -- Cameron Simpson, DoD#743[EMAIL PROTECTED]http://www.zip.com.au/~cs/ The Web site you seek cannot be located but endless others exist - Haiku Error Messages http://www.salonmagazine.com/21st/chal/1998/02/10chal2.html -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Menu items left highlighted
On Tue, Aug 13, 2002 at 01:12:04AM +0200, Dominik Vogt wrote: > On Mon, Aug 12, 2002 at 06:30:59PM +0100, John Latham wrote: > > If menus are decorated with a horizontal gradient, then quite often some > > menu > > items are left raised after the mouse pointer has scanned over them. In > > 2.4.8 > > they usually are flattened again after a short delay, although not always. > > In > > 2.4.6 they appear to be left raised for longer, but that could be just an > > impression. The problem remains in 2.5.2. > > > > An example MenuStyle is: > > > > MenuStyle * mwm > > MenuStyle * Font *helvetica*medium-r*12* > > MenuStyle * Greyed grey35 > > MenuStyle * Foreground #FF > > MenuStyle * MenuFace HGradient 128 2 #E50070 30 #1A80F0 70 #E50070 > > > > This is only a cosmetic problem, but it was not present in 2.2.4 and > > earlier. > > After a bit of experimenting, I could reproduce the problem. I'll > take care of it. Fixed. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Wait comand behaviour changed
On Tue, Aug 13, 2002 at 10:32:41AM +1000, Cameron Simpson wrote: > On 23:21 12 Aug 2002, Dominik Vogt <[EMAIL PROTECTED]> wrote: > | On Mon, Aug 12, 2002 at 06:24:58PM +0100, John Latham wrote: > | > This is not actually an undocumented feature change, but it is > understated! > | > :-) > | > Fvwm 2.2.4 man page says: ``Fvwm remains fully functional during a wait.'' > | > Fvwm 2.4.8 man page says ``Fvwm remains partially functional during a > wait.'' > [...] > | > I spotted the one word difference after a few hours tracking down the > cause of > | > a very strange behaviour. Presumeably, you have optimised away some > threads > | > that had a memory/CPU overhead, and perhaps never imagined anybody would > be > | > using Wait in a clever (=stupid!) way. > | > Alas, in AnotherLevelUp I was using Wait in a multi-threaded way, > | > | There is no multi threading in fvwm. > > Hmm. But more than one active Wait is not an insane idea. "Wait" works well only for windows that do appear do it fast. Any other use is asking for trouble. > | Event processing continues as usual. The modules can receive and > | send data to and from fvwm, but fvwm ignores all module input > | until the wait finishes. As this was the same in 2.2.x, I'm not > | sure what was changed. In general: Wait + using modules = bad. > > On this kind of topic: what about a FvwmButtons Swallow whose client > never appears? I'd imagine this is unrelated to FVWM itself and that the > module is simply monitoring a stream of events from FVWM, or does the > module get to preempty something off FVWM's event queue to do a swallow? FvwmButtons just looks for a matching new window and otherwise operates normally. But there is one important differene. FvwmButtons doesn't care when the window appears, but with the "Wait" command you explicitly ask not to continue executing the function that triggered it. That is exactly what it is good for: to not process any commands while the Wait is active. > Why do I ask? I swallow a wmflame in my button, but not on a VNC desktop > (because it means constant VNC traffic, which I explcitly don't want). > Now, instead of being smart and using piperead to conditionally generate > the swallowing button, I always generate the button but conditionally > fire up the wmflame. > > Is this likely to cause me trouble? It's safe to do that. > It seems to work ok so far. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Own mouse pointers: define hot spot?
On Mon, 12 Aug 2002, Gregg Dameron wrote: > Dominik Vogt wrote: > > > On Mon, Aug 12, 2002 at 11:49:54AM -0400, Dan Espen wrote: > > > Dominik Vogt writes: > > > > Could you put that in the FAQ? > > > > > > Sure. ... I noticed that there was a facility shipped with the standard xwindows distribution called "bitmap" which seems to do what is wanted. ie set the hotspot. Bruce [EMAIL PROTECTED] -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Own mouse pointers: define hot spot?
On 13 Aug 2002 09:41:58 +, Bruce M Beach wrote: > > On Mon, 12 Aug 2002, Gregg Dameron wrote: > > > Dominik Vogt wrote: > > > > > On Mon, Aug 12, 2002 at 11:49:54AM -0400, Dan Espen wrote: > > > > Dominik Vogt writes: > > > > > Could you put that in the FAQ? > > > > > > > > Sure. ... > > I noticed that there was a facility shipped with the standard xwindows > distribution called "bitmap" which seems to do what is wanted. ie > set the hotspot. bitmap creates xbm files, not xpm. Two xbms are needed to define a cursor (in some other WMs) and only one xpm in FVWM, because 3 colors are used. I think I will just add a small example of such xpm (from fvwm-themes) to the man page. But then the FAQ entry is a bit redudant. :) Regards, Mikhael. -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
