Re: changes to fvwm that have not been included in 2.4.5 for unknown reasons
> On Tue, 29 Jan 2002 00:03:12 -0500 > "Dan" == Dan Espen <[EMAIL PROTECTED]> wrote: Dan> Dan> Alexander Kotelnikov <[EMAIL PROTECTED]> writes: >> > On Mon, 28 Jan 2002 19:46:46 -0500 >> > "Dan" == Dan Espen <[EMAIL PROTECTED]> wrote: Dan> >> >> > And, please, add >> >> > #! /usr/bin/perl >> >> > to utils/fvwm24_convert.in >> >> >> >> But that would break the script for installations that don't have >> >> perl in /usr/bin. Dan> Dan> I agree. Whats wrong with the self bootstrapping code thats in there Dan> now, as long as perl is in your path, it should work. >> >> Really? >> >> 7:03 pts/13 [EMAIL PROTECTED]:/var/tmp/fvwm_cvs/utils 12> gmake >> DESTDIR=/tmp/fvwm_in >> st/ install >> 7:03 pts/13 [EMAIL PROTECTED]:/var/tmp/fvwm_cvs/utils 13> head -n 1 >> /tmp/fvwm_inst/u >> sr/X11R6/bin/fvwm24_convert >> # -*-perl-*- Dan> Dan> That line is in the file in order to make emacs go into perl mode. This line is the firts in /usr/X11R6/bin/fvwm24_convert after installation even if I have /usr/bin/perl. >> 7:03 pts/13 [EMAIL PROTECTED]:/var/tmp/fvwm_cvs/utils 14> which perl >> /usr/bin/perl -- Alexander Kotelnikov Saint-Petersburg, 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: changes to fvwm that have not been included in 2.4.5 for unknown reasons
Alexander Kotelnikov <[EMAIL PROTECTED]> writes: > > On Mon, 28 Jan 2002 19:46:46 -0500 > > "Dan" == Dan Espen <[EMAIL PROTECTED]> wrote: > Dan> > >> > And, please, add > >> > #! /usr/bin/perl > >> > to utils/fvwm24_convert.in > >> > >> But that would break the script for installations that don't have > >> perl in /usr/bin. > Dan> > Dan> I agree. Whats wrong with the self bootstrapping code thats in there > Dan> now, as long as perl is in your path, it should work. > > Really? > > 7:03 pts/13 [EMAIL PROTECTED]:/var/tmp/fvwm_cvs/utils 12> gmake > DESTDIR=/tmp/fvwm_in > st/ install > 7:03 pts/13 [EMAIL PROTECTED]:/var/tmp/fvwm_cvs/utils 13> head -n 1 > /tmp/fvwm_inst/u > sr/X11R6/bin/fvwm24_convert > # -*-perl-*- That line is in the file in order to make emacs go into perl mode. > 7:03 pts/13 [EMAIL PROTECTED]:/var/tmp/fvwm_cvs/utils 14> which perl > /usr/bin/perl -- 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: changes to fvwm that have not been included in 2.4.5 for unknown reasons
> On Tue, 29 Jan 2002 00:33:33 +0100 > "Olivier" == Olivier Chapuis <[EMAIL PROTECTED]> wrote: Olivier> Olivier> If you have any plan on the I18N_MB fvwm code say it as I plan to Olivier> start to rewrite it next week. I have already wrote that I am going to remove font field form FvwmFont when I18N_MB is defiend. I have some problems doing this, but I hope I will complete this up to Monday (at least in libs/ and fvwm/). -- Alexander Kotelnikov Saint-Petersburg, 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: changes to fvwm that have not been included in 2.4.5 for unknown reasons
> On Mon, 28 Jan 2002 19:46:46 -0500 > "Dan" == Dan Espen <[EMAIL PROTECTED]> wrote: Dan> >> > And, please, add >> > #! /usr/bin/perl >> > to utils/fvwm24_convert.in >> >> But that would break the script for installations that don't have >> perl in /usr/bin. Dan> Dan> I agree. Whats wrong with the self bootstrapping code thats in there Dan> now, as long as perl is in your path, it should work. Really? 7:03 pts/13 [EMAIL PROTECTED]:/var/tmp/fvwm_cvs/utils 12> gmake DESTDIR=/tmp/fvwm_inst/ install 7:03 pts/13 [EMAIL PROTECTED]:/var/tmp/fvwm_cvs/utils 13> head -n 1 /tmp/fvwm_inst/usr/X11R6/bin/fvwm24_convert # -*-perl-*- 7:03 pts/13 [EMAIL PROTECTED]:/var/tmp/fvwm_cvs/utils 14> which perl /usr/bin/perl -- Alexander Kotelnikov Saint-Petersburg, 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: redesign of wire frame move/resize look?
Dominik Vogt <[EMAIL PROTECTED]> writes: > On Mon, Jan 28, 2002 at 05:03:34PM -0500, Dan Espen wrote: > > Dominik Vogt <[EMAIL PROTECTED]> writes: > > > Isn't it time to get rid of these silly grid lines? This only > > > makes the code much more complicated and slower and - in my eyes - > > > serves no purpose at all. > > > > Running FVWM remotely, it serves a big purpose. > > Its dramatically faster. > > > > Didn't we just have a user complain about the grab with the grid, and > > then when I suggested resizeopaque, he said he preferred the grid > > lines. > > Um, I wanted to suggest to remove the lines inside the window. > > Now: > > +---+ > | | | | > +---+ > | | | | > +---+ > | | | | > +---+ > > After the suggested change: > > +---+ > | | > | | > | | > | | > | | > +---+ > > This is a relic from twm. I can't think of any other window > manager that still has these additional lines in the middle of the > window. Objection withdrawn. For a long time, Fvwm had a problem with the resize grid not being visible. I'd guess thats why the extra lines are there. The visibility problem was solved years ago. -- 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: changes to fvwm that have not been included in 2.4.5 for unknown reasons
Dominik Vogt <[EMAIL PROTECTED]> writes: > On Mon, Jan 28, 2002 at 07:29:19PM +0300, Alexander Kotelnikov wrote: > > > Content-Description: patch to make fvwm survive with SIGTTIN > > (and actually other signals from exec'ed programs) > > Wasn't there a portability issue with setpgrp? I'm willing to > commit a patch if it's clear that it compiles on any platform. I think there is. There are autoconf macros for setpgrp but I really don't understand how to use them. > > And, please, add > > #! /usr/bin/perl > > to utils/fvwm24_convert.in > > But that would break the script for installations that don't have > perl in /usr/bin. I agree. Whats wrong with the self bootstrapping code thats in there now, as long as perl is in your path, it should work. -- 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: redesign of wire frame move/resize look?
On Mon, Jan 28, 2002 at 05:03:34PM -0500, Dan Espen wrote: > Dominik Vogt <[EMAIL PROTECTED]> writes: > > Isn't it time to get rid of these silly grid lines? This only > > makes the code much more complicated and slower and - in my eyes - > > serves no purpose at all. > > Running FVWM remotely, it serves a big purpose. > Its dramatically faster. > > Didn't we just have a user complain about the grab with the grid, and > then when I suggested resizeopaque, he said he preferred the grid > lines. Um, I wanted to suggest to remove the lines inside the window. Now: +---+ | | | | +---+ | | | | +---+ | | | | +---+ After the suggested change: +---+ | | | | | | | | | | +---+ This is a relic from twm. I can't think of any other window manager that still has these additional lines in the middle of the window. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- 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: Notification: incoming/848
On Mon, Jan 28, 2002 at 11:34:41AM -0600, fvwm-bug wrote: > FVWM Bug Tracking notification > > new message incoming/848 > > Full_Name: marcell mars > Version: 2.4.4 > CVS_Date: > OS: linux 2.4.10 i686 > X_Server: 4.1.0-13 > Submission from: (NULL) (213.191.128.202) > > > when i start fvwm everything works fine... after some time i can't get any > fvwm related menu clicking with my usb mouse and it doesn't respond even on > keyboard shortcuts like alt+ctrl+left to change focus from window to > window mouse works fine in opened applications. maybe it is not bug > of fvwm but of kernel of xfree... i used a little bit the other window > managers and it worked fine but i didn't used it a lot, i prefer fvwm :))) One of your locking modifier keys is pressed, for example num-lock or scroll lock. Hit that key again and the bindings work again. For instructions to prevent this from happening at all, please refer to questions 0.1 and 5.5 in the fvwm FAQ. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- 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: changes to fvwm that have not been included in 2.4.5 for unknown reasons
On Mon, Jan 28, 2002 at 07:29:19PM +0300, Alexander Kotelnikov wrote: > Content-Description: patch to make fvwm survive with SIGTTIN > (and actually other signals form exec'ed programs) Wasn't there a portability issue with setpgrp? I'm willing to commit a patch if it's clear that it compiles on any platform. > And two more I've never wrote here: Content-Description: XSetLocaleModifier should be called on fvwm init in I18N_MB is defined > >From its manual page: "Clients should always call XSetLocaleModifiers > with a non-NULL modifier_list after setting the locale before they > call any locale-dependent Xlib routine. Somebody else should commit this patch. I don't know enough about internationalisation under X to judge it. > And, please, add > #! /usr/bin/perl > to utils/fvwm24_convert.in But that would break the script for installations that don't have perl in /usr/bin. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- 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 domivogt: * Fixed stack ring corruption.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/01/28 18:23:15 Modified files: . : Tag: branch-2_4 ChangeLog NEWS fvwm : Tag: branch-2_4 icons.c icons.h read.c stack.c Log message: * Fixed stack ring corruption. -- 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 domivogt: * Finally got that annoying stack ring corruption. The cause: the code in
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/01/28 18:22:48 Modified files: . : ChangeLog docs : DEVELOPERS fvwm : icons.c icons.h read.c stack.c Log message: * Finally got that annoying stack ring corruption. The cause: the code in stack.c counted the number of windows to restack. But it sometimes counted an icon title or pixmap window if the window did not have one, allocated memory for the non existing window and called XRestackWindows with the uninitialised memory --> random stacking order. -- 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: changes to fvwm that have not been included in 2.4.5 for unknown reasons
On Mon, Jan 28, 2002 at 07:29:19PM +0300, Alexander Kotelnikov wrote: > Hello > Content-Description: XSetLocaleModifier should be called on fvwm init in I18N_MB is defined > >From its manual page: "Clients should always call XSetLocaleModifiers > with a non-NULL modifier_list after setting the locale before they > call any locale-dependent Xlib routine. > Yes, I will "apply" this patch to 2.5.1 (note that the attached patch does not concern XSetLocaleModifier, but I will do it). If you have any plan on the I18N_MB fvwm code say it as I plan to start to rewrite it next week. Regards, 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: redesign of wire frame move/resize look?
On Mon, Jan 28, 2002 at 05:03:34PM -0500, Dan Espen wrote: > Dominik Vogt <[EMAIL PROTECTED]> writes: > > Isn't it time to get rid of these silly grid lines? This only > > makes the code much more complicated and slower and - in my eyes - > > serves no purpose at all. > > Running FVWM remotely, it serves a big purpose. > Its dramatically faster. > > Didn't we just have a user complain about the grab with the grid, and > then when I suggested resizeopaque, he said he preferred the grid > lines. > I'm agree with Dan. But what about using (no grab) override redirect grid? 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: Remaining UTF troubles | was (Re: fvwm is absolutely unusable with UTF-8 locales)
On Thu, Jan 24, 2002 at 08:46:28PM -0500, Dan Espen wrote: > Olivier Chapuis <[EMAIL PROTECTED]> writes: > > On Thu, Jan 24, 2002 at 04:25:10PM -0500, Dan Espen wrote: > > > Olivier Chapuis <[EMAIL PROTECTED]> writes: > > > > On Thu, Jan 24, 2002 at 03:44:20PM +0300, Alexander Kotelnikov wrote: > > > > > > On Thu, 24 Jan 2002 13:02:54 +0100 > > > > > > "Olivier" == Olivier Chapuis <[EMAIL PROTECTED]> wrote: > > > > > Olivier> > > > > I am not sure that it is so easy to remove these "3 bytes" (which > > are not only 3 bytes and which can be found at different place > > in the string). Basically, we have to rewrite the > > XmbTextPropertyToTextList > > function (maybe in a weak form). > > Maybe in theory the 3 bytes can occur anywhere, > but every time I've seen them, they are at the start of the string. > Java, for example, will put them there when you set the locale to > en_Us. I think, if you have true multibyte strings, they might > be anywhere, but when an application is just marking a string as > multibyte, just in case, they seem to only be at the start of the > string. > > > > > Do I have to apply such changes to 2.4.5? > > > > > > Not for my benefit. > > > > Hum I do not know what we should do. But it seems that > > since the 2002-01-01 all the Europe (East and West) needs > > to use a locale with a non iso8859-1 charset. Also, I think > > that a lot of people outside of the Europe will want the > > EuroSign. The problem is not that people need the EuroSign > > in window titles, the problem is that if you use a charset > > != iso8859-1 and if the window title of an xterm (and of a lot > > of others programs) contains non ascii characters, then > > the window title is not displayed in the good way. The > > only thing that we can respond to this bug is "--enable-multibyte" > > (which is now my default). And there are problems with > > the I18N_MB patch. > > > > What you would say if you have to use --enable-multibyte > > for the "$" characters :o) > > We may add --enable-us? or --disable-8bits? :o) > > > > Really, I do not know what we should do. For 2.6.x > > we must improve the I18N_MB patch (and fix the utf8 > > problem), but for 2.4.x? > > Hey, I'm old fashioned, in my opinion, proportional fonts > should never have been implemented on computers. I'm not > even sure lower case makes any sense. 6 bit characters > made more sense to me. > > IF I HAD MY WAY, EMAIL WOULD LOOK LIKE THIS. > > :) > > I don't think everyone understood your question. > Current FVWM development is mainly on the 2.5.x branch. > We don't know exactly when the 2.5.x branch will be ready, > so we are making critical patches to the next 2.4.x release, > 2.4.5. > > The question is should this change be applied to both branches > or can it wait for the release of 2.6.0. > Ooops, I missed this mail! I think that the change should be applied to both branches. If you object we can make some tests: I apply the patch to 2.4.6 with some "ifdef" and you (we) see if this makes a big differrence. 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: redesign of wire frame move/resize look?
Dominik Vogt <[EMAIL PROTECTED]> writes: > Isn't it time to get rid of these silly grid lines? This only > makes the code much more complicated and slower and - in my eyes - > serves no purpose at all. Running FVWM remotely, it serves a big purpose. Its dramatically faster. Didn't we just have a user complain about the grab with the grid, and then when I suggested resizeopaque, he said he preferred the grid lines. -- 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]
redesign of wire frame move/resize look?
Isn't it time to get rid of these silly grid lines? This only makes the code much more complicated and slower and - in my eyes - servers no purpose at all. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- 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: Cannot make fvwm link with libiconv
On Mon, Jan 28, 2002 at 05:52:06PM +, Tim Phipps wrote: > Configuration Information [Automatically generated, do not change]: > uname output: SunOS silver 5.5.1 Generic_103640-38 sun4u sparc SUNW,Ultra-5_10 > Compiler: gcc > Compilation CFLAGS: -g -O2 -Wall -Wno-implicit-int > prefix: /u/phippst/sunos > > FVWM Version: 2.5.1 > FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.0 > FVWM_DATADIR: /u/phippst/sunos/share/fvwm > FVWM_USERDIR: /u/phippst/.fvwm > > Description: > On Solaris 2.5.1 iconv support is pants. I downloaded libiconv, > compiled and installed. Now I can't get fvwm to compile. > > Repeat-By: > Any of > ./configure > ./configure --with-iconv-library=/u/phippst/sunos/lib > ./configure --with-iconv-library=/u/phippst/sunos/lib/libiconv.so > > All result in: > ewmh_names.c:56: #error libiconv not in use but included iconv.h is > from libiconv > > I think this is because I have an iconv.h on my include path, > put there by libiconv but ./configure is detecting the Solaris > iconv and not looking at --with-iconv-library > Fix: > Make ./configure take note of the --with-iconv-library and try > to use -liconv in it's test compilation before it tries the > system iconv. I think this would be best since not many people > would install a libiconv if they didn't need it. > > Maybe trying libiconv first would be best, it's not likely to > be worse than the system iconv. Yes, at the present time if a system iconv is found it is used. I will fix the --with-iconv-library option (the most simple solution). 0r we can add an --enable-iconv-library option. I do not know what is the good default. But it seems logic to use the system iconv if found, IMHO we cannot assume that the "users" have a consistent installation (nowdays most unix system has no system administrator). Some other advice? 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]
Notification: incoming/848
FVWM Bug Tracking notification new message incoming/848 Message summary for PR#848 From: [EMAIL PROTECTED] Subject: usb mouse click stop to respond Date: Mon, 28 Jan 2002 11:34:40 -0600 0 replies 0 followups > ORIGINAL MESSAGE FOLLOWS < >From [EMAIL PROTECTED] Mon Jan 28 11:34:41 2002 Received: from karazm.math.uh.edu ([129.7.128.1]) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 16VFg1-0001vR-00 for [EMAIL PROTECTED]; Mon, 28 Jan 2002 11:34:41 -0600 Received: from malifon.math.uh.edu (IDENT:[EMAIL PROTECTED] [129.7.128.13]) by karazm.math.uh.edu (8.9.3/8.9.3) with ESMTP id LAA28992 for <[EMAIL PROTECTED]>; Mon, 28 Jan 2002 11:34:40 -0600 (CST) From: [EMAIL PROTECTED] Received: from localhost ([127.0.0.1] ident=65534) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 16VFg0-0001vN-00 for [EMAIL PROTECTED]; Mon, 28 Jan 2002 11:34:40 -0600 To: [EMAIL PROTECTED] Subject: usb mouse click stop to respond Message-Id: <[EMAIL PROTECTED]> Date: Mon, 28 Jan 2002 11:34:40 -0600 Full_Name: marcell mars Version: 2.4.4 CVS_Date: OS: linux 2.4.10 i686 X_Server: 4.1.0-13 Submission from: (NULL) (213.191.128.202) when i start fvwm everything works fine... after some time i can't get any fvwm related menu clicking with my usb mouse and it doesn't respond even on keyboard shortcuts like alt+ctrl+left to change focus from window to window mouse works fine in opened applications. maybe it is not bug of fvwm but of kernel of xfree... i used a little bit the other window managers and it worked fine but i didn't used it a lot, i prefer fvwm :))) -- 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]
Cannot make fvwm link with libiconv
Configuration Information [Automatically generated, do not change]: uname output: SunOS silver 5.5.1 Generic_103640-38 sun4u sparc SUNW,Ultra-5_10 Compiler: gcc Compilation CFLAGS: -g -O2 -Wall -Wno-implicit-int prefix: /u/phippst/sunos FVWM Version: 2.5.1 FVWM_MODULEDIR: /u/phippst/sunos/libexec/fvwm/2.5.0 FVWM_DATADIR: /u/phippst/sunos/share/fvwm FVWM_USERDIR: /u/phippst/.fvwm Description: On Solaris 2.5.1 iconv support is pants. I downloaded libiconv, compiled and installed. Now I can't get fvwm to compile. Repeat-By: Any of ./configure ./configure --with-iconv-library=/u/phippst/sunos/lib ./configure --with-iconv-library=/u/phippst/sunos/lib/libiconv.so All result in: ewmh_names.c:56: #error libiconv not in use but included iconv.h is from libiconv I think this is because I have an iconv.h on my include path, put there by libiconv but ./configure is detecting the Solaris iconv and not looking at --with-iconv-library Fix: Make ./configure take note of the --with-iconv-library and try to use -liconv in it's test compilation before it tries the system iconv. I think this would be best since not many people would install a libiconv if they didn't need it. Maybe trying libiconv first would be best, it's not likely to be worse than the system iconv. -- 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]
changes to fvwm that have not been included in 2.4.5 for unknown reasons
Hello
--- fvwm/read.c.orig Tue Jan 8 02:47:05 2002
+++ fvwm/read.c Tue Jan 8 02:52:40 2002
@@ -140,8 +140,15 @@
tline[l - 1] = '\0';
if (debugging)
+/* [EMAIL PROTECTED]
+ tline is null terminated anyway and contains no new-lines
+ */
+/*
fvwm_msg(DBG,"ReadSubFunc","Module switch %d, about to exec: '%.*s'",
Module,strlen(tline)-1,tline);
+*/
+ fvwm_msg(DBG,"ReadSubFunc","Module switch %d, about to exec: '%s'",
+ Module, tline);
old_execute_function(tline, tmp_win, eventp, context, Module, 0, NULL);
tline = fgets(line, (sizeof line) - 1, f);
or "have you ever run fvwm with -debug?"
--- fvwm/builtins.c.orig Sun Jan 13 02:04:00 2002
+++ fvwm/builtins.c Sun Jan 13 04:00:43 2002
@@ -782,6 +782,11 @@
/* Not everyone has vfork! */
if (!(fork())) /* child process */
{
+if ( setpgrp() == -1 )
+{
+ fvwm_msg(ERR,"exec_function","setpgrp failed (%s)",strerror(errno));
+ exit(100);
+}
if (execl(exec_shell_name, exec_shell_name, "-c", cmd, NULL)==-1)
{
fvwm_msg(ERR,"exec_function","execl failed (%s)",strerror(errno));
And two more I've never wrote here:
--- libs/GetFont.c.orig Tue Dec 5 18:22:40 2000
+++ libs/GetFont.c Mon Jan 28 10:59:50 2002
@@ -59,38 +59,44 @@
XFontSet fontset = NULL;
char **ml;
int mc;
+ int i;
char *ds;
if (fontname)
-fontset = XCreateFontSet(disp,fontname,&ml,&mc,&ds);
- if (!fontset && fontname)
- {
-fprintf(stderr,
+if (!strcmp("fixed",fontname))
+ fontset = XCreateFontSet(disp,fontname,&ml,&mc,&ds);
+
+ else{
+ fprintf(stderr,
"[FVWM][GetFontSetOrFixed]: "
- "WARNING -- can't get fontset %s, trying 'fixed'\n",
-fontname);
+ "WARNING -- fontname is a NULL-string\n");
}
if (!fontset)
{
+fprintf(stderr,
+"[FVWM][GetFontSetOrFixed]: "
+ "WARNING -- can't get fontset '%s', trying '-*-fixed-medium-r-normal-*-14-*-*-*-*-*-*-*'\n",
+fontname);
/* fixed should always be avail, so try that */
-#ifdef STRICTLY_FIXED
-if ((fontset = XCreateFontSet(disp,"fixed",&ml,&mc,&ds))==NULL)
-{
- fprintf(stderr,
- "[FVWM][GetFontSetOrFixed]: "
- "ERROR -- can't get fontset 'fixed'\n");
-}
-#else
-/* Yes, you say it's not a *FIXED* font, but it helps you. */
if ((fontset =
XCreateFontSet(disp,
"-*-fixed-medium-r-normal-*-14-*-*-*-*-*-*-*",
&ml, &mc, &ds)) == NULL)
{
fprintf(stderr,"[FVWM][GetFontSetOrFixed]: "
- "ERROR -- can't get fontset 'fixed'\n");
+ "ERROR -- can't get fontset '-*-fixed-medium-r-normal-*-14-*-*-*-*-*-*-*'\n");
+}
+ }
+ if (fontset){
+if (mc > 0) {
+ (void)fprintf(stderr,
+ "[FVWM][GetFontSetOrFixed][%s]:"
+ "The following charsets are missing:\n", fontname);
+ for(i=0; i < mc; i++)
+ fprintf(stderr, " %s", ml[i]);
+ fprintf(stderr, "\n");
+ XFreeStringList(ml);
}
-#endif
}
return fontset;
>From its manual page: "Clients should always call XSetLocaleModifiers
with a non-NULL modifier_list after setting the locale before they
call any locale-dependent Xlib routine.
And, please, add
#! /usr/bin/perl
to utils/fvwm24_convert.in
Thanks for you attention,
--
Alexander Kotelnikov
Saint-Petersburg, Russia
Re: czech keyboard and fvwm
On Mon, Jan 28, 2002 at 03:31:50PM +0100, Jan Martinek wrote:
> > > > > Other interesting behaviour:
> > > > > 1) startx
> > > > > 2) shift+ctrl+r - runs rxvt
> > > > > 3) Left Shift + Right Shift simultaneously
> > > > >this activates Czech keyboard layout
> > > > > 4) if some window has focus, shift+ctrl+r runs another rxvt
> > > > >but if no window has focus, nothing happens.
> >
> > That's really funny. Obviously, the keyboard grabs are still
> > there, but they don't work on the root window. If you issue the
> > fvwm command
> >
> > Recapture
>
> I will do it later, as soon as I figure out how to do it.
Just start the FvwmConsole module (e.g. from a menu) and type the
command directly into its window.
> > after switching the layout, does it work then? Does restarting
> > fvwm (without restarting the X server) help?
> >
> > Please add these lines to the HandleKeyPress() function in
> > events.c, recompile and reinstall to see if fvwm gets the key
> > strokes at all:
> >
> > void HandleKeyPress(void)
> > {
> > ...
> > /* Here's a real hack - some systems have two keys with the
> > * same keysym and different keycodes. This converts all
> > * the cases to one keycode. */
> > fprintf(stderr, "key press: kc1 0x%x, mods 0x%x ", Event.xkey.keycode,
> > Event.xkey.state);
> > Event.xkey.keycode =
> > XKeysymToKeycode(dpy,XKeycodeToKeysym(dpy,Event.xkey.keycode,0));
> >
> > /* Check if there is something bound to the key */
> > action = CheckBinding(Scr.AllBindings, STROKE_ARG(0) Event.xkey.keycode,
> > Event.xkey.state, GetUnusedModifiers(), Context,
> > KEY_BINDING);
> > fprintf(stderr, "kc2 0x%x, action '%s'\n", Event.xkey.keycode,
> > (action)?action:"");
> > ...
> > }
> >
> > The two lines with the fprintf's are new; this is the latest code
> > from CVS, but older Versions should look similar enough.
>
> Please have patience with me, I must ask someone more experienced to help
> me with that.
No problem. If cou can tell me the exact version number you're
using right now I can make you a patch that can be easily
applied without knowing anything about C programming.
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]
CVS olicha: * Some ewmh names work:
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: olicha 02/01/28 09:38:42 Modified files: . : ChangeLog fvwm : ewmh_names.c modules: ChangeLog Log message: * Some ewmh names work: * Better error message in get_charset * use UTF-8 in the place of UTF8 * set the ewmh visible (icon) name only if the fvwm visible (icon) name is different from the ICCCM (icon) window name * limit the number of conversions error messages to 10 -- 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 olicha: * Complete the Transparent support (Modulo bugs fix, doc and
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: olicha 02/01/28 08:35:40 Modified files: fvwm : builtins.c commands.h events.c functions.c module_interface.c module_interface.h libs : Module.h defaults.h modules/FvwmBacker: FvwmBacker.c modules/FvwmButtons: FvwmButtons.c FvwmButtons.h draw.c parse.c modules/FvwmDragWell: fvwmDragWell.c modules/FvwmEvent: FvwmEvent.c modules/FvwmForm: FvwmForm.c modules/FvwmIconBox: FvwmIconBox.c modules/FvwmIconMan: FvwmIconMan.c FvwmIconMan.h fvwm.c modules/FvwmIdent: FvwmIdent.c FvwmIdent.h modules/FvwmPager: FvwmPager.c FvwmPager.h modules/FvwmScript: FvwmScript.c types.h modules/FvwmTaskBar: FvwmTaskBar.c modules/FvwmWinList: FvwmWinList.c Log message: * Complete the Transparent support (Modulo bugs fix, doc and ParentalRelativity auto config) * New all propse message MX_PROPERTY_CHANGE. * Use MX_PROPERTY_CHANGE to indicate background change and swallowing * New flags (No)FvwmModule to FvwmButtons Swallow * Rewrite the FvwmButtons Expose code * Note: Documentation is in progress (web and man page) -- 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: czech keyboard and fvwm
> On Sun, Jan 27, 2002 at 06:10:36PM +0100, Jan Martinek wrote: > > Please always reply to our mailing list, no to me personally. > > > > On Sun, Jan 27, 2002 at 05:09:31PM +0100, Jan Martinek wrote: > > > > Hello, > > > > > > > > some time ago I tried to send a bugreport (incoming, #837) but > > > > I claimed rather missleading and vague information. > > > > Let me please try to define the problem once more, from scratch: > > > > > > > > Fvwm does not respond to key bindings if this condition is met: > > > > Czech keyboard layout is selected AND no window has focus. > > > > > > > > This is the contents of my /.fvwm2rc > > > > It contains only one line defining key for starting rxvt > > > > (shift+ctrl+r). > > > > > > > > #beginning of /.fvwm2rc > > > > Key r A SC Exec exec rxvt > > > > #end of /.fvwm2rc > > > > > > > > this is the contents of .xinitrc > > > > > > > > #beginning of /.xinitrc > > > > setxkbmap 'cz(us_cz_prog)' > > > > exec fvwm2 > > > > #end of /.xinitrc > > > > > > > > (in case of XFree86-4.1.0-3 there must be > > > > setxkbmap 'cz' > > > > instead) > > > > > > When I use > > > > > > setxkbmap 'cz' > > > > > > I get this error message: > > > > > > > Error:Can't find file "cz" for symbols include > > > > Exiting > > > > Abandoning symbols file "default" > > > > > > And when I use > > > > > > setxkbmap 'cz(us_cz_prog)' > > > > > > the X server crashes with a floating point exception as soon as I > > > press any key. How do I get that working? > > > > I really have no idea why it crashes. It should work on plain Redhat > > installation. But I will try this also on other distributions. > > SuSE 7.2 here. I tried the same on my friend's SuSE 7.3: command setxkbmap 'cz(us_cz_prog)' failed with this error: Error loading new keyboard description so I tried setxkbmap 'cz' and this worked OK. It activated the czech keyboard layout. The difference is probably in X server version. SuSE 7.3 has xf86-4.1.0-52 SuSE 7.2 seems to have something older (4.0.3 maybe?). But on SuSE I found something that makes me to change the description of the strange behaviour. It worked fine with the czech keyboard but wrong with the US layout! So on SuSE it was like this: fvwm ignores key bindings if the keyboard was toggled from czech to US AND no window has the focus. And another thing: fvwm ignores key bindings if the numlock was toggled on AND no window has the focus. No matter what the keyboard layout was. HEY! NOW I found something similar on my system: fvwm ignores key bindings if the capslock was toggled on AND no window has the focus. No matter what the keyboard layout is. I cannot check out the numlock on my system, because I remapped numlock to something else. > > > > > How to reproduce the behaviour: > > > > > > > > 1) startx > > > > 2) Left Shift + Right Shift simultaneously > > > >this activates Czech keyboard layout > > > > 3) shift+ctrl+r simultaneously - this should exec rxvt, but is does not! > > > > > > Does the keycode of the r key change when you switch the layout? > > > Fvwm is not aware of nor does it handle this situation. > > > > No, this is not the reason. "r" remains on its position even on czech > > layout. > > Fvwm ignores all key bindings. I tried many of them (F11, F12, Alt+Tab, > > Ctrl+Shift+arrows, ...) > > And, if some window has the focus, fvwm does what I want no matter what > > the keyboard layout is. Keycode does not change. > > Something must have been changed since version 2.2.4 that could influence > > this. Would it be possible to find something in patches? > > With CVS access and a lot of patience - yes. You'd have to > download the 2.3.x releases (35 releases) and see where it > appeared first, look at the ChangeLog entries and try to find the > guilty patch by downloading the CVS code from specific dates and > then run a diff between the two versions. I tested several versions which I downloaded from CVS. The bug appeared probably somewhere between versions fvwm-2.3.6 and 2.2.5. I could not localize it better, because I was unable to compile versions older than 2.3.6. But I have two rpm's (2.2.4 and 2.2.5) that work fine. fvwm2-2.2.5-4.i386.rpm OK fvwm2-2.2.4-9.i386.rpm OK fvwm-2.3.29-1BUG fvwm-2.3.10 BUG fvwm-2.3.6 BUG fvwm-2.3.2 unable to compile fvwm-2.3.5 unable to compile fvwm-2.2.5 (from CVS)unable to compile fvwm-2.2.4 (from CVS)unable to compile I followed these instructions: autoreconf automake --add-missing ./configure make make install On versions that I was unable to compile I got this error: autoheader: missing template: > > > > > Other interesting behaviour: > > > > 1) startx > > > > 2) shift+ctrl+r - runs rxvt > > > > 3) Left Shift + Right Shift simultaneously > > > >this activates Czech keyboard layout > > > > 4) if some window has focus, shi
Re: Remaining UTF troubles | was (Re: fvwm is absolutely unusable with UTF-8 locales)
On Fri, 25 Jan 2002, Olivier Chapuis wrote:
[SNIP]
> I am not sure that it is so easy to remove these "3 bytes" (which
> are not only 3 bytes and which can be found at different place
> in the string). Basically, we have to rewrite the
> XmbTextPropertyToTextList
> function (maybe in a weak form).
Hmmm... Those "3 bytes" (generally, much more) are ISO2022 escape
sequences. The 2022 is a very complex encoding (AFAIR, 2022 interpreter
is a state machine). It is documented somewhere, but those docs are hard
to read.
I'll ask Juliusz Chroboczek about how to strip 2022 tags in the
easiest way. But I'm sure the reply wouldn't be fast -- he is quite busy
with upcoming XFree 4.2.0 now.
> > I wouldn't use any Xmb function to do it though.
> > On Solaris, all the Xmb functions are in a separate shared
> > library. I think if you use that function you'll cause another
> > shared library to be loaded.
> >
> > I think the sequence is "Esc ( B" or "Esc B (" (I forget which).
> >
> > > Do I have to apply such changes to 2.4.5?
> >
> > Not for my benefit.
>
> Hum I do not know what we should do. But it seems that
> since the 2002-01-01 all the Europe (East and West) needs
> to use a locale with a non iso8859-1 charset. Also, I think
> that a lot of people outside of the Europe will want the
> EuroSign. The problem is not that people need the EuroSign
> in window titles, the problem is that if you use a charset
> != iso8859-1 and if the window title of an xterm (and of a lot
> of others programs) contains non ascii characters, then
> the window title is not displayed in the good way. The
> only thing that we can respond to this bug is "--enable-multibyte"
> (which is now my default). And there are problems with
> the I18N_MB patch.
>
> What you would say if you have to use --enable-multibyte
> for the "$" characters :o)
> We may add --enable-us? or --disable-8bits? :o)
>
> Really, I do not know what we should do. For 2.6.x
> we must improve the I18N_MB patch (and fix the utf8
> problem), but for 2.4.x?
YES. Definitely yes. Alexander had posted a screenshot with
cyrillic titles from XTerm -- you can see that the result is hardly
readable. The same happens with Netscape and almost all other apps --
they are correctly i18n'ed on Xlib layer.
BTW, while just stripping 2022 tags wouldn't be a "correct"
solution, it will work at least for koi8-r, iso8859-* and for other
singlebyte charsets.
The trick is that (at least in Russia) in case of locale with
"FOO-N" charset the fonts which are default (i.e. used by fvwm, first dir
in fontpath etc.) are *-FOO-N. And singlebyte encodings are represented
in 2022 "as-is" (e.g. koi8-r text is ""). So, we'll display FOO-N-encoded strings with FOO-N-font, which
is right. Of course, visiting chinese or even polish websites when in
russian locale will give funky titles, but that's what we had in old days.
_
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: [Fwd: Re: 2.5.0 problems]
[EMAIL PROTECTED] wrote: On Mon, Jan 28, 2002 at 12:27:35PM +, Tim Phipps wrote: Part of this problem is that UTF8 isn't a valid charset. The GNU libiconv documentation says UTF-8 is the correct name. Does anyone know what the correct name for glibc is? The glibc support UTF8 and UTF-8 (>= 2.1.x). At least iconv --list gives the two names. I will be surprised that the gnu libiconv does not understand the two names too. http://www.gnu.org/software/libiconv only mentions UTF-8. Since glibc does both could you patch ewmh_names.c to use UTF-8? Cheers, Tim. -- 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: [Fwd: Re: 2.5.0 problems]
On Mon, Jan 28, 2002 at 12:27:35PM +, Tim Phipps wrote: > [EMAIL PROTECTED] wrote: > > > On Sun, Jan 27, 2002 at 07:55:20PM -0800, Elliot Sowadsky wrote: > > > >>Solaris 2.5.1 > >> > >>1) Warning on startup and window updates... > >> [FVWM][convert_charsets]: <> conversion from `' to `UTF8' > fail (init) > >> > >>What is this convert_charsets? > >> > >> > > > > This came from the "extended window manager hints" fvwm support. > > fvwm detects that your locale charset is "". It seems to me > > that your locale is broken but of course there is a fvwm bug here. > > You can try to export to the world the env variable CHARSET and > > set it to "ISO-8859-1" for example. > > Part of this problem is that UTF8 isn't a valid charset. The GNU > libiconv documentation says UTF-8 is the correct name. Does anyone know > what the correct name for glibc is? > The glibc support UTF8 and UTF-8 (>= 2.1.x). At least iconv --list gives the two names. I will be surprised that the gnu libiconv does not understand the two names too. > The other part of the problem is that Solaris 2.5.1 has its own iconv > which doesn't appear to dor UTF at all. I think you may get further if > you can force fvwm to be linked with the gnu libiconv. > I will limit the errors messages as well as the use of the conversion in a near future. An other things which can cause trouble is nl_langinfo. I do not know if Solaris (and other non glibc system) has it. 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]
[Fwd: Re: 2.5.0 problems]
[EMAIL PROTECTED] wrote: > On Sun, Jan 27, 2002 at 07:55:20PM -0800, Elliot Sowadsky wrote: > >>Solaris 2.5.1 >> >>1) Warning on startup and window updates... >> [FVWM][convert_charsets]: <> conversion from `' to `UTF8' fail (init) >> >>What is this convert_charsets? >> >> > > This came from the "extended window manager hints" fvwm support. > fvwm detects that your locale charset is "". It seems to me > that your locale is broken but of course there is a fvwm bug here. > You can try to export to the world the env variable CHARSET and > set it to "ISO-8859-1" for example. Part of this problem is that UTF8 isn't a valid charset. The GNU libiconv documentation says UTF-8 is the correct name. Does anyone know what the correct name for glibc is? The other part of the problem is that Solaris 2.5.1 has its own iconv which doesn't appear to dor UTF at all. I think you may get further if you can force fvwm to be linked with the gnu libiconv. Cheers, Tim. -- 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: 2.5.0 problems
On Sun, Jan 27, 2002 at 07:55:20PM -0800, Elliot Sowadsky wrote: > > Solaris 2.5.1 > > 2 problems... > > 1) Warning on startup and window updates... > [FVWM][convert_charsets]: <> conversion from `' to `UTF8' fail > (init) > > What is this convert_charsets? > > 2) xview icons that under previous versions first appeared in top left corner > but moved to iconbox afterwards (tho may have required mouseover to trigger > move) now stay in top left corner. Can you give detailed instructions how to see this? I have rewritten large parts of the icon code and fully expect problems (remember: 2.5.0 is an alpha release). 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: 2.5.0 problems
On Sun, Jan 27, 2002 at 07:55:20PM -0800, Elliot Sowadsky wrote: > > Solaris 2.5.1 > > 2 problems... > > 1) Warning on startup and window updates... > [FVWM][convert_charsets]: <> conversion from `' to `UTF8' fail > (init) > > What is this convert_charsets? > This came from the "extended window manager hints" fvwm support. fvwm detects that your locale charset is "". It seems to me that your locale is broken but of course there is a fvwm bug here. You can try to export to the world the env variable CHARSET and set it to "ISO-8859-1" for example. > 2) xview icons that under previous versions first appeared in top left corner > but moved to iconbox afterwards (tho may have required mouseover to trigger > move) now stay in top left corner. You may try to use Style * NoIconPosition But I do not think that fvwm changes its behavior regarding this style in 2.5.0. 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]
