CVS scott: FAQ 7.17 docfix.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: scott 06/07/13 01:00:23 Modified files: . : ChangeLog docs : FAQ Log message: FAQ 7.17 docfix. Usage of FvwmAuto module in FAQ 7.17 was incorrect. Reported by Serge Koksharov.
Re: FAQ Q7.17 error?
On 7/13/06, Scott Smedley [EMAIL PROTECTED] wrote: Hi Serge, In question 7.17 of the FVWM FAQ Autohiding FvwmButtons or other windows module FvwmAuto launched like this: + I Module FvwmAuto FvwmAutohide -menter enter_handler But from reading manpage source code of this module I figured out that it doesn't accept aliases, right? You are correct that the FvwmAuto module does not use aliases. However, the FvwmAuto module is hardcoded to treat the 1st argument as a timeout value. So, I think module invocation should look like this: + I Module FvwmAuto -menter enter_handler The correct command should be: + I Module FvwmAuto 1 -menter enter_handler I will update docs/FAQ. Do I need to do anything to regenerate the FAQ page for the website? I guess you have to edit the webpage in cvs: http://www.fvwm.org/documentation/dev_cvs.php#fvwm-web Renato Scott. :)
CVS griph: removed ifdefs for O_NOFOLLOW
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: griph 06/07/13 01:57:08 Modified files: modules: ChangeLog modules/FvwmCommand: FvwmCommand.c FvwmCommandS.c Log message: removed ifdefs for O_NOFOLLOW
CVS griph: fix allocation when using FVWM_USERDIR
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: griph 06/07/13 02:07:15 Modified files: modules: ChangeLog modules/FvwmCommand: fifos.c Log message: fix allocation when using FVWM_USERDIR
Re: CVS domivogt: * Removed ifdefs from fifos.c.
On Wed, 12 Jul 2006, FVWM CVS wrote: Log message: * Removed ifdefs from fifos.c. * Added a compat header file libs/fvwm_sys_stat.h to wrap stat.h compat issues. Is it really neccessary to defene everything with FVWM_ as a prefix? If it's not already defined, why not define it using the expected name? /Viktor
Re: FVWM crashes with $[0]
On Thu, 13 Jul 2006, Scott Smedley wrote: Hi all, I think there is a bug in FVWM's parameter expansion. FVWM crashes with a simple command such as: Echo $[0] I am looking at this problem in GDB. The variable 'm', suddenly has a huge value when I reach line 918 of fvwm/expand.c: if (input[m] == ']') Then I get a SEGV because this is an illegal memory access. Can anyone else confirm this problem? I can'tr make it crash with just Echo $[0]. However the following make it crash 100%: AddToFunc TestFunc I Echo $[0] TestFunc $[0] I'll investigate that further after breakfast to see if it's the same crash, or a different one. /Viktor
CVS scott fvwm-web: updated FAQ
CVSROOT:/home/cvs/fvwm Module name:fvwm-web Changes by: scott 06/07/13 02:43:48 Modified files: . : ChangeLog documentation/faq: index.php Log message: updated FAQ
Re: CVS domivogt: * Removed ifdefs from fifos.c.
On Thu, Jul 13, 2006 at 09:16:24AM +0200, Viktor Griph wrote: On Wed, 12 Jul 2006, FVWM CVS wrote: Log message: * Removed ifdefs from fifos.c. * Added a compat header file libs/fvwm_sys_stat.h to wrap stat.h compat issues. Is it really neccessary to defene everything with FVWM_ as a prefix? If it's not already defined, why not define it using the expected name? I use the fvwm prefix to document that we modified its meaning. If we had just #define O_NOFOLLOW 0 someone might rely ona that flag although it's just a dummy to make the compiler happy. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM crashes with $[0]
On Thu, 13 Jul 2006, Viktor Griph wrote: On Thu, 13 Jul 2006, Scott Smedley wrote: Hi all, I think there is a bug in FVWM's parameter expansion. FVWM crashes with a simple command such as: Echo $[0] I am looking at this problem in GDB. The variable 'm', suddenly has a huge value when I reach line 918 of fvwm/expand.c: if (input[m] == ']') Then I get a SEGV because this is an illegal memory access. Can anyone else confirm this problem? I can'tr make it crash with just Echo $[0]. However the following make it crash 100%: AddToFunc TestFunc I Echo $[0] TestFunc $[0] I'll investigate that further after breakfast to see if it's the same crash, or a different one. /Viktor Can you see if the fix I comitted for the above fixes your error as well? It's possible that it's the same error if your strlen doesn't segfault on NULL-input (and you did call Echo $[0] from within a funcion called by a trailing space or something else to form an argument string with no tokens). /Viktor
Re: CVS domivogt: * Removed ifdefs from fifos.c.
On Thu, 13 Jul 2006, Dominik Vogt wrote: On Thu, Jul 13, 2006 at 09:16:24AM +0200, Viktor Griph wrote: On Wed, 12 Jul 2006, FVWM CVS wrote: Log message: * Removed ifdefs from fifos.c. * Added a compat header file libs/fvwm_sys_stat.h to wrap stat.h compat issues. Is it really neccessary to defene everything with FVWM_ as a prefix? If it's not already defined, why not define it using the expected name? I use the fvwm prefix to document that we modified its meaning. If we had just #define O_NOFOLLOW 0 someone might rely ona that flag although it's just a dummy to make the compiler happy. Well, you didn't define it FVWM_O_NOFOLLOW in configure.ac, so it's just O_NOFOLLOW in there as well. It was all the stat-wrappers that I was concerned about. The code use many of them unwrapped already, so if there is a chance that some of them might not be defined it would be better to provide them, with the assumed values you did, under the name expected by the programmer. /Viktor
Re: FVWM crashes with $[0]
On Thu, Jul 13, 2006 at 09:25:09AM +0200, Viktor Griph wrote: On Thu, 13 Jul 2006, Scott Smedley wrote: Hi all, I think there is a bug in FVWM's parameter expansion. FVWM crashes with a simple command such as: Echo $[0] I am looking at this problem in GDB. The variable 'm', suddenly has a huge value when I reach line 918 of fvwm/expand.c: if (input[m] == ']') Then I get a SEGV because this is an illegal memory access. Can anyone else confirm this problem? I can'tr make it crash with just Echo $[0]. However the following make it crash 100%: AddToFunc TestFunc I Echo $[0] TestFunc $[0] I'll investigate that further after breakfast to see if it's the same crash, or a different one. There are several bugs/crashes in expand_args_extended(): 1) It does not check the range of the positional parameters. It happily parses and uses for example $[999]. I didn't try it, but I guess it causes random memory access. 2) In the if (is_single_arg) it uses the token returned by PeekToken as the base for further parsing functions. This is strictly forbidden because PeekToken returns a pointer to a static buffer. 3) As I said in an earlier message, PeekToken never returns an empty string. Calling PeekToken(, ...) returns a NULL pointer which the code accessed later. I've fixed all three. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
CVS domivogt: * Fixed crashes in expand_args_extended.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt06/07/13 04:17:38 Modified files: . : ChangeLog fvwm : expand.c Log message: * Fixed crashes in expand_args_extended.
Re: CVS domivogt: * Removed ifdefs from fifos.c.
On Thu, Jul 13, 2006 at 11:01:13AM +0200, Viktor Griph wrote:
On Thu, 13 Jul 2006, Dominik Vogt wrote:
Is it really neccessary to defene everything with FVWM_ as a prefix? If
it's not already defined, why not define it using the expected name?
I use the fvwm prefix to document that we modified its meaning.
If we had just
#define O_NOFOLLOW 0
someone might rely ona that flag although it's just a dummy to
make the compiler happy.
Well, you didn't define it FVWM_O_NOFOLLOW in configure.ac, so it's just
O_NOFOLLOW in there as well. It was all the stat-wrappers that I was
concerned about. The code use many of them unwrapped already, so if there
is a chance that some of them might not be defined it would be better to
provide them, with the assumed values you did, under the name expected by
the programmer.
There's really no final word on how to handle portability issues
yet. For maintenance reasons, we need to avoid ifdef'ed code as
much as possible. If we can't cope without ifdefs in some place,
they should be only in a single wrapper file (libs/FShape.h is an
example). Ifdefs in the code can easily be replaced with
constructs like this.
in .c file:
#ifdef FOOBAR
some(code);
#endif
becomes:
in some .h file:
#ifdef FOOBAR
# define USE_FOOBAR 1
#else
# define USE_FOOBAR 0
#endif
and in the .c file:
if (USE_FOOBAR)
{
some(code);
}
A big advantage is that *all* code is compiled, regardless of the
platform's features. The compiler should be smart enough to
optimise code like if (0) some(code);.
The latest way to go is to provide dummy functionality that
satisfies the original interfaces and put it in if (0) when it's
not used.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
Re: Removing gnome support from FvwmGtk
On Thu, Jul 13, 2006 at 12:18:02AM +0100, seventh guardian wrote: On 7/13/06, Olivier Chapuis [EMAIL PROTECTED] wrote: seventh guardian a écrit : On 7/12/06, Thomas Adam [EMAIL PROTECTED] wrote: On Wed, Jul 12, 2006 at 11:24:57PM +0100, seventh guardian wrote: Hello. Having looked at FvwmGtk code, I realise there's no need for gnome support, as no gnome specific functions are used. So, there's no advantage of calling gnome_init vs gtk_init. And from what I see, the gnome support has been several times mis-used by precompiled distros (forcing the instalation of gnome libs when they are not required at all). So, I ask if we can remove the gnome support from FvwmGtk. I've been saying this for years -- yet no one would listen. I am in favour of it. Humm.. After a bit more dig up, it seems that gnome support is not just that.. It's also the gnome wm hints support.. it may be important, as this allows fvwm to integrate with gnome desktop (pagers and stuff). So, what does this section from the FvwmGtk-manpage mean: .IP *FvwmGtk: RCFile \fBfile\fP Note that this command should be issued before defining any menus or dialog. Hint for GNOME users: If you add instances of this command for the standard GNOME rc files, switching themes via the control-center will apply to FvwmGtk widgets as well, giving a very integrated appearance of the desktop. yes, but only for gnome 1, so ... Oh! Didn't know that. But in what refers to FvwmGtk, it works exactly the same without gnome support. The final question is, is it worth remove gnome support from FvwmGtk if the rest of fvwm still needs it... Not exactly (bug report system, if I remember some discussions on this list). This known as, I am in favor of removing gnome support in FvwmGtk. And considering the above, what about removing the whole gnome support from fvwm? If you're referring to the gnome libs: FvwmGtk is the orly place where they are needed. If you mean the GNOMe WM hints: we should keep them. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Removing gnome support from FvwmGtk
On 7/13/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Thu, Jul 13, 2006 at 12:18:02AM +0100, seventh guardian wrote: On 7/13/06, Olivier Chapuis [EMAIL PROTECTED] wrote: seventh guardian a écrit : On 7/12/06, Thomas Adam [EMAIL PROTECTED] wrote: On Wed, Jul 12, 2006 at 11:24:57PM +0100, seventh guardian wrote: Hello. Having looked at FvwmGtk code, I realise there's no need for gnome support, as no gnome specific functions are used. So, there's no advantage of calling gnome_init vs gtk_init. And from what I see, the gnome support has been several times mis-used by precompiled distros (forcing the instalation of gnome libs when they are not required at all). So, I ask if we can remove the gnome support from FvwmGtk. I've been saying this for years -- yet no one would listen. I am in favour of it. Humm.. After a bit more dig up, it seems that gnome support is not just that.. It's also the gnome wm hints support.. it may be important, as this allows fvwm to integrate with gnome desktop (pagers and stuff). So, what does this section from the FvwmGtk-manpage mean: .IP *FvwmGtk: RCFile \fBfile\fP Note that this command should be issued before defining any menus or dialog. Hint for GNOME users: If you add instances of this command for the standard GNOME rc files, switching themes via the control-center will apply to FvwmGtk widgets as well, giving a very integrated appearance of the desktop. Well, Gtk themes are defined in $HOME/.gtkrc.. I supose gnome control center also updates this file (?) It's just a matter of telling FvwmGtk where to look for the gtk configs.. yes, but only for gnome 1, so ... Oh! Didn't know that. But in what refers to FvwmGtk, it works exactly the same without gnome support. The final question is, is it worth remove gnome support from FvwmGtk if the rest of fvwm still needs it... Not exactly (bug report system, if I remember some discussions on this list). This known as, I am in favor of removing gnome support in FvwmGtk. And considering the above, what about removing the whole gnome support from fvwm? If you're referring to the gnome libs: FvwmGtk is the orly place where they are needed. If you mean the GNOMe WM hints: we should keep them. I was refering to the hints.. Gnome 1 is obsolete, so it's a matter of deciding which degree of compatibility we want to keep. The same happens with rplay, but that's a matter for another mail :) Cheers, Renato Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEthdCmeSprTOr4tgRAkjeAKDPbFoiPDrzpi0X6D1LQb9PIs8ZMQCgwUbq 3stH7fxGfUBp5BDVXSr0SrI= =a6fF -END PGP SIGNATURE-
Re: Rplay obsolete?
On Thu, Jul 13, 2006 at 01:26:36PM +0100, seventh guardian wrote: On the other hand I realise some people may still use rplay, even though it has frozen since 1999. So removing it from fvwm may break some configs.. This is always an important consideration. I wouldn't have thought many people use sounds for events -- it's not something I have seen in many people's configs out late, and I've seen a lot. OTOH, keeping it in there doesn't cause any harm -- unlike the GNOME issue, rplay is not progressive, so we don't have to play catch-up. You might find some people moan if it is removed, but then you'll always get that. :) -- Thomas Adam -- If I were a witch's hat, sitting on her head like a paraffin stove, I'd fly away and be a bat. -- Incredible String Band.
Re: FVWM crashes with $[0]
On Thu, 13 Jul 2006, Dominik Vogt wrote: On Thu, Jul 13, 2006 at 09:25:09AM +0200, Viktor Griph wrote: On Thu, 13 Jul 2006, Scott Smedley wrote: Hi all, I think there is a bug in FVWM's parameter expansion. FVWM crashes with a simple command such as: Echo $[0] I am looking at this problem in GDB. The variable 'm', suddenly has a huge value when I reach line 918 of fvwm/expand.c: if (input[m] == ']') Then I get a SEGV because this is an illegal memory access. Can anyone else confirm this problem? I can'tr make it crash with just Echo $[0]. However the following make it crash 100%: AddToFunc TestFunc I Echo $[0] TestFunc $[0] I'll investigate that further after breakfast to see if it's the same crash, or a different one. There are several bugs/crashes in expand_args_extended(): 1) It does not check the range of the positional parameters. It happily parses and uses for example $[999]. I didn't try it, but I guess it causes random memory access. I believe that SkipNTokens just stops when there is no more to consume. Then $[999] will be empty if there are less then 1000 words in the string. 2) In the if (is_single_arg) it uses the token returned by PeekToken as the base for further parsing functions. This is strictly forbidden because PeekToken returns a pointer to a static buffer. Not true. With 'is_single_arg' true 'upper' will always be -1, so no other parse-function will be called on the string. 3) As I said in an earlier message, PeekToken never returns an empty string. Calling PeekToken(, ...) returns a NULL pointer which the code accessed later. This was the error I fixed already. /Viktor
Re: Tabs implementation question
On Thu, 13 Jul 2006 11:34:58 +1000, Scott Smedley [EMAIL PROTECTED] said: Hi David, I'm trying to find out how to have multiple windows sharing the same frame. I'm playing with FvwmTabs but I also want to experiment with a simpler implementation on my own. Simpler? H. I just want to get four functions working - add, next, close and detatch tab. That is enough functionality for what I want to do. I want to see what would be possible if it was integrated into fvwm. It would remove the need to create a tabber first - just join any two windows together; and also remove the second title bar - it could be integrated into the main one. The aim would be to make it transparent to the user rather than offering alot of functionality and configuration. It's just an idea I wanted to play around with based on how pekwm does this. You need to use XSetInputFocus(). The client window does get input focus and works normally, except that the frame decor isn't changed when the focus does. The event handlers aren't called so I can't think of anywhere to put this that would work. I also think that it is a problem with events in general and not just input focus. The thing I don't understand is how the second client is different from the first. When they are selected, they are both equal to fw-wins.client. They have the same parent, the same FvwmContext and similar setting from add_window. -- David -- http://www.fastmail.fm - A no graphics, no pop-ups email service
Re: FVWM crashes with $[0]
On Thu, 13 Jul 2006, Viktor Griph wrote: On Thu, 13 Jul 2006, Dominik Vogt wrote: On Thu, Jul 13, 2006 at 09:25:09AM +0200, Viktor Griph wrote: On Thu, 13 Jul 2006, Scott Smedley wrote: Hi all, I think there is a bug in FVWM's parameter expansion. FVWM crashes with a simple command such as: Echo $[0] I am looking at this problem in GDB. The variable 'm', suddenly has a huge value when I reach line 918 of fvwm/expand.c: if (input[m] == ']') Then I get a SEGV because this is an illegal memory access. Can anyone else confirm this problem? I can'tr make it crash with just Echo $[0]. However the following make it crash 100%: AddToFunc TestFunc I Echo $[0] TestFunc $[0] I'll investigate that further after breakfast to see if it's the same crash, or a different one. There are several bugs/crashes in expand_args_extended(): 1) It does not check the range of the positional parameters. It happily parses and uses for example $[999]. I didn't try it, but I guess it causes random memory access. I believe that SkipNTokens just stops when there is no more to consume. Then $[999] will be empty if there are less then 1000 words in the string. Checking the code again I see no reason to have a limit to only work with 10 arguments. The main purpose of expand_args_extended was to allow access to parameters beyond the 10th. That's why it's using parse-functions to find the selected parameters rather than looking them up in the arguments array that $0-$9 expansion does. 2) In the if (is_single_arg) it uses the token returned by PeekToken as the base for further parsing functions. This is strictly forbidden because PeekToken returns a pointer to a static buffer. Not true. With 'is_single_arg' true 'upper' will always be -1, so no other parse-function will be called on the string. I think that, for readability some change is needed, but I don't think it's neccessary to use GetNextToken instead of PeekToken. It just adds an extra free in an extra if. For readability it would probably be nicer to add !is_single_arg to the if (upper = 0) /Viktor
Re: FVWM crashes with $[0]
On Thu, Jul 13, 2006 at 02:55:24PM +0200, Viktor Griph wrote: On Thu, 13 Jul 2006, Dominik Vogt wrote: On Thu, Jul 13, 2006 at 09:25:09AM +0200, Viktor Griph wrote: On Thu, 13 Jul 2006, Scott Smedley wrote: Hi all, I think there is a bug in FVWM's parameter expansion. FVWM crashes with a simple command such as: Echo $[0] I am looking at this problem in GDB. The variable 'm', suddenly has a huge value when I reach line 918 of fvwm/expand.c: if (input[m] == ']') Then I get a SEGV because this is an illegal memory access. Can anyone else confirm this problem? I can'tr make it crash with just Echo $[0]. However the following make it crash 100%: AddToFunc TestFunc I Echo $[0] TestFunc $[0] I'll investigate that further after breakfast to see if it's the same crash, or a different one. There are several bugs/crashes in expand_args_extended(): 1) It does not check the range of the positional parameters. It happily parses and uses for example $[999]. I didn't try it, but I guess it causes random memory access. I believe that SkipNTokens just stops when there is no more to consume. Then $[999] will be empty if there are less then 1000 words in the string. 2) In the if (is_single_arg) it uses the token returned by PeekToken as the base for further parsing functions. This is strictly forbidden because PeekToken returns a pointer to a static buffer. Not true. With 'is_single_arg' true 'upper' will always be -1, so no other parse-function will be called on the string. Then, why do you not write if (is_single_arg) ... *else* if (upper = 0) ... ? -- Hm, now that I think about it, the new functionality deviates from the way the old $0 ... worked in important ways which should be fixed: * A range of args like $[0-1] is expanded to the original text, not the unquoted form. I.e. in 'foo a0 a1 a2' $[0-1] is expanded to 'a0 a1' but should be expanded to 'a0 a1'. * Currently, $* is broken too as it does not remove quoting but just copies the input string. * According to the man page, things like $[*] or $[3-] are removed from the command line if there are no arguments. This is wrong as it prevents that the string '$[*]' is passed to another command. These variable should not be treated specially. Currently, not even $[0] is identical to $0. * The code is written too complicated too understand easily (as you can see from the fact that I only understood about 50% of it), and it's nested too deep. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
CVS griph: * removed range checks in expand_vars_extended.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: griph 06/07/13 09:55:16 Modified files: . : ChangeLog docs : ChangeLog todo-vars fvwm : expand.c Log message: * removed range checks in expand_vars_extended. * reverted to PeekToken use in expand_vars_extended. * minor improvements for readability in expand_vars_extended. * todo-vars: added note on 'raw'-filter.
Re: FVWM crashes with $[0]
On Thu, Jul 13, 2006 at 04:10:53PM +0200, Viktor Griph wrote: On Thu, 13 Jul 2006, Dominik Vogt wrote: [snip] Not true. With 'is_single_arg' true 'upper' will always be -1, so no other parse-function will be called on the string. Then, why do you not write if (is_single_arg) ... *else* if (upper = 0) ... ? Probably because I didn't think of it as I added is_single_arg later to deal with the fact that $0 should be the same as $[0]. -- Hm, now that I think about it, the new functionality deviates from the way the old $0 ... worked in important ways which should be fixed: * A range of args like $[0-1] is expanded to the original text, not the unquoted form. I.e. in 'foo a0 a1 a2' $[0-1] is expanded to 'a0 a1' but should be expanded to 'a0 a1'. Do we really want that? It prevents passing arguments on to another function. The way it is now (quote-persistent) is as $* has worked, and is essensial for pasing multiple parameters on to another function without risking that they split into more parameters than intended. I believe that the current way is a good default until the variable quote system has been implemented. Yes, I really want that. Fvwm has always worked this way and changing this would break many functions. Mikhael suggested several times to add some notion of expansion modifies to instruct fvwm to quote the result, i.e. $[quote:0] to get '0' instead of '0'. I think this is the right approach. The fact that $* works differently just means that it's broken. [snip] * According to the man page, things like $[*] or $[3-] are removed from the command line if there are no arguments. This is wrong as it prevents that the string '$[*]' is passed to another command. These variable should not be treated specially. Currently, not even $[0] is identical to $0. The old variables also work in this way, so it's only trying to mimic the old behaviour. All my tests make $[0] identical to $0. In what way are they different? Heck, you're right. I still don't it this is good: destroyfunc bar addtofunc foo + i addtofunc bar i $0 If you now invoke foo echo $1 bar 0 1 2 It should print '1', but currently it prints an empty string. It's just the way the other $-Variables (like $w) work: If it can not be expanded, keep the Variable reference. Anyway, it's too risky to change now. * The code is written too complicated too understand easily (as you can see from the fact that I only understood about 50% of it), and it's nested too deep. The deepest nestings are in the actual parsing of the parameters, and that's hard to do without the nesting. Regarding the actual parameter extraction I treid to write useful comments to tell what's going on and why. I'm not sure what more can be done. Look at the code I've committed. It uses a subfunction to parse the parameter range and reduces the number of nesting levels by two. It also properly unquotes argument ranges. Note that I did not test anything. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
CVS domivogt: * ChangeLog.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt06/07/13 10:13:13 Modified files: . : ChangeLog Log message: * ChangeLog.
CVS domivogt: * Fixed, cleaned up and simplified positional parameter parsing code.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt06/07/13 10:12:18 Modified files: . : ChangeLog fvwm : expand.c Log message: * Fixed, cleaned up and simplified positional parameter parsing code.
Re: FVWM crashes with $[0]
Sorry, I've just removed your latest patch. The only difference between the old and new param style is now that $* does not dequote arguments while $[*] does. I'm not sure that this is good. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM crashes with $[0]
On Thu, Jul 13, 2006 at 05:00:27PM +0200, Viktor Griph wrote:
On Thu, 13 Jul 2006, Viktor Griph wrote:
On Thu, 13 Jul 2006, Dominik Vogt wrote:
On Thu, Jul 13, 2006 at 02:55:24PM +0200, Viktor Griph wrote:
On Thu, 13 Jul 2006, Dominik Vogt wrote:
On Thu, Jul 13, 2006 at 09:25:09AM +0200, Viktor Griph wrote:
On Thu, 13 Jul 2006, Scott Smedley wrote:
Hi all,
I think there is a bug in FVWM's parameter expansion.
FVWM crashes with a simple command such as:
Echo $[0]
I am looking at this problem in GDB. The variable 'm', suddenly has a
huge value when I reach line 918 of fvwm/expand.c:
if (input[m] == ']')
Then I get a SEGV because this is an illegal memory access.
Can anyone else confirm this problem?
I can'tr make it crash with just Echo $[0]. However the following make
it
crash 100%:
AddToFunc TestFunc I Echo $[0]
TestFunc $[0]
I'll investigate that further after breakfast to see if it's the same
crash, or a different one.
There are several bugs/crashes in expand_args_extended():
1) It does not check the range of the positional parameters. It
happily parses and uses for example $[999]. I didn't try it,
but I guess it causes random memory access.
I believe that SkipNTokens just stops when there is no more to consume.
Then $[999] will be empty if there are less then 1000 words in the
string.
2) In the if (is_single_arg) it uses the token returned by
PeekToken as the base for further parsing functions. This is
strictly forbidden because PeekToken returns a pointer to a
static buffer.
Not true. With 'is_single_arg' true 'upper' will always be -1, so no
other
parse-function will be called on the string.
Then, why do you not write
if (is_single_arg)
...
*else* if (upper = 0)
...
?
Probably because I didn't think of it as I added is_single_arg later to
deal with the fact that $0 should be the same as $[0].
--
Hm, now that I think about it, the new functionality deviates from
the way the old $0 ... worked in important ways which should be
fixed:
* A range of args like $[0-1] is expanded to the original text,
not the unquoted form.
I.e. in 'foo a0 a1 a2'
$[0-1] is expanded to 'a0 a1' but should be expanded to
'a0 a1'.
Do we really want that? It prevents passing arguments on to another
function. The way it is now (quote-persistent) is as $* has worked, and is
essensial for pasing multiple parameters on to another function without
risking that they split into more parameters than intended. I believe that
the current way is a good default until the variable quote system has been
implemented.
* Currently, $* is broken too as it does not remove quoting but
just copies the input string.
See above.
* According to the man page, things like $[*] or $[3-] are
removed from the command line if there are no arguments. This
is wrong as it prevents that the string '$[*]' is passed to
another command. These variable should not be treated
specially. Currently, not even $[0] is identical to $0.
The old variables also work in this way, so it's only trying to mimic the
old behaviour. All my tests make $[0] identical to $0. In what way are
they different?
* The code is written too complicated too understand easily (as
you can see from the fact that I only understood about 50% of
it), and it's nested too deep.
The deepest nestings are in the actual parsing of the parameters, and
that's hard to do without the nesting. Regarding the actual parameter
extraction I treid to write useful comments to tell what's going on and
why. I'm not sure what more can be done.
Waiting for a responce I've done some minor cleanup as suggested, and
removed the range-checks again. One thing that still looks weird to me,
(that wrote it) is the
argument_string = SkipSpaces(
SkipNTokens(argument_string, lower), NULL, 0);
The token parser stops after the first non-token character, e.g. a
space. In your old code, SkipSpaces was necessary, in the patch I
just committed it isn't.
args_end = SkipNTokens(argument_string, upper - lower + 1);
while (argument_string args_end isspace(*(args_end - 1)))
{
args_end--;
}
which seems to assume that SkipNTokens can end with any number of spaces
before or after the next token in the list. Is that so? Or is either
SkipSpaces or the while-loop unneeded?
If the tokens are copied dequoted, trailing spaces have to be
removed. If $[*] does not dequote, it should keep trailing
whitespace.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
Re: FVWM crashes with $[0]
On Thu, Jul 13, 2006 at 05:07:17PM +0200, Dominik Vogt wrote: On Thu, Jul 13, 2006 at 04:10:53PM +0200, Viktor Griph wrote: On Thu, 13 Jul 2006, Dominik Vogt wrote: [snip] Not true. With 'is_single_arg' true 'upper' will always be -1, so no other parse-function will be called on the string. Then, why do you not write if (is_single_arg) ... *else* if (upper = 0) ... ? Probably because I didn't think of it as I added is_single_arg later to deal with the fact that $0 should be the same as $[0]. -- Hm, now that I think about it, the new functionality deviates from the way the old $0 ... worked in important ways which should be fixed: * A range of args like $[0-1] is expanded to the original text, not the unquoted form. I.e. in 'foo a0 a1 a2' $[0-1] is expanded to 'a0 a1' but should be expanded to 'a0 a1'. Do we really want that? It prevents passing arguments on to another function. The way it is now (quote-persistent) is as $* has worked, and is essensial for pasing multiple parameters on to another function without risking that they split into more parameters than intended. I believe that the current way is a good default until the variable quote system has been implemented. Yes, I really want that. Fvwm has always worked this way and changing this would break many functions. Mikhael suggested several times to add some notion of expansion modifies to instruct fvwm to quote the result, i.e. $[quote:0] to get '0' instead of '0'. I think this is the right approach. The fact that $* works differently just means that it's broken. [snip] * According to the man page, things like $[*] or $[3-] are removed from the command line if there are no arguments. This is wrong as it prevents that the string '$[*]' is passed to another command. These variable should not be treated specially. Currently, not even $[0] is identical to $0. The old variables also work in this way, so it's only trying to mimic the old behaviour. All my tests make $[0] identical to $0. In what way are they different? Heck, you're right. I still don't it this is good: destroyfunc bar addtofunc foo + i addtofunc bar i $0 If you now invoke foo echo $1 bar 0 1 2 It should print '1', but currently it prints an empty string. It's just the way the other $-Variables (like $w) work: If it can not be expanded, keep the Variable reference. Anyway, it's too risky to change now. * The code is written too complicated too understand easily (as you can see from the fact that I only understood about 50% of it), and it's nested too deep. The deepest nestings are in the actual parsing of the parameters, and that's hard to do without the nesting. Regarding the actual parameter extraction I treid to write useful comments to tell what's going on and why. I'm not sure what more can be done. Look at the code I've committed. It uses a subfunction to parse the parameter range and reduces the number of nesting levels by two. It also properly unquotes argument ranges. Note that I did not test anything. I don't have much time now, but two random test results: Echo $[-0] should print the first argument but prints $[-0] Echo $[1-0] (or any other invalid range) should be just copied, but it is replaced with an empty string. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM crashes with $[0]
On Thu, 13 Jul 2006, Dominik Vogt wrote: On Thu, Jul 13, 2006 at 05:07:17PM +0200, Dominik Vogt wrote: On Thu, Jul 13, 2006 at 04:10:53PM +0200, Viktor Griph wrote: On Thu, 13 Jul 2006, Dominik Vogt wrote: [snip] Not true. With 'is_single_arg' true 'upper' will always be -1, so no other parse-function will be called on the string. Then, why do you not write if (is_single_arg) ... *else* if (upper = 0) ... ? Probably because I didn't think of it as I added is_single_arg later to deal with the fact that $0 should be the same as $[0]. -- Hm, now that I think about it, the new functionality deviates from the way the old $0 ... worked in important ways which should be fixed: * A range of args like $[0-1] is expanded to the original text, not the unquoted form. I.e. in 'foo a0 a1 a2' $[0-1] is expanded to 'a0 a1' but should be expanded to 'a0 a1'. Do we really want that? It prevents passing arguments on to another function. The way it is now (quote-persistent) is as $* has worked, and is essensial for pasing multiple parameters on to another function without risking that they split into more parameters than intended. I believe that the current way is a good default until the variable quote system has been implemented. Yes, I really want that. Fvwm has always worked this way and changing this would break many functions. Mikhael suggested several times to add some notion of expansion modifies to instruct fvwm to quote the result, i.e. $[quote:0] to get '0' instead of '0'. I think this is the right approach. The fact that $* works differently just means that it's broken. [snip] * According to the man page, things like $[*] or $[3-] are removed from the command line if there are no arguments. This is wrong as it prevents that the string '$[*]' is passed to another command. These variable should not be treated specially. Currently, not even $[0] is identical to $0. The old variables also work in this way, so it's only trying to mimic the old behaviour. All my tests make $[0] identical to $0. In what way are they different? Heck, you're right. I still don't it this is good: destroyfunc bar addtofunc foo + i addtofunc bar i $0 If you now invoke foo echo $1 bar 0 1 2 It should print '1', but currently it prints an empty string. It's just the way the other $-Variables (like $w) work: If it can not be expanded, keep the Variable reference. Anyway, it's too risky to change now. * The code is written too complicated too understand easily (as you can see from the fact that I only understood about 50% of it), and it's nested too deep. The deepest nestings are in the actual parsing of the parameters, and that's hard to do without the nesting. Regarding the actual parameter extraction I treid to write useful comments to tell what's going on and why. I'm not sure what more can be done. Look at the code I've committed. It uses a subfunction to parse the parameter range and reduces the number of nesting levels by two. It also properly unquotes argument ranges. Note that I did not test anything. I don't have much time now, but two random test results: Echo $[-0] should print the first argument but prints $[-0] This construct is not in the manpage (and thus never implemented (at lest not in my version. I've not checked the newcode yet.)) Echo $[1-0] (or any other invalid range) should be just copied, but it is replaced with an empty string. This worked with my version. The function should return -1 when it should be copied and 0 when it should be replaced with an empty string. /Viktor
Re: FVWM crashes with $[0]
On Thu, 13 Jul 2006, Dominik Vogt wrote: On Thu, Jul 13, 2006 at 04:10:53PM +0200, Viktor Griph wrote: On Thu, 13 Jul 2006, Dominik Vogt wrote: [snip] Not true. With 'is_single_arg' true 'upper' will always be -1, so no other parse-function will be called on the string. Then, why do you not write if (is_single_arg) ... *else* if (upper = 0) ... ? Probably because I didn't think of it as I added is_single_arg later to deal with the fact that $0 should be the same as $[0]. -- Hm, now that I think about it, the new functionality deviates from the way the old $0 ... worked in important ways which should be fixed: * A range of args like $[0-1] is expanded to the original text, not the unquoted form. I.e. in 'foo a0 a1 a2' $[0-1] is expanded to 'a0 a1' but should be expanded to 'a0 a1'. Do we really want that? It prevents passing arguments on to another function. The way it is now (quote-persistent) is as $* has worked, and is essensial for pasing multiple parameters on to another function without risking that they split into more parameters than intended. I believe that the current way is a good default until the variable quote system has been implemented. Yes, I really want that. Fvwm has always worked this way and changing this would break many functions. Mikhael suggested several times to add some notion of expansion modifies to instruct fvwm to quote the result, i.e. $[quote:0] to get '0' instead of '0'. I think this is the right approach. The fact that $* works differently just means that it's broken. $* has always worked they way it works as well. I for sure have some functions that rely on passing arguments to other functions, so changing the behaviour of $* would break my config. Also reading the todo-vars file it states that $[number] should be unquoted for backwardscompability. The $[range] can be treated differently as that is a new feature. I see use for both the 'raw' style and the unquoted style, but as I understand the todo it really should be single-quoted as they are niether $[number] not $[range], which are the only exceptions to that rule listed. Regarding the dequoting of the positional parameters I belive the best thing would be to make a function to unquote an entire string. I'm not sure how optimized it is to peek every token just to get rid of the quotings. Also the most flexible code for the argument expansion would be keeping the raw string as long as possible, and then dequote it and possible requote it depending on filter-selection. Maybe the best thing is to remove the $[range] alltogether until the filter-system is ready to not add another exception to how things work. I'd really like to hear Mikhael's opinion on this. [snip] * According to the man page, things like $[*] or $[3-] are removed from the command line if there are no arguments. This is wrong as it prevents that the string '$[*]' is passed to another command. These variable should not be treated specially. Currently, not even $[0] is identical to $0. The old variables also work in this way, so it's only trying to mimic the old behaviour. All my tests make $[0] identical to $0. In what way are they different? Heck, you're right. I still don't it this is good: destroyfunc bar addtofunc foo + i addtofunc bar i $0 If you now invoke foo echo $1 bar 0 1 2 It should print '1', but currently it prints an empty string. It's just the way the other $-Variables (like $w) work: If it can not be expanded, keep the Variable reference. Anyway, it's too risky to change now. * The code is written too complicated too understand easily (as you can see from the fact that I only understood about 50% of it), and it's nested too deep. The deepest nestings are in the actual parsing of the parameters, and that's hard to do without the nesting. Regarding the actual parameter extraction I treid to write useful comments to tell what's going on and why. I'm not sure what more can be done. Look at the code I've committed. It uses a subfunction to parse the parameter range and reduces the number of nesting levels by two. It also properly unquotes argument ranges. Note that I did not test anything. I'll take a look at the code more later. Currenlty I've only looked at the diff to get some idea of what you are doing. /Viktor
Re: FVWM crashes with $[0]
On Thu, 13 Jul 2006, Dominik Vogt wrote:
On Thu, Jul 13, 2006 at 05:00:27PM +0200, Viktor Griph wrote:
On Thu, 13 Jul 2006, Viktor Griph wrote:
On Thu, 13 Jul 2006, Dominik Vogt wrote:
On Thu, Jul 13, 2006 at 02:55:24PM +0200, Viktor Griph wrote:
On Thu, 13 Jul 2006, Dominik Vogt wrote:
On Thu, Jul 13, 2006 at 09:25:09AM +0200, Viktor Griph wrote:
On Thu, 13 Jul 2006, Scott Smedley wrote:
Hi all,
I think there is a bug in FVWM's parameter expansion.
FVWM crashes with a simple command such as:
Echo $[0]
I am looking at this problem in GDB. The variable 'm', suddenly has a
huge value when I reach line 918 of fvwm/expand.c:
if (input[m] == ']')
Then I get a SEGV because this is an illegal memory access.
Can anyone else confirm this problem?
I can'tr make it crash with just Echo $[0]. However the following make
it
crash 100%:
AddToFunc TestFunc I Echo $[0]
TestFunc $[0]
I'll investigate that further after breakfast to see if it's the same
crash, or a different one.
There are several bugs/crashes in expand_args_extended():
1) It does not check the range of the positional parameters. It
happily parses and uses for example $[999]. I didn't try it,
but I guess it causes random memory access.
I believe that SkipNTokens just stops when there is no more to consume.
Then $[999] will be empty if there are less then 1000 words in the
string.
2) In the if (is_single_arg) it uses the token returned by
PeekToken as the base for further parsing functions. This is
strictly forbidden because PeekToken returns a pointer to a
static buffer.
Not true. With 'is_single_arg' true 'upper' will always be -1, so no
other
parse-function will be called on the string.
Then, why do you not write
if (is_single_arg)
...
*else* if (upper = 0)
...
?
Probably because I didn't think of it as I added is_single_arg later to
deal with the fact that $0 should be the same as $[0].
--
Hm, now that I think about it, the new functionality deviates from
the way the old $0 ... worked in important ways which should be
fixed:
* A range of args like $[0-1] is expanded to the original text,
not the unquoted form.
I.e. in 'foo a0 a1 a2'
$[0-1] is expanded to 'a0 a1' but should be expanded to
'a0 a1'.
Do we really want that? It prevents passing arguments on to another
function. The way it is now (quote-persistent) is as $* has worked, and is
essensial for pasing multiple parameters on to another function without
risking that they split into more parameters than intended. I believe that
the current way is a good default until the variable quote system has been
implemented.
* Currently, $* is broken too as it does not remove quoting but
just copies the input string.
See above.
* According to the man page, things like $[*] or $[3-] are
removed from the command line if there are no arguments. This
is wrong as it prevents that the string '$[*]' is passed to
another command. These variable should not be treated
specially. Currently, not even $[0] is identical to $0.
The old variables also work in this way, so it's only trying to mimic the
old behaviour. All my tests make $[0] identical to $0. In what way are
they different?
* The code is written too complicated too understand easily (as
you can see from the fact that I only understood about 50% of
it), and it's nested too deep.
The deepest nestings are in the actual parsing of the parameters, and
that's hard to do without the nesting. Regarding the actual parameter
extraction I treid to write useful comments to tell what's going on and
why. I'm not sure what more can be done.
Waiting for a responce I've done some minor cleanup as suggested, and
removed the range-checks again. One thing that still looks weird to me,
(that wrote it) is the
argument_string = SkipSpaces(
SkipNTokens(argument_string, lower), NULL, 0);
The token parser stops after the first non-token character, e.g. a
space. In your old code, SkipSpaces was necessary, in the patch I
just committed it isn't.
args_end = SkipNTokens(argument_string, upper - lower + 1);
while (argument_string args_end isspace(*(args_end - 1)))
{
args_end--;
}
which seems to assume that SkipNTokens can end with any number of spaces
before or after the next token in the list. Is that so? Or is either
SkipSpaces or the while-loop unneeded?
If the tokens are copied dequoted, trailing spaces have to be
removed. If $[*] does not dequote, it should keep trailing
whitespace.
The only time it removed the trailing whitespace was in ranges with closed
upper end. It kept them for $[*] and $[2-] etc.
/Viktor
Re: FVWM crashes with $[0]
On Thu, Jul 13, 2006 at 06:39:40PM +0200, Viktor Griph wrote: On Thu, 13 Jul 2006, Dominik Vogt wrote: On Thu, Jul 13, 2006 at 04:10:53PM +0200, Viktor Griph wrote: On Thu, 13 Jul 2006, Dominik Vogt wrote: [snip] Hm, now that I think about it, the new functionality deviates from the way the old $0 ... worked in important ways which should be fixed: * A range of args like $[0-1] is expanded to the original text, not the unquoted form. I.e. in 'foo a0 a1 a2' $[0-1] is expanded to 'a0 a1' but should be expanded to 'a0 a1'. Do we really want that? It prevents passing arguments on to another function. The way it is now (quote-persistent) is as $* has worked, and is essensial for pasing multiple parameters on to another function without risking that they split into more parameters than intended. I believe that the current way is a good default until the variable quote system has been implemented. Yes, I really want that. Fvwm has always worked this way and changing this would break many functions. Mikhael suggested several times to add some notion of expansion modifies to instruct fvwm to quote the result, i.e. $[quote:0] to get '0' instead of '0'. I think this is the right approach. The fact that $* works differently just means that it's broken. $* has always worked they way it works as well. I for sure have some functions that rely on passing arguments to other functions, so changing the behaviour of $* would break my config. Also reading the todo-vars file it states that $[number] should be unquoted for backwardscompability. The $[range] can be treated differently as that is a new feature. I see use for both the 'raw' style and the unquoted style, but as I understand the todo it really should be single-quoted as they are niether $[number] not $[range], which are the only exceptions to that rule listed. Regarding the dequoting of the positional parameters I belive the best thing would be to make a function to unquote an entire string. I'm not sure how optimized it is to peek every token just to get rid of the quotings. Also the most flexible code for the argument expansion would be keeping the raw string as long as possible, and then dequote it and possible requote it depending on filter-selection. No, I think that is the wrong approach. Disregarding the fact that there won't be big changes in the parser before 3.0, its job is: * To read in tokens from a command line and provide them to the functions that use the parser. * To allow embedding whitespace and other special characters in tokens, the caller may quote parts of the token with double or single quotes, backticks and backslashes. * The parser has to remove one level of quoting every time it parses a token because *that is what the quoting was made for*. * If a function wants to pass a token to another command or function, it has to quote the token. The problem in fvwm is that there is no safe way to quote a token. The correct fix is to provide that functionality, not to modify the parser to do obscure things. I should never have coded the parameter $* in the way I did but should have called it $@ instead ($@ in shells works as $* now works in fvwm). Maybe the best thing is to remove the $[range] alltogether until the filter-system is ready to not add another exception to how things work. I'd really like to hear Mikhael's opinion on this. Note that passing arguments without dequoting them introduces subtle problems. Assume you have a function that takes a random number of (possibly quoted) arguments and passes them to a shell command: AddToFunc foobar + I Exec ls $* In this case, the arguments are filenames. Since the shell interprets the command, the caller of the function needs to choose a shell-compatible way of quoting. For example, he could say foobar file with spaces with double quotes but not foobar `file with spaces` with backticks. [snip] Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: FVWM crashes with $[0]
On Thu, Jul 13, 2006 at 06:12:05PM +0200, Viktor Griph wrote: On Thu, 13 Jul 2006, Dominik Vogt wrote: I don't have much time now, but two random test results: Echo $[-0] should print the first argument but prints $[-0] This construct is not in the manpage (and thus never implemented (at lest not in my version. I've not checked the newcode yet.)) Well, maybe it's not worth the effort after all. Echo $[1-0] (or any other invalid range) should be just copied, but it is replaced with an empty string. This worked with my version. The function should return -1 when it should be copied and 0 when it should be replaced with an empty string. ... and it does work now that I'm comparing integers instead of pointer values ;-) Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] signature.asc Description: Digital signature
CVS domivogt: * Bugfixes in parsing code.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt06/07/13 17:06:54 Modified files: . : ChangeLog fvwm : expand.c Log message: * Bugfixes in parsing code.
bugfix with clearing 'NoIcon' style
Hello,
Let me cite an excerpt of manpage:
If the NoIcon attribute is set then the specified window simply
disappears when it is iconified. The window can be recovered
through the window-list. If Icon is set without an argument
then the NoIcon attribute is cleared but no icon is specified.
An example which allows only the FvwmPager module icon to exist:
Style * NoIcon
Style FvwmPager Icon
But with current code in CVS any 'Icon' style clears the 'NoIcon'
attribute. So, here is my patch which makes fvwm behave like described
in manpage.
Best wishes
--
Serge Koksharov, Free Software user supporter
GPG public key ID: 0x3D330896 (pgp.mit.edu)
Key fingerprint: 5BC4 0475 CB03 6A31 0076 82C2 C240 72F0 3D33 0896
diff -Naur fvwmCVS-orig/ChangeLog fvwmCVS-fixed/ChangeLog
--- fvwmCVS-orig/ChangeLog 2006-07-14 02:07:19.0 +0400
+++ fvwmCVS-fixed/ChangeLog 2006-07-14 02:09:40.0 +0400
@@ -1,3 +1,9 @@
+2006-07-14 Serge Koksharov gentoosiast dog yandex dot ru
+
+ * fvwm/style.c (style_parse_one_style_option):
+ Now 'NoIcon' style can be cleared only with 'Icon' style without an
+ argument list, exactly like described in manpage
+
2006-07-13 Dominik Vogt dominik(dot)vogt(at)gmx(dot)de
* fvwm/expand.c (expand_args_extended):
diff -Naur fvwmCVS-orig/fvwm/style.c fvwmCVS-fixed/fvwm/style.c
--- fvwmCVS-orig/fvwm/style.c 2006-07-14 02:07:17.0 +0400
+++ fvwmCVS-fixed/fvwm/style.c 2006-07-14 02:07:49.0 +0400
@@ -2688,9 +2688,11 @@
ps-flag_mask.has_icon = 1;
ps-change_mask.has_icon = 1;
- S_SET_IS_ICON_SUPPRESSED(SCF(*ps), 0);
- S_SET_IS_ICON_SUPPRESSED(SCM(*ps), 1);
- S_SET_IS_ICON_SUPPRESSED(SCC(*ps), 1);
+ if (!ps-flags.has_icon) {
+ S_SET_IS_ICON_SUPPRESSED(SCF(*ps), 0);
+ S_SET_IS_ICON_SUPPRESSED(SCM(*ps), 1);
+ S_SET_IS_ICON_SUPPRESSED(SCC(*ps), 1);
+ }
}
else if (StrEquals(token, IconBackgroundColorset))
{
Re: Tabs implementation question
Hi David, I'm trying to find out how to have multiple windows sharing the same frame. I'm playing with FvwmTabs but I also want to experiment with a simpler implementation on my own. Simpler? H. I just want to get four functions working - add, next, close and detatch tab. That is enough functionality for what I want to do. I want to see what would be possible if it was integrated into fvwm. Most of the features you talk about are already possible with the FvwmTabs module or could be implemented without too much effort. It would remove the need to create a tabber first - just join any two windows together I've been using the following function to combine create add commands into a single action: # CreateTabberWithWin will put the focused window into a new tabber, # creating it at the same position as the window. DestroyFunc CreateTabberWithWin AddToFunc CreateTabberWithWin + I Current (!FvwmTabs) SetEnv CTWW_ID $[w.id] + I TestRc (NoMatch) Break + I PipeRead 'echo SetEnv CTWW_COUNT $(( $CTWW_COUNT+1 ))' + I NewTabber --geometry=+$[w.x]+$[w.y] .$[CTWW_COUNT] + I Wait FvwmTabs* + I WindowId $[CTWW_ID] Tabize .$[CTWW_COUNT] Key Z A CM CreateTabberWithWin To combine additional add commands into the same action would just require the use of the MultiAddTab function. and also remove the second title bar *FvwmTabs: showTitlebar false - it could be integrated into the main one. *FvwmTabs: useTMTitlebar true The aim would be to make it transparent to the user rather than offering alot of functionality and configuration. I agree that it's a pain that FvwmTabs depends on external libraries (X11::Protocol Tk) which can make configuration difficult for some users. I don't think I've ever heard a user complain about too much functionality though! (Some people complain about Emacs, but that's different! :) It's just an idea I wanted to play around with based on how pekwm does this. Go right ahead - the more people hacking on FVWM the better! IMHO. You need to use XSetInputFocus(). The client window does get input focus and works normally, except that the frame decor isn't changed when the focus does. The event handlers aren't called so I can't think of anywhere to put this that would work. I also think that it is a problem with events in general and not just input focus. Sorry, that's a little too cryptic for me to understand. I assume you know you have to ask the X server which events you're interested in (for each window) right? This is usually accomplished by setting the event mask with XChangeWindowAttributes(). Scott. :)
Bees
Damn this list is busy! http://gmane.org/plot-rate.php?group=gmane.comp.window-managers.fvwm.develwidth=1000height=400color=red,orange,%234000title=fvwm-workerssmooth=exp Not that I'm complaining. Scott. :)
Re: Bees
On 7/14/06, Scott Smedley [EMAIL PROTECTED] wrote: Damn this list is busy! http://gmane.org/plot-rate.php?group=gmane.comp.window-managers.fvwm.develwidth=1000height=400color=red,orange,%234000title=fvwm-workerssmooth=exp Not that I'm complaining. Yes.. Summer hollydays are comming in :) I can't wait to finish my exams!! Renato Scott. :)
Re: FVWM crashes with $[0]
I think there is a bug in FVWM's parameter expansion. FVWM crashes with a simple command such as: Echo $[0] Is this supposed to be fixed? FVWM still crashes on my system when I type Echo $[0] in FvwmConsole. I am using current version of CVS. Scott.
