CVS domivogt: * Updated.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt01/09/15 03:03:52 Modified files: docs : DEVELOPERS Log message: * Updated. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
CVS domivogt: * Colorset fix.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt01/09/15 03:29:52 Modified files: . : NEWS docs : DEVELOPERS modules: ChangeLog modules/FvwmPager: x_pager.c Log message: * Colorset fix. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
CVS domivogt: * Added '#include config.h' everywhere.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt01/09/15 04:10:28 Modified files: . : ChangeLog docs : DEVELOPERS libs : ClientMsg.c Event.c Grab.c Graphics.c Pointer.c WinMagic.c XError.c alloca.c envvar.c fvwmrect.c gethostname.c safemalloc.c strcasecmp.c strdup.c strerror.c strncasecmp.c usleep.c wild.c modules: ChangeLog modules/FvwmBacker: root_bits.c Log message: * Added '#include config.h' everywhere. -- 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]
FYI: Official Xinerama API spec
Hi! As was mentioned some time ago, Xinerama API implementation in XFree86 isn't an official X.org standard. And X environments other than XFree86 use different (and incomplete, and undisclosed) Panoramix API. A draft of upcoming standard API is available at http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/xinerama/xinerama/xc/doc/XineramaApi.txt?rev=1.2content-type=text/vnd.viewcvs-markup Differences from XFree86's implementation are very subtle and can be easily handled within FScreen.c with a little assistance from configure script. Additionally, Mark Vojkovich states at http://www.xfree86.org/pipermail/xpert/2001-September/011340.html that XFree86 will support both when the X.Org protocol is finalized. BTW, I'm going to contact him regarding our findings (like a desire to have a Pointer changed physical screen event). Are there any other similar things which will require assistance from X server and API? _ Dmitry Yu. Bolkhovityanov [EMAIL PROTECTED] The Budker Institute of Nuclear Physics -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
CVS domivogt: * Updated.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt01/09/15 04:39:20 Modified files: docs : DEVELOPERS utils : make_fvwmdist.sh Log message: * Updated. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
CVS domivogt: * Updated.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt01/09/15 04:56:23 Modified files: docs : DEVELOPERS utils : make_fvwmdist.sh Log message: * Updated. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
CVS domivogt: * Updated for 2.5.0.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt01/09/15 05:24:38 Modified files: . : ChangeLog NEWS configure.in Log message: * Updated for 2.5.0. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
CVS domivogt: * Updated.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt01/09/15 05:30:10 Modified files: docs : DEVELOPERS Log message: * Updated. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
CVS domivogt fvwm-web: * Updated for 2.4.1.
CVSROOT:/home/cvs/fvwm Module name:fvwm-web Changes by: domivogt01/09/15 05:31:05 Modified files: . : ChangeLog download.html index.html generated : NEWS.html Log message: * Updated for 2.4.1. -- 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: Several things
On Thu, 13 Sep 2001, Dominik Vogt wrote: On Thu, Sep 13, 2001 at 03:29:20PM +0700, Dmitry Yu. Bolkhovityanov wrote: Hi! First, a pair of questions regarding window decorations. 1. Is it possible to make titlebar buttons appear not side by side to each other and to borders, but at some offset? So that it would be possible to make a setup similar to OpenWindows (where the window ops button is at some distance from the left) and to MacOS/Aqua-alikes (where buttons are disjoint)? Its not possible with vector buttons but can be done with pixmap buttons. The following lines come from the system.fvwm2rc-sample-95: ButtonStyle 1 MiniIcon (-- flat) ButtonStyle all -- UseTitleStyle Flat AddButtonStyle 2 Pixmap mini.winXX-close.xpm AddButtonStyle 4 Pixmap mini.winXX-maximize.xpm AddButtonStyle 6 Pixmap mini.winXX-minimize.xpm Just give the pixmaps a transparent border in the dimensions you like. Unfortunatey you'll have to draw a separate pixmap for each button state if you need depressed and toggled looks. Yes, that's a known solution, but it has at least three disadvantages. First, as you stated, one has to draw pixmaps for each state. Second, such buttons aren't scalable (as vector buttons are), so they wouldn't follow the title font size. Third, such buttons wouldn't really be offset -- there will be invisible areas, which still can be clicked on, and this is confusing (a similar bug/feature exists in WinAmp/XMMS, where skin elements are separated from actual mouse handling code, and it is IMHO very irritating). Can an offset feature be treated as a TODO item? It doesn't seem hard to implement. 2. Somewhere after 2.2.4, the decoration code was changed so that borders became wider. This had several visible effects, all of which are IMHO negative: a) windows occupy more space (with 2.2.4 on 1152x864 screen xterm with lucidatypewriter-12 font could be tall-maximized to occupy exactly full screen with 64 lines, and xterm with lucidatypewriter-10 could be wide-maximized to use exactly full screen width; now there are unused gaps); The size of the decorations *didn't* change internally in fvwm. If things don't fit nicely anymore then either the font in your xterms has changed or fvwm's title font (TitleFont foo) or the width of the window borders (HandleWidth and BorderWidth styles). No. See below and screenshot. b) hilited parts of titlebar buttons stick -- see topmost scanline of buttons ##0,8. I'm not sure what you mean. Can you perhaps just provide a screenshot? A screenshot is attached. The left window is fvwm-2.2.4 (RedHat 6.2), the right is fvwm-cvs-2001-Sep-10 (compiled and run on RedHat 7.1). Both xterms were run from the same host and on the same X server, with a command xterm -fn lucidasanstypewriter-12 -geom 20x5, fvwm configuration is the same AnotherLevel-1.0.1-1 from RedHat-6.2. There are several things to notice: - 2.4 makes an additional dark border around the window, hence the window is 2px wider and 1px taller. - 2.4 title is less tall, but percents in vector buttons are somehow larger (the shapes are thicker); but that indifferent -- both cases are OK. - 2.4's titlebar buttons stick to each other (the topmost bright line runs from leftmost button to rightmost one uninterrupted), while in 2.2.4 buttons are separated. - On the upper [right resize corner]=[vertical part]=[hilite right vertical line] runs 1px higher than it should. This reminds a bug I reported on spring... BTW, about two months ago I ran than-current fvwm on a clockwise-rotated screen under Xvesa (RandR-enabled KDrive server). Xvesa is very slow in this mode, and I noticed that some pixels (those on the border between hilited and darkened parts) of the frame are redrawn several times. _ Dmitry Yu. Bolkhovityanov [EMAIL PROTECTED] The Budker Institute of Nuclear Physics fvwm_decors.gif Description: GIF image
Patch for fvwm modules man pages
Hi! Attached is a patch which a) adds a formal description of how fvwm maintains module's configs; b) corrects man pages for individual modules. Changelog entry: * Add a formal description of how fvwm maintains module's configs * Change manpages of individual modules to refer to fvwm2(1) for details about specifying configuration Previously many man pages contained a sentense like During initialization FvwmFoo reads the same config file as fvwm. The replacement template is On startup | During initialization | /*optional*/ \fBFvwmFoo\fP gets config info from \fBfvwm\fP's module configuration database (see .IR fvwm2 (1), section .BR MODULE COMMANDS ). Additionally, some manpages (e.g. FvwmScroll) included two references to config file: first in DESCRIPTION and than in INITIALIZATION. In such cases the one in DESCRIPTION is removed, since it is redundant. BTW1: I changed only those manpages which included those wrong sentences, but it is probably worth modifying other manpages too. BTW2: FvwmSave manpage wasn't changed, since it is completely broken: most text in it refers to NoClutter (?!?!?!). _ Dmitry Yu. Bolkhovityanov [EMAIL PROTECTED] The Budker Institute of Nuclear Physics Index: fvwm/fvwm2.1 === RCS file: /home/cvs/fvwm/fvwm/fvwm/fvwm2.1,v retrieving revision 1.400 diff -u -r1.400 fvwm2.1 --- fvwm/fvwm2.12001/09/05 16:39:56 1.400 +++ fvwm/fvwm2.12001/09/15 14:15:39 @@ -7179,6 +7179,28 @@ .SS MODULE COMMANDS +Fvwm maintains a database of module configuration lines in a form +.EX +.BI * ModuleName : Config-Resource +.EE +where +.I ModuleName +is either a real module name or an alias. + +This database is initially filled from config file (or from +output of +.B \-cmd +config command), and can be later modified either by user (via +.BR FvwmCommand ) +or by modules. + +When modules are run, they read appropriate portion of database. +(The concept of this database is similar to one used in X resource +database). + +Commands for manipulating module configuration database are +described below. + .TP .BI * module_config_line Defines a module configuration. Index: modules/FvwmAnimate/FvwmAnimate.1 === RCS file: /home/cvs/fvwm/fvwm/modules/FvwmAnimate/FvwmAnimate.1,v retrieving revision 1.13 diff -u -r1.13 FvwmAnimate.1 --- modules/FvwmAnimate/FvwmAnimate.1 2001/07/03 07:23:04 1.13 +++ modules/FvwmAnimate/FvwmAnimate.1 2001/09/15 14:15:48 @@ -51,8 +51,11 @@ the \fBFvwmAnimate\fP module, you don't really have to know what any of the configuration commands are. This section describes them anyway. -\fBFvwmAnimate\fP reads the same \fI.fvwm2rc\fP file as \fBfvwm\fP -reads when it starts up. +\fBFvwmAnimate\fP gets config info from \fBfvwm\fP's module configuration +database (see +.IR fvwm2 (1), +section +.BR MODULE COMMANDS ). In addition, \fBFvwmAnimate\fP reads the file $HOME/.FvwmAnimate, and accepts commands from fvwm and its modules as it runs. Index: modules/FvwmBacker/FvwmBacker.1 === RCS file: /home/cvs/fvwm/fvwm/modules/FvwmBacker/FvwmBacker.1,v retrieving revision 1.9 diff -u -r1.9 FvwmBacker.1 --- modules/FvwmBacker/FvwmBacker.1 2001/08/25 14:45:19 1.9 +++ modules/FvwmBacker/FvwmBacker.1 2001/09/15 14:15:49 @@ -24,9 +24,12 @@ for any purpose as long as the copyright is kept intact. .SH INITIALIZATION -During initialization, \fIFvwmBacker\fP will scan the same -configuration file that FVWM used during startup to find the options -that pertain to it. These options are discussed in a later section. +During initialization, \fIFvwmBacker\fP gets config info from +\fBfvwm\fP's module configuration database (see +.IR fvwm2 (1), +section +.BR MODULE COMMANDS ). +Available options are discussed in a later section. .SH INVOCATION FvwmBacker can be invoked by fvwm during initialization by inserting Index: modules/FvwmDragWell/FvwmDragWell.1 === RCS file: /home/cvs/fvwm/fvwm/modules/FvwmDragWell/FvwmDragWell.1,v retrieving revision 1.6 diff -u -r1.6 FvwmDragWell.1 --- modules/FvwmDragWell/FvwmDragWell.1 2001/08/02 23:06:18 1.6 +++ modules/FvwmDragWell/FvwmDragWell.1 2001/09/15 14:15:51 @@ -15,9 +15,12 @@ drops of type text/uri-list. .SH INITIALIZATION -During initialization, \fIFvwmDragWell\fP will search a configuration -file which is the same file that fvwm used during initialization. If -the FvwmDragWell executable is linked to another name, i.e. ln -s +During initialization, \fIFvwmDragWell\fP gets config info from +\fBfvwm\fP's module configuration database (see +.IR fvwm2 (1), +section +.BR MODULE COMMANDS ). +If the FvwmDragWell
StartsOnPage / X-resources
Hello - The section in the fvwm2 manpage which talks about: [ . . . ] your .Xdefaults file: XTerm*Desk: 1 or XTerm*Page: 3 2 1 Doesn't seem to work for me. If there is a way to fix this, can we add an equivalent way to do StartsOnScreen from .Xdefaults also? If not, how difficult would a StartsAtPosition (or StartsAtGeometry) Style be to implement? (Which would imply NoUSPosition and NoPPosition.) The problem is I'd like to have _one_ config file where I control which screen, and where on that screen all windows pop up. Right now I can only control the screen from .fvwm2rc with StartsOnScreen N, and I can only control the position with Xresources... Any advice? Thanks for you help, - Sidik -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
CVS domivogt: * Applied man page patch.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt01/09/15 17:53:18 Modified files: . : ChangeLog NEWS fvwm : add_window.c borders.c fvwm2.1 libs : Graphics.c XResource.c fvwmlib.h modules/FvwmAnimate: FvwmAnimate.1 modules/FvwmBacker: FvwmBacker.1 modules/FvwmDragWell: FvwmDragWell.1 modules/FvwmEvent: FvwmEvent.1 modules/FvwmGtk: FvwmGtk.1 modules/FvwmIconBox: FvwmIconBox.1 modules/FvwmIdent: FvwmIdent.1 modules/FvwmPager: FvwmPager.1 modules/FvwmScript: FvwmScript.1 modules/FvwmScroll: FvwmScroll.1 modules/FvwmWharf: FvwmWharf.1 modules/FvwmWinList: FvwmWinList.1 Log message: * Applied man page patch. * Fixed button relief drawing. * Fvwm honours desk and page X resources. -- 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: Several things
On Sat, Sep 15, 2001 at 08:42:21PM +0700, Dmitry Yu. Bolkhovityanov wrote: On Thu, 13 Sep 2001, Dominik Vogt wrote: On Thu, Sep 13, 2001 at 03:29:20PM +0700, Dmitry Yu. Bolkhovityanov wrote: Hi! First, a pair of questions regarding window decorations. 1. Is it possible to make titlebar buttons appear not side by side to each other and to borders, but at some offset? So that it would be possible to make a setup similar to OpenWindows (where the window ops button is at some distance from the left) and to MacOS/Aqua-alikes (where buttons are disjoint)? Its not possible with vector buttons but can be done with pixmap buttons. The following lines come from the system.fvwm2rc-sample-95: ButtonStyle 1 MiniIcon (-- flat) ButtonStyle all -- UseTitleStyle Flat AddButtonStyle 2 Pixmap mini.winXX-close.xpm AddButtonStyle 4 Pixmap mini.winXX-maximize.xpm AddButtonStyle 6 Pixmap mini.winXX-minimize.xpm Just give the pixmaps a transparent border in the dimensions you like. Unfortunatey you'll have to draw a separate pixmap for each button state if you need depressed and toggled looks. Yes, that's a known solution, but it has at least three disadvantages. First, as you stated, one has to draw pixmaps for each state. Second, such buttons aren't scalable (as vector buttons are), so they wouldn't follow the title font size. Third, such buttons wouldn't really be offset -- there will be invisible areas, which still can be clicked on, and this is confusing (a similar bug/feature exists in WinAmp/XMMS, where skin elements are separated from actual mouse handling code, and it is IMHO very irritating). Can an offset feature be treated as a TODO item? It doesn't seem hard to implement. I was planning to throw away all that BorderStyle, TitleStyle and ButtonStyle stuff because its almost impossible to maintain. The code is one big mess. Other that this, it doesn't require much to add a 'padding' option. But don't underestimate the complexity of the involved code. 2. Somewhere after 2.2.4, the decoration code was changed so that borders became wider. This had several visible effects, all of which are IMHO negative: a) windows occupy more space (with 2.2.4 on 1152x864 screen xterm with lucidatypewriter-12 font could be tall-maximized to occupy exactly full screen with 64 lines, and xterm with lucidatypewriter-10 could be wide-maximized to use exactly full screen width; now there are unused gaps); The size of the decorations *didn't* change internally in fvwm. If things don't fit nicely anymore then either the font in your xterms has changed or fvwm's title font (TitleFont foo) or the width of the window borders (HandleWidth and BorderWidth styles). No. See below and screenshot. Nope, window borders have always been 7 pixels wide, and they are too in 2.2.x. I don't know where this setting is coming from, but it's definitely not the default. You can verify that by running fvwm without a config file b) hilited parts of titlebar buttons stick -- see topmost scanline of buttons ##0,8. I'm not sure what you mean. Can you perhaps just provide a screenshot? A screenshot is attached. The left window is fvwm-2.2.4 (RedHat 6.2), the right is fvwm-cvs-2001-Sep-10 (compiled and run on RedHat 7.1). Both xterms were run from the same host and on the same X server, with a command xterm -fn lucidasanstypewriter-12 -geom 20x5, fvwm configuration is the same AnotherLevel-1.0.1-1 from RedHat-6.2. There are several things to notice: - 2.4 makes an additional dark border around the window, hence the window is 2px wider and 1px taller. See my comment above. With an empty config file, borders look the same in 2.4 and 2.2.5. - 2.4 title is less tall, but percents in vector buttons are somehow larger (the shapes are thicker); but that indifferent -- both cases are OK. The gap between the relief and the title seems to be one pixel larger in 2.4 (2 pixels, was 1 in 2.2.x). This was probably an unintentional change, but to mee the new titles look better. - 2.4's titlebar buttons stick to each other (the topmost bright line runs from leftmost button to rightmost one uninterrupted), while in 2.2.4 buttons are separated. Fixed. - On the upper [right resize corner]=[vertical part]=[hilite right vertical line] runs 1px higher than it should. This reminds a bug I reported on spring... I see it on your screenshot, but I don't see it here. Could you provide all your border/title/button related config lines, please?
Re: Patch for fvwm modules man pages
On Sat, Sep 15, 2001 at 09:39:43PM +0700, Dmitry Yu. Bolkhovityanov wrote: Hi! Attached is a patch which a) adds a formal description of how fvwm maintains module's configs; b) corrects man pages for individual modules. Applied. BTW1: I changed only those manpages which included those wrong sentences, but it is probably worth modifying other manpages too. Feel free to make another patch. BTW2: FvwmSave manpage wasn't changed, since it is completely broken: most text in it refers to NoClutter (?!?!?!). NoClutter is an ancient fvwm1 module. Since I never used fvwm1 myself I have no idea what it does. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
