[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: handling complex logic to enable/disable actions
From:       Andreas Pakulat <apaku () gmx ! de>
Date:       2009-06-23 13:13:19
Message-ID: 20090623131319.GD18099 () neo ! apaku ! dnsalias ! org
[Download RAW message or body]

On 23.06.09 14:42:48, Stefano Crocco wrote:
> Hello to everyone,
> 
> I'm developing an application for KDE, and I'm usingthe XML GUI framework to 
> enable and disable actions. I know how to do it for simple situations. For 
> example, if I have an action which starts an external process and one which 
> stops it, I can write:
> 
> <State name="process_started">
>   <enable>
>     <Action name="stop_process"/>
>   </enable>
>   <disable>
>     <Action name="start_process/>
>   </disable>
> </State>
> 
> This way, when I set the "process_started" state, the "stop_process" action 
> will be enabled and the "start_process" will be disabled.
> 
> The problem arises if I need a more complex logic to find out whether an 
> action should be enabled or not. For example, suppose that I have an action 
> called "action1" which needs to be enabled only if there are both an open 
> project and an open document. A first attempt would then be
> <State name="project_exists">
>   <enable>
>     <Action name="action1"/>
>   </enable>
> </State>
> <State name="document_exists">
>   <enable>
>     <Action name="action1"/>
>   </enable>
> </State>
> Of course, this won't work: as soon as the "project_exists" state is set, the 
> action will be activated, even if the "document_exists" state isn't set.
> 
> My question is: is it possible to use the XML GUI framework also to handle 
> these more complex situations?

Sure, but you're amount of states will "explode" with the number of checks
you have. The idea is instead of two states you'll have 4:

project_exists_document_exists
project_not_exists_document_exists
project_exists_document_not_exists
project_not_exists_document_not_exists

Then when a document is created check if a project exists and if there's
none, set the last state, if there is a project set the first one.
Obviously this can get rather complicated, but thats in general a problem
of having complex and many ui states. Of course at the place where you set
one of these 4 states you can just as well enable/disable the action
directly.

Andreas

-- 
You'll wish that you had done some of the hard things when they were easier
to do.
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]