Re: Frappr Map: Fvwm
On 10/30/05, Thomas Adam [EMAIL PROTECTED] wrote: Hello all, This is really just a bit of fun, but I thought I'd send it to fvwm-workers, rather than the FVWM mailing-list, since the people predominantly on this list do a lot for FVWM. I've created a Frappr map, so that we can see at a glance where people are. Just thought it would be an interesting and fun thing to do. Here's the URL: http://www.frappr.com/fvwm ... no pressure to add yourself, of course. :) -- Thomas Adam -- Try not to want people to like you too much, you'll just need more and more flatteries to recharge your batteries. -- Jeffrey Lewis. As you can see by the weather report, there are some baloons over the usa/canada and the north of europe. One guy caught some wind and ended up on australia though.. LOL Great thing you came up with! I hope I can join you soon in my baloon :) I'll be over Portugal though. As soon as I finish my FvwmXevie module and qualify as a real contributor.. Cheers!
Fvwm and xcompmgr (the composite extension)
Hi I've already posted a bug report on the fvwm mailing list some weeks ago regarding this, but no one answered. Today I switched to xorg-7.0.0 and the problem is still there, so it must be fvwm. The problem I found is related to the composite extension of xorg: when I run xcompmgr (the composite manager) fvwm looses the screen-scrolling abillity to the right and down. I mean, after running xcompmgr from the command line, you can no longer scroll (by placing the cursor on the screen edge) to the right or down. And even after killing the composite manager the problem persists. The left and up scrolling work fine. Also, if you restart fvwm, even with xcompmgr running, things go back to normal. So it must be something on the start of xcompmgr... Other wm's work flawlessly. I'm using a patched version of fvwm from the gentoo portage: it has the translucency patch applied. So if any of you are using a composite manager and it works ok with the unpatched fvwm, please let me know. Is there anything else I can do to help tracking the bug? Thanks! Cheers
Re: Fvwm and xcompmgr (the composite extension)
On 11/7/05, Dan Espen [EMAIL PROTECTED] wrote: seventh guardian [EMAIL PROTECTED] writes: Hi I've already posted a bug report on the fvwm mailing list some weeks ago regarding this, but no one answered. Today I switched to xorg-7.0.0 and the problem is still there, so it must be fvwm. The problem I found is related to the composite extension of xorg: when I run xcompmgr (the composite manager) fvwm looses the screen-scrolling abillity to the right and down. I mean, after running xcompmgr from the command line, you can no longer scroll (by placing the cursor on the screen edge) to the right or down. And even after killing the composite manager the problem persists. The left and up scrolling work fine. Also, if you restart fvwm, even with xcompmgr running, things go back to normal. So it must be something on the start of xcompmgr... Other wm's work flawlessly. I'm using a patched version of fvwm from the gentoo portage: it has the translucency patch applied. So if any of you are using a composite manager and it works ok with the unpatched fvwm, please let me know. Is there anything else I can do to help tracking the bug? Edge scrolling works by Fvwm creating invisible windows around the screen borders. xcompmgr must be interferring with them somehow. Try changing the 'edgethickness' to see if that helps. No, it's the same. I forgot to mention, I can drag windows between screens and it works fine. Only the empty handed scroll doesn't work. Run xwininfo -root -all to see if there is a window in the way. I really don't know how to read the output, and as it is quite large, here's a diff from both before and after running xcompmgr (command: diff before after -U 10) ~~~ --- before 2005-11-09 21:18:28.0 + +++ after 2005-11-09 21:18:40.0 + @@ -544,42 +544,22 @@ 1 child: 0x8001b5 (has no name): () 538x17+2+2 +420+465 2 children: 0x8001b0 (has no name): () 16x15+521+1 +941+466 0x8001af (has no name): () 520x15+1+1 +421+466 0x800014 (has no name): () 534x319+5+5 +422+140 2 children: 0x8000d1 (has no name): () 534x263+0+56 +422+196 2 children: 0x8000d2 (has no name): () 516x263+0+0 +422+196 - 12 children: - 0x800192 (has no name): () 20x20+27+214 +449+410 - 0x800193 (has no name): () 20x20+27+236 +449+432 - 0x80018d (has no name): () 20x20+27+90 +449+286 - 0x800184 (has no name): () 20x20+27+17 +449+213 - 0x80018a (has no name): () 20x20+27+39 +449+235 - 0x800194 (has no name): () 20x20+27+258 +449+454 - 0x80018e (has no name): () 20x20+27+112 +449+308 - 0x80018f (has no name): () 20x20+27+134 +449+330 - 0x800191 (has no name): () 16x16+5+197 +427+393 - 0x800190 (has no name): () 16x16+5+168 +427+364 - 0x80018c (has no name): () 16x16+5+73 +427+269 - 0x800186 (has no name): () 16x16+5+0 +427+196 0x800038 (has no name): () 18x263+516+0 +938+196 0x8000ea (has no name): () 534x56+0+0 +422+140 - 4 children: - 0x8001c4 (has no name): () 534x16+0+40 +422+180 - 1 child: - 0x800188 (has no name): () 16x16+5+0 +427+180 - 0x8001e2 (has no name): () 534x1+0+39 +422+179 - 0x800178 (has no name): () 502x39+32+0 +454+140 - 0x8001d9 (has no name): () 32x32+0+3 +422+143 0x40009e (has no name): () 18x18+493+3 +907+93 0x40009d (has no name): () 18x18+511+3 +925+93 0x40009c (has no name): () 18x18+529+3 +943+93 0x40009b (has no name): () 490x18+3+3 +417+93 0x400093 (has no name): () 21x21+0+0 +414+90 0x400095 (has no name): () 21x21+529+0 +943+90 0x400097 (has no name): () 21x21+0+427 +414+517 0x400099 (has no name): () 21x21+529+427 +943+517 0x400094 (has no name): () 508x3+21+0 +435+90 0x400096 (has no name): () 3x406+547+21 +961+111 @@ -656,20 +636,21 @@ ButtonPress ButtonRelease EnterWindow LeaveWindow Button1Motion Button2Motion Button3Motion Button4Motion Button5Motion ButtonMotion + Exposure StructureNotify SubstructureNotify
Re: argb visual patch against recent cvs
On 2/1/06, Marc Lehmann [EMAIL PROTECTED] wrote: Hi! The new argb visuals introduced by xorg have a serious drawback, namely, they don't work correctly unless the toplevel window has an ARGB visual. With my limited knowledge, I'd say this is a design problem within Xorg, but I seem to be alone with that notion. This means that each and every window manager needs special support just to support ARGB in client windows. Here is a small patch I wrote that implements such support for fvwm: http://data.plan9.de/fvwm-2.5-argb-visual.patch What it does is simply check wether the client window has an ARGB visual and, if yes, creates the frame window in the same visual. Nothing else should be changed by this patch. The only relevant problem I see is the detecting part, as xlib gives no indication about alpha channels (would need to use XRender just for that), so it assumes that 32 bit TrueColour means there is an alpha channel (one could check bits_per_rgb or so to be = 8, which means something weird is certainly going on, as 3*8 leave s8 bits unaccounted for). The other small uncleanlieness is the hardwired -1 for the pixel values, but that should hardly create any problems (all bits set boil down to opaque white - its not visible anyways, and is guarenteed to exist in such visuals). I was not sure what to do with the patch, I wrote it mainly for testing some things (not being a transparency geek myself), so I thought I'd send it to you to decide what to do with it :) If your patch does its work, I will gladly use it :) I'm an xorg extension geek ;)
Re: Module.h bug and sugestion
On 2/2/06, Dominik Vogt [EMAIL PROTECTED] wrote:
On Wed, Feb 01, 2006 at 02:58:27PM +, seventh guardian wrote:
Hi.
First of all, there's a minor bug in libs/Module.h: the funcion
SendFinishedStartupNotification() is declared twice (on lines 147 and
166).
With that asside, I'm writing a module for Fvwm to support the xorg's
Xevie extension. I really don't like to reinvent the wheel, so I'm
creating it inside the building tree, using Module.h and other helping
libs. (that's the reason why I found that bug).
I also found that there's a nice parsing function which is rarely used
by any of the other modules, ParseModuleArgs().
Actually it is not used at all.
It returns a struct
with the module args, including the two communication pipes. The
problem here is that the structure itself is strange to use, because
the other all the other functions genericaly require a pipe array,
fd*, with the first element as transmit pipe and the other as a
receive. So there are two alternatives here.
Um, I can't think of any function that needs a pipe array in any
module or the module library. Can you give examples?
void GetConfigLine(int *fd, char **tline)
{
(.)
SendText(fd, Send_ConfigInfo, 0);
(.)
packet = ReadFvwmPacket(fd[1]);
}
Either to ALLWAYS pass
them the to_fvwm pipe, which works because of their order in the
struct (but makes the code a little cryptic, like Receive(to_fvwm)),
There is no guarantee that this works.
or to copy them to an array fd[2], which uses twice as much memory
(not a real problem most of the times, but definitelly a bug).
With that said, my suggestion is this: to use a struct to store the
interface data (file descriptors, name, etc) and to make the functions
use that struct instead of the particular elements.
But ParseModuleArgs already allows this. It parses the module
arguments and passes back a structure that contains the number and
an array of options not yet parsed. It's easy to write more
parsing functions with this information, but it's actually not a
very good idea because modules should be configured by the config
file, not the command line (with some exceptions).
Yes, I know. But now functions rely on having two pipes and read/write
on them in a raw way. Having a proper (more complete) struct and
functions to work with it would make the code actually independent of
the real interface. Modules could communicate by TCP/IP and the module
wouldn't notice it at all (hum can't see the advantage of that, but I
guess you got my point).
That way more
helper functions would come up, such as a function that requests the
config info and calls a user defined parsing function to handle the
lines as they come up. Or a function to wait on the pipe for packets
and also passing them to a user defined parsing function. Having a
struct instead of scatered global vars makes that task easyer, as they
are all passed at once inside the struct.
Also, that way if someday (fvwm 3 maybe?) the module interface
changes, the modules themseves woudn't need to change that much.
The module packet interface changes once in a while, but I don't
see the command line changing anytime soon.
It
woudn't be that difficult to change the current modules to use the new
functions. Besides, all already compiled modules would work without
any change, and unofficial ones would compile perfectly as long as
they don't use the new Module.h. Also there could be an adaptation
time where both libs were supplied..
Those were my thoughts. Please comment..
Streamlining the module interface code is definitely worthwhile.
It's just that there are so many modules and so much work to do.
The first step would be to just *use* ParseModuleArguments
everywhere (without breaking all the existing code). Any further
changes can be made after that. I'm open to any patches.
Ok, I was suggesting to improve ParseModuleArguments before that, but
I believe I can do it. Of course there's got to be a change in that
example function (above) and maybe others..
I just needed to know if the work is worthwhile or not before doing
the actual work ;)
PS: there's a real bug on top of all this text ;)
Hint: Write two mails for two different topics to minimize the
risk the bad issue is forgotten.
Ok, got it.
Ciao
Dominik ^_^ ^_^
Cheers
Renato
Re: Module.h bug and sugestion
On 2/2/06, Dominik Vogt [EMAIL PROTECTED] wrote: So, the work can be split into several smaller steps: 1. Make all the modules use ParseModuleArgs() and copy the fds from the ModuleArgs struct to the arrays that are currently used by the modules. 2. Remove the fd arrays in the modules and use the fds in the ModuleArgs instead. 3. Make the service functions in Module.c use a (const ModuleArgs *) instead of passing individual arguments and adapt the modules. I'm working on it. I have a question though: modules usually use a global var to store the name lenght. Should it be stored in the ModuleArgs struct or should the modules call strlen() every time? Cheers, Renato Caldas
Patch: FvwmAnimate using ParseModuleArgs() - NOT WORKING YET
On 2/2/06, Dominik Vogt [EMAIL PROTECTED] wrote: So, the work can be split into several smaller steps: 1. Make all the modules use ParseModuleArgs() and copy the fds from the ModuleArgs struct to the arrays that are currently used by the modules. 2. Remove the fd arrays in the modules and use the fds in the ModuleArgs instead. 3. Make the service functions in Module.c use a (const ModuleArgs *) instead of passing individual arguments and adapt the modules. FvwmAnimate is mostly done for the 1st item in the list. I also made the code use the struct-name instead of the char *MyName global var. As for what isn't done yet in this module: FvwmAnimate uses some macros (yuch!) for the communication with fvwm. I used CatString3() for the places where we need the * char before the module name, but I really don't know what to do in with the macros. I thought of making them inline functions, but I would like to know what you think.. Search for these macros are not done yet in the patch and you will find it. With that problem aside, I hope FvwmAnimate users could test the new code to see if it works ok. Note that it is _not_ working right now because of those macros. Cheers! Renato Caldas
Re: Patch: FvwmAnimate using ParseModuleArgs() - NOT WORKING YET
On 2/4/06, seventh guardian [EMAIL PROTECTED] wrote: On 2/2/06, Dominik Vogt [EMAIL PROTECTED] wrote: So, the work can be split into several smaller steps: 1. Make all the modules use ParseModuleArgs() and copy the fds from the ModuleArgs struct to the arrays that are currently used by the modules. 2. Remove the fd arrays in the modules and use the fds in the ModuleArgs instead. 3. Make the service functions in Module.c use a (const ModuleArgs *) instead of passing individual arguments and adapt the modules. FvwmAnimate is mostly done for the 1st item in the list. I also made the code use the struct-name instead of the char *MyName global var. As for what isn't done yet in this module: FvwmAnimate uses some macros (yuch!) for the communication with fvwm. I used CatString3() for the places where we need the * char before the module name, but I really don't know what to do in with the macros. I thought of making them inline functions, but I would like to know what you think.. Search for these macros are not done yet in the patch and you will find it. With that problem aside, I hope FvwmAnimate users could test the new code to see if it works ok. Note that it is _not_ working right now because of those macros. Cheers! Renato Caldas OOPS forgot to send the patch itself.. here it goes. The patch goes against Fvwm-2.5.16. I guess FvwmAnimate hasn't changed in CVS.. If it has please tell me so that I can diff it against CVS. Cheers FvwmAnimate.patch Description: Binary data
Re: Patch: FvwmAnimate using ParseModuleArgs() - NOT WORKING YET
On 2/4/06, Dan Espen [EMAIL PROTECTED] wrote: I think you need to keep the asterisk at the front of the name. There are times when you need it there, and times when you don't. It's easier to put it there in the first place rather than trying to stick it back when you need it. Yes, it is far more efficient that way. But the problem is that the existing structure only stores the name, and not the asterisk. Of course we could use the existing char* MyName, but that would defeat the whole purpose of using the ModuleArgs struct. I wonder if we need the asterisk in the first place. Wouldn't it be easyer new-code-wise to use only the name for pattern matching? It could be stripped off by fvwm or simply not used in the config files. (since this is only experimental code we are allowed to forget backward compatibility issues) Since I put the macros there and I like to use macros, I have to ask what you think is wrong with them. Personally, I find that the more compact the code is, the easier it is to read. Sorry, it's just my personal liking. Macros are also ok, what I don't like in macros is that the code appears to be standard C but it's not (it has its own syntax..). And if it worked perfectly with the old code, it's puzling me with the new one: Assuming we are to replace char* MyName with the struct, I currently don't know what to do with one of the existing macros (the one that uses the asterisk'ed name). Forgive my macros' ignorance, but I don't know what to do to call CatString3() from within the macro.
Re: Patch: FvwmAnimate using ParseModuleArgs() - NOT WORKING YET
On 2/4/06, Dan Espen [EMAIL PROTECTED] wrote: seventh guardian [EMAIL PROTECTED] writes: On 2/4/06, Dan Espen [EMAIL PROTECTED] wrote: I think you need to keep the asterisk at the front of the name. There are times when you need it there, and times when you don't. It's easier to put it there in the first place rather than trying to stick it back when you need it. Yes, it is far more efficient that way. But the problem is that the existing structure only stores the name, and not the asterisk. Of course we could use the existing char* MyName, but that would defeat the whole purpose of using the ModuleArgs struct. I wonder if we need the asterisk in the first place. Wouldn't it be easyer new-code-wise to use only the name for pattern matching? It could be stripped off by fvwm or simply not used in the config files. (since this is only experimental code we are allowed to forget backward compatibility issues) Eventually you have to deal with compatibility. Yes, but unless there's a reason for the use of the asterisk, it is cleaner not to have it. Configuration keywords are changing all the time, it won't be that difficult to strip the * from the config files. By the way, anyone knows why is the asterisk there for? FvwmAnimate mallocs the storage for MyName and never frees it. I don't consider that a leak since it does it one time. Me neither. But it definitely makes sense to only use one location for the same data. We could arrange to free it though. You can change ParseModuleArgs to malloc the space for the name including the *. Then you have 2 choices: Pass the address of the second byte and change FvwmAnimate to refer to the full name as name-1 or Pass the address of the first byte and change all the modules that want the name without the asterisk to reference name+1. Yes, it's possible. The question is, is it worth the complication? Since we are redoing things let's cut the problems from the root: is there any reason for the existance of the asterisk? If not it would be _a lot_ simpler just to use the name. What it seems to me is that the module side has no need for it. It in fact makes thigs trickier. On the other hand, fvwm side may rely on it to sort out the module configs. Why can't fvwm just strip the leading * from the configs? Since I put the macros there and I like to use macros, I have to ask what you think is wrong with them. Personally, I find that the more compact the code is, the easier it is to read. Sorry, it's just my personal liking. Macros are also ok, what I don't like in macros is that the code appears to be standard C but it's not (it has its own syntax..). C macros are part of standard C. Wrong choice of words. I meant they have their special syntax, which can be misleading sometimes. And if it worked perfectly with the old code, it's puzling me with the new = one: Assuming we are to replace char* MyName with the struct, I currently don't know what to do with one of the existing macros (the one that uses the asterisk'ed name). Forgive my macros' ignorance, but I don't know what to do to call CatString3() from within the macro. Since CatString3 returns the addess of the static buffer, it should work fine. Yep, just tested it, it works just like you are using it with macros. I think you have something else going on. My fault. It's working now. The working patch goes attached. FvwmAnimate.patch Description: Binary data
Re: Patch: FvwmAnimate using ParseModuleArgs() - NOT WORKING YET
On 2/4/06, Mikhael Goikhman [EMAIL PROTECTED] wrote: On 04 Feb 2006 16:56:47 +, seventh guardian wrote: existing structure only stores the name, and not the asterisk. Of course we could use the existing char* MyName, but that would defeat the whole purpose of using the ModuleArgs struct. I wonder if we need the asterisk in the first place. Wouldn't it be easyer new-code-wise to use only the name for pattern matching? It could be stripped off by fvwm or simply not used in the config files. (since this is only experimental code we are allowed to forget backward compatibility issues) Eventually you have to deal with compatibility. Yes, but unless there's a reason for the use of the asterisk, it is cleaner not to have it. Configuration keywords are changing all the time, it won't be that difficult to strip the * from the config files. Here you speak about the fvwm configuration. You can't omit the asterisk without inventing a new syntax that does not conflict with the syntax of fvwm commands and functions. I see no problem in the asterisks syntax, it seems to be more optimal than other possible syntaxes for module configs. By the way, anyone knows why is the asterisk there for? Here I suppose you ask about the asterisk sent in M_CONFIG_INFO packets. I suggest you to learn the fvwm-to-module protocol more in depth. You may run FvwmGtkDebug or FvwmDebug to see what is sent by fvwm to a module on its Send_ConfigInfo request. You may discover that the asterisk is needed to distinguish from other M_CONFIG_INFO packets that carry a non module configuration. BTW, perllib solves this by having two tracker types, GlobalConfig and ModuleConfig, so a module in perl has a nice API. Yes, but as I found in the source code, modules distinguish them by looking for the *FvwmMyname string instead of just the asterisk. I don't know about perl, but c modules usually do that. In this case it would be as easy to look for just for FvwmMyname, without needing either the asterisked string or calling CatString3. Redesigning the module protocol may be fine in the future, but this would mean much larger changes than you think. A good suggestion may be, for example, to add a new module packet MX_MODULE_CONFIG carrying the configuration line without the leading *FvwmModule: , and not just omitting an asterisk, as you suggest. Please do not break any compatibility right now. Let's not forget, we are in the freeze before 2.6.0. I guess you're right. Breaking compatibility now would be a waste of time, since it's going to be redesigned again for 2.6.. So we're back to the issue of using CatString3 or not..
Patch: FvwmAuto using ParseModuleArgs()
Here goes the patch for making FvwmAuto use the ParseModuleArgs(), just like with FvwmAnimate. I must confess this was really straight-forward. I should have started from this one.. Cheers! Renato Caldas FvwmAuto.patch Description: Binary data
Module Alias standard and FvwmButtons
Hi. I'm changing the official modules to use the new ParseModuleArgs function, and I have a question regarding the module Alias argument. Is it in fact a protocol standard or is it something some modules use? I say that because some modules do use the argv[6] as an alias, but others get the name by other means from the args. Like FvwmButtons, which assumes the first unmarked argument as an alias. This is not necessarilly argv[6]. So the question is, do we want a real protocol extension for this or just a common thing. It makes no sense to use ParseModuleArgs unless it does simplify the module. I can change FvwmButtons to use argv[6] as an alias right now. But there would need to be an updating of the manual, and maybe lots of people would need to change their configs.. Cheers, Renato Caldas
Patch: FvwmConsole using ParseModuleArgs() and minor corrections
Hi. Here goes a patch for FvwmConsole. I've noticed there was an excess of vars for dealing with the module's name. I've corrected that too. I've tested it myself and it works ok. One question: there is a #define for a constant FARGS, the minimum number of args required for the module. It was set to 6, but since it was used only for parsing the user args, I've changed it to 0 (the minimum value of module-user_argc). Since there is no plan to change that in the future, I wonde if we can remove it. Anyway, here goes the patch. PS: Mikhael, I'm skipping FvwmButtons. Cheers, Renato Caldas FvwmConsole.patch Description: Binary data
Re: Module.h bug and sugestion
On 2/8/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Tue, Feb 07, 2006 at 09:01:34PM +, seventh guardian wrote: On 2/5/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Sat, Feb 04, 2006 at 02:27:20PM +, seventh guardian wrote: On 2/2/06, Dominik Vogt [EMAIL PROTECTED] wrote: So, the work can be split into several smaller steps: 1. Make all the modules use ParseModuleArgs() and copy the fds from the ModuleArgs struct to the arrays that are currently used by the modules. 2. Remove the fd arrays in the modules and use the fds in the ModuleArgs instead. 3. Make the service functions in Module.c use a (const ModuleArgs *) instead of passing individual arguments and adapt the modules. I'm working on it. I have a question though: modules usually use a global var to store the name lenght. Should it be stored in the ModuleArgs struct or should the modules call strlen() every time? I see no reson for not putting it in the ModuleArgs struct. Done. Here's a patch incase you haven't already written one. Thanks, but can you please make a single patch out of this one and your various module patches up to now? It's much less work for me to apply and cross read. And please include ChangeLog entries for every file and function you changed. Sure. Here goes the patch against cvs. (I'll work on the cvs version from now on) Cheers! Renato Caldas
Re: Module.h bug and sugestion
Sure. Here goes the patch against cvs. (I'll work on the cvs version from now on) OOPS again.. forgot the actual patch.. Renato Caldas patch Description: Binary data
Re: Module.h bug and sugestion
On 2/8/06, seventh guardian [EMAIL PROTECTED] wrote: Sure. Here goes the patch against cvs. (I'll work on the cvs version from now on) OOPS again.. forgot the actual patch.. Renato Caldas Sorry, I had a bug in the previous patch. This new one is corrected. Cheers, Renato Caldas patch Description: Binary data
Re: Patch: FvwmAnimate using ParseModuleArgs() - NOT WORKING YET
On 2/4/06, Dan Espen [EMAIL PROTECTED] wrote: seventh guardian [EMAIL PROTECTED] writes: On 2/4/06, Dan Espen [EMAIL PROTECTED] wrote: I think you need to keep the asterisk at the front of the name. There are times when you need it there, and times when you don't. It's easier to put it there in the first place rather than trying to stick it back when you need it. Yes, it is far more efficient that way. But the problem is that the existing structure only stores the name, and not the asterisk. Of course we could use the existing char* MyName, but that would defeat the whole purpose of using the ModuleArgs struct. I wonder if we need the asterisk in the first place. Wouldn't it be easyer new-code-wise to use only the name for pattern matching? It could be stripped off by fvwm or simply not used in the config files. (since this is only experimental code we are allowed to forget backward compatibility issues) Eventually you have to deal with compatibility. FvwmAnimate mallocs the storage for MyName and never frees it. I don't consider that a leak since it does it one time. We could arrange to free it though. You can change ParseModuleArgs to malloc the space for the name including the *. Then you have 2 choices: Pass the address of the second byte and change FvwmAnimate to refer to the full name as name-1 or Pass the address of the first byte and change all the modules that want the name without the asterisk to reference name+1. Giving it a better thought, probably using the first option will be better than using CatString3. Since the work I'm doing will eventually allow us to replace the args for InitGetConfigLine with the whole struct, and probably to remove the *FvwmAnimate part of the line before it is given to the user (maybe using something similar to GlobalConfig and ModuleConfig in perl), the module-name-1 string will only be used inside the Module.c functions. Being so it makes sense to have module-name availiable in a straightforward way for user output, and having module-name-1 still availiable for some obscure user function. For now I would ask you to tolerate the current use of CatString3 to avoid making those changes to Module.h, as it makes things easier for me. Cheers! Renato Caldas
Re: Module.h bug and sugestion
On 2/9/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Wed, Feb 08, 2006 at 02:05:14PM +, seventh guardian wrote: I've committed the patch to CVS (and removed the FARGS macro from FvwmConsole). For further patches, please always add a list of modified functions to the ChangeLog after the name of the .c file. This simplifies maintenance enormously. Here goes a second patch. I've added the list of modified functions after the file name, except for the main function. I followed the style of some of your entries in the changelogs, hope I've done it ok. As you said once, the command line syntax isn't going to change that much, even for 3.0. But even so, some coding styles make it difficult to use properly the ParseModuleArgs (or functions alike) regarding the module aliases. I wonder if there could be fixed a standard for aliases. I mean a true standard that modules using aliases should follow. The argv[6] rule would be ok, but it would break some config files. Obviosly some kind of wrapper could be used to avoid those breakings, like in FvwmRearrange. I wonder what you think about this. Without a proper standard, some modules using ParseModuleArgs won't be as clean as they should be. I'm skipping them for now, wainting for a definite solution. Cheers Renato Caldas patch2.patch Description: Binary data
Re: Module.h bug and sugestion
On 2/9/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Thu, Feb 09, 2006 at 03:32:44PM +, seventh guardian wrote: On 2/9/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Wed, Feb 08, 2006 at 02:05:14PM +, seventh guardian wrote: I've committed the patch to CVS (and removed the FARGS macro from FvwmConsole). For further patches, please always add a list of modified functions to the ChangeLog after the name of the .c file. This simplifies maintenance enormously. Here goes a second patch. I've added the list of modified functions after the file name, except for the main function. I followed the style of some of your entries in the changelogs, hope I've done it ok. Actually, its not my personal style but what xemacs (and emacs?) generate when you move the cursor into a function and the press ctrl-x 4 a. (Unfortunately more recent versions of xemacs changed the style of the function list which makes it more difficult to grep through it. As you said once, the command line syntax isn't going to change that much, even for 3.0. But even so, some coding styles make it difficult to use properly the ParseModuleArgs (or functions alike) regarding the module aliases. I wonder if there could be fixed a standard for aliases. I mean a true standard that modules using aliases should follow. The argv[6] rule would be ok, but it would break some config files. Obviosly some kind of wrapper could be used to avoid those breakings, like in FvwmRearrange. I wonder what you think about this. The one problem with that approach is that such a change would break all third-party modules. Hum, you're right. What about making the change only for official modules, those using Module.h? I don't know if third party modules use Module.h, but they will break anyway if that file changes.. Without a proper standard, some modules using ParseModuleArgs won't be as clean as they should be. I'm skipping them for now, wainting for a definite solution. Cheers Renato
Re: Module.h bug and sugestion
On 2/9/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Thu, Feb 09, 2006 at 04:08:00PM +, seventh guardian wrote: On 2/9/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Thu, Feb 09, 2006 at 03:32:44PM +, seventh guardian wrote: On 2/9/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Wed, Feb 08, 2006 at 02:05:14PM +, seventh guardian wrote: I've committed the patch to CVS (and removed the FARGS macro from FvwmConsole). For further patches, please always add a list of modified functions to the ChangeLog after the name of the .c file. This simplifies maintenance enormously. Here goes a second patch. I've added the list of modified functions after the file name, except for the main function. I followed the style of some of your entries in the changelogs, hope I've done it ok. Actually, its not my personal style but what xemacs (and emacs?) generate when you move the cursor into a function and the press ctrl-x 4 a. (Unfortunately more recent versions of xemacs changed the style of the function list which makes it more difficult to grep through it. As you said once, the command line syntax isn't going to change that much, even for 3.0. But even so, some coding styles make it difficult to use properly the ParseModuleArgs (or functions alike) regarding the module aliases. I wonder if there could be fixed a standard for aliases. I mean a true standard that modules using aliases should follow. The argv[6] rule would be ok, but it would break some config files. Obviosly some kind of wrapper could be used to avoid those breakings, like in FvwmRearrange. I wonder what you think about this. The one problem with that approach is that such a change would break all third-party modules. Hum, you're right. What about making the change only for official modules, those using Module.h? Hm, what about passing the module alias as an environment variable? It's ugly, but we're already doing it with FVWM_VISUALID and FVWM_COLORMAP. An FVWM_MODULE_ALIAS wouldn't do further harm. Do you mean something like Module ALIAS=mypager FvwmPager ? Using an evironment var for the alias would break third party modules, unless we also provide it via command args. Even discarding that, wouldn't it need major changes in the way fvwm interprets the config file? However, this doesn't solve the syntax issue on the fvwm side. What can we do about invocations like FvwmButtons ColourTable (right from my config file)? Okay, let's see how big the mess is: 1) Modules that currently support the syntax modulename [alias] without further command line args: Animate, CommandS, Form, Gtk, IconBox, TaskBar 2) Modules which do not accept any command line options, icluding aliases: Backer, DragWell, Ident, Proxy, Save, SaveDesk, Scroll, Theme, Wharf 3) Modules which do not have any config lines: Auto, Save, SaveDesk 4) Modules which only accept command line options beginning with '-': Console, Debug, GtkDebug, Rearrange, Tabs 5) Modules which accept a list of '-' options followed by a single argument that does not begin with '-' (and is not an alias): Cpp, M4 6) Modules that accept a single non-alias argument: Banner, Script 7) Weird cases: * Buttons Possible arguments are ['-'options] [alias] [cfgfile] Iterates over its arguments. For each argument it checks if it's an option with '-' first. If not (or the same option was encountered earlier), it's taken as the alias. If the alias is already define, it's taken as the cfgfile. If the cfgfile is already defined, it's ignored. YUCK! Mikhael is going to clean this one up. Maybe it could be redesigned, who knows? * OldDebug Can be invoked as one of OldDebug OldDebug alias OldDebug -v OldDebug -v alias OldDebug alias -v YUCK! OldDebug doesn't even compile anymore, and no one complained. I believe it may be removed from the building tree.. * Event Can be invoked as one of Event Event -audio Event alias Is the -audio option used at all? I believe not, but I may be wrong.. Even so, it only supports only either -audio or an alias, so I believe it's broken. As a side note, the module does two distinct things, so shouldn't it be splitt up into FvwmEvent and FvwmAudio? Is the Audio part used anyway? * IconMan Can be invoked as IconMan IconMan alias IconMan transient IconMan -transient IconMan transient alias IconMan -transient alias * Pager Same as IconMan, but may be followed by one or two desk numbers or asterisks. * Perl Can be invoked as Perl ['-'options] [alias] * WindowMenu Takes options without a '-' prefix but no alias
Re: Module.h bug and sugestion
On 2/10/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Thu, Feb 09, 2006 at 11:25:42PM +, seventh guardian wrote: On 2/9/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Thu, Feb 09, 2006 at 04:08:00PM +, seventh guardian wrote: On 2/9/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Thu, Feb 09, 2006 at 03:32:44PM +, seventh guardian wrote: [snip] As you said once, the command line syntax isn't going to change that much, even for 3.0. But even so, some coding styles make it difficult to use properly the ParseModuleArgs (or functions alike) regarding the module aliases. I wonder if there could be fixed a standard for aliases. I mean a true standard that modules using aliases should follow. The argv[6] rule would be ok, but it would break some config files. Obviosly some kind of wrapper could be used to avoid those breakings, like in FvwmRearrange. I wonder what you think about this. The one problem with that approach is that such a change would break all third-party modules. Hum, you're right. What about making the change only for official modules, those using Module.h? Hm, what about passing the module alias as an environment variable? It's ugly, but we're already doing it with FVWM_VISUALID and FVWM_COLORMAP. An FVWM_MODULE_ALIAS wouldn't do further harm. Do you mean something like Module ALIAS=mypager FvwmPager ? No, I don't know how to handle the command line yet, but maybe FvwmPager --alias foobar ... which would be recognized and handled by the fvwm core, or perhaps a separate ModuleAlias command, but that might be confusing, as many people don't use the Module command at all. But that was not my point. I was talking about a way to pass the alias to the module without putting it on the command line args of the module. The envvar allows to provide the module with an alias without disturbing its command line. Now I see your point. I agree, module aliases shouldn't disturb the command line. The envvar is a possible solution. Another one is making the alias mecanism _entirely_ a part of the fvwm core. Since the communication channel is point-to-point, a module wouldn't even need to know its own name, at least now. Aliases were useful when the config file parsing was done by the module itself. Now fvwm feeds the module with only global configs or its own configs (the filter being supplied by the module). So if you define an alias to a module inside the core, fvwm (core) would know it and would translate the module's requests to the aliased lines. For instance (using your example syntax): 1 - We call Module FvwmPager --alias foobar 2 - FvwmPager will name itself FvwmPager and would request the *FvwmPager lines. 3 - fvwm knows that this instance of FvwmPager is aliased as foobar and would search for the *foobar lines. 4 - fvwm then sends the *foobar lines to the module, but translated to *FvwmPager. Then we have two options: - Modules don't pass a matching string to fvwm and fvwm is entirely responsible of the module's aliases. - Modules continue to pass the matching string and fvwm translates it if an alias is defined in the core. Option 1 would be the cleanest, making the modules entirely alias-independent (probably the best solution for fvwm-3.0) Option 2 would allow for the current alias mecanisms to continue to work, but would be less efficient than option 1. Using an evironment var for the alias would break third party modules, unless we also provide it via command args. No, it wouldn't because aliases are not an official part of the module interface, as far as I know. The module classes (1) to (6) could easily be adapted to that logic without touching the way they interpret their arguments. Even discarding that, wouldn't it need major changes in the way fvwm interprets the config file? However, this doesn't solve the syntax issue on the fvwm side. What can we do about invocations like FvwmButtons ColourTable (right from my config file)? Okay, let's see how big the mess is: 1) Modules that currently support the syntax modulename [alias] without further command line args: Animate, CommandS, Form, Gtk, IconBox, TaskBar 2) Modules which do not accept any command line options, icluding aliases: Backer, DragWell, Ident, Proxy, Save, SaveDesk, Scroll, Theme, Wharf 3) Modules which do not have any config lines: Auto, Save, SaveDesk 4) Modules which only accept command line options beginning with '-': Console, Debug, GtkDebug, Rearrange, Tabs 5) Modules which accept a list of '-' options followed by a single argument that does not begin with '-' (and is not an alias): Cpp, M4 6) Modules that accept a single non-alias argument: Banner, Script 7) Weird cases
Re: Module.h bug and sugestion
On 2/10/06, Mikhael Goikhman [EMAIL PROTECTED] wrote: The module interface should be redesigned. Together with the module syntaxes. We may do it cleanly in 2.7 or 2.9 versions. The compatibility may be slightly broken then. I strongly prefer, however, to release 2.6 first, before any changes in the module interface. But when will 2.6 be released? 2.5 is mostly stable now, but there aren't even rumours about the release of a 2.6 version. We can't be delaying changes for ever.. Cheers Renato Caldas
Re: FVWM in the session screen
On 2/10/06, Giladi Mati-R57914 [EMAIL PROTECTED] wrote: Hi, I'm running RedHat3 WS U6 on my desktop. How do I configure the session in the Login screen to be able to choose FVWM also ( now the user can choose KDE and GNOME only ). I build the fvwm-2.4.19-1.src.rpm. Best Regards, Mati Please don't space your text that much. Also, this is _not_ the list to ask that. You should have tried the fvwm list first, (not the workers list), but in any case this has _nothing_ to do with fvwm. It's the entire responsability of your distro. Anyway, you could put #!/bin/bash /usr/bin/fwm2 in the file /etc/X11/Sessions/fvwm2 and make it executable. I have no idea if this applies to kdm though.. Please consult KDE's documentation. And please use google _before_ posting this kind of things in any mailing list. Cheers Renato Caldas
Re: Module.h bug and sugestion
On 2/10/06, Mikhael Goikhman [EMAIL PROTECTED] wrote: On 10 Feb 2006 08:35:04 +0100, Dominik Vogt wrote: On Fri, Feb 10, 2006 at 01:19:26AM +, seventh guardian wrote: Then we have two options: - Modules don't pass a matching string to fvwm and fvwm is entirely responsible of the module's aliases. - Modules continue to pass the matching string and fvwm translates it if an alias is defined in the core. Hm, would that break the old way FvwmIconMan requested its config liens? I mean *FvwmIconMan*1*foobar ... Instead of the new *FvwmIconMan: 1 foobar ... Or is that completely transparent to the modules? Mikhael? The second line is unfortunately (for backward compatibility with all other modules parsing their config) is sent as: *FvwmIconMan1 foobar ... FvwmIconMan simply supports 2 formats, old with *, and without *. Similarly, FvwmButtons config that looks like: *MyButtons: Frame 5 *MyButtons: (Container) is sent (again, for backward compatibility) as: *MyButtonsFrame 5 *MyButtons(Container) At least DestroyModuleConfig MyButtons: Width and DestroyModuleConfig MyButtons: * do the right thing, i.e. do not affect lines of another alias *MyButtonsFrame: Title my-frame. Of corse, the correct thing is to introduce MX_MODULE_CONFIG packet and new rules (a module may request from the core a config related to the module name, say FvwmScript, or related to its alias, say FvwmButtons, or both, say FvwmForm) and to send the config lines without any prefix. This requires rewrite of all modules and the core. Not before 2.6. I'm forced to agree, but when will 2.6 come out? I happende to step on this when I was trying the wiki: DV What about the future? Well, the work for the next stable series DV (2.6.x) is proceeding very well. Fvwm will go into feature freeze DV again near the end of the year so that 2.6 is ready before fvwm's DV tenth birthday on 1st of June, 2003. I have vague plans for a DV big event on that day to remind people that fvwm is still there DV and that it can easily compete with any other window manager. DV After that there are plans for a version 3.0 that would change a DV lot of the syntax and introduce fantastic new features, but that's DV too far from now. It has been a long time, and there are no major bugs now. Can we proceed to the next level? Cheers Renato Caldas
todo-2.6: E6 - rename FvwmProxy
Hi. After giving a look at the todo-2.6 list I got curious about what FvwmProxy actually does, and the name is a bit misleading. It's so nice I've just binded SendToModule FvwmProxy ShowToggle to the Super_L key. Anyway, on that list there's the entry E6, saying FvwmProxy should be renamed. I agree, and suggest FvwmWinTag. PS: I'm trying to give a kick-start to the 2.6 process. Cheers, Renato Caldas
Re: todo-2.6: E6 - rename FvwmProxy
On 2/10/06, Thomas Adam [EMAIL PROTECTED] wrote: On Fri, Feb 10, 2006 at 05:45:21PM +, seventh guardian wrote: Anyway, on that list there's the entry E6, saying FvwmProxy should be renamed. I agree, and suggest FvwmWinTag. I'm indifferent. Proxy makes sense to me in this case -- they're proxy windows that are bound to the current windows on the screen. In any case, we either decide to change it or remove the entry from the todo-2.6 file. I've given my suggestion, but it's not my call. Let's start cleaning up the todo list :) Cheers, Renato Caldas
Re: Module.h bug and sugestion
On 2/10/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Fri, Feb 10, 2006 at 05:03:09PM +, seventh guardian wrote: I happende to step on this when I was trying the wiki: DV What about the future? Well, the work for the next stable series DV (2.6.x) is proceeding very well. Fvwm will go into feature freeze DV again near the end of the year so that 2.6 is ready before fvwm's DV tenth birthday on 1st of June, 2003. I have vague plans for a DV big event on that day to remind people that fvwm is still there DV and that it can easily compete with any other window manager. DV After that there are plans for a version 3.0 that would change a DV lot of the syntax and introduce fantastic new features, but that's DV too far from now. It has been a long time, and there are no major bugs now. Can we proceed to the next level? It's just a matter of doing the tedious work, and it looks like nobody has the time to do it right now. We have a todo-2.6 that lists all the open issues, but that is several years old and needs updating. Here goes the 3rd patch (maybe the last), for the work I've done until yesterday. I will put this project on hold now, and see if I can help bringing 2.6 to life. Cheers, Renato Caldas patch3.patch Description: Binary data
Re: On module names and aliases
On 2/11/06, Mikhael Goikhman [EMAIL PROTECTED] wrote: On 10 Feb 2006 16:48:49 +, Mikhael Goikhman wrote: On 10 Feb 2006 08:25:41 +, Nick Fortune wrote: You'd write AliasModule FvwmButtons MonitorPanel DestroyModuleConfig MonitorPanel *MonitorPanel: (1x1, Swallow 'asclock' 'Exec exec asclock') # ... AddToFunc StartFunction + I Module MonitorPanel This is an option to consider, before redesigning the module interface. However, this syntax will require 2 lines for launching every module, AliasModule and Module, instead of just Module. And we also need UnaliasModule. I.e. now the user should predeclare all module instances he wants to use. I should rething this idea first before agreeing or disagreeing with it. Another serious problem with this suggestion is that now we start to manipulate with strings like ColourTable or MonitorPanel and have no any idea whether they are actually FvwmButtons, FvwmForm, FvwmScript, FvwmGtk or maybe even FvwmEvent. And these are very different modules with different configuration syntaxes and command line options. Several years ago I had and still have the following idea in mind, that seems to solve all problems. However it applies a restriction on the module alias name. And this is its only drawback. The alias name (or more correctly the module id) is anything that is modulename-subname. I.e. FvwmScript-ClockMonitor or FvwmForm-Talk. Now, a module should receive subname and not alias as we know it. Then this module id is used everywhere straightforwardly: Module FvwmButtons-Monitor -g 240x360 KillModule FvwmButtons-Monitor SendToModule FvwmButtons-Monitor PressButton 2 *FvwmButtons-Monitor: Colorset 1 I think, this syntax is pretty clean and self-descriptive. If a module does not accept multiple instances, then it may still be accessible as FvwmBanner (with no subname needed). The FvwmForm and FvwmScript configurations shipped with fvwm already follow this naming scheme. As well as all modules in fvwm-themes. I currently don't see a better solution for module ids. I like the idea, and it's definitely as clean as it can be. Also, aliases are exclusive to the configuration, and not visible in daily use. So there's really no drawback. I have one question though: how is this meant to be aplied? Is it pre- or post-2.6?
todo-2.6: E7 - FvwmProxy placement algorithm
Hi. I found this on the todo-list: E.7 Fix the FvwmProxy placement algorithm (it may loop and can place windows off screen) [dv: added on 02-Mar-2003] I've looked int othe code, but I really don't know what the bug is. Can please anyone point me to where to look, and how to trigger it? Then I cound put my hands on it.. PS: I'm really looking forward to the release of 2.6.. Cheers, Renato Caldas
Re: todo-2.6: E7 - FvwmProxy placement algorithm
On 2/16/06, seventh guardian [EMAIL PROTECTED] wrote: On 2/14/06, Mikhael Goikhman [EMAIL PROTECTED] wrote: On 14 Feb 2006 13:45:10 +, seventh guardian wrote: I found this on the todo-list: E.7 Fix the FvwmProxy placement algorithm (it may loop and can place windows off screen) [dv: added on 02-Mar-2003] I've looked int othe code, but I really don't know what the bug is. Can please anyone point me to where to look, and how to trigger it? Then I cound put my hands on it.. The mail archives are now fully searchable (more or less all years). You may go to http://www.mail-archive.com/fvwm-workers@lists.math.uh.edu/ and type FvwmProxy placement or any other search phrase. Thanks for the tip (oops, I should have searched first..) :) Anyway, It works perfectly so far (and passed the xterm -geom 10x5-0-0 xterm -geom 10x5-0-0 xterm -geom 10x5-0-0 test). Well, not perfectly. The algorythm is broken, and I suspect it was even before I messed with it. If I execute the above command about 5 times FvwmProxy crashes, as the windows start getting beyond the screen. It needs a more serious intervention, even though it shouldn't crash or misbehave in normal circumnstances.. In any case, I already know the problem, so with some time it will be easy to solve it. I have my last exam tomorrow, so.. Cheers Renato Caldas
Re: todo-2.6: E7 - FvwmProxy placement algorithm
On 2/14/06, Mikhael Goikhman [EMAIL PROTECTED] wrote: On 14 Feb 2006 13:45:10 +, seventh guardian wrote: I found this on the todo-list: E.7 Fix the FvwmProxy placement algorithm (it may loop and can place windows off screen) [dv: added on 02-Mar-2003] I've looked int othe code, but I really don't know what the bug is. Can please anyone point me to where to look, and how to trigger it? Then I cound put my hands on it.. The mail archives are now fully searchable (more or less all years). You may go to http://www.mail-archive.com/fvwm-workers@lists.math.uh.edu/ and type FvwmProxy placement or any other search phrase. Thanks for the tip (oops, I should have searched first..) :) Anyway, I found the problem and here's a correction. The code is a bit ugly now, so I will probably clean it up as soon as I get some time. Anyway, It works perfectly so far (and passed the xterm -geom 10x5-0-0 xterm -geom 10x5-0-0 xterm -geom 10x5-0-0 test). Here goes the patch. I've added a function to test if the proxy window is on screen (don't know if there is one already..). Cheers Renato Caldas proxy.patch Description: Binary data
Re: mkstemp bug in the FVWM 2.5 branch with possible security consequences
On 4/3/06, Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote: Good (day|morning|night) everyone, During examination of FvwmM4 '--debug' option I decided to examine FVWM's temporary file creation mechanism. Can you believe what I dig out: In libs/System.c there is a pragma '#ifdef HAVE_SAFTY_MKSTEMP'. This construction decides based on configure script system check whether to use underlying OS's mkstemp function (if it considered secure) or FVWM's internal one, which lies at the bottom of the same libs/System.c file. But acinclude.m4 defines 'HAVE_SAFETY_MKSTEMP' pragma, not 'HAVE_SAFTY_MKSTEMP' which found in libs/System.c. So, in any case FVWM's internal implementation of mkstemp used even if the OS have its own _much more secure_ version of this function. This bug probably existed for almost three years and was introduced on 2003-08-27 according to main Changelog. I attached patch which applies cleanly against 2.5.x CVS sources. It also corrects all other 'safty' typos in the source tree. Somebody on the list needs to verify stable 2.4 branch also. Wow! And there must be more, as the code is quite old.. This example shows that a single typo can potentially lead to the big disaster. I hope it will be good lesson to all of us. In future, all workers should review every commit more attentively. It's much easier to not introduce newer bugs and typos than to find and fix them afterwards. I wonder, was FVWM's code extensively audited? Who knows that may be lurking inside? I guess there should be a complete rewrite for the next major version, but on the other hand there's a need to release a stable 2.6.. And this last task is proving to be quite discouraging, as people with new ideas tend to get bored when all they should do is to clean up the old code.. There's a TODO list in the source that must (should) be done before the next release. Auditing the code may be a huge task, but it surely helps the next release, and any help is wellcome! On the other hand it can be useless in the iminence of a major rewrite, so if there is really going to be one, maybe we should audit the code as we rewrite it, having the errors corrected on the stable 2.6 version. This is just my two cents, anyone is free to disagree.. Cheers! Renato Caldas
Re: FvwmTaskBar fixes, `Pad' documentation fvwm-bug fixes
On 4/7/06, Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote: Hi, dear developers, 1) First of all, the entire FvwmTaskBar module is broken in the current CVS tree. Because of incorrect module-namelen calculation it does not parses its configuration entries properly. I fixed this, quality assured this and provided a patch. Golden rule to all: test before commit. That's probably my fault. Sorry.. BTW, you're doing a great job! I wonder if we can get a new stable release this year! :D Cheers! Renato Caldas
Re: Possible patches
On 6/6/06, David Maciver [EMAIL PROTECTED] wrote: Hello devs, I've created a patchset[1] to try to improve the way fvwm looks. I've been using it for a while and made various themes and it seems to work ok. Some of it is inefficient and incomplete, but I can clean it up if you want. I was wondering if you were interested in any of the features for the main branch. I'm not sure what can be added before 2.6/3.0 so I haven't planned on commiting but some of the patches are quite small and might be worth a look. [1] http://abdn.ac.uk/~u15dm4/fvwm/ I really liked the following patches: -FlatSeparators -InactiveFont -RoundedCorners -MultiBorder -Hover I also think most of the others are good too. The question is, can they be thrown in without sacrificing performance. I'm affraid I cannot answer that. Maybe in a future version the window/menu decorations could be modular, and then everyone could choose how much looks or performance they want. Before that, it's just a matter of weighting the pros and cons. And that should be the task of the senior devs.. (read the guys who know best). Anyway, good job! Renato Caldas
Re: ModuleListenOnly command
On 6/24/06, Mikhael Goikhman [EMAIL PROTECTED] wrote: On 24 Jun 2006 16:35:21 +0200, Dominik Vogt wrote: On Sat, Jun 24, 2006 at 02:08:43PM +, Mikhael Goikhman wrote: I can't say I am very happy about this. Actually, I would not be happy about any new feature added without discussion before 2.6.0. :) Hm, I don't see that happen in the foreseeable future. Nobody is doing anything in that direction. But is this a reason to make this task harder? Can we release a 2.6.0-rc1 and move on? Then while some would maintain it until a real 2.6.0, some would be working on 2.7. For the volunteers it's a matter of deciding to either help on perfecting 2.6.0 or on improving 2.7.0. The way things are, the project either dies or someone forks it. It's not going forward if we don't allow it to. Can we do it? Cheers, Renato
Re: ModuleListenOnly command
On 6/24/06, Thomas Adam [EMAIL PROTECTED] wrote: On Sat, Jun 24, 2006 at 10:09:03PM +0100, seventh guardian wrote: Can we release a 2.6.0-rc1 and move on? Then while some would maintain it until a real 2.6.0, some would be working on 2.7. For the volunteers it's a matter of deciding to either help on perfecting 2.6.0 or on improving 2.7.0. I wouldn't advise this, since all that is doing is playing version numbers games without there being any forethought or intent behind that move, other than to fit some psychological need that 2.6.0 *has* to be released soon. Well, if new features aren't welcome until 2.6.0 comes out, then there is a purpose of releasing 2.6.0. Many things have yet to be done -- that's evident all over the place, based what is in the TODO file, and what has already resulted from previous discussions on this list. What would probably have to happen before 2.6.0 is even thought about is a brain-storming idea, and prioritising those features currently out standing, or in the current 2.5.X tree that need fixing/improving. And be warned: it's going to take *a lot* of work. I had always hoped that when 2.6.0 hit, that would more or less mark the starting point for what the (very distant) FVWM3 might become. So the question is this: before all the numbers change in terms of versioning, and the happy-go-lucky followers of higher numbers means better software jump on their bandwagon, what needs doing? The problem, if it can be called so, is that fvwm uses the numbering scheme od - unstable, even - stable. Current version, 2.5.0 is almost stable, which prevents any major change, so there's really no unstable version now. Everything is frozen until 2.6.0 comes out, which (as so many times stated) may never hapen.. The way things are, the project either dies or someone forks it. It's not going forward if we don't allow it to. Welcome to the wonderful world of $REAL_LIFE. Things, alas, get in the way. Volunteers help when they can and WHERE they want. It's allways that way.. If the volunteers want to improve fvwm in a way that may break the current almost stable version, then I guess they should be allowed to. If that means playing with numbers, then why not? Renato -- 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: Grabbing and complex functions
On 6/28/06, Scott Smedley [EMAIL PROTECTED] wrote: Hi Mikhael, DefineFunc would behave much like AddToFunc except for 3 differences: 1. It would generate a warning message if the function already existed. This is bad. Configs should usually be re-read-able. Instead, it should silently apply DestroyFunc. In fact, DefineFunc (combining DestroyFunc and AddToFunc) is something I wanted to have for a long time. Good idea. It is ok by me to add DefineFunc before 2.6.0, if it fixes issues. Particularly, will it fix reliability of (re-)Schedule? In my opinion, it's not Schedule that is broken/unreliable. _Any_ function may fail to execute if the pointer is grabbed for ~1 second at the time of execution. With the proposed modifications, NoGrab functions will not be prone, to this failure. ie. if Schedule invokes a NoGrab function, it will execute - even if the pointer is grabbed by some other app. This patch is available at: http://members.optusnet.com.au/scottsmedley/fvwm/defineFunc.patch Apply with: patch -p0 defineFunc.patch A question about the implementation: Given this function DefineFunc MyFunc NoGrab + I Echo hello world + C Echo click should FVWM generate a warning (or error?) about using a non-I (immediate) condition within a NoGrab function? Perhaps reverting the function to a normal Grab function? Hum.. I supose the warning/error should be generated. Reverting a function to a normal grab function would allow the abuse of NoGrab, which may be a source of false bugs.. But on the other hand it would make it more robust.. I can't decide on that.. Also, I took the liberty of adding an AllImmediate function option which allows the condition to be omitted. For example: DefineFunc MyFunc NoGrab AllImmediate + Echo hello + Echo world which I find much more intuitive. The AllImmediate flag indicates that all actions are I - immediately executed. How do others feel about this option? If there are objections I will happily remove it. Yes, but on the other hand it would break the standard way of defining functions, which defeats the intuitive advantage.. I don't like the AllImmediate option :P.. Cheers, Renato SCoTT. :)
debug vs fvwm_debug_msgs
Hi. I have found FVWM_DEBUG_MSGS and DEBUG ifdef's all over the code (as expected). But it seems to me they are allways used at the same time, one defining the other, and thus replaceable just by one of them. Is this true or do they have distinct purposes? This supports my theory (from fvwmsignal.c): (...) #ifdef FVWM_DEBUG_MSGS volatile sig_atomic_t debug_term_signal = 0; #endif (...) #ifdef DEBUG debug_term_signal = sig; #endif (...) So if FVWM_DEBUG_MSGS is not defined then we have an error. But for instance FVWM_DEBUG_MSGS is defined by #ifdef DEBUG on FvwmPager, so.. If they are used for the same purpose, then I'll clean the code up to just use DEBUG. Cheers, Renato
Re: debug vs fvwm_debug_msgs
On 7/5/06, seventh guardian [EMAIL PROTECTED] wrote: Hi. I have found FVWM_DEBUG_MSGS and DEBUG ifdef's all over the code (as expected). But it seems to me they are allways used at the same time, one defining the other, and thus replaceable just by one of them. Is this true or do they have distinct purposes? This supports my theory (from fvwmsignal.c): (...) #ifdef FVWM_DEBUG_MSGS volatile sig_atomic_t debug_term_signal = 0; #endif (...) #ifdef DEBUG debug_term_signal = sig; #endif (...) So if FVWM_DEBUG_MSGS is not defined then we have an error. But for instance FVWM_DEBUG_MSGS is defined by #ifdef DEBUG on FvwmPager, so.. If they are used for the same purpose, then I'll clean the code up to just use DEBUG. After a bit of dig up, I realised that FVWM_DEBUG_MSGS is the true fvwm debug var (it is defined conditionally on config.h by ./configure). Some modules link to libfvwm.a, which should be already compiled (at least after the first module requiring it). The question is, DEBUG is only defined in the modules, which means that libfvwm.c is never compiled with debug support (see the code snipet on the first mail). Can this be confirmed or am I crazy? :) Renato Cheers, Renato
Re: debug vs fvwm_debug_msgs
On 7/6/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Wed, Jul 05, 2006 at 02:35:10PM +0100, seventh guardian wrote: On 7/5/06, seventh guardian [EMAIL PROTECTED] wrote: Hi. I have found FVWM_DEBUG_MSGS and DEBUG ifdef's all over the code (as expected). But it seems to me they are allways used at the same time, one defining the other, and thus replaceable just by one of them. Is this true or do they have distinct purposes? This supports my theory (from fvwmsignal.c): (...) #ifdef FVWM_DEBUG_MSGS volatile sig_atomic_t debug_term_signal = 0; #endif (...) #ifdef DEBUG debug_term_signal = sig; #endif (...) So if FVWM_DEBUG_MSGS is not defined then we have an error. But for instance FVWM_DEBUG_MSGS is defined by #ifdef DEBUG on FvwmPager, so.. If they are used for the same purpose, then I'll clean the code up to just use DEBUG. After a bit of dig up, I realised that FVWM_DEBUG_MSGS is the true fvwm debug var (it is defined conditionally on config.h by ./configure). Some modules link to libfvwm.a, which should be already compiled (at least after the first module requiring it). The question is, DEBUG is only defined in the modules, which means that libfvwm.c is never compiled with debug support (see the code snipet on the first mail). Can this be confirmed or am I crazy? :) Actually, there is no plan or design behind all the debug code. It just appeared independently in the places where it was needed at the given time. Nowadays nobody can tell between usefull debug code and stuff that is not needed anymore. The only useful module debug code I am aware of is in the FvwmAuto module. Hum so what's the wise step? I'm thinking of doing a clean up, but I'm not sure on wich policy to follow.. Renato Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFErORgmeSprTOr4tgRAo6iAKDnJArXWLeZQZBGuFW4RhWzPmchXQCg4FcD 1ZMpTXNrw5dLakifhi2KKJ4= =ULOv -END PGP SIGNATURE-
debug code cleanup patch #1
Hi. This is a debug code cleanup patch: It removes most of the FvwmPager debug code (very old), also removing useless debug code from fvwmsignal.c and fvmwsignal.h. It also removes an unused #define from libs/PictureUtils.c, which Olivier forgot to remove :P I've only put safe changes on this patch, but please check if it doesn't remove useful code (or if I was too conservative.. who knows?). Cheers, Renato cleanup_patch Description: Binary data
Re: debug code cleanup patch #1
On 7/6/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Thu, Jul 06, 2006 at 05:20:14PM +0100, seventh guardian wrote: Hi. This is a debug code cleanup patch: It removes most of the FvwmPager debug code (very old), also removing useless debug code from fvwmsignal.c and fvmwsignal.h. It also removes an unused #define from libs/PictureUtils.c, which Olivier forgot to remove :P I've only put safe changes on this patch, but please check if it doesn't remove useful code (or if I was too conservative.. who knows?). The patch looks fine. I'll commit it. By the way, do you have commit privileges for CVS? No, I don't.. Am I ready for it? :) Renato Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFErWDOmeSprTOr4tgRAkplAJ96hAFJH5Q0haNuVdIjaXtPW98/BgCeKsO3 ED8VfM9VdvXGaJ4UPrNGFQ0= =1P8S -END PGP SIGNATURE-
Re: debug code cleanup patch #1
On 7/7/06, Dan Espen [EMAIL PROTECTED] wrote: Bob Woodside [EMAIL PROTECTED] writes: On Thursday 06 July 2006 16:19, Dominik Vogt wrote: On Thu, Jul 06, 2006 at 08:23:50PM +0100, seventh guardian wrote: On 7/6/06, Dominik Vogt [EMAIL PROTECTED] wrote: The patch looks fine. I'll commit it. By the way, do you have commit privileges for CVS? No, I don't.. Am I ready for it? :) I think so :-) Any second vote for Renato? I'll cast a second . Third. Renato, if you haven't seen it already, check the Fvwm web site Developer section for getting commit access. Ok :) I'll send the login and encrypted passwd to Jason. Cheers Renato -- Dan Espen E-mail: [EMAIL PROTECTED]
Re: debug.c still useful?
On 7/7/06, Dan Espen [EMAIL PROTECTED] wrote: seventh guardian [EMAIL PROTECTED] writes: Hi. After some checking around, it seems that the file libs/debug.c isn't used anymore. The file was created in 1998 as a debuging library, but it seems to have been replaced by simpler solutions. It's part of libfvwm.a, and the *.c code is surrounded by a #ifdef DEBUG, so never gets compiled. The whole file is empty at the moment, except for an int variable that is there (outside the #ifdef) expressly to prevent an empty file, as some compilers don't like that (it's written on the coments). On the other hand, the header file fvwmlib.h has its macros and structs allways defined, (but there is no compiled code!). Nothing is ever used, so I think it's safe to remove it. These are the only places where you find the macros (which need to be removed ): - DB() is in a #if 0 part of module_interface.c (but the rest of the file already uses the DBUG macro) and in focus. - __FILE__ and __LINE__ is in a ifdef'ed to 0 part of focus.h where alternative debuging macros are defined. It's a big decision to remove a whole file, so I need a second opinion.. Is the file still useful or may I remove it? The whole debug facility is rarely used, and I can't remember it ever being useful. I find the stuff in FvwmAnimate/FvwmForm suits my own personal needs. Ok then, I'll commit the changes. There's allways the possibility to revert them any time.. Renato -- Dan Espen E-mail: [EMAIL PROTECTED]
Libtool ltdl on fvwm
Hello all. It all starts with this snip from docs/TODO: - Implement (or at least investigate) dynamic loading of functions on systems that support it? (There is more on that on that file. These are just the first two lines) Recently I began testing GNU's Libtool on a project of mine, particulary using Ltdl. Ltdl is a dynamic library loading framework. It allows dynamic loading of modules for an application, or or as a last resort for systems not supporting it, either preloading (linking just before execution) or static linking (during the compilation time). It's very portable and flexible, as you can see from here: http://www.gnu.org/software/libtool/manual.html#Tested-platforms Anyway, it would be great to have the facility to load new styles or functions from a library (a ltdl module). Minimalistic systems would just load (or compile, depending on the arch) the very basic functions and styles, while more feature-rich systems would load all of them. The unoficial feature patchsets would be replaced by style modules (it has nothing to do with the current fvwm modules).. And so on. The text on docs/TODO explains the whole idea. For those interested in this, you can find libtool's manual here: http://www.gnu.org/software/libtool/manual.html For now I'm studying the fvwm code to see where this fits. I'm thinking of trying it out (in a my local private branch, as this is definitely not a 2.5 feature). If I get to do anything I'll inform you. Cheers, Renato
Re: CVS renato:
On 7/8/06, FVWM CVS fvwm-workers@fvwm.org wrote: CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: renato 06/07/08 09:57:42 fvwm/compat Update of /home/cvs/fvwm/fvwm/compat In directory util9.math.uh.edu:/tmp/cvs-serv3957/compat Log Message: Directory /home/cvs/fvwm/fvwm/compat added to the repository OOPS sorry.. I should have done that only locally... Will never hapen again :) Renato
Separating compat code from libfvwm
Hi. What do you think of separating the compatibility code (replacement functions) from libfvwm? Functions like strncasecmp or strdup are spread all over the code. For systems that do not have them availiable, libfvwm is responsible for providing them. But the question is, should this be the responsibility of libfvwm? Or should fvwmlib have only fvwm related functions and leave the system compatibility functions to another lib? What I think: Compatibility functions should be separated from libfvwm, as they are not part of fvwm. They should be linked automatically if needed, but should remain invisible for the libfvwm code. Particulary, the replacement function definitions should be in config.h if needed, instead of fvwmlib.h. It would help on keeping the code clean, as the replacement functions should be stable now, and may even be kept as is to fvwm3.0 (?). I believe (supported by local tests) that this is possible to do without too much fuss or without introducing any bugs. On the other hand, it may be prudent to wait before the 2.5.17 release. I'm waiting for opinions.. Cheers, Renato
Re: CVS renato: Removed the warning about the obsolete option -blackout.
On 7/8/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Fri, Jul 07, 2006 at 06:34:31PM -0500, fvwm-workers wrote: CVSROOT: /home/cvs/fvwm Module name: fvwm Changes by: renato 06/07/07 18:34:31 Modified files: . : ChangeLog fvwm : fvwm.1.in fvwm.c Log message: Removed the warning about the obsolete option -blackout. Removed its reference from the manual. Um, why? We've never had any 'secret' features (at least not on purpose). Every option is documented, even if it's frowned upon. The -blackout code was removed a long time ago. The warning I refer to was put there by you in 1999 (pre-2.4) so that people who used to start fvwm with the -blackout option could still do it, even if it didn't do nothing. There was really no option -blackout, fvwm just accepted it and said it doesnt do nothing anymore, instead of refusing to start. It's there (the warning) since 1999, so I guess no one needs that anymore.. Cheers, Renato Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEr5hHmeSprTOr4tgRArLlAKCGMrl4JT7tV0SAvv3hKQqd8Qd0HwCbBu3t 5adq7LfT20dzmR9KI9PxpDI= =od5t -END PGP SIGNATURE-
Re: Separating compat code from libfvwm
On 7/8/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Sat, Jul 08, 2006 at 07:58:46PM +0100, seventh guardian wrote: Hi. What do you think of separating the compatibility code (replacement functions) from libfvwm? Functions like strncasecmp or strdup are spread all over the code. For systems that do not have them availiable, libfvwm is responsible for providing them. But the question is, should this be the responsibility of libfvwm? Or should fvwmlib have only fvwm related functions and leave the system compatibility functions to another lib? What I think: Compatibility functions should be separated from libfvwm, as they are not part of fvwm. They should be linked automatically if needed, but should remain invisible for the libfvwm code. Particulary, the replacement function definitions should be in config.h if needed, instead of fvwmlib.h. It would help on keeping the code clean, as the replacement functions should be stable now, and may even be kept as is to fvwm3.0 (?). I believe (supported by local tests) that this is possible to do without too much fuss or without introducing any bugs. On the other hand, it may be prudent to wait before the 2.5.17 release. I don't get the point of doing that. Whats the difference between having them in libfvwm.a or a different lib? Instead of a big monolythic library we have two libraries: one with actual fvwm code, and the other with compatibility code (used only if needed). It's just a matter of modularity, as it would keep different things separate. But I agree that there's no big difference at the end, as things would end up linked against each other in the final executable.. Renato Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEsCw8meSprTOr4tgRAsK8AJ9ddvhmx9n/Mt5ZintUk9L6Ba4eHgCg4svj Ik22tDxOKU+hr8BVro+n2s8= =3iJw -END PGP SIGNATURE-
Re: CVS renato: Removed the warning about the obsolete option -blackout.
On 7/8/06, seventh guardian [EMAIL PROTECTED] wrote: On 7/8/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Fri, Jul 07, 2006 at 06:34:31PM -0500, fvwm-workers wrote: CVSROOT: /home/cvs/fvwm Module name: fvwm Changes by: renato 06/07/07 18:34:31 Modified files: . : ChangeLog fvwm : fvwm.1.in fvwm.c Log message: Removed the warning about the obsolete option -blackout. Removed its reference from the manual. Um, why? We've never had any 'secret' features (at least not on purpose). Every option is documented, even if it's frowned upon. The -blackout code was removed a long time ago. The warning I refer to was put there by you in 1999 (pre-2.4) so that people who used to start fvwm with the -blackout option could still do it, even if it didn't do nothing. There was really no option -blackout, fvwm just accepted it and said it doesnt do nothing anymore, instead of refusing to start. It's there (the warning) since 1999, so I guess no one needs that anymore.. I'm still a bit overwelmed by the commit access, so I triple-check (instead of double-check) what I do :) From ChangeLog-pre2.4: 1999-07-08 Dominik Vogt dominik(dot)vogt(at)gmx(dot)de (...) * fvwm/fvwm.h: * fvwm/builtins.c (do_recapture): * fvwm/fvwm.c: removed the 'blackout' code completely (...) Cheers Renato Cheers, Renato Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEr5hHmeSprTOr4tgRArLlAKCGMrl4JT7tV0SAvv3hKQqd8Qd0HwCbBu3t 5adq7LfT20dzmR9KI9PxpDI= =od5t -END PGP SIGNATURE-
Re: CVS renato: Removed the warning about the obsolete option -blackout.
On 7/9/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Sat, Jul 08, 2006 at 11:48:43PM +0100, seventh guardian wrote: On 7/8/06, seventh guardian [EMAIL PROTECTED] wrote: On 7/8/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Fri, Jul 07, 2006 at 06:34:31PM -0500, fvwm-workers wrote: CVSROOT: /home/cvs/fvwm Module name: fvwm Changes by: renato 06/07/07 18:34:31 Modified files: . : ChangeLog fvwm : fvwm.1.in fvwm.c Log message: Removed the warning about the obsolete option -blackout. Removed its reference from the manual. Um, why? We've never had any 'secret' features (at least not on purpose). Every option is documented, even if it's frowned upon. The -blackout code was removed a long time ago. The warning I refer to was put there by you in 1999 (pre-2.4) so that people who used to start fvwm with the -blackout option could still do it, even if it didn't do nothing. There was really no option -blackout, fvwm just accepted it and said it doesnt do nothing anymore, instead of refusing to start. It's there (the warning) since 1999, so I guess no one needs that anymore.. Well, we have been very *very* conservative in the past about backwards compatibility - and that patch breaks it. It's no longer possible to start fvwm with -blackout. I don't think this is the right time to remove it. Of course it's obsolete and useless, but in the 2.x series we tried to keep compatibility as much as possible. The ominous 3.0 release (which is meant to remove a lot of old and obsolete stuff) would be the place to clean everything up. Well, it wasn't even useful to 2.4, and I doubt people would keep configs from pre-2.4.. So I thought it wouldn't matter.. My fault. How can I reverse the change? I'm still a bit overwelmed by the commit access, so I triple-check (instead of double-check) what I do :) Well, I certainly don't want to discourage you from doing usefull work, but please don't become too eager committing potentially harmful changes without discussing them. Compatibility is a sensitive issue, and we have spent lots of time thinking about the right way to go. (The fact that most of us don't have time to write patches nowadays does not mean we don't have the time to argue about patches ;-) ) Sorry, you're right.. Won't happen again :) Cheers, Renato Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEsEPbmeSprTOr4tgRAvijAKDUpJbB6gS+oF8zoklKwBVhJsH/rACfV5Bv Ab6/ggXU2ocAevGUMFiCoJk= =KPUA -END PGP SIGNATURE-
Re: CVS renato: Removed the warning about the obsolete option -blackout.
On 7/9/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Sun, Jul 09, 2006 at 01:00:08AM +0100, seventh guardian wrote: On 7/9/06, Dominik Vogt [EMAIL PROTECTED] wrote: Well, we have been very *very* conservative in the past about backwards compatibility - and that patch breaks it. It's no longer possible to start fvwm with -blackout. I don't think this is the right time to remove it. Of course it's obsolete and useless, but in the 2.x series we tried to keep compatibility as much as possible. The ominous 3.0 release (which is meant to remove a lot of old and obsolete stuff) would be the place to clean everything up. Well, it wasn't even useful to 2.4, and I doubt people would keep configs from pre-2.4.. So I thought it wouldn't matter. My fault. Sometimes it is surprising how long it can take until everybody has switched to a more recent release. Some people stick to 2.2.x for no other reason than that it is smaller. How can I reverse the change? With a bit of CVS magic. First, find out the revision numbers of the changed files before and after the change. For example, for fvwm.c do $ cvs log -N fvwm.c ... revision 1.375 date: 2006/07/07 23:34:31; author: renato; state: Exp; lines: +0 -8 Removed the warning about the obsolete option -blackout. Removed its reference from the manual. revision 1.374 ... (The relevant numbers are 1.374 and 1.375 here). Next, generate a patch for that change: $ cvs diff -u -r 1.374 -r 1.375 fvwm.c blackout.patch (Double check that the patch contains only the changes you want to reverse; edit the patch file if necessary). Finally reverse-apply the patch: $ patch -p0 -R blackout.patch Repeat this for all affected files. Well, although I've now done the change myself locally, I leave it to you as it is a good practive for using cvs :-) Ok, done. Thanks for the tip :) -- While you're at it you can change the warning (and todo-3.0 file) to inform the user that -blackout *will* be removed in 3.0. Done. I've also added the the info about its future removal to the manual (hope it's ok). Cheers, Renato I'm still a bit overwelmed by the commit access, so I triple-check (instead of double-check) what I do :) ... Sorry, you're right.. Won't happen again :) There's really no reason to feel disheartened. I appreciate your work very much and other surely do too. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEsMFJmeSprTOr4tgRAjAsAKCNDMZXYYvLWDBa5bv0Dd/Cacbx1QCghVlJ MYfu0Uj0Wl3JmlIiK+4Cgik= =NOZ/ -END PGP SIGNATURE-
Re: KillModule fix
On 7/11/06, Scott Smedley [EMAIL PROTECTED] wrote: Hi Renato, The attached patch fixes the broken KillModule command. Can someone please apply it? Done. How long was it broken? Not long. Since 2006/06/24. Ok, that explains why yesterday I couldn't kill FvwmPager. I didn't give it much attention though.. I should have By the way, I've long wanted to know the significance of seventh guardian ... ? LOL Well, seven is kind of a mystical number, it´s the last day of the week. I'm kind of the last guardian for something.. I'm yet to discover what.. Anyway, I created this alternative identity during my early adolescence (it's a long story..), and it remained.. It's my nickname for everything, from IRC to CounterStrike.. But for grown up projects I use my real name ;) SCoTT. :) Cheers, Renato
Re: FvwmPager: Compilation fix when --enable-debug-msgs is set
On 7/11/06, Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote: Hello, With current state of things it's impossible to compile 2.5.17 CVS branch with --debug-msgs configure option. I investigated created a patch which fixes this problem. OOPS that was my fault.. Appiled. BTW, is it my impression or you don't have an @ on your ChangeLog email? 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
ChangeLog vs modules/ChangeLog ?
Hi. I have a question regarding the use of the ChangeLogs. Obviously, changes to the fvwm core are reported in the root ChangeLog. But what about changes to modules? I ask this because I've allways logged my changes to the root one, but now think I should have done it to modues/ChangeLog. On the other hand, there are lots of module changes in the root changelog.. So, what is our ChangeLog policy? If it is module stuff - modules/ChangeLog, rest - ChangeLog, then I guess module stuff should be moved to the correct modules/ChangeLog. If not, then we would be better served with just one ChangeLog, in wich case we should merge both. Cheers, Renato
Re: ChangeLog vs modules/ChangeLog ?
On 7/12/06, Dan Espen [EMAIL PROTECTED] wrote: seventh guardian [EMAIL PROTECTED] writes: Hi. I have a question regarding the use of the ChangeLogs. Obviously, changes to the fvwm core are reported in the root ChangeLog. But what about changes to modules? I ask this because I've allways logged my changes to the root one, but now think I should have done it to modues/ChangeLog. On the other hand, there are lots of module changes in the root changelog.. So, what is our ChangeLog policy? If it is module stuff - modules/ChangeLog, rest - ChangeLog, then I guess module stuff should be moved to the correct modules/ChangeLog. If not, then we would be better served with just one ChangeLog, in wich case we should merge both. The Changelogs were getting huge so they were split up. Using Emacs, you find the right one using C-x 4 a. Otherwise it's the first one above the directory your in. Hum.. Ok, then there are lots of entries in the root ChangeLog not belonging there.. Should they be moved to the right place? Renato -- Dan Espen E-mail: [EMAIL PROTECTED]
Removing gnome support from FvwmGtk
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. BTW, please correct me if I'm wrong. Cheers, Renato
Re: Removing gnome support from FvwmGtk
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). 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... Renato -- 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: Removing gnome support from FvwmGtk
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). 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? Olivier
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. :)
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: 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: bugfix with clearing 'NoIcon' style
On 7/16/06, Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote: On Sun, Jul 16, 2006 at 12:51:55PM +0200, Dominik Vogt wrote: On Sat, Jul 15, 2006 at 03:55:17AM +0400, Serge (gentoosiast) Koksharov wrote: On Fri, Jul 14, 2006 at 12:28:45AM +0200, Dominik Vogt wrote: Um, if the manpage is not clear enough, it should be reworded. The NoIcon style is *of course* overridden by specifying an icon, Oh, I missed this nuance. But I still think that my change is useful. Author which implemented current logic most likely assumed that 'NoIcon' hides icon completely. But it's not true. For example, user using 'FvwmIconBox' module may want to change icon of one of his applications. And with current code 'NoIcon' style will be reset which not that he wants. I.e., 'NoIcon' doesn't hide icons, all this style does is hide them from root window but they still can be used in modules. I'm not sure I understand what you are saying. Can you please rephrase that and add an example, that shows in which way things work differently with that patch? Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Hello, Dominik, I'll try. Many users may prefer not to use icons on desktop at all, so they keep 'NoIcon' style set for all their applications. But icons are still useful to them if they use module like 'FvwmIconBox' which can display them. But with current code in CVS if they, for example, change icon on the fly, 'NoIcon' style will be disabled automatically, which not that they want. If my patch will be accepted this will not happen anymore. And example: from 'FvwmConsole' execute following commands: Style * NoIcon Module FvwmIconBox Style SomeApp Icon /path/to/another/icon See? Icon for 'SomeApp' again appeared on desktop and to hide it you need to execute 'Style SomeApp NoIcon'. With my patch this extra command no longer needed. Hope, this time I made this clear enough. I believe this can be solved with UseIcon vs !UseIcon for showing vs not showing the desktop icon, and the Icon or IconPath style just to set the icon path. But NoIcon would go away. It's intuitive and simple.. Cheers, Renato 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
Re: FVWM: FVWM, GNOME and preloading GNOME libs
On 7/17/06, Andrei Popov [EMAIL PROTECTED] wrote: Hello Dominik and thanks for you response. You could add some dummy Gnome application to your start function. I'm sorry, dummy Gnome application doesn't sound too clear to me, and Google didn't help me either =) Can you perhaps provide an example? Start something like the gnome calculator.. What you need is a small gnome program so that it loads the gnome libs at startup. You can then kill it.. If you want to you can make a real dummy program only with gnome_init and a few other functions tha just starts itself and then exits. I think it takes so long because the first Gnome app starts a process called gconfd-2 from some obscure library. Maybe so. After some googling I came across a GDM speedup tip that I thought could apply to my situation. I didn't see any visible improvements though after I followed the steps successfully and rebooted. http://blogs.sun.com/roller/page/jmr?entry=jds_gnome_performance_leaner_meaner This seems to be just a _gnome_ speed improvement. It doesn't start gconfd-2, so you have no real _startup_ speed improvement. It may help on the performance once all gnome libs are loaded though.. Cheers Renato -- WBR, Andrei Popov Using FVWM 2.5.16 on Debian GNU/Linux
Re: FVWM: How to use StippledTitleOff
On 7/17/06, Thomas Adam [EMAIL PROTECTED] wrote: On Mon, Jul 17, 2006 at 10:35:15AM +0100, Leon wrote: Thomas Adam [EMAIL PROTECTED] writes: On Sun, Jul 16, 2006 at 05:56:18PM +0100, Leon wrote: However it seems it does nothing at all. All the icons still have sticky title. Any ideas? Of course -- the style StippledTitleOff is only applicable to non-sticky windows which have been told to use StippledTitle -- it doesn't work for sticky windows. Humm first of all this now should be a flag StippledTitle vs !StippledTitle. I will correct the man page. -- Thomas Adam I misunderstood StippledTitleOff. Is there any way to tell sticky icons to use a normal title? Thanks, -- Leon No, there isn't. I did send a patch in last year to address this problem, but it was mostly ignored. Style only works with window/class names. So there's no easy way of telling fvwm just to stipple sticky windows. (Like Style Sticky !StippledTitle). Perhaps this could be done with conditional commands, but it's not an easy thing. The imediate solution would be to add another style to set/reset the StippledTitle flag only on the sticky windows, or globally (like Style * NeverStipple) but in my oppinion this is wrong.. But the long term solution would be to extend the Style command not just for window/class names but also for Window states (Style Icon (...) or Style Sticky (...)). Dominik? Finally as a personal oppinion, I see no utility in the current StippledTitle style, so maybe Thomas' patch could be re-discussed? Cheers, Renato -- 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.
Flags - is negation prefered?
Hi. I have a question. Is the flag vs. !flag syntax the prefered one? I ask this because even though some styles only have the !(stylename) counterpart, some are still documented as (stylename)Off. So if the flag negation is prefered to the (stylename) vs. (stylename)Off, or the other way round, then it should be explicit in the man page. This is the only way we can avoid compatibility confusion in a future version. My opinion is that the flag vs. !flag style is simpler to parse, and it should be prefered. the (stylename)Off code should be maintained for compatibility's sake, but marked as deprecated. Comments? Renato
Re: FVWM: How to use StippledTitleOff
On 7/17/06, Thomas Adam [EMAIL PROTECTED] wrote: On Mon, Jul 17, 2006 at 03:26:32PM +0100, seventh guardian wrote: On 7/17/06, Thomas Adam [EMAIL PROTECTED] wrote: On Mon, Jul 17, 2006 at 10:35:15AM +0100, Leon wrote: Thomas Adam [EMAIL PROTECTED] writes: On Sun, Jul 16, 2006 at 05:56:18PM +0100, Leon wrote: However it seems it does nothing at all. All the icons still have sticky title. Any ideas? Of course -- the style StippledTitleOff is only applicable to non-sticky windows which have been told to use StippledTitle -- it doesn't work for sticky windows. Humm first of all this now should be a flag StippledTitle vs !StippledTitle. I will correct the man page. Most commands should be using !Foo in the negatory sense. Style only works with window/class names. So there's no easy way of Name, Class, Resource. telling fvwm just to stipple sticky windows. (Like Style Sticky !StippledTitle). Perhaps this could be done with conditional commands, but it's not an easy thing. How do you mean? It's perfectly simple to add something like: Style * StickyStipples Style * !StickyStipples ... Which might apply to windows which have been declared as sticky. Yes, but then you'd end up with lots of equal styles applying to different situations.. The imediate solution would be to add another style to set/reset the StippledTitle flag only on the sticky windows, or globally (like Style * NeverStipple) but in my oppinion this is wrong.. Maybe it is, but then you can turn that around and say that stippling sticky windows in the first place is also wrong. Yes, I did say that :) but it's just my opinion.. But the long term solution would be to extend the Style command not just for window/class names but also for Window states (Style Icon (...) or Style Sticky (...)). Dominik? I don't like this, since you would probably extend it to include things like: Style Shaded (...) Style HasTitle (...) It gets too boring, unmanagable, and ultimately wrong. The stylation of window *states* (as in the above) just doesn't make logical sense to me. It would allow us for instance to use a different color style for sticky windows, instead of just allowing stippling.. It would allow setting different colors to the iconified windows. This currently can only be done with the use of colorsets, which I belive is a broken behaviour. And the list goes on. It's a flexible solution that follows the same philosophy that was behindreplacing all sorts of old fvwm commands with their Style counterpart.. Cheers, Renato -- 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: Flags - is negation prefered?
On 7/17/06, Thomas Adam [EMAIL PROTECTED] wrote: On Mon, Jul 17, 2006 at 03:47:13PM +0100, seventh guardian wrote: Hi. I have a question. Is the flag vs. !flag syntax the prefered one? I ask this because even though some styles only have the !(stylename) counterpart, some are still documented as (stylename)Off. So if the flag negation is prefered to the (stylename) vs. (stylename)Off, or the other way round, then it should be explicit in the man page. This is the only way we can avoid compatibility confusion in a future version. My opinion is that the flag vs. !flag style is simpler to parse, and it should be prefered. the (stylename)Off code should be maintained for compatibility's sake, but marked as deprecated. Comments? Renato Yes -- I thought 2.5.X was having the !Foo syntax as the preferred one, removing any old Foo versus NoFoo options. Of course, it's currently on FVWM 2.4.X which still exhibits this. Yes, but then the 2.5 manual should be updated. I'll start doing that.. Renato -- 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: Flags - is negation prefered?
On 7/17/06, Thomas Adam [EMAIL PROTECTED] wrote: On Mon, Jul 17, 2006 at 04:02:47PM +0100, seventh guardian wrote: Yes, but then the 2.5 manual should be updated. I'll start doing that.. Don't be too hasty. :) Things like: Style foo !Icon Won't work. Yes, I know :) But in any case, I'll test things before changing the manpage.. Renato -- 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: Flags - is negation prefered?
On 7/17/06, Viktor Griph [EMAIL PROTECTED] wrote: On Mon, 17 Jul 2006, Thomas Adam wrote: On Mon, Jul 17, 2006 at 04:02:47PM +0100, seventh guardian wrote: Yes, but then the 2.5 manual should be updated. I'll start doing that.. Don't be too hasty. :) Things like: Style foo !Icon Won't work. Another thing to remember is that all options that still are supported, but not preferred should still be documented, or someone searching for what an option in a config file does might not find it. Yes, I also adressed that. I hope the first three items are good. I'll continue tomorrow after my last exam.. :) Cheers, Renato /Viktor
Re: FVWM: How to use StippledTitleOff
On 7/17/06, Thomas Adam [EMAIL PROTECTED] wrote: On Mon, Jul 17, 2006 at 04:36:08PM +0100, seventh guardian wrote: On the other hand, BackColor and ForeColor apply to both situations. Don't get too attached to those though -- they're deprecated in favour of using colorsets. :) So you can only set a specific icon color if using a colorset, and never directly like you do to a window. This is why I believe the behaviour is broken. I like this aproach. But it would be more clear if was something like: Style (name=foo | class=foo) Stick That's horrible. I really don't want to see any C idioms like that. :) Most people that use FVWM aren't programmers -- enforcing something like that on them might make them run away. :) Lol.. Yes, but how do you specify if its an and or an or? Renato The comma is a bit ambiguous.. at least for a C programmer ;) I guess these two ways of parsing could eventually be merged. I like the comma because it separates out the different clauses, just like most other commands are delimited in this way in FVWM. It also doesn't enforce a prepositional meaning with '' -- which, unless you're a programmer, you're not going to necessarily grok at first. But this idiom doesn't add anything new, it just organizes the way style works. It could be extended in the same way to accept window states as an argument: It does add something new in that the conjunctions are now considered as one, as opposed to separately, which is how FVWM would currently interpret them as. Granted it adds no new options to the styles, but think about how powerful that would be. Style (name=foo winstate=iconic) That might be a little better, yes. (Again, losing the '' syntax in preference of a comma). I might look into this if I get some time. -- 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.
Adding the possibility of not compiling deprecated code ?
Hi. This idea just came into my head: why not #ifdef'ing the deprecated code and having configure.ac option --disable-backcompat? Examples: User A has an old config. So he downloads the new package, compiles it and installs it just like he allways did. User B has a new config and wants to compile fvwm so that it doesn't waste time/space looking for deprecated options. This could make fvwm run a tiny bit faster (?), and also would allow user B to see if its config is up-to-date (i.e., not using deprecated options). He downloads the new package, runs configure --disable-backcompat and compiles it. The performance gain may not be that noticeable, but it would allow us to mark clearly deprecated code and test if things work without it. Maybe it would make it easyer to remove in the future (?). It would also be useful for users who want to make sure they have an up-to-date config, being this a way to enforce that. What do you think? Renato
Re: FVWM: How to use StippledTitleOff
On 7/17/06, Thomas Adam [EMAIL PROTECTED] wrote: On Mon, Jul 17, 2006 at 04:56:18PM +0100, seventh guardian wrote: Lol.. Yes, but how do you specify if its an and or an or? Just have two separate lines for them? Style (title=foo, winstate=normal) . Style (title=fii, winstate=iconic) . Touche.. :) Renato -- 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: Flags - is negation prefered?
On 7/18/06, Viktor Griph [EMAIL PROTECTED] wrote: On Mon, 17 Jul 2006, Dominik Vogt wrote: On Mon, Jul 17, 2006 at 03:47:13PM +0100, seventh guardian wrote: Hi. I have a question. Is the flag vs. !flag syntax the prefered one? I ask this because even though some styles only have the !(stylename) counterpart, some are still documented as (stylename)Off. So if the flag negation is prefered to the (stylename) vs. (stylename)Off, or the other way round, then it should be explicit in the man page. This is the only way we can avoid compatibility confusion in a future version. My opinion is that the flag vs. !flag style is simpler to parse, and it should be prefered. the (stylename)Off code should be maintained for compatibility's sake, but marked as deprecated. The ! negation style is preferred. I coded it for exactly the reasons you describe. There are so many different typed of on/off syntax. Should the old style negation options be deprecated in the code (give warnings) before 2.6? I vote yes ;) Regarding my docs intervention, I finished my last exam today, so hopefuly I have some spare time now. One question though: I think it's better to mention the fact that the !* is now prefered (and the other negations are deprecated) only once, instead of mentioning it in every command description. This way we have a man page section with something like: NoButton - !Button NoTitle - !Title (...) or even something like: These negation styles are deprecated. Please use now the ! sign to negate the styles. The list: NoButton, NoTitle, (...) I think this clears up the manpage and concentrates the info about deprecated styles in only one place (easyer to maintain and to track). Any opinions on this, and if agreed, on how should this be done? It's a major doc cleanup process, so it should be well done. Cheers, Renato
Re: Flags - is negation prefered?
On 7/18/06, seventh guardian [EMAIL PROTECTED] wrote: On 7/18/06, Viktor Griph [EMAIL PROTECTED] wrote: On Mon, 17 Jul 2006, Dominik Vogt wrote: On Mon, Jul 17, 2006 at 03:47:13PM +0100, seventh guardian wrote: Hi. I have a question. Is the flag vs. !flag syntax the prefered one? I ask this because even though some styles only have the !(stylename) counterpart, some are still documented as (stylename)Off. So if the flag negation is prefered to the (stylename) vs. (stylename)Off, or the other way round, then it should be explicit in the man page. This is the only way we can avoid compatibility confusion in a future version. My opinion is that the flag vs. !flag style is simpler to parse, and it should be prefered. the (stylename)Off code should be maintained for compatibility's sake, but marked as deprecated. The ! negation style is preferred. I coded it for exactly the reasons you describe. There are so many different typed of on/off syntax. Should the old style negation options be deprecated in the code (give warnings) before 2.6? I vote yes ;) Regarding my docs intervention, I finished my last exam today, so hopefuly I have some spare time now. One question though: (bump) The question remains.. If noone is against, then I'll do my best :) Cheers, Renato I think it's better to mention the fact that the !* is now prefered (and the other negations are deprecated) only once, instead of mentioning it in every command description. This way we have a man page section with something like: NoButton - !Button NoTitle - !Title (...) or even something like: These negation styles are deprecated. Please use now the ! sign to negate the styles. The list: NoButton, NoTitle, (...) I think this clears up the manpage and concentrates the info about deprecated styles in only one place (easyer to maintain and to track). Any opinions on this, and if agreed, on how should this be done? It's a major doc cleanup process, so it should be well done. Cheers, Renato
Re: CVS scott fvwm-web: Updated on-line man pages for 2.5.17.
On 7/21/06, FVWM CVS fvwm-workers@fvwm.org wrote: CVSROOT:/home/cvs/fvwm Module name:fvwm-web Changes by: scott 06/07/20 22:30:23 Modified files: documentation/manpages/unstable: FvwmAnimate.php FvwmAuto.php FvwmBacker.php FvwmBanner.php FvwmButtons.php FvwmCommand.php FvwmConsole.php FvwmConsoleC.pl.php FvwmCpp.php FvwmDebug.php FvwmDragWell.php FvwmEvent.php FvwmForm.php FvwmGtk.php FvwmGtkDebug.php FvwmIconBox.php FvwmIconMan.php FvwmIdent.php FvwmM4.php FvwmPager.php FvwmPerl.php FvwmProxy.php FvwmRearrange.php FvwmSave.php FvwmSaveDesk.php FvwmScript.php FvwmScroll.php FvwmTabs.php FvwmTaskBar.php FvwmTheme.php FvwmWharf.php FvwmWinList.php FvwmWindowMenu.php focus-link.php fvwm-bug.php fvwm-config.php fvwm-convert-2.2.php fvwm-convert-2.4.php fvwm-convert-2.6.php fvwm-menu-desktop.php fvwm-menu-directory.php fvwm-menu-headlines.php fvwm-menu-xlock.php fvwm-perllib.php fvwm-root.php fvwm.php index.php Log message: Updated on-line man pages for 2.5.17. Hi! Could there be an easy way to do the update automatically? Renato
Man page changes - negation method
Hello all. After some thought and reasoning, here's a preliminary solution to the man page entry regarding the style negation method. I followed Thomas' sugestion and here's what is done for the menu styles. Since I hadn't done any change to this section yet, I've updated the HilightBackOff option to !HilightBack as an example. The big change: @@ -2948,6 +2948,11 @@ triples with a '/' in between. These options exclude each other. All paired options can be negated to have the effect of the counterpart option by prefixing ! to the option. +Deactivating an option is done by prefixing ! to the option. This is +the prefered negation method, and other methods are now deprecated. + +This is a list of MenuStyle deprecated negative options: +HilightBackOff .IR Fvwm , Mwm , Win reset all options to the style with the same name in former Please comment :) The diff goes atached. Cheers, Renato patch Description: Binary data
MenuStyle options - negate or not to negate?
Hi. Some of the MenuStyle (an maybe Style too) options don't have a negative form on the man page. But the truth is that some can be negated. So in order to unify the whole thing, what should be done to those? Should we add the negative forms to the man page to the ones missing, or should we remove them from the ones which have a !* negation form? Example: MouseWheel TrianglesUseFore / !TrianglesUseFore should become MouseWheel / !MouseWheel TrianglesUseFore / !TrianglesUseFore or MouseWheel TrianglesUseFore ? Let us consider now that the way to negate the styles is now explained on the man page. Opinions? Renato Caldas
Re: MenuStyle options - negate or not to negate?
On 7/21/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Fri, Jul 21, 2006 at 03:56:00PM +0100, seventh guardian wrote: Hi. Some of the MenuStyle (an maybe Style too) options don't have a negative form on the man page. But the truth is that some can be negated. So in order to unify the whole thing, what should be done to those? Should we add the negative forms to the man page to the ones missing, or should we remove them from the ones which have a !* negation form? Example: MouseWheel TrianglesUseFore / !TrianglesUseFore should become MouseWheel / !MouseWheel TrianglesUseFore / !TrianglesUseFore This is the right decision. Great :) As soon as we agree on the ! notice on the man page I'll do this. One thing at a time :) or MouseWheel TrianglesUseFore Nope. Let us consider now that the way to negate the styles is now explained on the man page. Note that there are many more styles and options that could have a !-negation, bui I don't want to tackle them now. Ok. My new proposal accounts for this. Cheers Renato Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEwQ1RmeSprTOr4tgRAt/MAJ9+9tRrSI8uafiuIffHJvGQrBKzQwCeOZhW G/MlmWG1JgXJ1+BuGsEW1PU= =dK69 -END PGP SIGNATURE-
Re: Man page changes - negation method
On 7/21/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Fri, Jul 21, 2006 at 03:38:40PM +0100, seventh guardian wrote: Hello all. After some thought and reasoning, here's a preliminary solution to the man page entry regarding the style negation method. I followed Thomas' sugestion and here's what is done for the menu styles. Since I hadn't done any change to this section yet, I've updated the HilightBackOff option to !HilightBack as an example. The big change: @@ -2948,6 +2948,11 @@ triples with a '/' in between. These options exclude each other. All paired options can be negated to have the effect of the counterpart option by prefixing ! to the option. '!' --^^^ +Deactivating an option is done by prefixing ! to the option. This is '!' -^^^ +the prefered negation method, and other methods are now deprecated. But ... as far as I know it's not true. Not all options can be negated with the !-prefix. I eventually want to get there, but it's not true at the moment. Ok, what about this: Some options are now deactivated by prefixing ! to the option. This will eventually be the default, and the old negative options are now deprecated. This is a list of MenuStyle deprecated negative options: AutomaticHotkeysOff, HilightBackOff, TitleWarpOff It's a bit more conservative, yet should still be useful :) Cheers Renato +This is a list of MenuStyle deprecated negative options: +HilightBackOff Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEwQ4+meSprTOr4tgRAg1pAJ9qGCNJJXQVfyeX2RkYS0Q93s6ZEQCeLD0R BstZkG0kfP95hpeQg1MwTXA= =Kj8o -END PGP SIGNATURE-
Re: Man page changes - negation method
On 7/23/06, Jacob Bachmeyer [EMAIL PROTECTED] wrote: seventh guardian wrote: Ok, what about this: Some options are now deactivated by prefixing ! to the option. This will eventually be the default, and the old negative options are now deprecated. This is a list of MenuStyle deprecated negative options: AutomaticHotkeysOff, HilightBackOff, TitleWarpOff It's a bit more conservative, yet should still be useful :) Cheers Renato the default in that could be confusing to new users, how about the preferred form? (default could be taken as all options will be default off.) You're right. But it will not be the preferred method, it will be the only method (hence the other methods being deprecated). Can you find me a word for the only method that fits here? :) Cheers Renato This would be: Some options are now deactivated by prefixing ! to the option. This will eventually be the preferred form, and the old negative forms are now deprecated.
Re: FVWM: Color / ForeColor no longer supported?
On 7/23/06, Thomas Adam [EMAIL PROTECTED] wrote:
On 23/07/06, Peter Daum [EMAIL PROTECTED] wrote:
Hi,
already for a while now (I think it started shortly after 2.5.15)
the specification of a foreground color for a window (something
like Style * Color red/green or ForeColor red) has been
silently ignored.
That is strange. I have my config working perfectly with ForeColor
etc. (fvwm cvs)
Are these commands obsoleted by the newer colorset stuff and only
the documentation not yet adjusted or is it just a bug (background
is still honored). Is there a simple workaround?
You should be using Colorsets regardless in 2.5.X -- deprecation of
{Fore,Back}Color is definitely on the cards, and has been for a while.
Then I guess there should be at least some note in the manual page..
Cheers
Renato
-- Thomas Adam
Re: Man page changes - negation method
On 7/24/06, Thomas Adam [EMAIL PROTECTED] wrote: On 24/07/06, Jacob Bachmeyer [EMAIL PROTECTED] wrote: seventh guardian wrote: On 7/23/06, Jacob Bachmeyer [EMAIL PROTECTED] wrote: seventh guardian wrote: Ok, what about this: Some options are now deactivated by prefixing ! to the option. This will eventually be the default, and the old negative options are now deprecated. This is a list of MenuStyle deprecated negative options: AutomaticHotkeysOff, HilightBackOff, TitleWarpOff It's a bit more conservative, yet should still be useful :) Cheers Renato the default in that could be confusing to new users, how about the preferred form? (default could be taken as all options will be default off.) You're right. But it will not be the preferred method, it will be the only method (hence the other methods being deprecated). Can you find me a word for the only method that fits here? :) Cheers Renato This would be: Some options are now deactivated by prefixing ! to the option. This will eventually be the preferred form, and the old negative forms are now deprecated. Ok, how about: Some options are now deactivated by prefixing ! to the option. This I wouldn't use that word. This seems to be becoming more complex when it's actually very simple. Rewording the sentence above, and adding what you have below should be sufficient. I would simply reword that sentence as: Some options can now be negated by prefixing ``!'' to the option. Sounds good. will soon be the preferred form for all such options. Any negatable option for which ! does not work should be reported as a bug. The other ^^^ This is unnecessary, at least for now, as we should know what doesn't work. Besides, it is obvious that things that _are_documented_ and don't work as documented should be reported as bugs. negative forms are now deprecated and will be removed in FVWM X.Y. ^^ In here I would prefer the future. Because we don't really know when it will be removed. I would prefer it being removed previous to the 2.6 release, as we are growing to have more compatibility options than real options :P . But I bet thats not the opinion of most of us, so.. Future it should be :) Does everybody agree with something like this: Some options are now negated by prefixing ! to the option. This will soon be the preferred form for all such options. The other negative forms are now deprecated and will be removed in the future. Cheers Renato -- Thomas Adam
Where did the MenuStyle ActiveBack go?
Hello. I found this unusual thing in the manual. There is a reference to ActiveBack/ActiveBackOff all over the place, but aparently the style doesn't exist any more. It is not documented at all, nor is mentioned in (both) the ChangeLogs.. Not even in any part of the source code. Is there a replacement for it? Should I just delete the references? What now? Cheers Renato PS: Sounds like it was silenced by fvwm secret services ;)
Re: Where did the MenuStyle ActiveBack go?
On 7/25/06, Dominik Vogt [EMAIL PROTECTED] wrote: I found this unusual thing in the manual. There is a reference to ActiveBack/ActiveBackOff all over the place, but aparently the style doesn't exist any more. It is not documented at all, nor is mentioned in (both) the ChangeLogs.. Not even in any part of the source code. Is there a replacement for it? Should I just delete the references? What now? Ah, It's a relic of the patch splitting AftiveFore and HilightBack. I probably thought about renaming HilightBack, but gave up the idea in favour of the ActiveColorset option. It's safe to remove it from the man page (or replace it with HighlightBack where appropriate). Done. It had already been replaced by HilightBack, except the old ActiveBack was also there. Cheers Renato Ciao Dominik ^_^ ^_^ -- Echte DSL-Flatrate dauerhaft für 0,- Euro*. Nur noch kurze Zeit! Feel free mit GMX DSL: http://www.gmx.net/de/go/dsl
Re: CVS renato: Created a ! flag explanation in Style similar to the one in MenuStyle
On 7/25/06, FVWM CVS fvwm-workers@fvwm.org wrote: CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: renato 06/07/25 09:24:00 Modified files: . : ChangeLog fvwm : fvwm.1.in Log message: Created a ! flag explanation in Style similar to the one in MenuStyle Moved the deprecated reference of some styles to a centralized place (NoTitle, StippledTitleOff, NoHandles,NoButton, NoIconTitle) Oops.. Looks like I did a mess with these changes above. I'll revert them for now, and review them as soon as I can. Cheers renato Removed the ActiveBack relics from the man page
Re: New MenuStyle which forbids tear off
On 8/4/06, Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote: Hello, I want new MenuStyle which disables ability to tear off menu. Reason: because I have some dynamic menues like this: Mouse 3 IST A Menu winmenu +0m +0 DestroyMenu winmenu AddToMenu winmenu Window menu: Title + DynamicPopupAction Function MakeWinMenu DestroyFunc MakeWinMenu AddToFunc MakeWinMenu + I DestroyMenu recreate winmenu + I AddToMenu winmenu Window menu $[w.class]: Title + I ThisWindow (Shaded) + %menu-cbox_on.png%UnShade WindowShade + I TestRc (NoMatch) + %menu-cbox_off.png%Shade WindowShade ...skipped... When user tear offs such dynamic menu, menu items in it no longer working, because functions called without window context. I already coded a patch which adds MenuStyle 'AllowTearOff/!AllowTearOff' (feel free to offer another name for it) and I'll send it to the list if: - core developers agree that proposed functionality is useful I'm not a core dev, but I think this can be useful. On the other hand, the menu only tears off if you specifically ask it to. So unless the desktop is used by someone else, I guess I can live with just not tearing it off in the first place :) - there are no other ways to solve described problem without this new MenuStyle. Cheers Renato 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
Re: Tracking flag changes from modules
On 8/7/06, Dominik Vogt [EMAIL PROTECTED] wrote: Is there any way that the module interface allows keeping track of changes to the window flags of a window? Currently FvwmPager allows moving of FixedPosition mini-windows, but the main window does not move. Just checking for IS_FIXED in MoveWindow doesn't work if the FixedPosition flag was set after the window was added to the pager (i.e with 'WindowStyle FixedPosition') since the flags get outdated. I've been looking some at the module interface, but I think that no message exist to indicate change in window flags. Is this correct? Actually, the window flags are part of some message, but they should not be used. Looking at a flag does not solve the problem anyway because the decision whether a window can be moved or not is much more complex (affected by a number of styles). What about providing modules a way to ask fvwm to move the windows instead of the module moving them through X calls? This way the sanity checks would be done in fvwm, leaving all these problems to the window manager. It would work the same as moving the viewport. The pager asks fvwm to move the viewport, it doesn't directly move all the windows. But it would require a rewrite of the pager, and some major changes to the fvwm code.. :( not a task for 2.5 I guess... Even so, can this be a 2.6 feature? Cheers Renato Ciao Dominik ^_^ ^_^ -- Echte DSL-Flatrate dauerhaft für 0,- Euro*. Nur noch kurze Zeit! Feel free mit GMX DSL: http://www.gmx.net/de/go/dsl
Re: Tracking flag changes from modules
On 8/8/06, Viktor Griph [EMAIL PROTECTED] wrote: On Tue, 8 Aug 2006, seventh guardian wrote: On 8/7/06, Dominik Vogt [EMAIL PROTECTED] wrote: Is there any way that the module interface allows keeping track of changes to the window flags of a window? Currently FvwmPager allows moving of FixedPosition mini-windows, but the main window does not move. Just checking for IS_FIXED in MoveWindow doesn't work if the FixedPosition flag was set after the window was added to the pager (i.e with 'WindowStyle FixedPosition') since the flags get outdated. I've been looking some at the module interface, but I think that no message exist to indicate change in window flags. Is this correct? Actually, the window flags are part of some message, but they should not be used. Looking at a flag does not solve the problem anyway because the decision whether a window can be moved or not is much more complex (affected by a number of styles). What about providing modules a way to ask fvwm to move the windows instead of the module moving them through X calls? This way the sanity checks would be done in fvwm, leaving all these problems to the window manager. It would work the same as moving the viewport. The pager asks fvwm to move the viewport, it doesn't directly move all the windows. But it would require a rewrite of the pager, and some major changes to the fvwm code.. :( not a task for 2.5 I guess... Even so, can this be a 2.6 feature? The mechanism for asking fvwm to move a window is already there. It's just to send the Move command. However, this does not fix the problem, since there is no way for the pager to know if the move was successful or not. It could move the mini window back to te original position on button release and then send the move command and wait for a corresponding configure-package to know the new position if the window was moved. This however would cause windows jumping back and forth in the pager. Some sort of meanpath would be to add a message for ignored requests and have it have the same info as the configure window package, but that's definately a hack. Both these 'solutions' would allow the miniature window to move, but have them jump back on non-moveable windows. The best thing would be to not allow movement on non-moveable windows to start in the pager view. Well, it could work properly. Just ask for a null move (move the window to its current position) as soon as the user tries to move the miniwindow. If the command was rejected fvwm issues a simple error packet. The Pager now knows it can't move the window. If the command wasn't rejected then the pager can send the real Move command, to move the window to its new position. What about adding a command to check for movement ability (CanMove or something like this)? This way fvwm would tackle the multiple style conflicts, and the pager needed to know nothing about the actual flags and stuff. Also, no new packet would be required. It would work the same way as the above solution, so the above could be simpler. Cheers Renato
Re: Tracking flag changes from modules
On 8/8/06, Viktor Griph [EMAIL PROTECTED] wrote: On Tue, 8 Aug 2006, seventh guardian wrote: On 8/8/06, Viktor Griph [EMAIL PROTECTED] wrote: On Tue, 8 Aug 2006, seventh guardian wrote: On 8/7/06, Dominik Vogt [EMAIL PROTECTED] wrote: Is there any way that the module interface allows keeping track of changes to the window flags of a window? Currently FvwmPager allows moving of FixedPosition mini-windows, but the main window does not move. Just checking for IS_FIXED in MoveWindow doesn't work if the FixedPosition flag was set after the window was added to the pager (i.e with 'WindowStyle FixedPosition') since the flags get outdated. I've been looking some at the module interface, but I think that no message exist to indicate change in window flags. Is this correct? Actually, the window flags are part of some message, but they should not be used. Looking at a flag does not solve the problem anyway because the decision whether a window can be moved or not is much more complex (affected by a number of styles). What about providing modules a way to ask fvwm to move the windows instead of the module moving them through X calls? This way the sanity checks would be done in fvwm, leaving all these problems to the window manager. It would work the same as moving the viewport. The pager asks fvwm to move the viewport, it doesn't directly move all the windows. But it would require a rewrite of the pager, and some major changes to the fvwm code.. :( not a task for 2.5 I guess... Even so, can this be a 2.6 feature? The mechanism for asking fvwm to move a window is already there. It's just to send the Move command. However, this does not fix the problem, since there is no way for the pager to know if the move was successful or not. It could move the mini window back to te original position on button release and then send the move command and wait for a corresponding configure-package to know the new position if the window was moved. This however would cause windows jumping back and forth in the pager. Some sort of meanpath would be to add a message for ignored requests and have it have the same info as the configure window package, but that's definately a hack. Both these 'solutions' would allow the miniature window to move, but have them jump back on non-moveable windows. The best thing would be to not allow movement on non-moveable windows to start in the pager view. Well, it could work properly. Just ask for a null move (move the window to its current position) as soon as the user tries to move the miniwindow. If the command was rejected fvwm issues a simple error packet. The Pager now knows it can't move the window. If the command wasn't rejected then the pager can send the real Move command, to move the window to its new position. While this could work, it probably requires a largeer rewrite of the pager code to allow it to wait for a response from fvwm before starting the move. This resoponse can come mixed with several other messages that has to be taken care of in the normal way. What about adding a command to check for movement ability (CanMove or something like this)? This way fvwm would tackle the multiple style conflicts, and the pager needed to know nothing about the actual flags and stuff. Also, no new packet would be required. It would work the same way as the above solution, so the above could be simpler. A CanMove command is not needed, and not desireable. Instead it should be a 'Movable' conditional, which probably is quite easy to add. There is still one problem, that already affects the code somewhat: The SendToModule command can be used to send instructions back to the module on a successful test. However, it can only direct the messages by name, which mean that they might get to multiple instances of a module. Properly designed messages, in combination with the module knowing which messages it's waiting for can solve this, but it would be nice for a way for a module to uniqely define itself to fvwm as a recipent in a SendToModule command. It would be easy to uniquely identify the modules if the alias' were managed by fvwm instead of the modules. This way fvwm would know which specific module was listening on which pipe. As a (positive) side effect, modules wouldn't need to know their alias, which in turn would make the message requesting/parsing easyer. I've already suggested this, but it was said to be too complicated to be worth implementing before 2.6.. Things that needed to change: -Change of the module interface code in fvwm. -Add a command/style to specify the module alias in the config file. - VISIBLE (new feature) -Minor changes to the module's config parsing code. -The module's parsing cmd line options (now reject the alias options). - VISIBLE (could break backward-compatibility) As a way to provide backward compatibility and minimizing the effects of the above VISIBLE changes
Re: Tracking flag changes from modules
On 8/8/06, seventh guardian [EMAIL PROTECTED] wrote: On 8/8/06, Viktor Griph [EMAIL PROTECTED] wrote: On Tue, 8 Aug 2006, seventh guardian wrote: On 8/8/06, Viktor Griph [EMAIL PROTECTED] wrote: On Tue, 8 Aug 2006, seventh guardian wrote: On 8/7/06, Dominik Vogt [EMAIL PROTECTED] wrote: Is there any way that the module interface allows keeping track of changes to the window flags of a window? Currently FvwmPager allows moving of FixedPosition mini-windows, but the main window does not move. Just checking for IS_FIXED in MoveWindow doesn't work if the FixedPosition flag was set after the window was added to the pager (i.e with 'WindowStyle FixedPosition') since the flags get outdated. I've been looking some at the module interface, but I think that no message exist to indicate change in window flags. Is this correct? Actually, the window flags are part of some message, but they should not be used. Looking at a flag does not solve the problem anyway because the decision whether a window can be moved or not is much more complex (affected by a number of styles). What about providing modules a way to ask fvwm to move the windows instead of the module moving them through X calls? This way the sanity checks would be done in fvwm, leaving all these problems to the window manager. It would work the same as moving the viewport. The pager asks fvwm to move the viewport, it doesn't directly move all the windows. But it would require a rewrite of the pager, and some major changes to the fvwm code.. :( not a task for 2.5 I guess... Even so, can this be a 2.6 feature? The mechanism for asking fvwm to move a window is already there. It's just to send the Move command. However, this does not fix the problem, since there is no way for the pager to know if the move was successful or not. It could move the mini window back to te original position on button release and then send the move command and wait for a corresponding configure-package to know the new position if the window was moved. This however would cause windows jumping back and forth in the pager. Some sort of meanpath would be to add a message for ignored requests and have it have the same info as the configure window package, but that's definately a hack. Both these 'solutions' would allow the miniature window to move, but have them jump back on non-moveable windows. The best thing would be to not allow movement on non-moveable windows to start in the pager view. Well, it could work properly. Just ask for a null move (move the window to its current position) as soon as the user tries to move the miniwindow. If the command was rejected fvwm issues a simple error packet. The Pager now knows it can't move the window. If the command wasn't rejected then the pager can send the real Move command, to move the window to its new position. While this could work, it probably requires a largeer rewrite of the pager code to allow it to wait for a response from fvwm before starting the move. This resoponse can come mixed with several other messages that has to be taken care of in the normal way. What about adding a command to check for movement ability (CanMove or something like this)? This way fvwm would tackle the multiple style conflicts, and the pager needed to know nothing about the actual flags and stuff. Also, no new packet would be required. It would work the same way as the above solution, so the above could be simpler. A CanMove command is not needed, and not desireable. Instead it should be a 'Movable' conditional, which probably is quite easy to add. There is still one problem, that already affects the code somewhat: The SendToModule command can be used to send instructions back to the module on a successful test. However, it can only direct the messages by name, which mean that they might get to multiple instances of a module. Properly designed messages, in combination with the module knowing which messages it's waiting for can solve this, but it would be nice for a way for a module to uniqely define itself to fvwm as a recipent in a SendToModule command. It would be easy to uniquely identify the modules if the alias' were managed by fvwm instead of the modules. This way fvwm would know which specific module was listening on which pipe. As a (positive) side effect, modules wouldn't need to know their alias, which in turn would make the message requesting/parsing easyer. I've already suggested this, but it was said to be too complicated to be worth implementing before 2.6.. Things that needed to change: -Change of the module interface code in fvwm. -Add a command/style to specify the module alias in the config file. - VISIBLE (new feature) -Minor changes to the module's config parsing code. -The module's parsing cmd line options (now reject the alias options). - VISIBLE (could
Re: Tracking flag changes from modules
On 8/8/06, seventh guardian [EMAIL PROTECTED] wrote: On 8/8/06, seventh guardian [EMAIL PROTECTED] wrote: On 8/8/06, Viktor Griph [EMAIL PROTECTED] wrote: On Tue, 8 Aug 2006, seventh guardian wrote: On 8/8/06, Viktor Griph [EMAIL PROTECTED] wrote: On Tue, 8 Aug 2006, seventh guardian wrote: On 8/7/06, Dominik Vogt [EMAIL PROTECTED] wrote: Is there any way that the module interface allows keeping track of changes to the window flags of a window? Currently FvwmPager allows moving of FixedPosition mini-windows, but the main window does not move. Just checking for IS_FIXED in MoveWindow doesn't work if the FixedPosition flag was set after the window was added to the pager (i.e with 'WindowStyle FixedPosition') since the flags get outdated. I've been looking some at the module interface, but I think that no message exist to indicate change in window flags. Is this correct? Actually, the window flags are part of some message, but they should not be used. Looking at a flag does not solve the problem anyway because the decision whether a window can be moved or not is much more complex (affected by a number of styles). What about providing modules a way to ask fvwm to move the windows instead of the module moving them through X calls? This way the sanity checks would be done in fvwm, leaving all these problems to the window manager. It would work the same as moving the viewport. The pager asks fvwm to move the viewport, it doesn't directly move all the windows. But it would require a rewrite of the pager, and some major changes to the fvwm code.. :( not a task for 2.5 I guess... Even so, can this be a 2.6 feature? The mechanism for asking fvwm to move a window is already there. It's just to send the Move command. However, this does not fix the problem, since there is no way for the pager to know if the move was successful or not. It could move the mini window back to te original position on button release and then send the move command and wait for a corresponding configure-package to know the new position if the window was moved. This however would cause windows jumping back and forth in the pager. Some sort of meanpath would be to add a message for ignored requests and have it have the same info as the configure window package, but that's definately a hack. Both these 'solutions' would allow the miniature window to move, but have them jump back on non-moveable windows. The best thing would be to not allow movement on non-moveable windows to start in the pager view. Well, it could work properly. Just ask for a null move (move the window to its current position) as soon as the user tries to move the miniwindow. If the command was rejected fvwm issues a simple error packet. The Pager now knows it can't move the window. If the command wasn't rejected then the pager can send the real Move command, to move the window to its new position. While this could work, it probably requires a largeer rewrite of the pager code to allow it to wait for a response from fvwm before starting the move. This resoponse can come mixed with several other messages that has to be taken care of in the normal way. What about adding a command to check for movement ability (CanMove or something like this)? This way fvwm would tackle the multiple style conflicts, and the pager needed to know nothing about the actual flags and stuff. Also, no new packet would be required. It would work the same way as the above solution, so the above could be simpler. A CanMove command is not needed, and not desireable. Instead it should be a 'Movable' conditional, which probably is quite easy to add. There is still one problem, that already affects the code somewhat: The SendToModule command can be used to send instructions back to the module on a successful test. However, it can only direct the messages by name, which mean that they might get to multiple instances of a module. Properly designed messages, in combination with the module knowing which messages it's waiting for can solve this, but it would be nice for a way for a module to uniqely define itself to fvwm as a recipent in a SendToModule command. It would be easy to uniquely identify the modules if the alias' were managed by fvwm instead of the modules. This way fvwm would know which specific module was listening on which pipe. As a (positive) side effect, modules wouldn't need to know their alias, which in turn would make the message requesting/parsing easyer. I've already suggested this, but it was said to be too complicated to be worth implementing before 2.6.. Things that needed to change: -Change of the module interface code in fvwm. -Add a command/style to specify the module alias in the config file. - VISIBLE (new
Re: Tracking flag changes from modules
On 8/8/06, Dominik Vogt [EMAIL PROTECTED] wrote: As a way to provide backward compatibility and minimizing the effects of the above VISIBLE changes there could be provided a command that the modules could use to request an alias. This way the module would parse the command line alias options and request the attribution of an alias. So old configs would still work properly!! :) Strange thing now looking through module_interface.c: there is already a string array called pipeAlias!! Is it possible that the infrastructure is already there?? YES! Strangely enough, the infrastructure is there!! You can actually send commands to specific aliased modules! Just use the module alias instead of the name, and voila! Except pipeAlias is never properly written. It seems that someone started the job but didn't get to finish it. The code is as good as it could be at the time Mikhael wrote it. It's not much more than a hack that tries to guess whether the first argument of a module was intended to be an alias (i.e. not an option etc.). It fails in a number of cases, but we can not do much better without rewriting the interface of some modules. So what could be the solution to the initial problem without any kind of rewrite? The very first issue is that there is no defined way of choosing the alias. From what I see in the code, it was suposed to have the very first user argument as an alias (standard). Since some modules don't use (respect?) this, I guess the effort was undermined by the back-compat issues.. But this can be partially tackled if we add a command for the modules to request their alias in the fvwm internal data. Is it worth continuing the job? Is it safer to start an experimental side branch on this? Well, shouldn't we try to stabilise 2.5.x now, release it an then think about big changes in the module interface? Yes.. But we are constantly facing problems that would either be solved by some kind of rewrite or by hacks.. 2.5 is mostly stable. It's definitely more stable than some other release programs Cheers, Renato Ciao Dominik ^_^ ^_^ -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
Re: FvwmIconMan: debug code cleanup
On 8/7/06, Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote: Hello, Here some documentation fixes and debug code cleanups in FvwmIconMan. Please see attached patch's ChangeLog section for more information. Hello! Your patch seems ok to me :) BTW, I've seen some references of manger replaced by manager. I guess having so many of them could mean the intended word was indeed manger. After a search in the dictionary, manger means something like a cattle pen (a fenced place where you put livestock). This would definitely fit the module, as it is indeed a fenced place for icons :) Could there have been a misunderstanding of the Man short word right in the begining? Can the original author clear this up? I'll let you all think about that :) Cheers Renato Bye. -- 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
Re: Tracking flag changes from modules
On 8/8/06, Thomas Adam [EMAIL PROTECTED] wrote: On Tue, 8 Aug 2006 16:18:41 +0100 seventh guardian [EMAIL PROTECTED] wrote: On 8/8/06, Dominik Vogt [EMAIL PROTECTED] wrote: As a way to provide backward compatibility and minimizing the effects of the above VISIBLE changes there could be provided a command that the modules could use to request an alias. This way the module would parse the command line alias options and request the attribution of an alias. So old configs would still work properly!! :) Strange thing now looking through module_interface.c: there is already a string array called pipeAlias!! Is it possible that the infrastructure is already there?? YES! Strangely enough, the infrastructure is there!! You can actually send commands to specific aliased modules! Just use the module alias instead of the name, and voila! Except pipeAlias is never properly written. It seems that someone started the job but didn't get to finish it. The code is as good as it could be at the time Mikhael wrote it. It's not much more than a hack that tries to guess whether the first argument of a module was intended to be an alias (i.e. not an option etc.). It fails in a number of cases, but we can not do much better without rewriting the interface of some modules. So what could be the solution to the initial problem without any kind of rewrite? There isn't, I'm afraid. I can perfectly understand and see the logic behind why the flags should be sent in the packet information -- however in order Should they? I don't agree. The modules shouldn't have to deal with fvwm's internals. The module interface should be as clean as possible.. As Dominik said, it is a hack. for there to be a solution to what you're proposing, it is going to mean a rewrite most likely. This was discussed here on this list a few months ago. If you like I will dig through the on-line archives for you. Well, shouldn't we try to stabilise 2.5.x now, release it an then think about big changes in the module interface? Yes.. But we are constantly facing problems that would either be solved by some kind of rewrite or by hacks.. 2.5 is mostly stable. It's definitely more stable than some other release programs There's still one or two things that need fixing before I would deem 2.5.X as a release candidate. There's no rush. :) I'd much rather see it done proper than released; pampering to the possible cries of the users that so desperately want it. :) Anything that wouldn't require a rewrite/hack? Cheers Renato -- Thomas Adam -- ThisWindow (thomas_adam) Destroy
Re: icon movement tracking
On 8/7/06, Viktor Griph [EMAIL PROTECTED] wrote: Should the flag tracking icon movement be set by MoveToPage? Currently it's not, which makes icons jump back to the initial page if do for example 'Style * IconTitle' if an icon has been moved to another page by MoveToPage. On a sidenote the same problem exists whenever moving icons with the pager, even if they are kept on the same page. I can confirm this behaviour, it's wrong IMHO. I guess the flag should be set. Cheers Renato /Viktor
Re: FvwmIconMan: debug code cleanup
On 8/8/06, Thomas Adam [EMAIL PROTECTED] wrote: On Tue, 8 Aug 2006 16:39:42 +0100 seventh guardian [EMAIL PROTECTED] wrote: On 8/7/06, Serge (gentoosiast) Koksharov [EMAIL PROTECTED] wrote: Hello, Here some documentation fixes and debug code cleanups in FvwmIconMan. Please see attached patch's ChangeLog section for more information. Hello! Your patch seems ok to me :) BTW, I've seen some references of manger replaced by manager. I guess having so many of them could mean the intended word was indeed manger. After a search in the dictionary, manger means something like a cattle pen (a fenced place where you put livestock). This would definitely fit the module, as it is indeed a fenced place for icons :) Indeed -- have you never sung the Christmas carol Away in a Manger? No.. I'm portuguese.. but the word mangedoura exists here too with the same meaning :) Could there have been a misunderstanding of the Man short word right in the begining? Can the original author clear this up? It depends in what context the word 'manger' is being used (I haven't looked). It does seem awfully like a typo to me. :) Yes, but it does appear several times.. spooky :) Renato -- Thomas Adam -- ThisWindow (thomas_adam) Destroy
Re: FvwmIconMan: debug code cleanup
On 8/8/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Tue, Aug 08, 2006 at 12:16:44AM +0400, Serge (gentoosiast) Koksharov wrote: Hello, Here some documentation fixes and debug code cleanups in FvwmIconMan. Please see attached patch's ChangeLog section for more information. The patch looks fine. Any volunteers to commit it? Good, I'll do it then. Cheers, Renato Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFE2NVwmeSprTOr4tgRAgWCAJ9l7GcGSKVpXC9TFus00+aIDgocpwCcC4VG IsHE3z8MgyhJdnwqv8CL+bU= =VAt2 -END PGP SIGNATURE-
Re: FvwmIconMan: debug code cleanup
On 8/8/06, seventh guardian [EMAIL PROTECTED] wrote: On 8/8/06, Dominik Vogt [EMAIL PROTECTED] wrote: On Tue, Aug 08, 2006 at 12:16:44AM +0400, Serge (gentoosiast) Koksharov wrote: Hello, Here some documentation fixes and debug code cleanups in FvwmIconMan. Please see attached patch's ChangeLog section for more information. The patch looks fine. Any volunteers to commit it? Good, I'll do it then. BTW, do you think typo corrections should be mentioned in the changelog? I'm tempted to remove them, but need a core-dev opinion.. :) Cheers Renato Cheers, Renato Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFE2NVwmeSprTOr4tgRAgWCAJ9l7GcGSKVpXC9TFus00+aIDgocpwCcC4VG IsHE3z8MgyhJdnwqv8CL+bU= =VAt2 -END PGP SIGNATURE-
