Re: gCvs popup menu customization, future plans

Hello Guy,

Tuesday, February 14, 2006, 4:24:04 AM, you wrote:

GR>    Richard, I'm working on allowing the user to customize the popup menus
GR>  (as you already can do in WinCvs.)

You're lucky to have so mutch time!

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

I also think they're stable.
But I'm not verry happy with the persistent format in general. It is
raw binary, and this complete machine dependent. So one can not move
its setup from one computer to another. Also there is no easy way in
migrating existing setups when new fearures are added. So I often
thought about storing prefernces in clear text. But that will imply a
lot of work, cause there isn't an easy way for transforming binary
complex data into text...

But for the moment your approach is the best we can implement!

GR>  
GR>  Have you given any thought to near and long term plans for gCvs?  I 
GR>  mentioned here a short while ago the idea of rewriting all platforms in
GR>  something like mono/.Net, but Jerzy expressed doubt that the platform
GR>  was up to the task.

Rewriting it in .Net is like a complete new implementation -- too
mutch work :-((

GR>   If that is true and the three platforms are 
GR>  destined to be separately implemented for the foreseeable future, then
GR>  near term we should probably
GR>  
GR>  (1) find and fix memory leaks

Most of them come from my stupid implementation of FoldersView. The Gtk2
aproach is verry incompatible with the existing rf. So the whole
FoldersView (and also FilesView) have to be reimplemented independent
of the rf (like WinCvs and MacCvs already do).

GR>  (2) revamp the build system (at the very least, so newcomers can use it
GR>  without having to come to the ML numerous times just to get it built;
GR>  you also mentioned your desire to get rid of the autotools approach and
GR>  just use a simple configure/make. 

(I was talking autogen.sh versus simple configure/make. Autotools are
ever used to do the job in any case. But autogen.sh requires autotools
to be installed in the correct version on the target, while
configure/make do only reqire this on the developers platform)

There is a basic question about gCvs's target environment to be
answered first. Is gCvs a true gnome application or not?
This has implications on the autogen/configure approach.

At the moment gCvs isn't a gnome app but it is also not gnome
independent.
There are lots of crude things like the hardcoded fonts (have you ever
tried it on a high resolution desktop??)

I would prefere a pure gnome independant application. But what about
all the gnome users than??

GR>  I'm unable to build it on Gentoo
GR>  32-bit because newer versions of intltool have gotten rid of 
GR>  xml-i18n-toolize.

So we should adapt the build to not use this and doing things another
way (!). I'm using SuSE linux and Solaris and have not seen this
problem until now.

GR>  I have noticed on Gentoo at least, many packages are
GR>  migrating *to* the autotools approach.  I have no preference.)

Do they use the autogen.sh approach? It's surely not a problem for
Geentoo cause the whole build env comes from a single source and is
consitent for each version.

GR>  (3) address the kludges we used (e.g., using hidden variables) to get
GR>  the tree view working.  The kludges may very well be the source of the
GR>  memory leaks.

As I mentioned above...
There are lots of other things ported from WinCvs to gCvs (first all
'INTERNAL_AUTHEN' stuff).

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

Inheritance isn't a solution. Many platform specific code is
intermixed with platform common code. Inheritance will lead to copy
the common code, so it isn't manageable any more.
For that task all code has to be restructured. And that is like
rewriting the whole app (for all Platforms).

So I think we have to live with the current code anyway. The only
thing I see is to migrate the Windows code to a more portable GUI
library (like qt or wxWidgets) to have one source for Windows and
KDE based systems.
(I prefer KDE on my desktops even on Solaris :))

-- 
Best regards,
 Richard                            mailto:[email protected]





 
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/