[Kbabel] RFC: Proposal for enabling/disabling actions

[Stanislav Visnovsky]

Sorry for a late response...

IMHO:

We need to implement something like this. I'm not sure if the way 
described here, but I have no other idea. I would say let's go for it.
My key worry here is that we need to traverse all actions at each item 
change.

1. in catalogmanagerui.rc we should leave the state for building the
   tree
2. we should have a list for next/prev fuzzy etc. - this is a bit
   problematic, since Qt does not provide a signal if the ordering
   is changed by user, but it can be done.
3. there must be a set of macros for readability

I would like to develop a generic framework for this, which could be 
incorporated into KDElibs directly - but that's daydreaming ATM.

Stanislav

On Wed, 15 Jan 2003, Marco Wegner wrote:

> Hi,
> 
> in the last hour I've been trying to think of a system which should make the
> enabling and disabling of actions in Catalog Manager much easier.
> 
> Until recently the current system with states defined in the file
> catalogmanagerui.rc has been quite sufficient. But already the toggeling of
> the appropriate CVS actions has shown the limits of this system. Right now I
> am working on features which apply only to directories. Just another state
> which is not covered by the current implementation. Therefore I thought a
> different approach could be helpful. So here are my thoughts:
> 
> Instead of defining different states in the *ui.rc file we could simply create
> a bit matrix:
> 
> Bit 0: current item has PO file
> Bit 1: current item has POT file
> Bit 2: current item is marked
> Bit 3: current item is dir
> Bit 4: a valid CVS PO repository exists
> Bit 5: a valid CVS POT repository exists
> 
> If one of these things is necessary to enable an action then the appropriate
> bit is set. Examples:
> 
> - - rough translation: 0 (can be applied to any item)
> - - spell check: 1 (needs PO file)
> - - mail marked files: 5 (needs PO file and a mark)
> - - cvs update: 17 (needs PO file and a valid PO repository)
> - - cvs commit marked templates: 38 (needs POT file, a mark and a valid POT
> repository)
> 
> I think the idea should be clear by now :-) These values can be QMap'ped
> against the names of the actions. I call this value 'actionValue' for the
> better understanding of issues coming later on.
> 
> To decide which actions are enabled/disabled for the current item we just
> create the bit pattern for the current item like this (item is a
> CatManListItem*):
> 
> uint itemValue = 1*item->hasPo( ) + 2*item->hasPot( ) + 4*item->isMarked( ) +
>   8*item->isDir( ) + 16*isValidPORepository + 32*isValidPOTRepository;
> 
> Traverse the list of actions and set those enabled for which the associated
> 'actionValue' combined by bit-wise AND with the above created 'itemValue' has
> the 'actionValue' as a result. If this is not the case set the action
> disabled. Examples:
> 
> The current item has PO file, POT file, is not marked and has valid PO and POT
> repositories -> itemValue results in 51
> 
> - - rough translation: (51 AND 0) == 0 -> enable
> - - spell check: (51 AND 1) == 1 -> enable
> - - mail marked files: (51 AND 5) != 5 -> disable
> - - cvs update: (51 AND 17) == 17 -> enable
> - - cvs commit marked templates: (51 AND 38) != 38 -> disable
> 
> I hope I made myself sufficiently clear. I'd like to hear your comments on
> this. It is easy to implement and should not need much more (if any) code
> than the current system. It also shouldn't be slower than using states but is
> more flexible all the same.
> 
> BTW: This system can be applied to the the actions in the markings and tools
> menu. But I'm sure a similar system can be created for the correct toggeling
> of 'go to' actions.
> 
> Marco
>