Re: gCvs popup menu customization, future plans

Am 15.02.2006 um 05:03 schrieb Guy Rouillier:

> Richard Wirth wrote:
>> I would prefere a pure gnome independant application. But what about
>> all the gnome users than??
>
> I think a pure GTK2 implementation is the way to go.  I actually  
> thought
> we had that already.  There are no Gnome dependencies in the build  
> that
> I'm aware of.  By making it dependent only on GTK2, we'd remain
> compatible with lighter weight window managers.
>
>> 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).
>
> I'm not saying that using a C++ inheritance approach is a good  
> solution,
> but I'm curious why you believe it would be a bad solution.  For
> example, because I'm working on the menus, I've had occasion to  
> look at
> rf/umenu.cpp.  Method UMenuAddPulldown has absolutely no common code,
> other than some variable declarations and a call to GetMenuTitle().
> After that are disjoint #ifdef sections, one for each platform.  That
> should be able to be restructured to remove the #ifdef's and use C++
> capabilities to supply logic by platform.
>
> At any rate, I'm just tossing about ideas for discussion.  Some of the
> source files are literally drowning in #ifdef's.  It would be great if
> we could get rid of most of those and have the common/ files just have
> truly common code, with subdirectories like /gcvs, /wincvs and /maccvs
> containing platform-specific code.

It's certainly possible to reduce the #ifdef clutter a lot by  
factoring out the platform specific code sections into their own  
subclasses and/or functions. However, this is the sort of major re- 
architecture that Richard was talking about. Basically, you'd need to  
factor each of the mixed-code functions into parts that do common  
stuff and parts that handle the platform specific stuff. There are  
certainly cases where this is easy, such as the one you mentioned  
above, but other places have platform specific and common code  
intermixed in a way that it's not obvious how to factor them without  
producing method/function clutter instead of #ifdef clutter :(

I agree that it would be nice to have an architecture that does  
factor out the platform specific code more (switching to a cross- 
platform is along the same lines, although my experience with cross- 
platform frameworks running on Mac OS tends to be dissapointing), but  
basically it boils down to how much effort can/do we want to we put  
into rearchitecturing instead of fixing the boldest blunders.

</jum>



 
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/