Re: Why the CompatXXX for dialog boxes?

Am 22.02.2005 um 23:29 schrieb Guy Rouillier:

>
> On Tue, 22 Feb 2005 09:39:56 +0100
> Jens Miltner <[email protected]> wrote:
>
>> Am 21.02.2005 um 23:44 schrieb Guy Rouillier:
>>
>>>
>>> I'm implementing the customize menu dialog for the context menus in
>>> gCvs2.  I'm trying to follow the approach used by other dialogs.
>>> I'm curious why the dialogs are initialized with a non-class method
>>> beginning with the word Compat; for example, the graph option dialog
>>> is invoked via CompatGetGraphOptions.  Why not bring up the dialog
>>> via the class constructor, which is what the Compat function seems
>>> to be doing for all platforms?  I don't understand what value the
>>> Compat function adds.  Thanks.
>>
>> I suspect that it may have it's origin in historic implementations,
>> but I'd also like to mention that most CompatGetXXX calls are _not_
>> implemented as plain classes for MacCvs: They do make use of some
>> helper classes, but basically, they're just implemented as a regular
>> function.
>> This doesn't prevent using a class constructor to do the work, but the
>> use of a class constructor is much less obvious if there's no common
>> class to use. Since there's almost no code or data shared between the
>> platform implementations of the CompatGetXXX functions, I don't see
>> how it would help them class based?
>
> Jens, thanks for the reply.  I'm very new to all this code, so I'm
> learning as I go.  I do see that not a lot of code is shared across the
> platforms, though from what little experience I have it looks like more
> could be.

Hmmh, are you thinking about the rf framework stuff? I'm not sure how 
well this is still working on the other platforms, and from my 
experience, implementing a cross-platform framework in a way that 
doesn't reduce all platforms to a lowest-common-denominator is a highly 
non-trivial task :(
I think the current approach of having a GetCompatXXX function that 
puts up a dialog and just returns for the options is a pretty good 
solution for this specific issue, even if it requires the code to be 
reproduced on each platform and makes catching up with new options a 
little harder.

> You are correct, putting all the code into the class would
> not reduce any complexity.  But the CompatXXX layer doesn't seem to be
> helping any either.

The GetCompatXXX APIs do provide a platform-agnostic way of getting the 
options/results for a specific command/action, so they _do_ help, IMHO.
(However, you're right if you're talking about them not reducing the 
code complexity as compared to having the code in a class...)

</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/