AW: gCvs popup menu customization, future plans

Hello Guy, hello Richard

it's a long time ago since I participate in your (our) work. As you already told, we all have a private life with plenty of work. In the meanwhile i got two sons and they deserve closer attention. So my spare time decreases. But I followed the development all the time. 

First I have to say: You and Richard did a very good job. Keep on!!!

I see for the shorter term:

- branch the GTK1 stuff 
- merge the GTK2 to the main trunk
- eliminate the kludges (memory leaks?)
- check the make process; it must be possible for everyone to build gcvs
- create a new version 2.0 with all functions known from the gcvs 1.0

In a longer term we should

- add further features (e.g. customized popup menu ;) )
- eliminate double code segments
- reuse (move) functions already used/implemnted in WinCVS to the common folder


Hopefully I will have some time in the near future. Are there any thing I could do for you?

Yours,
Kalle
>
>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
>
>
>
> 
>
>
>


 
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/