Re[5]: 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 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/