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
