m4 Macros for configure
Hi. The definition of smr_SWITCH (in both acinclude.m4 and aclocal.m4) uses m4_substr and m4_len, neither of which exist in any m4 I know about. (The three on my Solaris 8 machine are /usr/ccs/bin/m4, /usr/xpg4/bin/m4, and GNU m4 1.4.) Does this exist in some newer or more odd M4? Shouldn't we just use substr and len? The sign that this has failed is in the --help output of the generated configure. It contains the macro calls, rather than the intended strings resulting from the macro. Anyone know where these came from? (And why there's ones in both aclocal.m4, and acinclude.m4?) - Chris -- 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: m4 Macros for configure
Mikhael Goikhman wrote: You need a more recent autoconf. This part is tricky, I know how to make autoconf = 2.13 happy and autoconf 2.13 happy, but not both together. If someone knows, feel free to fix this, but I don't think it worth the effort. It only affects the --help output, and if the recent autoconf is used to create releases, then the release will be ok. Well, at the very least, you could check which version of autoconf is running, right? And if it's = 2.13, you can redefine m4_substr and m4_len to substr and len, yes? I'll take a look into autoconf and see if I see how to do this anywhere from inside of m4... - Chris -- 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: m4 Macros for configure
Mikhael Goikhman wrote: aclocal.m4 is generated from acinclude.m4 by aclocal that's from automake (before this generated file is used by autoconf to generate ./configure). Excellent. Thank you for that information. Okay, I've applied a fairly ugly patch to acinclude.m4. It tears apart the AC_ACVERSION macro into the major and minor number [string]s, and then if the minor number is 13, defines m4_substr and m4_len. It works for me, and I've tested that the macro leaves m4_* unset when I hand-feed it a 2.51 instead of AC_ACVERSION. Unfortunately, m4 only knows about strings. So, do do a = 2.13, I'd have to use syscmd() and sysval(). I could do that, but I wasn't sure it was worth the effort. But, I don't know what versions of autoconf are likely to be in use. Let me know if anything like this would be acceptable. Thanks... - Chris Index: acinclude.m4 === RCS file: /home/cvs/fvwm/fvwm/acinclude.m4,v retrieving revision 1.49 diff -u -u -r1.49 acinclude.m4 --- acinclude.m48 Jul 2004 10:08:09 - 1.49 +++ acinclude.m41 Sep 2004 17:50:11 - @@ -103,6 +103,17 @@ fi ]) +dnl Versions of autoconf 2.13 and older don't have m4_substr and m4_len +dnl built into them. So, check the version of autoconf we're running, +dnl and if it's 2.13, substitude alternative definitions for them. +define([SEGMENT1],[substr([$1],0,ifelse(index([$1],.),-1,len([$1]),index([$1],.)))])dnl +define([SEGMENT2],[ifelse( index([$1],.), -1, [], SEGMENT1(substr([$1], incr(index([$1],.)])dnl + +define([AC_ACVERSION_MAJOR],[SEGMENT1(AC_ACVERSION)])dnl +define([AC_ACVERSION_MINOR],[SEGMENT2(AC_ACVERSION)])dnl +ifelse(AC_ACVERSION_MINOR,13, +[define([m4_substr],[substr([$1],[$2])])dnl +define([m4_len],[len([$1])])dnl])dnl dnl Configure-time switch with default dnl
Re: Solaris Xinerama support
Thanks Dominik. Dominik Vogt wrote: They changed something with quoting in autoconf/automake a while ago. Unfortunately you have to test with the old and new auto* versions to make sure some things in configure work fine. Odd. It worked for me, too, using the same version of autoconf that'd previously generated the configure. Guess that must've changed on your system and not mine. Thanks for fixing it! There were a couple issues with your changes to libs/FScreen.c. I don't know that I agree with the all code should be compiled opinion, but that's certainly your call to make. And the #ifdef'd code is now more sensible than it was, and than I'd made it. Thanks. But, there was one typo (capitalization error), and one error in the #def's. Solaris' xinerama.h does *not* define XineramaScreenInfo, since Solaris' xinerama system API is *completely* different. I just moved the relevant #def out one level. A patch to libs/FScreen.c is attached. It will now link both with and without the Solaris xinerama.h header. Thanks again! - Chris Index: libs/FScreen.c === RCS file: /home/cvs/fvwm/fvwm/libs/FScreen.c,v retrieving revision 1.24 diff -u -r1.24 FScreen.c --- libs/FScreen.c 26 Aug 2004 09:40:42 - 1.24 +++ libs/FScreen.c 26 Aug 2004 15:52:53 - @@ -73,10 +73,10 @@ # define FScreenHaveXinerama 1 # ifdef HAVE_SOLARIS_XINERAMA # define FScreenHaveSolarisXinerama 1 +# define FSCREEN_NEED_SCREENINFO # ifdef HAVE_SOLARIS_XINERAMA_H # include X11/extensions/xinerama.h # else -# define FSCREEN_NEED_SCREENINFO # define FSCREEN_NEED_SOLARIS_PROTOTYPES # endif # else @@ -114,7 +114,7 @@ #if FScreenHaveXinerama # if FScreenHaveSolarisXinerama # define XineramaQueryExtension(d,b,c) 1 /* Lie, for now */ -# define XineramaIsActive(d) Xineramagetstate((d),0) +# define XineramaIsActive(d) XineramaGetState((d),0) # endif #else # define XineramaQueryExtension(da, b, c) 0
configure extra cflags?
Hey there. I have a small problem, that will require changes to configure to solve. On my Solaris machine, there are #pragma's in some of the openwin X headers that gcc (3.3.2) doesn't like. This is easily solvable with -wunknown-pragmas, but if I put that in CFLAGS on the configure command-line environment, it will append -Wall, thus cancelling it out. I thought it might be more useful to be able to put arbitrary things on the CFLAGS (and/or CPPFLAGS), but have them go after the -Wall. Anyone else have any thoughts on this issue? - Chris -- 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: Solaris Xinerama support
Dan Espen wrote:
If the #define'd stuff is only used on Solaris, when the header
isn't there, and the library support is there, I'd say that was
OK.
Yup. That's how it's done. Only if the libXinerama stuff
isn't found will it look for Solaris' calls, and only if those
are found will it look for the header. If the header is found,
the few lines (to replace the header) I added don't get used.
The following should be the full diff against CVS HEAD for
this patch. Thanks for all your help!
- Chris
Index: configure.in
===
RCS file: /home/cvs/fvwm/fvwm/configure.in,v
retrieving revision 1.294
diff -u -u -r1.294 configure.in
--- configure.in23 May 2004 16:20:23 - 1.294
+++ configure.in20 Aug 2004 13:26:58 -
@@ -298,8 +298,18 @@
$UNSET ac_cv_lib_Xinerama_XineramaIsActive
AC_CHECK_LIB(Xinerama, XineramaIsActive,
with_xinerama=yes; Xinerama_LIBS=-lXinerama; AC_DEFINE(HAVE_XINERAMA),
+AC_CHECK_LIB(Xext, XineramaGetState,
+ [ AC_DEFINE(HAVE_XINERAMA) AC_DEFINE(HAVE_SOLARIS_XINERAMA)
+ with_xinerama=yes; Xinerama_LIBS=-lXext
+ my_CPPFLAGS=$CPPFLAGS; CPPFLAGS=$X_CPPFLAGS $CPPFLAGS
+ my_hdr=X11/extensions/xinerama.h
+ AC_CHECK_HEADER($my_hdr, AC_DEFINE(HAVE_SOLARIS_XINERAMA_H)
+ problem_xinerama= (Using Solaris Xinerama calls),
+ problem_xinerama= (Failed to find Sun's $my_hdr))
+ CPPFLAGS=$my_CPPFLAGS],
with_xinerama=no; Xinerama_LIBS=
problem_xinerama=: Failed to detect libXinerama,
+[$X_LIBS $X_PRE_LIBS -lX11 $X_EXTRA_LIBS]),
[$X_LIBS $X_PRE_LIBS -lXext -lX11 $X_EXTRA_LIBS])
fi
AC_SUBST(Xinerama_LIBS)
Index: acconfig.h
===
RCS file: /home/cvs/fvwm/fvwm/acconfig.h,v
retrieving revision 1.72
diff -u -u -r1.72 acconfig.h
--- acconfig.h 8 Jul 2004 10:08:09 - 1.72
+++ acconfig.h 20 Aug 2004 13:26:58 -
@@ -32,6 +32,14 @@
/* Define if Xinerama library is used. */
#undef HAVE_XINERAMA
+/* Define if Solaris' Xinerama calls are being used. */
+/* (Solaris 7 11/99 and later) */
+#undef HAVE_SOLARIS_XINERAMA
+
+/* Define if Solaris' X11/extensions/xinerama.h header is provided. */
+/* (Solaris 9 and later) */
+#undef HAVE_SOLARIS_XINERAMA_H
+
/* Define if Xrender library is used. */
#undef HAVE_XRENDER
Index: fvwm/fvwm.c
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/fvwm.c,v
retrieving revision 1.368
diff -u -u -r1.368 fvwm.c
--- fvwm/fvwm.c 15 Jul 2004 13:12:28 - 1.368
+++ fvwm/fvwm.c 20 Aug 2004 13:26:59 -
@@ -1312,6 +1312,9 @@
strcat(support_str, Bidi text,);
#endif
#ifdef HAVE_XINERAMA
+# ifdef HAVE_SOLARIS_XINERAMA
+ strcat(support_str, [Solaris' odd-ball]);
+# endif
strcat(support_str, Xinerama,);
#endif
#ifdef HAVE_XRENDER
Index: libs/FScreen.c
===
RCS file: /home/cvs/fvwm/fvwm/libs/FScreen.c,v
retrieving revision 1.22
diff -u -u -r1.22 FScreen.c
--- libs/FScreen.c 17 Mar 2004 14:42:54 - 1.22
+++ libs/FScreen.c 20 Aug 2004 13:26:59 -
@@ -69,8 +69,62 @@
#include PictureBase.h
#ifdef HAVE_XINERAMA
-#define FScreenHaveXinerama 1
-#include X11/extensions/Xinerama.h
+# define FScreenHaveXinerama 1
+# ifdef HAVE_SOLARIS_XINERAMA
+# ifdef HAVE_SOLARIS_XINERAMA_H
+# include X11/extensions/xinerama.h
+# else
+/* Copied from Solaris 9's X11/extensions/xinerama.h */
+#defineMAXFRAMEBUFFERS 16
+Bool XineramaGetState(Display*, int);
+Status XineramaGetInfo(Display*, int, XRectangle*, unsigned char*, int*);
+Status XineramaGetCenterHint(Display*, int, int*, int*);
+# endif /* HAVE_SOLARIS_XINERAMA_H */
+typedef struct
+{
+ int screen_number;
+ short x_org;
+ short y_org;
+ short width;
+ short height;
+} XineramaScreenInfo;
+# define XineramaIsActive(d) XineramaGetState((d),0)
+# define XineramaQueryScreens(d,b)solaris_XineramaQueryScreens((d),(b))
+# define XineramaQueryExtension(d,b,c)1 /* Lie, for now */
+static XineramaScreenInfo *
+solaris_XineramaQueryScreens(Display *d, int *xin_nscreens)
+{
+ XineramaScreenInfo *screens = NULL;
+ XRectangle monitors[MAXFRAMEBUFFERS];
+ unsigned char hints[16];
+
+ int result = XineramaGetInfo(d, DefaultScreen(d), monitors, hints,
+xin_nscreens);
+ if (result)
+ {
+ int m;
+
+ screens = (XineramaScreenInfo
*)malloc(sizeof(XineramaScreenInfo) * (*xin_nscreens));
+ for (m = 0; m *xin_nscreens; ++m)
+ {
+ screens[m].screen_number = m;
+ screens[m].x_org = monitors[m].x;
+ screens[m].y_org = monitors[m].y;
+
Re: Solaris Xinerama support
Dan Espen wrote: I guess I can answer my own question, it configures but doesn't compile: gcc -DHAVE_CONFIG_H -I. -I../../version-2_5_11/libs -I.. -I../../version-2_5_11 -I/opt/public/include -I/usr/openwin/include -I/opt/public/include -g -O2 -Wall -Wno-implicit-int -c ../../version-2_5_11/libs/FScreen.c ../../version-2_5_11/libs/FScreen.c:74: X11/extensions/xinerama.h: No such file or directory You can send any additional patches to the list. I'm not sure what to do to fix that. I suppose there may be some way to check for the header in configure, and if it's not present (Solaris 7 11/99, or Solaris 8) I could just sub in the contents. They're quite minimal. This seem to objectionable to people? - Chris -- 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: Solaris Xinerama support
Dan Espen wrote: Didn't you say the Sol 9/10 header would work on Sol 8. Why not make the header required. If someone wants Xinerama on Sol 8, make them supply the header. It does, but it seems like having the xinerama support enabled with no user effort for Solaris 8 users would be worth having. You don't need to be an admin, or even very smart, to build a window manager. Making sure you can put an extension somewhere and have auto-conf'd programs find them requires more of the user. It only requires putting 4 lines in FScreen.c. One #def, and three prototypes. Actually, we're only using two of the functions, so we could take out the other prototype. - Chris -- 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]
Solaris Xinerama support
Okay. I don't know how many of you know this, but Solaris ships
an Xsun that has Xinerama support in it (as of the last dist.
of Solaris 7). *But*, in typical Sun Microsystems style, there
is no Xinerama library, nor header file.
So, in doing some research, it appears there are a few functions
in libXext, that while providing a totally different API, will
allow the needed access to the Xinerama extension in the server.
So, I updated acconfig.h, configure.in, fvwm/fvwm.c (which
is an avoidable change, if you want to ignore it), and
libs/FScreen.c.
Patch for the above is attached. Should I gen diffs to
configure and config.h.in, or will those get taken care
of (either automatically, or by someone else with the blessed
autoconf installation)?
Thanks...
- Chris
Index: acconfig.h
===
RCS file: /home/cvs/fvwm/fvwm/acconfig.h,v
retrieving revision 1.72
diff -u -u -r1.72 acconfig.h
--- acconfig.h 8 Jul 2004 10:08:09 - 1.72
+++ acconfig.h 13 Aug 2004 15:31:23 -
@@ -32,6 +32,9 @@
/* Define if Xinerama library is used. */
#undef HAVE_XINERAMA
+/* Define if Solaris' Xinerama calls are being used. */
+#undef HAVE_SOLARIS_XINERAMA
+
/* Define if Xrender library is used. */
#undef HAVE_XRENDER
Index: configure.in
===
RCS file: /home/cvs/fvwm/fvwm/configure.in,v
retrieving revision 1.294
diff -u -u -r1.294 configure.in
--- configure.in23 May 2004 16:20:23 - 1.294
+++ configure.in13 Aug 2004 15:31:23 -
@@ -298,9 +298,13 @@
$UNSET ac_cv_lib_Xinerama_XineramaIsActive
AC_CHECK_LIB(Xinerama, XineramaIsActive,
with_xinerama=yes; Xinerama_LIBS=-lXinerama; AC_DEFINE(HAVE_XINERAMA),
+AC_CHECK_LIB(Xext, XineramaGetState,
+with_xinerama=yes; Xinerama_LIBS=-lXext; AC_DEFINE(HAVE_XINERAMA)
+AC_DEFINE(HAVE_SOLARIS_XINERAMA)
+problem_xinerama= (Using Solaris Xinerama calls),
with_xinerama=no; Xinerama_LIBS=
problem_xinerama=: Failed to detect libXinerama,
-[$X_LIBS $X_PRE_LIBS -lXext -lX11 $X_EXTRA_LIBS])
+[$X_LIBS $X_PRE_LIBS -lXext -lX11 $X_EXTRA_LIBS]))
fi
AC_SUBST(Xinerama_LIBS)
AC_SUBST(Xinerama_CFLAGS)
Index: fvwm/fvwm.c
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/fvwm.c,v
retrieving revision 1.368
diff -u -u -r1.368 fvwm.c
--- fvwm/fvwm.c 15 Jul 2004 13:12:28 - 1.368
+++ fvwm/fvwm.c 13 Aug 2004 15:31:23 -
@@ -1312,6 +1312,9 @@
strcat(support_str, Bidi text,);
#endif
#ifdef HAVE_XINERAMA
+# ifdef HAVE_SOLARIS_XINERAMA
+ strcat(support_str, [Solaris' odd-ball]);
+# endif
strcat(support_str, Xinerama,);
#endif
#ifdef HAVE_XRENDER
Index: libs/FScreen.c
===
RCS file: /home/cvs/fvwm/fvwm/libs/FScreen.c,v
retrieving revision 1.22
diff -u -u -r1.22 FScreen.c
--- libs/FScreen.c 17 Mar 2004 14:42:54 - 1.22
+++ libs/FScreen.c 13 Aug 2004 15:31:23 -
@@ -69,8 +69,54 @@
#include PictureBase.h
#ifdef HAVE_XINERAMA
-#define FScreenHaveXinerama 1
-#include X11/extensions/Xinerama.h
+# define FScreenHaveXinerama 1
+# ifdef HAVE_SOLARIS_XINERAMA
+# include X11/extensions/xinerama.h
+typedef struct
+{
+ int screen_number;
+ short x_org;
+ short y_org;
+ short width;
+ short height;
+} XineramaScreenInfo;
+# define XineramaIsActive(d) XineramaGetState((d),0)
+# define XineramaQueryScreens(d,b)solaris_XineramaQueryScreens((d),(b))
+# define XineramaQueryExtension(d,b,c)1 /* Lie, for now */
+static XineramaScreenInfo *
+solaris_XineramaQueryScreens(Display *d, int *xin_nscreens)
+{
+ XineramaScreenInfo *screens = NULL;
+ XRectangle monitors[MAXFRAMEBUFFERS];
+ unsigned char hints[16];
+
+ int result = XineramaGetInfo(d, DefaultScreen(d), monitors, hints,
+xin_nscreens);
+ if (result)
+ {
+ int m;
+
+ screens = (XineramaScreenInfo
*)malloc(sizeof(XineramaScreenInfo) * (*xin_nscreens));
+ for (m = 0; m *xin_nscreens; ++m)
+ {
+ screens[m].screen_number = m;
+ screens[m].x_org = monitors[m].x;
+ screens[m].y_org = monitors[m].y;
+ screens[m].width = monitors[m].width;
+ screens[m].height = monitors[m].height;
+ }
+ }
+ else
+ {
+ fprintf(stderr, Error getting Xinerama information\n);
+ *xin_nscreens = 0;
+ }
+
+ return (screens);
+}
+# else /* Must be XFree86 Xinerama */
+# include X11/extensions/Xinerama.h
+# endif
#else
#define FScreenHaveXinerama 0
typedef struct
Re: Solaris Xinerama support
Chris Ross wrote: Okay. I don't know how many of you know this, but Solaris ships an Xsun that has Xinerama support in it (as of the last dist. of Solaris 7). *But*, in typical Sun Microsystems style, there is no Xinerama library, nor header file. Oops. I should've mentioned that this patch was tested with Solaris 8, but will only work on Solaris 8 with the X11/extensions/xinerama.h header copied from Solaris 9. Solaris' 9 and 10 ship with this header in place, so will work with no additional effort. That should be noted somewhere, I'm sure. :-) - Chris -- 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]
bin/fvwm-root.c won't compile
It looks like Dominik changed the return type of SetRootWindow from void to int, but failed to change the prototype on line 24. This should be fixed. Thanks! - Chris -- 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: Somthing broken in fvwm-snap-20040608!
I would argue that while it's harder to do, it should prefer most specific, rather than either earliest or latest. ie, if something requests M, and something else A, then it should respond to M, and only A when there isn't a specific binding for the modifiers in use. Should M match when Ctrl-Meta is down? Does that work currently? Or will that match only Meta? This complicates the above, but it can be done either way... - Chris Scott Smedley wrote: Note: this thread moved to fvwm-workers list. : - Key binding in the Root context won't work, for example : Key F1 RMExec exec rxvt : it won't start rxvt but pop up the default menu instead. : - StrokeFunc in the Root crashes X, for example: : Mouse 1 RNStrokeFunc DrawMotion FeedBack StrokeWidth 2 : now when you click the Root, you'll exit X and there is no error msg. I've not used Stroke, but I changed the mouse binding to: Mouse 1 R N Echo myMouse1BindingInvoked for testing. In both instances I found the bindings to be ignored. This was because FVWM defines default bindings for the F1 key left mouse button. They are: Key F1 R A Popup MenuFvwmRoot Mouse 1 R A Menu MenuFvwmRoot If I do a: Key F1 R A - Mouse 1 R A - Both bindings are successfully invoked when expected. So the question is: what's changed? The binding list used to use the _earliest_ matching binding. The current implementation uses the _latest_ matching binding. It would be trivial to make it utilise the _earliest_ binding, however I am undecided if this is really the behaviour we want. The current previous implementation match on (in this example) F1 bindings with 'A' (any) modifier or 'M' (meta) modifier. ie. they match on _both_ bindings, its just which one appears first/last (depending on implementation) in the internal binding list that gets invoked. Should I extend the binding-comparison code to discrimiate on the modifiers further? (Dominik, I hope you're reading this? :) ie. choose 'M' modifier bindings (if they exist) before 'A' modifier bindings if the 'M' modifier is actually pressed. I should have renamed this thread degrees of matchingness! :) SCoTT. :) -- 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] -- 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: Enhancement to FvwmIconMan
Dominik Vogt wrote: Cool. I'll apply the patch shortly. Can you provide something for the NEWS and AUTHORS files too? (and ChangeLog, and Modules/ChangeLog) Done. I also updated the entry in FvwmIconMan.1, which I realized I hadn't updated since putting in your suggestions, and making negative values work. (I'm not 100% sure that using 0 for ReliefThickness will cause TitleButtons to be flat. But I think so. Anyone have a better idea if TitleButtons are different than the other classes of buttons?) Thanks! - Chris Index: ChangeLog === RCS file: /home/cvs/fvwm/fvwm/ChangeLog,v retrieving revision 1.2472 diff -u -u -r1.2472 ChangeLog --- ChangeLog 19 Mar 2004 16:39:54 - 1.2472 +++ ChangeLog 19 Mar 2004 17:19:04 - @@ -49,6 +49,11 @@ (__place_window): renamed function +2004-03-15 Chris Ross [EMAIL PROTECTED] + + * libs/Graphics.c (do_relieve_rectangle_with_rotation) + allow a negative line_width to invert the relief + 2004-03-06 Marcus Lundblad [EMAIL PROTECTED] * libs/Flocale.c (FlocaleDrawString) Index: NEWS === RCS file: /home/cvs/fvwm/fvwm/NEWS,v retrieving revision 1.514 diff -u -u -r1.514 NEWS --- NEWS19 Mar 2004 16:39:54 - 1.514 +++ NEWS19 Mar 2004 17:19:04 - @@ -13,7 +13,7 @@ * New BugOpts option ExplainWindowPlacement. -* Inverted button reliefs in FvwmIconMan. +* Adjustable button reliefs in FvwmIconMan (option ReliefThickness). * Security patch in fvwm-bug. See http://securitytracker.com/alerts/2004/Jan/1008781.html Index: AUTHORS === RCS file: /home/cvs/fvwm/fvwm/AUTHORS,v retrieving revision 1.90 diff -u -u -r1.90 AUTHORS --- AUTHORS 15 Mar 2004 15:53:16 - 1.90 +++ AUTHORS 19 Mar 2004 17:19:04 - @@ -235,6 +235,9 @@ Autoconf automake support, configuration portability improvements, and general code gadfly a la Paul Smith. +Chris Ross: +Addition of ReliefThickness feature to FvwmIconMan. + Paul D. Smith: Purify support (heap rot, array overwrites, memory stompage of all sorts). Some autoconf/automake/portability help. Initial cut at a Index: modules/ChangeLog === RCS file: /home/cvs/fvwm/fvwm/modules/ChangeLog,v retrieving revision 1.1106 diff -u -u -r1.1106 ChangeLog --- modules/ChangeLog 19 Mar 2004 09:50:18 - 1.1106 +++ modules/ChangeLog 19 Mar 2004 17:19:07 - @@ -1,7 +1,15 @@ -2004-03-19 Dominik Vogt [EMAIL PROTECTED] +2004-03-15 Chris Ross [EMAIL PROTECTED] - * FvwmIconMan/FvwmIconMan.c: - applied inverted relief patch by Chris Ross + * FvwmIconMan/FvwmIconMan.1: + * FvwmIconMan/FvwmIconMan.h: + * FvwmIconMan/globals.c (init_win_manager): + * FvwmIconMan/readconfig.c (read_in_resources): + * FvwmIconMan/xmanager.c (draw_3d_icon) + (draw_relief): + Added ReliefThickness option to FvwmIconMan to control + the width of the relief used for both icon manager buttons + and icons. Works much the same as the Frame specification + of FvwmButtons. 2004-03-15 Dominik Vogt [EMAIL PROTECTED] Index: modules/FvwmIconMan/FvwmIconMan.1 === RCS file: /home/cvs/fvwm/fvwm/modules/FvwmIconMan/FvwmIconMan.1,v retrieving revision 1.28 diff -u -u -r1.28 FvwmIconMan.1 --- modules/FvwmIconMan/FvwmIconMan.1 19 Mar 2004 09:50:18 - 1.28 +++ modules/FvwmIconMan/FvwmIconMan.1 19 Mar 2004 17:19:07 - @@ -252,11 +252,13 @@ still only be applied with plainbutton. See FvwmTheme. .IP *FvwmIconMan: [id] ReliefThickness \fInum\fP -\fInum\fP is a positive integer specifying the number of pixels thick -that the relief at the edge of non-flat buttons should be. This has -no effect on flat buttons. In theory, you should be able to set this -to a negative number and have it act like \fIReverse\fP, but negative -numbers don't work. This may change later. +\fInum\fP is an integer specifying the number of pixels thick +that the relief at the edge of non-flat buttons should be. Setting +this to 0 will produce flat buttons, as if the values for +\fIFocusAndSelectButton\fP, \fIFocusButton\fP, \fIIconButton\fP, +\fIPlainButton\fP, \fISelectButton\fP, and \fITitleButton\fP were +all set to \fIflat\fP. If \fInum\fP is negative, the button +will be inverted as if you had used \fIReverse\fP for all classes. .IP *FvwmIconMan: [id] Resolution \fIresolution\fP Specifies when the manager will display an entry for a certain
Re: fvwm-root failure
Olivier Chapuis wrote: On Fri, Feb 20, 2004 at 11:38:34AM -0500, Chris Ross wrote: [ limits on shm usage cause fvwm-root to fail ] I will fix this bug this week-end. Normaly, if shm fail fvwm-root use normal XImage, but it seems that there is miss-print somewhere (a cast problem I think). Thank you very much! Would much appriciate it. - Chris -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
fvwm-root failure
Hi. I'm running a solaris 8 system, with the installed openwin X server, and fvwm-root is failing with a shared memory error on my machine. I looked into it, and it's a error returned from shmget() somewhere in the X libraries. The X error being displayed is: X Error of failed request: BadAccess (attempt to access private resource denied) Major opcode of failed request: 131 (MIT-SHM) Minor opcode of failed request: 1 (X_ShmAttach) Serial number of failed request: 10 Current serial number in output stream: 11 Looking at the system calls, it appears that shmget() is returning EINVAL when it's being called to create a 5+ MB memory segment. In reading documentation, I see that the system default maximum size for shared memory is 1MB. I realize my fvwm-root is trying to ask for a little over 5MB, but, doing some math, even a 1024x768 screen at 16-bit pixmap-depth will produce an X Pixmap that is 1.5MB in size. Perhaps there should be another way to load this? Is this just a solaris bogosity? Can we interact with the MIT-SHM extension directly to check on things? - Chris -- 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: Enhancement to FvwmIconMan
Dominik Vogt wrote: The patch looks nice and simple, and I think I will apply it. My only concern is that it does not do any boundary checks. Reasonable. I can add some boundary-checking. It should: - Check for negative and zero thickness. I didn't want to do this, because I thought that those were reasonable. Zero works, and behaves as you would expect. It makes the button flat. Do you want me to explicitly disallow this method of making the button flat, so that it must be done as a button style? As to negative, that doesn't work as expected, but I would've expected that to act as Reverse causes, and if it worked should be valid. I also asked for any help in figuring out why that doesn't work. Do you want me to just ignore it, so that if you want them sunken, you must Reverse either icon or normal? This prevents you from being able to reverse all states, correct? What if someone wanted to do that? - Limit the thickness to what fits in a button (you do not want to allow relief thickness 25000 in a button that is 10 pixels high). Right. This is reasonable. I'll take a look at how to do this... Please post replies below the quoted portions original mail on this list. Can do. :-) Thanks for the policy statement. - Chris -- 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: Enhancement to FvwmIconMan
Hey there. Any feedback on this? Dominik: I see you're committing things that aren't bug fixes, so that means you're accepting new functionality for the post-2.6 work? Any issue with checking in this patch? Thanks... - Chris Chris Ross wrote: I have an FvwmIconMan inside of FvwmButtons. I was changing the Frame definition for various buttons, and wanted to change the relief width on the buttons in FvwmIconMan, and was suprised to find there was no way to do that. They're just 2. Always 2. So, I fixed this. They still default to two, but I added a ReliefThickness keyword to FvwmIconMan. -- 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]
Enhancement to FvwmIconMan
I know there's no good reason to stick this in beofre 2.6, but it's
a simple enough patch, can it be committed for inclusion after 2.6?
I have an FvwmIconMan inside of FvwmButtons. I was changing the
Frame definition for various buttons, and wanted to change the
relief width on the buttons in FvwmIconMan, and was suprised to find
there was no way to do that. They're just 2. Always 2.
So, I fixed this. They still default to two, but I added a
ReliefThickness keyword to FvwmIconMan. You can set it to 0,
as another way to get flat buttons, or to a positive integer to
have the button-reliefs be that many pixels wide/thick. I don't
know why you can't make it negative to get the equivalent of Reverse
buttons, but that doesn't work. I don't think it's important to
fix, but I'd be happy for anyone else to fix it.
Again, the default after this patch will be the same. 2 pixels.
But you can now change it. (I've set mine to 1).
Thanks. Let me know when this can get checked in, and when
that change will hit a release. Much appriciated.
- Chris
Index: modules/FvwmIconMan/FvwmIconMan.1
===
RCS file: /home/cvs/fvwm/fvwm/modules/FvwmIconMan/FvwmIconMan.1,v
retrieving revision 1.27
diff -u -u -r1.27 FvwmIconMan.1
--- modules/FvwmIconMan/FvwmIconMan.1 19 Apr 2003 03:01:02 - 1.27
+++ modules/FvwmIconMan/FvwmIconMan.1 10 Feb 2004 18:39:38 -
@@ -108,6 +108,7 @@
NoIconActionanimate iconification NOP
PlainButton style for normal buttons up black grey
PlainColorset
+ReliefThickness size of button relief 2
Resolution global/desk/page/screenpage
Reverse normal, icon or none none
SelectButtonstyle for selected buttons flat black grey
@@ -249,6 +250,13 @@
.IP *FvwmIconMan: [id] PlainColorset \fIcolorset\fP
Works like plainbutton but uses colorsets instead. The style setting can
still only be applied with plainbutton. See FvwmTheme.
+
+.IP *FvwmIconMan: [id] ReliefThickness \fInum\fP
+\fInum\fP is a positive integer specifying the number of pixels thick
+that the relief at the edge of non-flat buttons should be. This has
+no effect on flat buttons. In theory, you should be able to set this
+to a negative number and have it act like \fIReverse\fP, but negative
+numbers don't work. This may change later.
.IP *FvwmIconMan: [id] Resolution \fIresolution\fP
Specifies when the manager will display an entry for a certain
Index: modules/FvwmIconMan/FvwmIconMan.h
===
RCS file: /home/cvs/fvwm/fvwm/modules/FvwmIconMan/FvwmIconMan.h,v
retrieving revision 1.55
diff -u -u -r1.55 FvwmIconMan.h
--- modules/FvwmIconMan/FvwmIconMan.h 25 Aug 2003 06:47:09 - 1.55
+++ modules/FvwmIconMan/FvwmIconMan.h 10 Feb 2004 18:39:38 -
@@ -303,6 +303,7 @@
Uchar showonlyiconic;
Uchar showtransient;
rectangle managed_g;/* dimensions of managed screen portion */
+ int relief_thickness; /* relief thickness for each non-flat button */
/* X11 state */
Window theWindow, theFrame;
Index: modules/FvwmIconMan/globals.c
===
RCS file: /home/cvs/fvwm/fvwm/modules/FvwmIconMan/globals.c,v
retrieving revision 1.25
diff -u -u -r1.25 globals.c
--- modules/FvwmIconMan/globals.c 29 Jun 2003 19:53:25 - 1.25
+++ modules/FvwmIconMan/globals.c 10 Feb 2004 18:39:38 -
@@ -83,6 +83,7 @@
globals.managers[id].we_are_drawing = 1;
globals.managers[id].showonlyiconic = 0;
globals.managers[id].showtransient = 0;
+ globals.managers[id].relief_thickness = 2;
}
void print_managers(void)
Index: modules/FvwmIconMan/readconfig.c
===
RCS file: /home/cvs/fvwm/fvwm/modules/FvwmIconMan/readconfig.c,v
retrieving revision 1.55
diff -u -u -r1.55 readconfig.c
--- modules/FvwmIconMan/readconfig.c5 Jul 2003 01:37:47 - 1.55
+++ modules/FvwmIconMan/readconfig.c10 Feb 2004 18:39:39 -
@@ -1951,6 +1951,19 @@
ConsoleDebug(CONFIG, Setting usewinlist to: %d\n, i);
SET_MANAGER(manager, usewinlist, i);
}
+ else if (!strcasecmp(option1, reliefthickness)) {
+ p = read_next_cmd(READ_ARG);
+ if (!p) {
+ ConsoleMessage(Bad line: %s\n, current_line);
+ continue;
+ }
+ if (extract_int(p, n) == 0) {
+ ConsoleMessage(This is not a number: %s\n, p);
+ ConsoleMessage(Bad line: %s\n, current_line);
+ continue;
+ }
+ SET_MANAGER(manager, relief_thickness, n);
+ }
else {
ConsoleMessage(Bad line: %s\n, current_line);
ConsoleMessage(Unknown option: %s\n, p);
Index: modules/FvwmIconMan/xmanager.c
===
RCS file:
Description and patches for proposed new feature
[EMAIL PROTECTED] wrote; in a message with the subject Re: How do I redraw menuitems in an active menu?: Why don't you post your patch so that I can take a look (include instructions to show the problem). Well, as it happens, I figured out the problem with modifying the menu item. It was just an issue of the code not clearing the menuitem window area before drawing a substring. I got that fixed now, so it clears the whole area before drawing in the case of the new feature I added. Okay, included here are a description and patches for the new keyword I added. This keyword will allow me to define menuitems that change based on modifier key-presses. The patch is based on the HEAD of the CVS tree as of today (14-Jan-2004). Much feedback welcome from all! Please, let me know any thoughts you have! Thanks! - Chris The new ModSwitch keyword - This is intended to solve a problem I've been looking to solve. I sometimes have menu items duplicated, with only one minor change (as an example, ssh'ing into a remote host, one without X port forwarding, one with.) What I decided the cleanest solution would be, to reduce the size of my menu's, would be to have menuitems that would have different labels and/or actions when you held a modifier key. To implement this, my first pass was the here-described ModSwitch keyword. When used as follows: AddToMenu RemoteLogins Menu Title + Tomcat ModSwitch N ( Exec exec xterm -e ssh tomcat ) \ S ( w/ X fwd Exec exec xterm -e ssh -R 6000:127.0.0.1:6000 tomcat ) + Sphynx Exec exec xterm -e ssh sphynx Would cause the top [non-Title] menuitem in that menu to ssh in without extra command line args, unless you hold Shift, in which case it will do X forwarding through 127.0.0.1. This syntax is just what I came up with. If anyone has any better ideas for syntax, then please convince me. I'd be happy to change it if a better option presents itself. Caveats/ToDo's: - When the menu draws, the correct string isn't displayed until you move the mouse into the menu. I must be missing a place where I should put a call to dink with the menuitems. - When you hold modifiers that don't match any listed ones, it maintains the previous state, instead of doing something else. Should there be a concept of a default? Same as N? - I only mess with label[0]. Why do MenuItems even have an array of labels? I couldn't figure that out while I was in there... - I don't pre-initialize the label or action when the config is parsed. So, for a little while, ModSwitch is the action. I've got it mapped to CMD_Beep right now, since it shouldn't really do anything as an action or command, but. Perhaps I should just ensure that it can never be called in the first place by reconfiguring action and label when it's initially scanned. - I'm not careful to figure out how to initialize or not, and free if necessary, the copies of the original label and action. - Right now the top-level label (before the ModSwitch keyword) is a base, and the other string it appended to it. You could do at top, and use the new string in each mod-switch-spec, to do whole replacement. Should I code it to work that way instead? This falls back under syntax... Anyway. Lots of questions, and I'd love to hear opinions... - Chris Ross [EMAIL PROTECTED] 14-Jan-2004 Index: fvwm/commands.h === RCS file: /home/cvs/fvwm/fvwm/fvwm/commands.h,v retrieving revision 1.41 diff -u -p -u -r1.41 commands.h --- fvwm/commands.h 16 Jul 2003 09:10:40 - 1.41 +++ fvwm/commands.h 14 Jan 2004 17:32:15 - @@ -80,6 +80,7 @@ enum F_LAYER, F_LOCALE_PATH, F_MENUSTYLE, + F_MOD_SWITCH, F_MODULE, F_MODULE_PATH, F_MODULE_SYNC, Index: fvwm/functable.c === RCS file: /home/cvs/fvwm/fvwm/fvwm/functable.c,v retrieving revision 1.29 diff -u -p -u -r1.29 functable.c --- fvwm/functable.c16 Jul 2003 09:10:40 - 1.29 +++ fvwm/functable.c14 Jan 2004 17:32:15 - @@ -348,6 +348,9 @@ const func_t func_table[] = CMD_ENT(menustyle, CMD_MenuStyle, F_MENUSTYLE, 0, 0), /* - Control appearance and behavior of a menu */ + CMD_ENT(modswitch, CMD_Beep, F_MOD_SWITCH, 0, 0), + /* - Never called directly; sets up menu entry based on modif. keys */ + CMD_ENT(module, CMD_Module, F_MODULE, 0, 0), /* - Invoke an fvwm module */ Index: fvwm/menuitem.c === RCS file: /home/cvs/fvwm/fvwm/fvwm/menuitem.c,v retrieving revision 1.32 diff -u -p -u -r1.32 menuitem.c --- fvwm/menuitem.c 29 Jun 2003 19:53:23 - 1.32 +++ fvwm/menuitem.c 14 Jan 2004 17:32:15 - @@ -150,6
fvwm 2.5.8+ FvwmPager problem
Hi. I'm having a slight problem I can't figure out with respect to running something from near the head of the CVS tree, which reports itself as 2.5.9. On 2.4.4, FvwmPager seems to take the Color (call its argument A/B) that I have specified in 'Style *' as the background color of non-highlighted windows. But, under 2.5.9, this doesn't work. They are currently white (#FF) backgrounds, with a B foreground color. So, it's clearly getting *something* from the Style * Color arg, but not getting it right. It should be noted that this is not a problem in the inactive window borders and titlebars, just in FvwmPager. Is this a FvwmPager bug? - Chris -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: fvwm 2.5.8+ FvwmPager problem
Doh. Ignore this. It was my fault. It was running the old Fvwm 2.4.4 FvwmPager module, not the current one. It works just fine with the current module. Sorry for the excess email... :-) - Chris Chris Ross wrote: Hi. I'm having a slight problem I can't figure out with respect to running something from near the head of the CVS tree, which reports itself as 2.5.9. On 2.4.4, FvwmPager seems to take the Color (call its argument A/B) that I have specified in 'Style *' as the background color of non-highlighted windows. But, under 2.5.9, this doesn't work. They are currently white (#FF) backgrounds, with a B foreground color. So, it's clearly getting *something* from the Style * Color arg, but not getting it right. It should be noted that this is not a problem in the inactive window borders and titlebars, just in FvwmPager. -- 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]
How do I redraw menuitems in an active menu?
Hey there. I'm trying to add a new feature that I'd been looking for, and have it mostly working. I would like to be able to bind certain menuitems to react differently if you're holding down a modifier. I've developed a syntax for this, by way of a whole new menuitem type. And, when I open the menu, it maps correctly. And when I hold down the shift key, it adds the suffix to the normal menuitem label ([0]). However, when I release that modifier, it doesn't revert as it should, until I pass over it with my mouse thus highlighting and dehilighting that item. Does anyone know what I'm doing wrong? I'm modifying things in the MenuItem* directly, and then calling: get_menu_paint_item_parameters(mpip, mr, mi, NULL, NULL, False); menuitem_paint(mi, mpip); As noted, it works just fine when I'm appending to the previous label, but not when I changing the label to the previous shorter string. Perhaps I'm misunderstanding what the array of labels are to be used for? Why are there an array of labels? In what situation would they be used? Thanks. Any help would be appriciated... - Chris -- 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]
