adobe-source-devel

[Adobe-source-devel] command system questions

[Ralph T. <ra...@gm...>]

Hi adobe-source list,

  I was looking at the new command system and was wondering how to
command system will work with the current "action_fallback" in
window_server_t. Currently I use the action fallback like this:

  button( name: "Rotate Right", action: @rotate, value:
["file://image.jpg", 90] );
  button( name: "Rotate Left", action: @rotate, value:
["file://image.jpg", 270] );

I specify the target of the action by the value. This is very limited,
because I can't do things like (say) disable the buttons if
"file://image.jpg" is read-only. Is this the kind of problem that the
new command_system could help solve?

Thanks,
 Ralph

Re: [Adobe-source-devel] command system questions

[Sean P. <sea...@ma...>]

On Dec 5, 2005, at 9:22 PM, Ralph Thomas wrote:

> Hi adobe-source list,
>
>   I was looking at the new command system and was wondering how to
> command system will work with the current "action_fallback" in
> window_server_t. Currently I use the action fallback like this:
>
>   button( name: "Rotate Right", action: @rotate, value:
> ["file://image.jpg", 90] );
>   button( name: "Rotate Left", action: @rotate, value:
> ["file://image.jpg", 270] );
>
> I specify the target of the action by the value. This is very limited,
> because I can't do things like (say) disable the buttons if
> "file://image.jpg" is read-only. Is this the kind of problem that the
> new command_system could help solve?

This is the goal - certainly the details aren't worked out yet  
(Foster's getting a good start though - I haven't yet had a chance to  
fully review his work).

The idea with the button as with a menu is that the enabled state is  
controlled by some predicate representing the pre-condition of the  
command.

Normally with Adam and buttons this is driven from invariants on the  
Adam sheet (an Adam sheet is a model for relationships having to do  
with the parameters to some function, an invariant in Adam is a pre- 
condition of the function). So normally we would bind the button to a  
parameter and it's associated predicate (fire up the image size  
example and make the very large in pixels in either dimension). You  
example would be better described as:

// eve description
button (name "Rotate Left", action: @rotate, value: 270, bind: @file);

// adam description
   input:
	file_name: "file://image.jpg";
   output:
	file <== file_name;
   invariant:
	fa <== is_valid_file(file_name, @writeable);


This is not a particularly elegant solution - but hopefully conveys  
the idea. For commands I've asked Foster to simply provide an  
"enabled" flag which can be set to reflect if the preconditions are  
satisfied - there should be two ways to drive this flag:

Have a collection of predicate functions which are evaluated "when  
something has changed" - not particularly efficient but easy to  
represent.

Have an Adam (like) rule which is updated by tracking dependencies  
(Adam is currently brute force so it isn't any more efficient than  
the above solution - but the dependencies are available so it could  
do better).

The goal here is to start using the Adam modeling capabilities for  
describing functions to control the enabling of commands.

Sean

>
> Thanks,
>  Ralph
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through  
> log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD  
> SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel

Re: [Adobe-source-devel] command system questions

[Foster T. B. <fbr...@ad...>]

Hi Ralph,

Yes, this is exactly the sort of thing the command system is intended =20=

to solve. The idea is that the command system will have a pool of =20
commands and a pool of targets, and by some form of handwaving not =20
yet figured out, will enable and disable various commands for a set =20
of 0 or more targets and parameters. In the case below the rotate =20
button would be linked to an enable callback of the command system, =20
and when an image is highlighted it is added to the target pool. The =20
command system would then make a pass over the available commands, =20
and "discover" that Rotate is a valid command for the image target. =20
It would then call the enable callback for that command with the =20
relevant targets, and the button would become enabled.

There are still several issues that remain to be solved. The greatest =20=

of them so far is the discovery algorithm the system uses to link up =20
commands and targets. What we'd like to do, ultimately, is have some =20
means of defining the requirements of the command (targets and =20
concepts that are required for each target) and the command system =20
will sift through the pool looking for targets that meet those =20
requirements. When the requirements are met and the parameters of the =20=

command completely satisfied, the enable callback is notified with =20
the parameter set (note that targets are not the only possible =20
parameters: state information of the application [e.g., the position =20
of the mouse or whether or not "bold" is toggled right now] could =20
also comprise requirements that must be met for the command. Other =20
issues like performance while sifting through all the commands and =20
parameters and distinguishing callbacks for differing parameters from =20=

the same command are problems we haven't figured out, either.

The menu_system is a UI-based element much like the ui_core, and is =20
intended to provide a minimum set of required APIs to handle the menu =20=

system for an application. I also have a demo app set up that has a =20
menu_system_assemblage structure in it that binds the command system =20
to the menu system, providing some rudimentary capabilities with =20
menus and commands. The intention is, as always, to completely =20
separate the modules one from the other, and to allow space for an =20
assemblage to manage the relationship between modules.

If you have any thoughts or feedback on these issues or the systems, =20
please do share.

Blessings,
Foster


On Dec 5, 2005, at 09:22p, Ralph Thomas wrote:

> Hi adobe-source list,
>
>   I was looking at the new command system and was wondering how to
> command system will work with the current "action_fallback" in
> window_server_t. Currently I use the action fallback like this:
>
>   button( name: "Rotate Right", action: @rotate, value:
> ["file://image.jpg", 90] );
>   button( name: "Rotate Left", action: @rotate, value:
> ["file://image.jpg", 270] );
>
> I specify the target of the action by the value. This is very limited,
> because I can't do things like (say) disable the buttons if
> "file://image.jpg" is read-only. Is this the kind of problem that the
> new command_system could help solve?
>
> Thanks,
>  Ralph
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through =20
> log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD =20
> SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dclick
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel

--
Foster T. Brereton              <}}}><              Romans 3:21-26
A d o b e   S o f t w a r e   T e c h n o l o g y   L a b
"The fact is that the author of STL does not know how to write min, =20
the author of C++ is not quite sure, and the standards committee is =20
at a loss." -- Alexander Stepanov