CVS dane: * fvwm-menu-xlock.1:
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: dane02/02/01 20:11:42 Modified files: modules: ChangeLog modules/FvwmCpp: FvwmCpp.1 modules/FvwmDragWell: FvwmDragWell.1 modules/FvwmIconMan: FvwmIconMan.1 modules/FvwmIdent: FvwmIdent.1 modules/FvwmM4 : FvwmM4.1 modules/FvwmPager: FvwmPager.1 modules/FvwmSave: FvwmSave.1 modules/FvwmScript: FvwmScript.1 modules/FvwmScroll: FvwmScroll.1 modules/FvwmWinList: FvwmWinList.1 utils : ChangeLog fvwm-menu-desktop.1 fvwm-menu-directory.1 fvwm-menu-headlines.1 fvwm-menu-xlock.1 Log message: * fvwm-menu-xlock.1: * fvwm-menu-headlines.1: * fvwm-menu-directory.1: * fvwm-menu-desktop.1: fvwmrc -> .fvwm2rc * FvwmWinList/FvwmWinList.1: * FvwmScroll/FvwmScroll.1: * FvwmScript/FvwmScript.1: * FvwmSave/FvwmSave.1: * FvwmPager/FvwmPager.1: * FvwmM4/FvwmM4.1: * FvwmIconMan/FvwmIconMan.1: * FvwmDragWell/FvwmDragWell.1: * FvwmCpp/FvwmCpp.1: .fvwmrc -> .fvwm2rc -- 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: FVWM: Click in a window raises, move marks, can I?
On Fri, Feb 01, 2002 at 05:21:17PM +0100, Dominik Vogt wrote: > > I have also noticed that in the CVS version, GrabFocusTransient seems > > to default to off, even though the manual still says it's on by default. > > And it should be on by default. The ConfigFvwmDefaults file has > this line: > > Style * GrabFocusTransient, LowerTransient, RaiseTransient, > StackTransientParent > > So probably ConfigFvwmDefaults is not installed properly on your > site. Yes, you're right of course. I was trying out the freshly compiled fvwm from the source dir so ConfigFvwmDefaults wasn't found. I seems to me however that the combination of MouseFocusClickRaises and MouseFocusClickIgnoreMotion is a little undeterministic. If I select text in one xterm, which is on top and then click on another xterm, it raises but selection is kept. However, if I then click on the first xterm again, it raises but selection is lost. Not really a problem, but it would be neater to have an option which sets this, either the click is passed to the window that is raised or it isn't. I also would really like a configurable MouseFocusClickRaises, to choose which button(s) raises... -- 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: CHARSET environment variable
On Fri, Feb 01, 2002 at 04:01:33PM +0600, Dmitry Yu. Bolkhovityanov wrote: > On Fri, 1 Feb 2002, Olivier Chapuis wrote: > > > So nl_langinfo and iconv should not be used :o) but it does not > > seem that there are obvious (portable) replacement (XFree >=4.0.2 > > has some Xutf8 functions, we may try to use if available). > > Please, please, please don't use Xutf8*() functions -- they are > absolutely unportable. They were introduced due to the inadequacy (sp?) > of the current X locale model: only one locale at one moment, so Xutf8*() > are "current-locale"-independent. But their unportability completely > outweighs their advantage. > Do there are bad or only unprotable? If there are bad only because there are not protable this may be fixed as xterm do: xterm has a file with these functions in the case the "locale" Xlib does not have it (xterm -u8 work fine with XFree-3.3.6 and old glibc). What happen is that for ewmh support fvwm should deal with utf8 strings for window names: a window can gives its names with an UTF-8 string and fvwm should set on the window the names that it really used in UTF-8 (this name may be different form the original window name: xterm, xterm (1), xterm (2) ...). Moreover, more and more utf-8 strings will appear in the future. So now what we should do for performing conversion? In the average (lib)iconv seems to give good result but it speaks an other language than X. Maybe the Xutf8* function may help at some points? Any other ideas? Also what to do for displaying directly utf8 strings (with a libc which does not support utf8 locales)? Is XRender/Xft can do that? Really any suggestion is welcome. But, any way at the present time the most important thing is to centralize all the fvwm text rendering and locale stuff in 2 or 3 libs file so that we can really works on all this locale stuff which is a real (interesting) mess IMHO. Olivier -- 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: request for IncludePath
Peder Stray <[EMAIL PROTECTED]> writes: > Dan Espen <[EMAIL PROTECTED]> writes: > > > Is there a reason you don't want to put the global stuff in > > FVWM_DATADIR? > > up to seven differen flavours of unix, spred over 2-3 different > locations. i would think it would be nicer to keep our sitewide setup > seperate from files installed by fvwm. I think you'll find that PipeRead is the best way to deal with multiple UNIX flavors and common configuration files. -- Dan Espen 444 Hoes Lane Room RRC 1C-214 E-mail: [EMAIL PROTECTED] Piscataway, NJ 08854 Phone: (732) 699-5570 -- 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: CHARSET environment variable
Olivier Chapuis <[EMAIL PROTECTED]> writes: > On Thu, Jan 31, 2002 at 09:41:39PM -0500, Dan Espen wrote: > > > > I have multibyte enabled. > > With the latest CVS I get this warning: > > > > [FVWM][FInitCharset]: WARN -- Cannot get charset with CHARSET env variable > > > > Where do I find the documentation on this env variable? > > > > Hum, I do not know if there is a documentation somewhere. This variable > is used by some programs in the gnu world to get the charset associated > to your locale if your libc does not have nl_langinfo which can do the > job (it seems that you do not have nl_langinfo). It can also be used to > override the charset returned by nl_langinfo. > Now, it is not used in mb support but in the ewmh support for iconv > conversion from/to UTF-8 and your charset. If you have iconv > you can get the list of charsets by using "iconv --list". > There are multiple problems here: > > 1 - FInitCharset is run by fvwm even if you do not have iconv > support (easy to fix). > 2 - nl_langinfo may return a different charset than the "X charset". > 3 - iconv is not an X function. > > So nl_langinfo and iconv should not be used :o) but it does not > seem that there are obvious (portable) replacement (XFree >=4.0.2 > has some Xutf8 functions, we may try to use if available). > I will try to fix these problems progressively. I begin to understand > the X i18n stuff. Any way these problems are small and these concern > only applications with ewmh support (but these should be fixed). I looked at the various codesets iconv supports to try to figure out a default value. It looks like if CHARSET is not set, is should default to ISO_8859-1 (on Linux). On Solaris and AIX, the default should be ISO8859-1. On HPUX, it looks like it should be either "amere", "iso81", or "engle". I'd be happy if it just didn't print any warning. -- Dan Espen 444 Hoes Lane Room RRC 1C-214 E-mail: [EMAIL PROTECTED] Piscataway, NJ 08854 Phone: (732) 699-5570 -- 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 to enable dynamic FvwmButton button titles
Hi All,
Here's a patch to make FvwmButtons understand this:
FvwmCommand "SendToModule FvwmButtons Title 5 You have Mail!"
Buttons are numbered from 0 and are in the order in your config file
(containers don't count). It only works with buttons that have a title
in the config file (could be " ") and I haven't tested it with anything
other than a simple button (just a title, no icon or swallows).
I've stuffed the new code into FvwmButtons.c which is probably the wrong
place.
Cheers,
Tim.
PS I think I can get rid of all my swallowed (non-fvwm) apps except
xload with this.
Index: modules/FvwmButtons/FvwmButtons.c
===
RCS file: /u/phippst/share/cvsroot/fvwm/modules/FvwmButtons/FvwmButtons.c,v
retrieving revision 1.18
diff -u -r1.18 FvwmButtons.c
--- modules/FvwmButtons/FvwmButtons.c 2002/02/01 14:28:11 1.18
+++ modules/FvwmButtons/FvwmButtons.c 2002/02/01 16:01:53
@@ -110,6 +110,7 @@
void process_message(unsigned long type,unsigned long *body);
extern void send_clientmessage (Display *disp, Window w, Atom a,
Time timestamp);
+void parse_message_line(char *line);
void CheckForHangon(unsigned long*);
static Window GetRealGeometry(
Display*,Window,int*,int*,unsigned int*,unsigned int*, unsigned int*,
@@ -936,7 +937,7 @@
SetMessageMask(fd, M_NEW_DESK | M_END_WINDOWLIST | M_MAP | M_WINDOW_NAME
| M_RES_CLASS | M_CONFIG_INFO | M_END_CONFIG_INFO | M_RES_NAME
-| M_SENDCONFIG | M_ADD_WINDOW | M_CONFIGURE_WINDOW);
+| M_SENDCONFIG | M_ADD_WINDOW | M_CONFIGURE_WINDOW | M_STRING);
SetMessageMask(fd, MX_PROPERTY_CHANGE);
/* request a window list, since this triggers a response which
@@ -2618,6 +2619,9 @@
swallowed = body[1];
}
break;
+ case M_STRING:
+parse_message_line((char *)&body[3]);
+break;
default:
break;
}
@@ -3076,5 +3080,54 @@
}
break;
}
+ }
+}
+
+/* SendToModule options */
+static void parse_title(char *line)
+{
+ int n, count, i;
+ button_info *b, *ub = UberButton;
+
+ /* find out which button */
+ if (GetIntegerArguments(line, &line, &n, 1) != 1)
+return;
+ if (n < 0)
+ {
+fprintf(stderr, "%s: button number must not be negative\n", MyName);
+return;
+ }
+ i = count = -1;
+ /* find the button */
+ while (NextButton(&ub, &b, &i, 0)) {
+if (++count == n)
+ break;
+ }
+ if (count != n) {
+fprintf(stderr, "%s: button number %d not found\n", MyName, n);
+return;
+ }
+ if (b) {
+if (!b->flags & b_Title) {
+ fprintf(stderr, "%s: cannot create a title, only change one\n", MyName);
+ return;
+}
+free(b->title);
+CopyString(&b->title, line);
+RedrawButton(b, 2);
+ }
+ return;
+}
+
+static char *message_options[] = {"Title", NULL};
+
+void parse_message_line(char *line)
+{
+ char *rest;
+
+ switch(GetTokenIndex(line, message_options, -1, &rest)) {
+ case 0:
+parse_title(rest);
+break;
}
}
Re: FVWM: Click in a window raises, move marks, can I?
On Sun, Jan 20, 2002 at 09:15:56PM +0200, Anssi Saari wrote: > On Sun, Jan 20, 2002 at 07:06:05PM +0100, Dominik Vogt wrote: > > > That not new. MouseFocusClickRaises has always worked with any > > mouse button, not just the button 1. > > OK, it was just my idea that customization of this might be enjoyable, > for the mouse wheel for example. Also some new web browsers jump to a URL > from Selection with mouse-2 click. > > > > I also noticed it's easy to nudge the mouse or click before you stop > > > the mouse completely, so maybe a threshhold setting for what is actually > > > considered moving might be good. > > > > It already uses the threshold defined with the MoveThreshold > > command. > > Ah, of course. > I have also noticed that in the CVS version, GrabFocusTransient seems > to default to off, even though the manual still says it's on by default. And it should be on by default. The ConfigFvwmDefaults file has this line: Style * GrabFocusTransient, LowerTransient, RaiseTransient, StackTransientParent So probably ConfigFvwmDefaults is not installed properly on your site. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- 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: config tool.
"Narendra.M." <[EMAIL PROTECTED]> writes: > hi guys, > > i am developing an x11 based configuration tool for fvwm. its called > fvwmrced it > (sourceforge.net/projects/fvwmrcedit). Fvwm1 hasn't been changed in a very long time. We don't provide any support for Fvwm1. Upgrade to Fvwm2. -- Dan Espen 444 Hoes Lane Room RRC 1C-214 E-mail: [EMAIL PROTECTED] Piscataway, NJ 08854 Phone: (732) 699-5570 -- 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]
CVS dane: * FvwmButtons/FvwmButtons.1: Language fix.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: dane02/02/01 08:06:14 Modified files: modules: ChangeLog modules/FvwmButtons: FvwmButtons.1 Log message: * FvwmButtons/FvwmButtons.1: Language fix. -- 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 olicha fvwm-web: * Documented the MX_PROPERTY_CHANGE and MX_VISIBLE* messages
FVWM CVS writes: > CVSROOT: /home/cvs/fvwm > Module name: fvwm-web > Changes by: olicha 02/01/29 07:17:49 > > Modified files: > . : ChangeLog mod_f2m_communication.html >mod_initialization.html > > Log message: > * WARNING: there is some ... in both files I left a "dont understand" comment in mod_f2m_communication.html. What "id" is it referring to? Use short sentences. -- Dan Espen 444 Hoes Lane Room RRC 1C-214 E-mail: [EMAIL PROTECTED] Piscataway, NJ 08854 Phone: (732) 699-5570 -- 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]
CVS dane fvwm-web: * mod_f2m_communication.html: Language fix.
CVSROOT:/home/cvs/fvwm Module name:fvwm-web Changes by: dane02/02/01 07:28:32 Modified files: . : ChangeLog mod_f2m_communication.html mod_initialization.html Log message: * mod_f2m_communication.html: Language fix. * mod_initialization.html: Language fix. -- 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: FVWM: FVWM configuration.
Dominik Vogt wrote: > > On Thu, Jan 24, 2002 at 08:05:13PM +0530, Narendra.M. wrote: > > Hello guys, > > > > I am working on a configuration tool for FVWM (and similar WMs). Its called > > fvwmrcedit > > and is hosted at SourceForge.net (fvwmrcedit.sourceforge.net). It writes > > and edits fvwmrc > > files and is written using the Xt toolkit and the Athena widget set. I have > > covered basic > > options to some extent and am now working on editing menus (that part is > > not complete). > > Hope you guys will have a look at it and try it out. Thanks in advance. > > We are definitely interested in such a tool. I didn't have time > to look at it yet, but I'll do so as soon as I can. It would be > a good idea to join the fvwm-workers mailing and to discuss the > overall design and how the tool is intended to be integrated with > fvwm. > I'd just like to point out that fvwm already has everything it needs to create a set of configuration gui's due to Dan's enhancements of the FvwmForm module to enable them to read & write to file. A couple of years ago I actually attempted to utilise this method to create a complete config tool but received very little or no interest. Eventually I was persuaded to abandon the project in favour of the new fvwm-themes project, but I'm hoping to now ressurect it to create some gui config tools for fvwm-themes. I attach a simple form to configure the FvwmWinList module as an example. This form is still just an example and should be optimised at some stage but it works. Invoke it normally as Module FvwmForm FvwmForm-WinList then once you have saved your settings it should automatically reload them upon each invocation a la FvwmForm-Form. This method would enable building a config tool without the need for any other software other than fvwm itself. Perhaps FvwmScript's capabilities of swallowing other forms and scripts could be used to keep the suite of gui's tidy? Alex#---# # FvwmForm-WinList by Alex Wallis <[EMAIL PROTECTED]> #---# DestroyModuleConfig FvwmForm-WinList: * *FvwmForm-WinList: WarpPointer *FvwmForm-WinList: Line center *FvwmForm-WinList: Text "Form to configure FvwmWinList" *FvwmForm-WinList: Line center *FvwmForm-WinList: Text "##" *FvwmForm-WinList: Line center *FvwmForm-WinList: Text "Refer \"man FvwmWinList\" for details." *FvwmForm-WinList: Line center *FvwmForm-WinList: Text "Geometry" *FvwmForm-WinList: Input GeomX 6 "" *FvwmForm-WinList: Text "X" *FvwmForm-WinList: Input GeomY 6 "" *FvwmForm-WinList: Text "Y -- Font" *FvwmForm-WinList: Input WLFont 40 "" *FvwmForm-WinList: Line right *FvwmForm-WinList: Text "Colorset" *FvwmForm-WinList: Input ColMain 3 "" *FvwmForm-WinList: Text " ButtonFrameWidth" *FvwmForm-WinList: Input BFWidth 3 "" *FvwmForm-WinList: Text "" *FvwmForm-WinList: Line right *FvwmForm-WinList: Text "FocusColorset" *FvwmForm-WinList: Input ColFocus 3 "" *FvwmForm-WinList: Text " MinWidth" *FvwmForm-WinList: Input MinW 3 "" *FvwmForm-WinList: Text "" *FvwmForm-WinList: Line right *FvwmForm-WinList: Text "IconColorset" *FvwmForm-WinList: Input ColIcon 3 "" *FvwmForm-WinList: Text " MaxWidth" *FvwmForm-WinList: Input MaxW 3 "" *FvwmForm-WinList: Text "" *FvwmForm-WinList: Line center *FvwmForm-WinList: Text "#- Options -#" *FvwmForm-WinList: Line center *FvwmForm-WinList: SelectionOptsmultiple *FvwmForm-WinList: Choice DepFoc DepFoc off "DontDepressFocus" *FvwmForm-WinList: Choice FWList FWList off "FollowWindowList" *FvwmForm-WinList: Choice USList USList off "UseSkipList " *FvwmForm-WinList: Choice SCDesk SCDesk off "ShowCurrentDesk " *FvwmForm-WinList: Line center *FvwmForm-WinList: Choice NoAnch NoAnch off "NoAnchor" *FvwmForm-WinList: Choice UIName UIName off "UseIconNames" *FvwmForm-WinList: Choice LeftJ LeftJ off "LeftJustify " *FvwmForm-WinList: Choice TruncL TruncL off "TruncateLeft" *FvwmForm-WinList: Line center *FvwmForm-WinList: Text "# Actions & Responses #" *FvwmForm-WinList: Line center *FvwmForm-WinList: Text "Click1" *FvwmForm-WinList: InputClk130 "" *FvwmForm-WinList: Text " Click2" *FvwmForm-WinList: InputClk230 "" *FvwmForm-WinList: Line center *FvwmForm-WinList: Text "Click3" *FvwmForm-WinList: InputClk330 "" *FvwmForm-WinList: Text "NoIconAction" *FvwmForm-WinList: Input NoIAct 30 "" *FvwmForm-WinList: Line left *FvwmForm-WinList: Text "" *FvwmForm-WinList: Line expand *FvwmForm-W
Re: request for IncludePath
Dan Espen <[EMAIL PROTECTED]> writes: > Is there a reason you don't want to put the global stuff in > FVWM_DATADIR? up to seven differen flavours of unix, spred over 2-3 different locations. i would think it would be nicer to keep our sitewide setup seperate from files installed by fvwm. -- [ IRL : Peder Stray ] [ "A new life awaits you in the off-world colonies" ] -- 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: request for IncludePath
Peder Stray <[EMAIL PROTECTED]> writes: > Mikhael Goikhman <[EMAIL PROTECTED]> writes: > > > Still you didn't described an example where this would be required. > > I can invent artificial examples, but I want to see a real-life one > > where using FVWM_DATADIR for system stuff and FVWM_USERDIR for > > user's is not enough. > > we (that is Institute for Informatics, University of Oslo, Norway) > have sitewide fvwm setup for all new users. Installed on at least 2 > different architectures as of now... using a highly modularised setup, > where users can customize parts of the setup by making their own files > in FVWM_USERDIR, these would otherwise be included from the global > setup directory (same for all architectures). Other stuff from the > fvwm distribution would be included from FVWM_DATADIR. Is there a reason you don't want to put the global stuff in FVWM_DATADIR? -- Dan Espen 444 Hoes Lane Room RRC 1C-214 E-mail: [EMAIL PROTECTED] Piscataway, NJ 08854 Phone: (732) 699-5570 -- 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: request for IncludePath
On 01 Feb 2002 12:42:24 +0100, Peder Stray wrote: > > Mikhael Goikhman <[EMAIL PROTECTED]> writes: > > > Still you didn't described an example where this would be required. > > I can invent artificial examples, but I want to see a real-life one > > where using FVWM_DATADIR for system stuff and FVWM_USERDIR for > > user's is not enough. > > we (that is Institute for Informatics, University of Oslo, Norway) > have sitewide fvwm setup for all new users. Installed on at least 2 > different architectures as of now... using a highly modularised setup, > where users can customize parts of the setup by making their own files > in FVWM_USERDIR, these would otherwise be included from the global > setup directory (same for all architectures). Other stuff from the > fvwm distribution would be included from FVWM_DATADIR. So you don't need more than one directory in IncludePath like I expected. You want the situation #1: * The system stuff in /usr/share/fvwm-includes that is not FVWM_DATADIR * Have this command in user or system fvwmrc: IncludePath /usr/share/fvwm-includes I suggest the situation #2: * The system stuff in FVWM_DATADIR, i.e. `fvwm-config --fvwm-datadir` (by default datadir is a shared directory) For me (and probably for you) #2 is preferable, because it does not require to add a hard coded path to configs. My point is that if even fvwm-themes (pretty modular and fully configurable setup) does not require IncludePath, maybe it is not needed. Regards, Mikhael. -- 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: request for IncludePath
Mikhael Goikhman <[EMAIL PROTECTED]> writes: > Still you didn't described an example where this would be required. > I can invent artificial examples, but I want to see a real-life one > where using FVWM_DATADIR for system stuff and FVWM_USERDIR for > user's is not enough. we (that is Institute for Informatics, University of Oslo, Norway) have sitewide fvwm setup for all new users. Installed on at least 2 different architectures as of now... using a highly modularised setup, where users can customize parts of the setup by making their own files in FVWM_USERDIR, these would otherwise be included from the global setup directory (same for all architectures). Other stuff from the fvwm distribution would be included from FVWM_DATADIR. -- [ IRL : Peder Stray ] [ "A new life awaits you in the off-world colonies" ] -- 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: request for IncludePath
On 01 Feb 2002 01:02:51 +0100, Peder Stray wrote: > > Mikhael Goikhman <[EMAIL PROTECTED]> writes: > > > On 31 Jan 2002 14:46:01 -0600, [EMAIL PROTECTED] wrote: > > > > > > Message summary for PR#849 > > > From: [EMAIL PROTECTED] > > > Subject: request for IncludePath > > > > > > Would be nice if fvwm got IncludePath, and search it when including files > > > from the configuration. Now i have to patch in support for at least one > > > extra directory to search (sitewide modularized setup requires this). > > > > It was thought in the past to add IncludePath, so instead of the current > > > > FVWM_USERDIR FVWM_DATADIR > > > > this search order is used: > > > > FVWM_USERDIR IncludePath FVWM_DATADIR > > > > Maybe it will be implemented sometimes in fvwm and modules... > > that would be very much appreciated. sooner than later i hope ;) Still you didn't described an example where this would be required. I can invent artificial examples, but I want to see a real-life one where using FVWM_DATADIR for system stuff and FVWM_USERDIR for user's is not enough. Regards, Mikhael. -- 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: compiling with -Wall -Werror seems to be broken
On Fri, Feb 01, 2002 at 01:57:44AM +0100, Tomas Ogren wrote: > On 31 January, 2002 - Dominik Vogt sent me these 0,7K bytes: > > > I just noticed that when I compile with > > > > make CFLAGS="-g -Wall -Werror" > > > > I get no warnings at all. I believe that worked a while ago, but > > I'm not sure. When I compile with > > > > make CFLAGS="-g -Wall -Werror -O2" > > > > the warnings work fine. Could that have anything to do with hard > > coding some of the options in the Makefile? Or is this a gcc bug? > > Some warning stuff won't be found until the compiler starts shuffling > stuff around, noticing new angles of the same data... Of course. What I wanted to point out is that I get warnings if I compile with optimization, and I don't get warnings if I turn off optimization. There should be no relationship between warnings and optimizitaion. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- 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: CHARSET environment variable
On Fri, 1 Feb 2002, Olivier Chapuis wrote: > So nl_langinfo and iconv should not be used :o) but it does not > seem that there are obvious (portable) replacement (XFree >=4.0.2 > has some Xutf8 functions, we may try to use if available). Please, please, please don't use Xutf8*() functions -- they are absolutely unportable. They were introduced due to the inadequacy (sp?) of the current X locale model: only one locale at one moment, so Xutf8*() are "current-locale"-independent. But their unportability completely outweighs their advantage. _ Dmitry Yu. Bolkhovityanov The Budker Institute of Nuclear Physics Novosibirsk, Russia -- 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: CHARSET environment variable
On Thu, Jan 31, 2002 at 09:41:39PM -0500, Dan Espen wrote: > > I have multibyte enabled. > With the latest CVS I get this warning: > > [FVWM][FInitCharset]: WARN -- Cannot get charset with CHARSET env variable > > Where do I find the documentation on this env variable? > Hum, I do not know if there is a documentation somewhere. This variable is used by some programs in the gnu world to get the charset associated to your locale if your libc does not have nl_langinfo which can do the job (it seems that you do not have nl_langinfo). It can also be used to override the charset returned by nl_langinfo. Now, it is not used in mb support but in the ewmh support for iconv conversion from/to UTF-8 and your charset. If you have iconv you can get the list of charsets by using "iconv --list". There are multiple problems here: 1 - FInitCharset is run by fvwm even if you do not have iconv support (easy to fix). 2 - nl_langinfo may return a different charset than the "X charset". 3 - iconv is not an X function. So nl_langinfo and iconv should not be used :o) but it does not seem that there are obvious (portable) replacement (XFree >=4.0.2 has some Xutf8 functions, we may try to use if available). I will try to fix these problems progressively. I begin to understand the X i18n stuff. Any way these problems are small and these concern only applications with ewmh support (but these should be fixed). Olivier -- 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]
