Re: FVWM Documentation
Olivier Chapuis <[EMAIL PROTECTED]> writes: > I think that what we need is SGML+DocBook. The LDP and numerous open > source project use this now. Everyone else has moved on to XML, using Norm Walsh's very nice docbook-xsl stylesheets. > docbook2man - a dramatic perl script that can convert the sgml file >that I've written to manual pages. This need some works XSLT is a much better solution for this type of problem, and as a matter of fact the docbook-xsl package already includes a man page stylesheet. -- 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 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: * improved screenshot
Mikhael Goikhman <[EMAIL PROTECTED]> writes: > Transparent (and tinted) menus are very slow, I don't use this > on the daily basis (not that I use any predictable theme on a > daily basis). Hopefully transparent menus could be somehow > speeded up, or maybe it is just my video card and my 350Mhz > processor. Yes, it is slow, but on my 1.2GHz Athlon system it is not noticeable. My configuration on this box is quite different from that on my ancient Pentium 75 Thinkpad :). > * optionally install the latest wm-icons cvs and execute: > % wm-icons-config -p -f -q norm 64x64-aquafusion > % wm-icons-config -p -f -q menu 22x22-aquafusion > % wm-icons-config -p -f -q mini 22x22-aquafusion > % wm-icons-config -p -f -q 16x16 16x16-aquafusion > > Now create ~/.fvwm/themes/personal/startup-extra that have one function: These are the parts i wanted to see. Thanks. -- 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 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: * improved screenshot
> Changes by: migo02/10/09 20:10:41 > Log message: > * improved screenshot I grabbed fvwm-themes CVS and ran through all the themes, but could not find anything matching what's in this screenshot (the RedmondXP stuff is nice, but didn't include the transparent menus, for example). Can you share this config? Thanks. -- 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 http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: [PATCH] Add GTK+ 2.0 support to FvwmGtk
Mikhael Goikhman <[EMAIL PROTECTED]> writes: > So, I move /usr/include/gtk+-1.2/ to /tmp/ and pkg-config > --cflags gtk+ still returns 0. We in fvwm do not trust anything > except for successful compilation and running (if needed) of > some test code. Er, that's a pretty diabolical case. If that's how far you want to go, i will comply. > I don't know whether gnome-2.0 will be detected using > gnome-config, but I know that if it is detected, it is likely > to be usable, because we build a test code with gnome_init in > it. No. gnome-config is a GNOME 1.x thing; 2.x uses pkg-config. You can't have a program linking to both GTK+ 1.2 and 2.0, so you cannot have a program linking to both GTK+ 2.0 and GNOME 1.x. So, if GTK+ 2.0 is enabled, you cannot look for gnome-config. > If you do it manually anyway, I think, supporting of '&' may be > restored. Unless you feel strongly to do it otherwise. Yes, that's what i said. > I mean, I see in some applications with Ctrl-key labels at the > right. I don't think they are defined using underscores. Oh, now i see what you mean. OK, i guess i will have to handle all this manually. > Take a look at WindowList implementation in FvwmGtk, it uses 2 > columns. The second is right justified. It would be nice if > FvwmGtk may support 3 colums like fvwm, so WindowList would > look nicer than it is now (i.e. both columns are > left-justified). This is possible in both 1.2 and 2.0; i'm not sure why it wasn't implemented that way in the first place. I can fix this. -- 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 http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: [PATCH] Add GTK+ 2.0 support to FvwmGtk
Mikhael Goikhman <[EMAIL PROTECTED]> writes: > Your changes in configure.in are not very good, we should check > for a correctness of the gtk headers and libs found, a user may > have pkg-config, but not the gtk libs. Yes, i tested this case. Notice that i test the exit code of pkg-config --cflags gtk+-2.0-x11. > with_gtk should be only "yes" or "no", since it is > used in other places. Whoops, didn't know that. > gnome support should not be special with gtk-2.0, i.e. if gnome > detection still works with gnome-2.0 why to disable it, Well, like i said, i have no interest in GNOME support. You seem to think that the current GNOME detection will find GNOME 2.0; i think that this is not the case, i think pkg-config will also have to be used. Aside from that, i know that some changes in the actual code would be necessary (gnome_init is gone, for example). With or without my patch a user can use GNOME 1 but not GNOME 2, so i don't see why lack of GNOME 2 support should matter. > with_gdkimlib should be set to "no". Yeah, missed that. > It would be possible to still keep '&' and convert it to "_" with > gtk-2.0.0. But I don't care too much here. Yes. I just thought it would be better to be consistent with how GTK normally handles this. If someone thinks it is important to use ampersands instead, i will look to see whether it is better to convert & to _ or just handle all this manually like in the 1.2 code (i'd have to do it all manually anyway to handle r_label). > In fvwm menus, if you use real tab in the label there are (by > default) 3 columns, the first 2 are left justified and the > third is right justified (good for accelerator keys for Accelerator keys? But this is handled automatically (when a character is preceeded by an underscore it gets underlined and becomes the accelerator key). > example). See MenuStyle ItemFormat in fvwm(1) to learn more. In > FvwmGtk menus, only 2 columns may be defined. Or maybe these > are not columns, but right justified texts. I think it is good > to have this functionality. I see this in gtk+ apps. OK, i will read up on this. > So waiting for your reply or maybe another patch. I will come back with a better patch. -- 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 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]
[PATCH] Add GTK+ 2.0 support to FvwmGtk
This patch adds support for GTK+ 2.0 to FvwmGtk in addition to
1.2, not replacing it. If you have both versions installed, it
defaults to 2.0 unless you pass --without-gtk2 to configure.
When using GTK+ 2.0, Imlib is not necessary and thus not used.
As for GNOME, that could be used, but i don't care to install it.
If someone wants to add GNOME 2.0 support, that can easily be
done separately.
I have made one change in the 1.2 code. Previously, FvwmGtk
menus handled accelerators the same way Fvwm built-in menus do.
That is, '&Foo' would cause the F to be underlined and to become
the shortcut key. This is inconsistent with the way GTK+
normally handles accelerators, using an underscore character
instead of ampersand (i.e. '_Foo'). I changed the 1.2 code to
use underscores instead of ampersands; the 2.0 code is handling
accelerators automatically, so i didn't have to do anything
special with it.
Now, i have a question. What on earth is the r_label parameter
to the FvwmGtk menu items supposed to be? I didn't bother to
handle this in the 2.0 code because i don't know what it is for.
Supporting it would take a bit more work, since this is not
normally a thing you do with menu items; i would have to use
weird custom code (this is, as a matter of fact, what FvwmGtk
currently has to do to support this). I'm not sure this is a
good idea. Suggestions?
--
Eric Gillespie, Jr. <*> [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
Index: configure.in
===
RCS file: /home/cvs/fvwm/fvwm/configure.in,v
retrieving revision 1.245
diff -a -u -r1.245 configure.in
--- configure.in2002/09/18 13:55:17 1.245
+++ configure.in2002/09/26 20:44:40
@@ -874,27 +874,50 @@
dnl * GTK, IMLIB, GNOME
-dnl Check the availability of gtk
-AM_PATH_GTK(1.1.0,[FVWMGTK=FvwmGtk AC_SUBST(FVWMGTK)],)
-if test x"$no_gtk" = x; then
- with_gtk=yes
- problem_gtk=""
-else
- with_gtk=no
- problem_gtk=": Failed to detect GTK, see config.log"
-fi
+with_gtk=no
-dnl Check the availability of gdk-imlib
-AM_PATH_GDK_IMLIB(1.8.0, AC_DEFINE(GDK_IMLIB),)
-if test x"$no_imlib" = x; then
- with_gdkimlib=yes
- problem_gdkimlib=""
-else
- with_gdkimlib=no
- problem_gdkimlib=": Failed on gdk-imlib, see config.log"
+AC_ARG_WITH(gtk2, AC_HELP_STRING([--with-gtk2], [use GTK+ 2.0]),
+[try_gtk2=${withval}], [try_gtk2=yes])
+
+dnl First look for GTK+ 2.0, unless --without-gtk2.
+if test "x${try_gtk2}" = 'xyes'; then
+AC_PATH_TOOL(PKG_CONFIG, pkg-config, no)
+if test "x${PKG_CONFIG}" != 'xno'; then
+AC_MSG_CHECKING([for GTK+ 2.0])
+GTK_CFLAGS=`${PKG_CONFIG} --cflags gtk+-x11-2.0`
+if test $? -eq 0; then
+AC_MSG_RESULT(yes)
+with_gtk='yes (version 2.0)'
+GTK_LIBS=`${PKG_CONFIG} --libs gtk+-x11-2.0`
+FVWMGTK=FvwmGtk
+AC_SUBST(FVWMGTK)
+fi
+fi
fi
+
+dnl Failing that, look for GTK+ 1.2.
+if test "x${with_gtk}" = 'xno'; then
+AM_PATH_GTK(1.1.0,[FVWMGTK=FvwmGtk AC_SUBST(FVWMGTK)],)
+if test x"$no_gtk" = x; then
+with_gtk='yes (version 1.2)'
+problem_gtk=""
+else
+with_gtk=no
+problem_gtk=": Failed to detect GTK, see config.log"
+fi
+
+dnl Check the availability of gdk-imlib
+AM_PATH_GDK_IMLIB(1.8.0, AC_DEFINE(GDK_IMLIB),)
+if test x"$no_imlib" = x; then
+with_gdkimlib=yes
+problem_gdkimlib=""
+else
+with_gdkimlib=no
+problem_gdkimlib=": Failed on gdk-imlib, see config.log"
+fi
-GNOME_INIT_HOOK
+GNOME_INIT_HOOK
+fi
dnl Unfortunately we have 2 gnome supports: WM hints and gnome libs.
dnl The $with_gnomehints below refers to the first, not GNOME_INIT_HOOK.
@@ -1053,7 +1076,7 @@
test x"$FVWM_PERLLIB" = x && my_plldir="(Not installed) $my_plldir"
case "$with_gtk" in
- yes) fvwmgtk_msg="
+ *1.2*) fvwmgtk_msg="
With GDK image support in FvwmGtk? $with_gdkimlib$problem_gdkimlib
With GNOME libs support in FvwmGtk? $with_gnomelibs$problem_gnomelibs" ;;
no) fvwmgtk_msg="" ;;
Index: modules/FvwmGtk/FvwmGtk.1
===
RCS file: /home/cvs/fvwm/fvwm/modules/FvwmGtk/FvwmGtk.1,v
retrieving revision 1.20
diff -a -u -r1.20 FvwmGtk.1
--- modules/FvwmGtk/FvwmGtk.1 2002/05/19 02:20:47 1.20
+++ modules/FvwmGtk/FvwmGtk.1 2002/09/26 20:44:41
@@ -69,8 +69,8 @@
.SH MENUS
The following commands define menus. For all arguments named "label"
-in the following
Re: Compile Issues
Dominik Vogt writes: > Currently: > > $ touch configure.in > $ make CFLAGS="-Wall -Werror" > => make reruns configure > => some configure test programs fail because of the warnings in > some header files > => features are detected/missed incorrectly (e.g. AC_C_CONST > detects a non-ansi compiler and adds "#define const" to > config.h) > => bad surprises when compiling (in other words: BOOM) > => lots of time wasted debugging imagined problems Oh! I thought it was bombing already, and that's what you were trying to prevent. Yes, what you describe looks pretty nasty. -- 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 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 writes: > Okay, but what about CFLAGS? I don't care much about the You're probably OK resetting CFLAGS; anything someone will need to add to build it would be a define, include path, or library path, i should think. You never know though, and there's still the principle of least surprise, since fvwm's configure script will behave differently than other configure scripts. > CPPFLAGS or LDFLAGS. And by the way, the paths of all > libraries that fvwm uses can be set with configure options. Sure, it will add a -L, but not a -Wl,-R or any other platform- or site-specific flag. > No, it isn't necessarily a user error. Sometimes, when one of > the autoconf/automake files has changed, an I type > > $ make CFLAGS="-Wall -Werror -O2 -g" > > configure is rerun automatically with the CFLAGS I passed to > make. Ah, good old automake. Rerunning the configure script is evil, for this reason and many others. Since my advice "don't use automake" probably isn't something anyone is interested in hearing, resetting only CFLAGS like you suggested will probably be OK. While we're on this, let me point out one of the other reasons rerunning the configure script is evil. 0 fvwm% cat ../configure/fvwm #! /bin/sh CFLAGS=-g CPPFLAGS='-I/usr/pkg/include' LDFLAGS="-Wl,-R/usr/pkg/lib -L/usr/pkg/lib -Wl,-R/usr/X11R6/lib" export CFLAGS CPPFLAGS LDFLAGS sh ./configure \ --disable-gnome-hints \ --without-gnome \ --disable-sm \ "$@" I have a similar script for every package i install. Luckily for me, the only automake-using package is fvwm, for which my CPPFLAGS and LDFLAGS settings are apparently unnecessary because it will pick them up from the gtk-config script. If it weren't for that luck, the automake-generated would happily run a configure script incorrectly and things would explode. > How about this: write a small test program that issues lots of > warnings with -Wall and AC_TRY_COMPILE it. When that fails, > configure bugs out with an error message. I guess you meant -Werror? I don't see what you're trying to accomplish though. -- 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 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 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 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]
[PATCH] fvwm/gnome.h broken when GNOME hint support disabled
Some of these functions changed recently, but the macros that are defined when GNOME hint support is disabled were not updated. Index: fvwm/gnome.h === RCS file: /home/cvs/fvwm/fvwm/fvwm/gnome.h,v retrieving revision 1.9 diff -a -u -r1.9 gnome.h --- fvwm/gnome.h 2002/09/10 23:20:141.9 +++ fvwm/gnome.h 2002/09/17 01:56:43 @@ -65,7 +65,7 @@ #else #define GNOME_Init() -#define GNOME_ProcessClientMessage(fwin, ev) 0 +#define GNOME_ProcessClientMessage(exc) 0 #define GNOME_ButtonFunc(eventp, w, fwin, context, action, Module) #define GNOME_ProxyButtonEvent(ev) #define GNOME_ShowDesks(eventp, w, fwin, context, action, Module) @@ -75,7 +75,7 @@ #define GNOME_SetLayer(fwin) #define GNOME_SetDesk(fwin) #define GNOME_SetWinArea(w) -#define GNOME_HandlePropRequest(propm, prop, win, ev) +#define GNOME_HandlePropRequest(exc, propm, prop) #define GNOME_SetAreaCount() #define GNOME_SetDeskCount() #define GNOME_SetCurrentArea() -- Visit the official FVWM web page at 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]
MultiPixmap Broken?
(I'm returning to Fvwm after a long fling with Sawfish and am still getting my bearings. I've forgotten a lot, but don't be surprised if i provide one lame patch or another from time to time :) While putting together a new fvwm configuration (using fvwm built from cvs HEAD this morning), i stumbled upon Suzanne Britton's MultiPixmap stuff (http://www.igs.net/~tril/fvwm/configs/index.html). It appears to be broken, however. I notice that the frame code has been under significant renovation since her patch was committed, so perhaps this isn't a surprise. The following minimal .fvwm2rc demonstrates the problem: ### ImagePath /u/home/epg/.fvwm TitleStyle \ ActiveUp (MultiPixmap Main blue_metal/title_active.xpm) \ Inactive (Solid red -- flat) ### The image is originally from Suzanne's site but can also be found at <http://pretzelnet.org/~epg/tmp/title_active.xpm>, though really it doesn't matter what image you test with. If no one else has time to look at this, i'll have time to look into it next weekend. Thanks. -- Eric Gillespie, Jr. <*> [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 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]
