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
