adobe-source-devel

[Adobe-source-devel] visual eve editor

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

Hi list,

  I plan to implement a few features in my app that would benefit from
having some kind of visual eve editor library (I want to use Eve to do
page layout for printing photos, and for DVD menu layout). In the ASL
Overview there is reference to a "Expresso2" visual editor -- I was
wondering if you had any plans on how to implement the app?

  Obviously it would be great if I could write a library that could be
used by my app and by Expresso2 (or other Eve visual editor tools).

Ralph

Re: [Adobe-source-devel] visual eve editor

[Sean P. <sp...@ad...>]

I have some thoughts - Foster may have some also - he implemented the  
original Expresso -

* The basic UI that I envision is a two view editor - a tree view  
showing the UI elements and a preview.

The tree view should be fairly simple - showing an icon for the view  
type and the name property (after localize is executed) for the item  
- if no name property then the view type is displayed

[] My Dialog
  -- row
    () OK
    () Cancel

* Drag and drop (including multiple items) - should be allowed within  
the tree view as well as between the tree view and preview windows.

* The preview window should be live - meaning you can select elements  
directly in it and drag items around. Items can be dropped into  
containers (containers should highlight to show you where the item  
will be dropped.

* An inspector palette should be present to show you the properties  
of the view selected. I would only show the editable properties and  
possibly organize them into panels - you might want a debugging  
palette or panel which shows the calculated properties. This palette  
should be fairly easy to create with Eve (and Adam) - I've been  
meaning to construct this part with the current system just to show  
the properties of each of the widgets types.

     * Shortcuts for typical properties should be provided - ctrl- 
[ - ] for align left, center, right, etc...

* A palette of the available widgets that can be dropped onto either  
the tree view or the preview would be great.

* Within the inspector palette I would allow expressions - not just  
values - for the properties.

* From an implementation standpoint - the Eve (and Adam) languages  
have been designed to support roundtrip editing - this is why the  
comments are in the syntax - so they can be associated with  
particular elements and carried through an editor. The way to build  
such a beast is to replace the eve_evaluate file that captures the  
information from the parser and populate a structure for the editor  
(possibly using the forest library).

* One implementation hole that I know of at the moment is that there  
is no way way to erase an item from a layout - but I believe that  
could be easily added.

* Bonus points for a live source view
* Double bonus points for alternative syntaxes (especially an XML  
based one)
* Triple bonus points for a property model view (a table of cells and  
expressions) - and drag-drop to connect
* 50 bonus points for a property model visualizer (likely using GrafViz)





On Dec 9, 2006, at 9:18 PM, Ralph Thomas wrote:

> Hi list,
>
>   I plan to implement a few features in my app that would benefit from
> having some kind of visual eve editor library (I want to use Eve to do
> page layout for printing photos, and for DVD menu layout). In the ASL
> Overview there is reference to a "Expresso2" visual editor -- I was
> wondering if you had any plans on how to implement the app?
>
>   Obviously it would be great if I could write a library that could be
> used by my app and by Expresso2 (or other Eve visual editor tools).
>
> Ralph
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel

Re: [Adobe-source-devel] visual eve editor

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

That's useful -- I've added it to the wiki. I chatted with Foster a
few days ago and we discussed ways that you could place a new control
in the preview window, highlighting the part of the container where
the control will end up as you suggest.

Also, it's trivial to move items around inside a running Eve -- I've
been able to splice a subtree of the proxy forest into another forest
and then splice it back in somewhere else (always under the same real
widget, though... based on the Win32 experiences it seems like
reparenting widgets is something we can't easily do).

Regarding an XML syntax: one of the things that I like about the
current syntax is that you know at parse time if you're parsing an
integer or a string, e.g.:

  slider( value: 50, name: "a slider" );

Whereas with XML, all attributes look like strings:

  <slider value="50" name="a slider"/>

Unless you make the syntax more verbose:

  <slider>
    <attribute type="int" name="value">50</attribute>
    <attribute type="string" name="name">a slider</attribute>
  </slider>

I'd be interested to hear the opinion of an XML expert on the correct
way to go here :).

Thanks!
 Ralph

On 12/14/06, Sean Parent <sp...@ad...> wrote:
> I have some thoughts - Foster may have some also - he implemented the
> original Expresso -
>
> * The basic UI that I envision is a two view editor - a tree view
> showing the UI elements and a preview.
>
> The tree view should be fairly simple - showing an icon for the view
> type and the name property (after localize is executed) for the item
> - if no name property then the view type is displayed
>
> [] My Dialog
>   -- row
>     () OK
>     () Cancel
>
> * Drag and drop (including multiple items) - should be allowed within
> the tree view as well as between the tree view and preview windows.
>
> * The preview window should be live - meaning you can select elements
> directly in it and drag items around. Items can be dropped into
> containers (containers should highlight to show you where the item
> will be dropped.
>
> * An inspector palette should be present to show you the properties
> of the view selected. I would only show the editable properties and
> possibly organize them into panels - you might want a debugging
> palette or panel which shows the calculated properties. This palette
> should be fairly easy to create with Eve (and Adam) - I've been
> meaning to construct this part with the current system just to show
> the properties of each of the widgets types.
>
>      * Shortcuts for typical properties should be provided - ctrl-
> [ - ] for align left, center, right, etc...
>
> * A palette of the available widgets that can be dropped onto either
> the tree view or the preview would be great.
>
> * Within the inspector palette I would allow expressions - not just
> values - for the properties.
>
> * From an implementation standpoint - the Eve (and Adam) languages
> have been designed to support roundtrip editing - this is why the
> comments are in the syntax - so they can be associated with
> particular elements and carried through an editor. The way to build
> such a beast is to replace the eve_evaluate file that captures the
> information from the parser and populate a structure for the editor
> (possibly using the forest library).
>
> * One implementation hole that I know of at the moment is that there
> is no way way to erase an item from a layout - but I believe that
> could be easily added.
>
> * Bonus points for a live source view
> * Double bonus points for alternative syntaxes (especially an XML
> based one)
> * Triple bonus points for a property model view (a table of cells and
> expressions) - and drag-drop to connect
> * 50 bonus points for a property model visualizer (likely using GrafViz)
>
>
>
>
>
> On Dec 9, 2006, at 9:18 PM, Ralph Thomas wrote:
>
> > Hi list,
> >
> >   I plan to implement a few features in my app that would benefit from
> > having some kind of visual eve editor library (I want to use Eve to do
> > page layout for printing photos, and for DVD menu layout). In the ASL
> > Overview there is reference to a "Expresso2" visual editor -- I was
> > wondering if you had any plans on how to implement the app?
> >
> >   Obviously it would be great if I could write a library that could be
> > used by my app and by Expresso2 (or other Eve visual editor tools).
> >
> > Ralph
> >
> > ----------------------------------------------------------------------
> > ---
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to
> > share your
> > opinions on IT & business topics through brief surveys - and earn cash
> > http://www.techsay.com/default.php?
> > page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > Adobe-source-devel mailing list
> > Ado...@li...
> > https://lists.sourceforge.net/lists/listinfo/adobe-source-devel
>
>

Re: [Adobe-source-devel] visual eve editor

[Sean P. <sp...@ad...>]

On Dec 15, 2006, at 9:11 PM, Ralph Thomas wrote:

>  slider( value: 50, name: "a slider" );
>
> Whereas with XML, all attributes look like strings:
>
>  <slider value="50" name="a slider"/>
>
> Unless you make the syntax more verbose:
>
>  <slider>
>    <attribute type="int" name="value">50</attribute>
>    <attribute type="string" name="name">a slider</attribute>
>  </slider>

There are a couple of options here and nearly any choice has an  
example in common use - one is to have a two level parser - this is  
the approach of the XPath syntax when used in XSL. Here you would  
have something like:

<slider value='50' name='(a slider)'/>

Here we borrow the PDF syntax (xpath doesn't have a very rich type  
system) as a sub-syntax. The problem with this is if you allow  
complex expressions then you need a fairly complete sub-parser:

button(items: ["OK", "Cancel"]); // simplified properties

<button name='[(OK) (Cancel)]'>

Getting to full expressions gets even more complicated - the approach  
used by XFA is to imbed full expression in the sub-syntax:

<Calc>Quantity * UnitPrice</Calc>

Borrowing from XFA (which is in some respects similar to Adam) may  
not be a bad idea.

If we avoid the sub-syntax then following the lead of MXML is likely  
a way to go:

<mx:Array>
   <mx:String >OK</mx:String>
   <mx:String>Cancel</mx:String>
</mx:Array>

A common request is for the embedding of Eve descriptions in MXML  
(has a lot to do with where I work :-) ). Larry sent me a paper at  
one point on extending MXML which is related.

There is also the option of simply imbedding CEL in XML - this would  
allow for structural manipulation using XSL (a big advantage of an  
XML syntax) and we'd get away with our existing CEL parser. This  
would require escaping which is also done with XPath in XSL.

Here we might have something like:

<slider value='50' name='&quot;a slider&quot;'/>

This would likely be the approach for xstrs - so we could have the  
very verbose:

slider(value: 50, name: "<xstr id='slider'>a slider</xstr>"); // CEL  
syntax

<slider value='50' name='&quot;&lt;xstr id=&apos;slider&apos;&gt;a  
slider&lt;/xstr&gt;'>

Oh what fun!

I think what is needed more than an XML expert is a customer - so  
far, anytime someone has asked for an XML syntax (and this happens  
often) there isn't any use case that warrants it. The question comes  
up enough though that I get tired of answering it and one solution  
might be to just pick _any_ XML syntax. The one major exception being  
the answer "I want to use Adam/Eve with Flex" but that requires more  
than just a move to an XML syntax - but I am interested in this  
project if I can find the bandwidth (or volunteers).

At some point, I want to tackle style sheets for Eve - For example,  
be able to have styles for the OK-Cancel cluster being on the top- 
right (Photoshop style) - bottom-right (Mac style) or bottom  
distributed (Windows style) - this kind of structural manipulation is  
a natural use case for XSL but I haven't had time to explore. Oddly  
though, I don't have others asking for this capability.

Sean

Re: [Adobe-source-devel] visual eve editor

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

Goodness! For the record, I agree that it would be nice to be able to
apply an XSLT (or similar) to an Eve definition.

I have a similar requirement, but was planning on using Lua to write
the view definitions in (and then write custom functions for the
things that can vary between platforms -- and just for complex
constructs that I want to reuse). I don't think it's possible to
round-trip Lua in an editor though (but it's probably not possible to
round-trip XML that has to be processed with XSLT either).

I imagine that it would be easier to write stylesheets for XML that
has no sub-syntaxes (I've only ever written very simple XSLTs to do
"join" type operations on webservices, though).

Ralph

On 12/15/06, Sean Parent <sp...@ad...> wrote:
>
> On Dec 15, 2006, at 9:11 PM, Ralph Thomas wrote:
>
> >  slider( value: 50, name: "a slider" );
> >
> > Whereas with XML, all attributes look like strings:
> >
> >  <slider value="50" name="a slider"/>
> >
> > Unless you make the syntax more verbose:
> >
> >  <slider>
> >    <attribute type="int" name="value">50</attribute>
> >    <attribute type="string" name="name">a slider</attribute>
> >  </slider>
>
> There are a couple of options here and nearly any choice has an
> example in common use - one is to have a two level parser - this is
> the approach of the XPath syntax when used in XSL. Here you would
> have something like:
>
> <slider value='50' name='(a slider)'/>
>
> Here we borrow the PDF syntax (xpath doesn't have a very rich type
> system) as a sub-syntax. The problem with this is if you allow
> complex expressions then you need a fairly complete sub-parser:
>
> button(items: ["OK", "Cancel"]); // simplified properties
>
> <button name='[(OK) (Cancel)]'>
>
> Getting to full expressions gets even more complicated - the approach
> used by XFA is to imbed full expression in the sub-syntax:
>
> <Calc>Quantity * UnitPrice</Calc>
>
> Borrowing from XFA (which is in some respects similar to Adam) may
> not be a bad idea.
>
> If we avoid the sub-syntax then following the lead of MXML is likely
> a way to go:
>
> <mx:Array>
>    <mx:String >OK</mx:String>
>    <mx:String>Cancel</mx:String>
> </mx:Array>
>
> A common request is for the embedding of Eve descriptions in MXML
> (has a lot to do with where I work :-) ). Larry sent me a paper at
> one point on extending MXML which is related.
>
> There is also the option of simply imbedding CEL in XML - this would
> allow for structural manipulation using XSL (a big advantage of an
> XML syntax) and we'd get away with our existing CEL parser. This
> would require escaping which is also done with XPath in XSL.
>
> Here we might have something like:
>
> <slider value='50' name='&quot;a slider&quot;'/>
>
> This would likely be the approach for xstrs - so we could have the
> very verbose:
>
> slider(value: 50, name: "<xstr id='slider'>a slider</xstr>"); // CEL
> syntax
>
> <slider value='50' name='&quot;&lt;xstr id=&apos;slider&apos;&gt;a
> slider&lt;/xstr&gt;'>
>
> Oh what fun!
>
> I think what is needed more than an XML expert is a customer - so
> far, anytime someone has asked for an XML syntax (and this happens
> often) there isn't any use case that warrants it. The question comes
> up enough though that I get tired of answering it and one solution
> might be to just pick _any_ XML syntax. The one major exception being
> the answer "I want to use Adam/Eve with Flex" but that requires more
> than just a move to an XML syntax - but I am interested in this
> project if I can find the bandwidth (or volunteers).
>
> At some point, I want to tackle style sheets for Eve - For example,
> be able to have styles for the OK-Cancel cluster being on the top-
> right (Photoshop style) - bottom-right (Mac style) or bottom
> distributed (Windows style) - this kind of structural manipulation is
> a natural use case for XSL but I haven't had time to explore. Oddly
> though, I don't have others asking for this capability.
>
> Sean