Re: Style * NoHandles bug?
On Sat, Sep 14, 2002 at 11:59:26AM +, Mikhael Goikhman wrote: On 13 Sep 2002 19:42:26 -0600, S. Anderson wrote: When I use Style * NoHandles in my .fvwm2rc, CursorStyle definitions using xpm don't work anymore, and the border width for windows is set to 1 pixel. You can reproduce by putting just the following in your .fvwm2rc: # start Style * NoHandles CursorStyle LEFT/home/sa/.fvwm/cursors/resize_side.xpm # end I think it worked this way always (2.2.x, 2.4.x). Without handles it is pretty difficult to determine where a corner and where starts and ends LEFT. If you want cursors on borders you may use this: Style * Handles BorderStyle -- HiddenHandles ok, I assumed Style * NoHandles was supposed to do the same thing as BorderStyle -- HiddenHandles, which is what I usualy use. but, I still think there is some wierdness going on here, for instance if you do this in FvwmConsole: Style * BorderWidth 5 Style * NoHandles CursorStyle LEFT gumby #or CursorStyle LEFT resize_side.xpm Then the border cursors work for all existing windows, but when you open any new windows, the border cursors don't work on the new windows only. Is this how its supposed to work? thanks, sa -- 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]
Compile Issues
Fvwm does not compile if Gnome hints and/or EWMH hints are disabled. The attached patch fixes this. Also, CFLAGS aren't working at all? Also also, Fvwm fails to link if compiled without Xinerama, because of the reference to XineramaQueryScreens (possibly others, haven't checked) in FScreen.o. Perhaps if -O2 were working it would be safely optimized away... Suzanne -- [EMAIL PROTECTED] - http://www.igs.net/~tril/ --- gnome.h.origTue Sep 17 01:35:59 2002 +++ gnome.h Tue Sep 17 01:35:59 2002 @@ -65,7 +65,7 @@ #else #define GNOME_Init() -#define GNOME_ProcessClientMessage(fwin, ev) 0 +#define GNOME_ProcessClientMessage(fwin) 0 #define GNOME_ButtonFunc(eventp, w, fwin, context, action, Module) #define GNOME_ProxyButtonEvent(ev) #define GNOME_ShowDesks(eventp, w, fwin, context, action, Module) --- ewmh.h.orig Tue Sep 17 01:35:58 2002 +++ ewmh.h Tue Sep 17 01:35:58 2002 @@ -117,8 +117,8 @@ /* ewmh_conf.c */ /* ewmh_events.c */ -#define EWMH_ProcessClientMessage(x, y) 0 -#define EWMH_ProcessPropertyNotify(x, y) +#define EWMH_ProcessClientMessage(x) 0 +#define EWMH_ProcessPropertyNotify(x) /* ewmh_icon.c */ #define EWMH_DoUpdateWmIcon(x,y,z)
Re: Style * NoHandles bug?
On Mon, Sep 16, 2002 at 11:54:29PM -0600, S. Anderson wrote: On Sat, Sep 14, 2002 at 11:59:26AM +, Mikhael Goikhman wrote: On 13 Sep 2002 19:42:26 -0600, S. Anderson wrote: When I use Style * NoHandles in my .fvwm2rc, CursorStyle definitions using xpm don't work anymore, and the border width for windows is set to 1 pixel. You can reproduce by putting just the following in your .fvwm2rc: # start Style * NoHandles CursorStyle LEFT/home/sa/.fvwm/cursors/resize_side.xpm # end I think it worked this way always (2.2.x, 2.4.x). Without handles it is pretty difficult to determine where a corner and where starts and ends LEFT. If you want cursors on borders you may use this: Style * Handles BorderStyle -- HiddenHandles ok, I assumed Style * NoHandles was supposed to do the same thing as BorderStyle -- HiddenHandles, which is what I usualy use. but, I still think there is some wierdness going on here, for instance if you do this in FvwmConsole: Style * BorderWidth 5 Style * NoHandles CursorStyle LEFT gumby #or CursorStyle LEFT resize_side.xpm Then the border cursors work for all existing windows, but when you open any new windows, the border cursors don't work on the new windows only. Is this how its supposed to work? No, that's a bug. When the CursorStyle command is issued, all the cursors come back. 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 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: Compile Issues
On Tue, Sep 17, 2002 at 01:54:56AM -0400, Suzanne Skinner wrote: Fvwm does not compile if Gnome hints and/or EWMH hints are disabled. The attached patch fixes this. Also, CFLAGS aren't working at all? They should be working as usual. I have disabled them in configure because they often cause some tests to fail. How did you specify the flags? When I run $ make CFLAGS=... it works as it always did. Also also, Fvwm fails to link if compiled without Xinerama, because of the reference to XineramaQueryScreens (possibly others, haven't checked) in FScreen.o. Perhaps if -O2 were working it would be safely optimized away... Fixed. --- gnome.h.orig Tue Sep 17 01:35:59 2002 +++ gnome.h Tue Sep 17 01:35:59 2002 @@ -65,7 +65,7 @@ #else #define GNOME_Init() -#define GNOME_ProcessClientMessage(fwin, ev) 0 +#define GNOME_ProcessClientMessage(fwin) 0 #define GNOME_ButtonFunc(eventp, w, fwin, context, action, Module) #define GNOME_ProxyButtonEvent(ev) #define GNOME_ShowDesks(eventp, w, fwin, context, action, Module) --- ewmh.h.orig Tue Sep 17 01:35:58 2002 +++ ewmh.hTue Sep 17 01:35:58 2002 @@ -117,8 +117,8 @@ /* ewmh_conf.c */ /* ewmh_events.c */ -#define EWMH_ProcessClientMessage(x, y) 0 -#define EWMH_ProcessPropertyNotify(x, y) +#define EWMH_ProcessClientMessage(x) 0 +#define EWMH_ProcessPropertyNotify(x) /* ewmh_icon.c */ #define EWMH_DoUpdateWmIcon(x,y,z) Applied. 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 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: * Various build fixes.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/09/17 04:26:50 Modified files: . : ChangeLog fvwm : cursor.c ewmh.h gnome.h libs : FScreen.c Log message: * Various build fixes. * Fixed CursorStyle being applied to NoHandles windows. -- 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: Style * NoHandles bug?
On Tue, Sep 17, 2002 at 11:04:12AM +0200, fvwm-workers wrote: On Mon, Sep 16, 2002 at 11:54:29PM -0600, S. Anderson wrote: On Sat, Sep 14, 2002 at 11:59:26AM +, Mikhael Goikhman wrote: On 13 Sep 2002 19:42:26 -0600, S. Anderson wrote: When I use Style * NoHandles in my .fvwm2rc, CursorStyle definitions using xpm don't work anymore, and the border width for windows is set to 1 pixel. You can reproduce by putting just the following in your .fvwm2rc: # start Style * NoHandles CursorStyle LEFT/home/sa/.fvwm/cursors/resize_side.xpm # end I think it worked this way always (2.2.x, 2.4.x). Without handles it is pretty difficult to determine where a corner and where starts and ends LEFT. If you want cursors on borders you may use this: Style * Handles BorderStyle -- HiddenHandles ok, I assumed Style * NoHandles was supposed to do the same thing as BorderStyle -- HiddenHandles, which is what I usualy use. but, I still think there is some wierdness going on here, for instance if you do this in FvwmConsole: Style * BorderWidth 5 Style * NoHandles CursorStyle LEFT gumby #or CursorStyle LEFT resize_side.xpm Then the border cursors work for all existing windows, but when you open any new windows, the border cursors don't work on the new windows only. Is this how its supposed to work? No, that's a bug. When the CursorStyle command is issued, all the cursors come back. 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 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: Compile Issues
On Tue, 17 Sep 2002, Dominik Vogt wrote: On Tue, Sep 17, 2002 at 01:54:56AM -0400, Suzanne Skinner wrote: Also, CFLAGS aren't working at all? They should be working as usual. I have disabled them in configure because they often cause some tests to fail. How did you specify the flags? When I run $ make CFLAGS=... it works as it always did. If I understand the True Gnu Way Of Doing Things right, configure should read any CFLAGS (and CXXFLAGS and LDFLAGS and ...) you have set in your shell and write them to the appropriate Makefiles, such that afterwards, make CFLAGS=$CFLAGS should be equivalent to simply saying make , and make CFLAGS=aVerySpecialFlag would be the same as make CFLAGS=aVerySpecialFlag $CFLAGS Of course there can be good reasons to disable CFLAGS recognition in configure, but then things do not work the True Gnu Way anymore (which is not A Bad Thing, but maybe it deserves to be mentioned in the INSTALL file). Just my 2c, Uli -- Ulrich Fahrenberg -- http://www.math.auc.dk/~uli -- 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: Compile Issues
On Tue, Sep 17, 2002 at 12:44:03PM +0200, Ulrich Fahrenberg wrote: On Tue, 17 Sep 2002, Dominik Vogt wrote: On Tue, Sep 17, 2002 at 01:54:56AM -0400, Suzanne Skinner wrote: Also, CFLAGS aren't working at all? They should be working as usual. I have disabled them in configure because they often cause some tests to fail. How did you specify the flags? When I run $ make CFLAGS=... it works as it always did. If I understand the True Gnu Way Of Doing Things right, configure should read any CFLAGS (and CXXFLAGS and LDFLAGS and ...) you have set in your shell and write them to the appropriate Makefiles, such that afterwards, make CFLAGS=$CFLAGS should be equivalent to simply saying make Well, if it's set in your shell, make inherits them automatically unless you unset them between configure an make. (testing) But it doesn't work. Autoconf seems to override the shell settings. , and make CFLAGS=aVerySpecialFlag would be the same as make CFLAGS=aVerySpecialFlag $CFLAGS Of course there can be good reasons to disable CFLAGS recognition in configure, Yes, there is a very good reason: configure chokes on the -Werror flag and produces more or less random test results. This can be hell to debug. Maybe I can find a way to enable the original CFLAGS again before they are placed in the Makefiles. but then things do not work the True Gnu Way anymore (which is not A Bad Thing, but maybe it deserves to be mentioned in the INSTALL file). 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 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: * Enable the original CFLAGS and CPPFLAGS before generating the Makefiles.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/09/17 07:09:53 Modified files: . : ChangeLog configure.in Log message: * Enable the original CFLAGS and CPPFLAGS before generating the Makefiles. -- 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: * Add a warning at beginning of man page that it's generated from .in file.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/09/17 07:30:02 Modified files: . : ChangeLog configure.in fvwm : fvwm.1.in Log message: * Add a warning at beginning of man page that it's generated from .in file. -- 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: * Allow using buttons other than first in transient FvwmWinList.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/09/17 08:41:51 Modified files: . : Tag: branch-2_4 NEWS modules: Tag: branch-2_4 ChangeLog modules/FvwmWinList: Tag: branch-2_4 FvwmWinList.c Log message: * Allow using buttons other than first in transient FvwmWinList. -- 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: * Allow using buttons other than first in transient FvwmWinList.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/09/17 08:42:00 Modified files: . : NEWS modules: ChangeLog modules/FvwmWinList: FvwmWinList.c Log message: * Allow using buttons other than first in transient FvwmWinList. -- 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]
Expose events and menus
Hello, I am not sure that the following problem is new, but I've just not it (I am currently work on clipping the menu drawing). If the popdown menu delay is very small, for example with MenuStyle * PopdownImmediately [,PopupOffSet 0 50, PopupDelayed, PopupDelay 500] then sometimes menus do not refresh correctly when one of its submenu pop down. It seems to me that the Expose event that should generate fvwm (or the server) when a menu pop down is not generated or taken in account. To see this you should not use an Xserver with BackingStore enabled. Olivier -- 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]
Warning in .xsession-errors
Hello dear fvwm workers.
I'm a highly satisfied fvwm2 user.
Reproducably, I get the advice in .xsession-errors to report
a 'bug' (?). I don't know whats going on here and I see no
disturbance at all ('xept for the message in .xsession-errors).
So I paste it here:
[FVWM][GetWindowSizeHints]: WARNING Discard or Save Message - KMail window
0x2a0348b has broken (max_width) size hints
Please send a bug report to the application owner,
you may use fvwm-workers@fvwm.org as a reference.
hint override = 0
flags = 23f
min_width = 419, min_height = 115, max_width = 418, max_height = 114
width_inc = 0, height_inc = -1073749792
min_aspect = 1088063394/1092065668, max_aspect = 140755152/-1073749624
base_width = 1093476281, base_height = 1095207832
win_gravity = 1
Again, I have no issue with this. I do not notice anything strange.
But if you need more information, feel free to contact me and I'm willing
to supply whatever you require.
Regards, Michael
--
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 migo fvwm-web: * regenerated man pages of 2.4.10
CVSROOT:/home/cvs/fvwm Module name:fvwm-web Changes by: migo02/09/17 09:54:00 Modified files: . : ChangeLog generated/manpages: FvwmAnimate.html FvwmAuto.html FvwmBacker.html FvwmBanner.html FvwmButtons.html FvwmCommand.html FvwmConsole.html FvwmCpp.html FvwmDebug.html FvwmDragWell.html FvwmEvent.html FvwmForm.html FvwmGtk.html FvwmIconBox.html FvwmIconMan.html FvwmIdent.html FvwmM4.html FvwmPager.html FvwmRearrange.html FvwmSave.html FvwmSaveDesk.html FvwmScript.html FvwmScroll.html FvwmTaskBar.html FvwmTheme.html FvwmWharf.html FvwmWinList.html focus-link.html fvwm-config.html fvwm-menu-desktop.html fvwm-menu-directory.html fvwm-menu-headlines.html fvwm-menu-xlock.html fvwm2.html fvwm24_convert.html fvwmbug.html fvwmrc_convert.html index.html xpmroot.html generated/perllib: FVWM::Constants.html FVWM::Event.html FVWM::EventNames.html FVWM::Module.html FVWM::Module::Gtk.html FVWM::Module::Tk.html General::FileSystem.html General::Parse.html index.html perllib2html tutorial.html Added files: generated/manpages: FvwmConsoleC.pl.html FvwmPerl.html fvwm-bug.html fvwm-convert-2.2.html fvwm-convert-2.4.html fvwm-convert-2.6.html fvwm-perllib.html fvwm-root.html fvwm.html manpages2html Removed files: generated : run_man2html.sh Log message: * regenerated man pages of 2.4.10 * replaced run_man2html.sh with a more maintanable perl script manpages2html * some fixes and improvements in functionality (cross-links) and better colors * added missing FvwmConsoleC.pl.html * added new 2.5.x man pages (non-existing in 2.4.x), but they are not really _ linked from anywhere except for maybe between themselves and from perllib * updated perllib2html to match more or less manpages2html I hope noone (Dan) objects these changes. -- 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: Warning in .xsession-errors
On Tue, Sep 17, 2002 at 04:29:31PM +0200, Michael Naumann wrote:
Hello dear fvwm workers.
I'm a highly satisfied fvwm2 user.
Reproducably, I get the advice in .xsession-errors to report
a 'bug' (?). I don't know whats going on here and I see no
disturbance at all ('xept for the message in .xsession-errors).
So I paste it here:
[FVWM][GetWindowSizeHints]: WARNING Discard or Save Message - KMail
window
0x2a0348b has broken (max_width) size hints
Please send a bug report to the application owner,
you may use fvwm-workers@fvwm.org as a reference.
hint override = 0
flags = 23f
min_width = 419, min_height = 115, max_width = 418, max_height = 114
width_inc = 0, height_inc = -1073749792
min_aspect = 1088063394/1092065668, max_aspect = 140755152/-1073749624
base_width = 1093476281, base_height = 1095207832
win_gravity = 1
Again, I have no issue with this. I do not notice anything strange.
But if you need more information, feel free to contact me and I'm willing
to supply whatever you require.
The application requested a minimum width of 419 pixels and a
maximum width of 418 pixels. Although fvwm can handle this
situation well, it points out a bug in the application and should
be reported to the KMail developrs. It usually has no effect for
the user.
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 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: Expose events and menus
On Tue, Sep 17, 2002 at 03:56:27PM +0200, Olivier Chapuis wrote: Hello, I am not sure that the following problem is new, but I've just not it (I am currently work on clipping the menu drawing). If the popdown menu delay is very small, for example with MenuStyle * PopdownImmediately [,PopupOffSet 0 50, PopupDelayed, PopupDelay 500] then sometimes menus do not refresh correctly when one of its submenu pop down. It seems to me that the Expose event that should generate fvwm (or the server) when a menu pop down is not generated or taken in account. Pending Expose events are eaten up in some places. Try disabling the flush_expose() and flush_accumulate_expose() calls in menus.c. To see this you should not use an Xserver with BackingStore enabled. Or use a b/d gradient MenuFace. 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 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 migo fvwm-web: * small bug fix in index
CVSROOT:/home/cvs/fvwm Module name:fvwm-web Changes by: migo02/09/17 11:07:32 Modified files: generated/manpages: index.html manpages2html generated/perllib: perllib2html Removed files: generated/manpages: FvwmConsoleC.html Log message: * small bug fix in index * removed unexisting man page -- 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 fvwm-web: * regenerated man pages of 2.4.10
FVWM CVS fvwm-workers@fvwm.org writes:
I hope noone (Dan) objects these changes.
I can't tell what part you want me to object to.
:)
--
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 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 dane fvwm-web: * screenshots/index.html: Add link to freshmeat for CDEmu.
CVSROOT:/home/cvs/fvwm Module name:fvwm-web Changes by: dane02/09/17 12:47:23 Modified files: . : ChangeLog screenshots: index.html Log message: * screenshots/index.html: Add link to freshmeat for CDEmu. -- 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 migo fvwm-web: * woops, fixed SYNOPSIS
CVSROOT:/home/cvs/fvwm Module name:fvwm-web Changes by: migo02/09/17 13:03:55 Modified files: generated/perllib: FVWM::Module.html Log message: * woops, fixed SYNOPSIS -- 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 migo fvwm-web: * more fixes
CVSROOT:/home/cvs/fvwm Module name:fvwm-web Changes by: migo02/09/17 13:55:13 Modified files: generated/perllib: FVWM::Module.html perllib2html Log message: * more fixes -- 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: Compile Issues
Dominik Vogt fvwm-workers@fvwm.org writes:
Yes, there is a very good reason: configure chokes on the
-Werror flag and produces more or less random test results.
This can be hell to debug. Maybe I can find a way to enable
the original CFLAGS again before they are placed in the
Makefiles.
That is not generally sufficient, nor is setting the variables on
the make command line. There is a reason for the standard
behavior. If you have libraries installed outside the standard
search path (/usr), you need to set CPPFLAGS and LDFLAGS before
running configure. The most famous examples are /usr/X11R6 and
/usr/local (yes, i know most (all?) GNU/Linux distributions put
those on the standard search path, but that's just lunacy), but
there are also things like /opt and /usr/pkg (where NetBSD
packages are installed).
And no, it isn't generally sufficient for the configure script to
set the appropriate options itself. That is necessary for the
standard options (-L and -I), but not sufficient because
sometimes platform- or site-specific settings are needed. For
example, on NetBSD we always set an rpath with -Wl,-R, but on
Darwin the linker will explode since it has no -R option.
Configure scripts would be a mess if they had to handle this sort
of thing.
I say generally because, in my experience, it is not necessary
to set these variables with fvwm. I think it's picking up
/usr/{X11R6,pkg}/{include,pkg} from the gtk-config script. So
the above paragraph may not apply to Fvwm (someone not using the
Gtk stuff will have to comment), but it's good to keep in mind
anyway. And it may be worth sticking with the standard behavior
so as not to violate the principle of least surprise, if for no
other reason.
As for the -Werror example, that is just user error. There are
things you need to put into CPPFLAGS (defines and includes), and
there are things you can put in there that will break (code
generation or scanning flags).
--
Eric Gillespie * [EMAIL PROTECTED]
Build a fire for a man, and he'll be warm for a day. Set a man on
fire, and he'll be warm for the rest of his life. -Terry Pratchett
--
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: planning the 10th fvwm birthday event
Maybe Mr. Nation could be persuaded to retract feeble and designate his choice for a new word for F. Failing that, how about a ballot, with the FAQ 1.1 choices, plus write-ins (I like Foundry, myself) and a choice of Keep the mystery. fvwm-workers wrote: On the first of June, 2003, we will be celebrating fvwm's tenth birthday. It may seem an eternity now, but the preparations will probably take much longer than I believe right now. As fvwm is mostly about users, I'd like to invite everybody to help planning the Grand-Fvwm-Birthday-Event (tm). I have collected a few vague ideas (o = maybe, * = must): * Publish some words about fvwm history. * Promote the event (magazines, announcement lists, newsgroups). * Finish the 2.6 release before that day. * Vamp up the web page for the event. o Find Robert Nation and get at least a statement from him. o Revive the fvwm logo contest a few months before the birthday and proclaim the winning logo on the birthday. o Create an IRC channel on that day. o Make a web page with photographs of the developers. Don't hesitate to post your suggestions, comments, offers for help or whatever you can think of. Although I posted this message on both, the fvwm and the fvwm-workers list, I would like to keep this discussion on the fvwm-workers mailing list to keep the noise on fvwm low. Please reply to fvwm-workers. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: fvwm-workers@fvwm.org -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: planning the 10th fvwm birthday event
On 17 Sep 2002 14:00:26 -0600, Gregg Dameron wrote: Maybe Mr. Nation could be persuaded to retract feeble and designate his choice for a new word for F. Failing that, how about a ballot, with the FAQ 1.1 choices, plus write-ins (I like Foundry, myself) and a choice of Keep the mystery. My choice is a recursive acronym. FVWM == FVWM's Virtual Window Manager. 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: planning the 10th fvwm birthday event
in message [EMAIL PROTECTED], wrote fvwm-workers thusly... On the first of June, 2003, we will be celebrating fvwm's tenth birthday. It may seem an eternity now no kidding... (o = maybe, * = must): * Finish the 2.6 release before that day. shouldn't that be an maybe item as that release will server nobody if it would be only in name sake? i would much prefer a stable version (any of 2.[45].x) than the _necessary_ 2.6 ... ...of course, if the release just happen to be on the birthday, that would be another thing. - parv -- -- 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]
