gCvs popup menu customization, future plans

Richard, I'm working on allowing the user to customize the popup menus 
(as you already can do in WinCvs.)  I had the GUI done a year ago, but 
got hung up trying to understand the multistring class (no 
documentation!), then got busy at work.  Turns out I don't think I need 
multistrings, and I hope to have this work committed within a month.

The approach I'm now pursuing is to store the customized menus in the 
preferences file, using one string for the customized folder popup menu 
and one for the customized file popup menu.  I'm thinking of just using 
the numeric values for the menu commands, separated by a single space. 
Do you see any issues with this approach?  I originally thought of using 
the string representations (like cmdSave, etc, from UCvsCommands.h), 
which is what sent me down the multistrings path.  But now I don't see 
much value to doing that, as I would just have to translate those 
strings to their numeric equivalents anyway.  The only benefit I can see 
to using the strings instead of the numbers is that it makes the stored 
values impervious to any change in the value of the constants.  But that 
probably hasn't happened since the project began, so it's likely not a 
big deal.

Have you given any thought to near and long term plans for gCvs?  I 
mentioned here a short while ago the idea of rewriting all platforms in 
something like mono/.Net, but Jerzy expressed doubt that the platform 
was up to the task.  If that is true and the three platforms are 
destined to be separately implemented for the foreseeable future, then 
near term we should probably

(1) find and fix memory leaks
(2) revamp the build system (at the very least, so newcomers can use it 
without having to come to the ML numerous times just to get it built; 
you also mentioned your desire to get rid of the autotools approach and 
just use a simple configure/make.  I'm unable to build it on Gentoo 
32-bit because newer versions of intltool have gotten rid of 
xml-i18n-toolize.  I have noticed on Gentoo at least, many packages are 
migrating *to* the autotools approach.  I have no preference.)
(3) address the kludges we used (e.g., using hidden variables) to get 
the tree view working.  The kludges may very well be the source of the 
memory leaks.

Longer term, I'd like to investigate some possible code refactoring. 
All the current precompiler conditionals make the code very hard to 
follow for newcomers like me; using C++ inheritance to separate all that 
out would certainly help.  (Don't mean any offense to the long timers 
here; previous contributors may have tried that approach and found it 
too cumbersome.)

Please let me know your thoughts.

--
Guy Rouillier


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/cvsgui-dev/

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/