Re: Re[5]: problem with rf

Richard,

> What impacts will this have on MacCvs/WinCvs ?????

WinCvs should not use much of /rf stuff - it's been moved back to MFC due to
easier maintenance ;)

> It will require major changes to BrowseViewModel.[h|cpp] and
> UCvsFrame.cpp and minor changes (if ever) to any handler of
> ON_UCOMMANDxxx.

Please try to keep the BrowseViewModel files gui-free as much as possible,
it's pretty nice and tidy out there right now ;)

Perhaps you can add a midlle-tier somewhere?

Heck, you could probably go all the way and try some native approach ;)

Best Regards,
Jerzy

----- Original Message ----- 
From: "Richard Wirth" <[email protected]>
To: "Jens Miltner" <[email protected]>
Sent: Wednesday, June 16, 2004 11:37
Subject: Re[5]: [cvsgui-dev] problem with rf


> Hello Jens,
>
> Wednesday, June 16, 2004, 1:27:39 PM, you wrote:
>
>
> JM> Am 16.06.2004 um 11:03 schrieb Richard Wirth:
>
> >> Hello Richard,
> >>
> >> Tuesday, June 15, 2004, 10:30:09 PM, you wrote:
> >>
> >> RW> Hello Jerzy,
> >>
> >> RW> Tuesday, June 15, 2004, 11:05:50 PM, you wrote:
> >>
> >> JK>> Richard,
> >>
> >>>>> But this results in a new button pressed event for OnViewConflict()
> >>>>> and all the others, which in turn change the state not being
> >>>>> "kFilterModified" any more. So we get a perfect recursion!
> >>
> >> JK>> Perhaps disabling the other buttons while toggling them would
> >> help - the
> >> JK>> disable state could be used to prevent recursion - the handler
> >> can check it
> >> JK>> and ignore the event...?
> >>
> >> RW> The Problem is, the knobs get updated while UpdateUI(), which is
> >> long
> >> RW> time after the initial change to "SeeModified". And the
> >> implementation
> >> RW> only does a toggle regardless of the current internal state.
> >>
> >> RW> I think a possible way is not to modify the state of the other
> >> filters
> >> RW> directly, but forcing the buttons to do the state change. But than
> >> the
> >> RW> buttons must know each other...
> >>
> >> I suspect this also isn't possible, cause the change of state is done
> >> inside KoFilterModel, where we have no knowledge about any user
> >> interface elements.
> >>
> >> So we definitively have to extend the handlers for ON_UCOMMAND_xxx()
> >> to include the state of the button.
> >>
> >> What impacts will this have on MacCvs/WinCvs ?????
>
> JM> Hmmh, not sure for MacCvs. Actually only very little of the rf code is
> JM> used in MacCvs, AFAIK. I'm pretty sure the filter buttons are handled
> JM> "natively" (i.e. not through rf), but I have to admit I'm not entirely
> JM> sure :|
> It will require major changes to BrowseViewModel.[h|cpp] and
> UCvsFrame.cpp and minor changes (if ever) to any handler of
> ON_UCOMMANDxxx.
>
> >>
> >> One other questioin:
> >> Does MacCvs get influenced by changes on the autoconf/automake stuff?
> >> I'd like to change the configure.in to not rely on gnome but only on
> >> gtk (and if possible enable the use of gtk2).
>
> JM> Is the autoconf/automake stuff shared with the cvsgui tool's setup (in
> JM> the cvs-1.10 subtree)?
> JM> The cvsgui tool is the only place where MacCvs would use
> JM> autoconf/automake (unless it's build using the Xcode IDE).
> The changes will only affect the gui stuff of gcvs, not any of the cvs
> related sub projects.
> So what is Xcode IDE?
>
>
>
> -- 
> Best regards,
>  Richard                            mailto:[email protected]
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>


------------------------ Yahoo! Groups Sponsor --------------------~--> 
Yahoo! Domains - Claim yours for only $14.70
http://us.click.yahoo.com/Z1wmxD/DREIAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~-> 

 
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/