adobe-source-devel — ASL development topic discussion

[Adobe-source-devel] Main Window

[Jacob F. <ja...@gm...>]

Howdy,

I'm starting an application from scratch and am looking for recommendations
on what API to use for the "main" window.  Looking at the Begin code, I see
that you guys just used the platform specific API's for the main app window
(e.g. CreateWindowExW).

I'd rather start with something more platform independent, that is also
going to integrate quickly with ASL.  Any advice?

Are there plans to support application type windows with Adam & Eve?  (I
think I remember reading something about that, but forgot where.)  On a
related note, what separates dialogs from main windows?  Persistence?
Pull-down menus?  Min/Max/Restore buttons?

Thanks!
Jacob

Re: [Adobe-source-devel] Adobe Begin on WinXP 64-bit

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

Hi,

I have fixed the x64 issue in the submission depot of the
opensource.adobe.com perforce server. Turns out it was a manifest issue. The
fix will be a part of the 1.0.25 distro. Thanks for bringing this one up.

Blessings,
Foster  


On 2/1/07 9:59 AM, "Tux Han" <tu...@ya...> wrote:

> Hi,
>     I've downloaded Adobe Begin. It worked very well on my 32-bit PC (WinXP
> 32-bit), but it crashed on my 64-bit PC( WinXP 32-bit). It said:
>     "The application failed to initialize properly (0xc0150002)."
>     I even compiled it on my 64-bit PC, it can be compiled successfully, but
> it also failed to run.
>     Is it a bug?
> 
>     Thanks
>    
> 
> 
> Need a quick answer? Get one in minutes from people who know. Ask your
> question on Yahoo! Answers
> <http://answers.yahoo.com/;_ylc=X3oDMTFvbGNhMGE3BF9TAzM5NjU0NTEwOARfcwMzOTY1ND
> UxMDMEc2VjA21haWxfdGFnbGluZQRzbGsDbWFpbF90YWcx> .
> 
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> 
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel

Re: [Adobe-source-devel] Adobe Begin on WinXP 64-bit

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

Hi,

I have an installation of x64 running and am able to reproduce the issue.
While I don=B9t know the specifics just yet, I can tell you that it=B9s got
something to do with the manifest file not being what the x64 environment i=
s
expecting. I=B9ll continue to look into it =8B not sure yet when I=B9ll have
something definitive.

Blessings,
Foster


On 2/1/07 9:59 AM, "Tux Han" <tu...@ya...> wrote:

> Hi,
>     I've downloaded Adobe Begin. It worked very well on my 32-bit PC (Win=
XP
> 32-bit), but it crashed on my 64-bit PC( WinXP 32-bit). It said:
>     "The application failed to initialize properly (0xc0150002)."
>     I even compiled it on my 64-bit PC, it can be compiled successfully, =
but
> it also failed to run.
>     Is it a bug?
>=20
>     Thanks
>   =20

Re: [Adobe-source-devel] aspect ratios in Eve

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

On Feb 2, 2007, at 4:28 PM, Ralph Thomas wrote:

> Hi List,
>
>   Is there a reasonable way to extend Eve such that a view can specify
> an aspect ratio that it must be placed at (if it was a video or
> picture, for example). I'm aware of the twopass layout, but that only
> solves the case where the ratio is wider than it is taller.

No - it simply biases the width first to the hight - you can use the  
same two passes to preserve the aspect ratio-

Think about it this way - given something that is 10 unites wide with  
an aspect ration of 1:2 how tall is it? What if the aspect ration is  
2:1 - now how tall?

>
>   Imagine that such a ratio constrained view is center aligned
> horizontally and filling vertically (and imagine that it's tiny, and
> being scaled up because it's filling vertically). The view won't know
> what width to return to Eve until it knows the height that's
> available.

Simply because you are asked to fill a space horizontally doesn't  
mean you need to use the space - you can place limits on the vertical  
calculation given the aspect ration and horizontal calculation - this  
may then adjust the actual width - and you'll have extra white space  
- but this is white space you would have anyway.

>
>   The only easy way I can think of "solving" this problem is by
> solving vertical layout first, adjusting horizontal and the solving
> horizontal layout when a layout has a view that's constrained like
> this. Clearly this breaks down when there are two views that not both
> constrained in the same way (and probably some platform's paragraph
> layout APIs won't give you width based on height, breaking word-wrap
> in labels). Is there another (reasonable) way to extend Eve to support
> views with fixed aspect ratios?
>
> Thanks!
>  Ralph
>
> ---------------------------------------------------------------------- 
> ---
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel

[Adobe-source-devel] aspect ratios in Eve

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

Hi List,

  Is there a reasonable way to extend Eve such that a view can specify
an aspect ratio that it must be placed at (if it was a video or
picture, for example). I'm aware of the twopass layout, but that only
solves the case where the ratio is wider than it is taller.

  Imagine that such a ratio constrained view is center aligned
horizontally and filling vertically (and imagine that it's tiny, and
being scaled up because it's filling vertically). The view won't know
what width to return to Eve until it knows the height that's
available.

  The only easy way I can think of "solving" this problem is by
solving vertical layout first, adjusting horizontal and the solving
horizontal layout when a layout has a view that's constrained like
this. Clearly this breaks down when there are two views that not both
constrained in the same way (and probably some platform's paragraph
layout APIs won't give you width based on height, breaking word-wrap
in labels). Is there another (reasonable) way to extend Eve to support
views with fixed aspect ratios?

Thanks!
 Ralph

[Adobe-source-devel] ASL 1.0.24 Released

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

Version 1.0.24 of the Adobe Source Libraries was released. Highlights of
this release include:

    * Added adobe::rotate and adobe::reduce_balanced, based on Alex
Stepanov's work. See http://www.stepanovpapers.com/notes.pdf
    * Added adobe::partition_selection_copy, adobe::split_selection, and
adobe::stable_partition_selection
    * Simplified overloading and namespace strategy
    * Rewrote the build instructions in hopes of making them easier to grasp
    * For more information and more changes see the Release Notes

Change list information can be found here:
http://opensource.adobe.com/asl_release_notes.html

Documentation to get started with the release is here:
http://opensource.adobe.com/asl_readme.html

Distribution files can be downloaded from here:
http://sourceforge.net/project/showfiles.php?group_id=132417&package_id=1454
20

Blessings,
Foster

[Adobe-source-devel] Adobe Begin on WinXP 64-bit

[Tux H. <tu...@ya...>]

Hi,=0A    I've downloaded Adobe Begin. It worked very well on my 32-bit PC =
(WinXP 32-bit), but it crashed on my 64-bit PC( WinXP 32-bit). It said:=0A =
   "The application failed to initialize properly (0xc0150002)."=0A    I ev=
en compiled it on my 64-bit PC, it can be compiled successfully, but it als=
o failed to run.=0A    Is it a bug?=0A=0A    Thanks=0A   =0A=0A=0A=0A=0A =
=0A________________________________________________________________________=
____________=0ADo you Yahoo!?=0AEveryone is raving about the all-new Yahoo!=
 Mail beta.=0Ahttp://new.mail.yahoo.com

Re: [Adobe-source-devel] gil on gcc-3.3

[Hubert F. <hu...@fi...>]

Peter K=FCmmel wrote:
> There are big improvements in the template support of
> gcc 3.4, so maybe 3.4 is an option. But I've not
> tried to compile with 3.4.

It works with gcc 3.4 apparently. Looks like I can make it an option.

Maybe it would be worth putting that in the documentation as a
requirement. ;-)

Thanks

Hub

Re: [Adobe-source-devel] gil on gcc-3.3

[<syn...@gm...>]

Hubert Figuiere wrote:
> Hi,
> 
> I'm trying to use gil from asl 1.0.23, and compile my files with gcc-3.3
> on Linux, and it fails miserably.
> 
> The first errors are these:
> 
> In file included from ../../external/gil/core/channel.hpp:26,
>                  from ../../external/gil/core/gil_all.hpp:22,
>                  from ximage.h:10,
>                  from ximage.cpp:7:
> ../../external/gil/core/utilities.hpp:68: error: conflicting types for
> `T
> gil::point2<T>::*gil::point2<T>::mem_array[gil::point2<T>::num_dimensions]'
> ../../external/gil/core/utilities.hpp:64: error: previous declaration as `T
> gil::point2<T>::*gil::point2<T>::mem_array[gil::point2<T>::num_dimensions]'
> In file included from ../../external/gil/core/gil_all.hpp:22,
>                  from ximage.h:10,
>                  from ximage.cpp:7:
> ../../external/gil/core/channel.hpp:107: warning: `inline' is not at
> beginning of declaration
> ../../external/gil/core/channel.hpp:110: warning: `inline' is not at
> beginning of declaration
> 
> The header on do this:
> 
> #include <gil/core/gil_all.hpp>
> 
> (no other includes before).
> 
> If I use gcc-4.x, it works. Unfortunately it is again a case were gcc
> 4.0 is not an option.
> 
> Any idea or GIL is know to NOT work with gcc 3.3
> 

There are big improvements in the template support of
gcc 3.4, so maybe 3.4 is an option. But I've not
tried to compile with 3.4.

Peter

[Adobe-source-devel] gil on gcc-3.3

[Hubert F. <hu...@fi...>]

Hi,

I'm trying to use gil from asl 1.0.23, and compile my files with gcc-3.3
on Linux, and it fails miserably.

The first errors are these:

In file included from ../../external/gil/core/channel.hpp:26,
                 from ../../external/gil/core/gil_all.hpp:22,
                 from ximage.h:10,
                 from ximage.cpp:7:
../../external/gil/core/utilities.hpp:68: error: conflicting types for
`T
gil::point2<T>::*gil::point2<T>::mem_array[gil::point2<T>::num_dimensions]'
../../external/gil/core/utilities.hpp:64: error: previous declaration as `T
gil::point2<T>::*gil::point2<T>::mem_array[gil::point2<T>::num_dimensions]'
In file included from ../../external/gil/core/gil_all.hpp:22,
                 from ximage.h:10,
                 from ximage.cpp:7:
../../external/gil/core/channel.hpp:107: warning: `inline' is not at
beginning of declaration
../../external/gil/core/channel.hpp:110: warning: `inline' is not at
beginning of declaration

The header on do this:

#include <gil/core/gil_all.hpp>

(no other includes before).

If I use gcc-4.x, it works. Unfortunately it is again a case were gcc
4.0 is not an option.

Any idea or GIL is know to NOT work with gcc 3.3


Thanks


Hub

[Adobe-source-devel] assemblage granularity

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

Hi list,

  One of the things that may need attention for the Expresso editor
(amongst other things) is assemblage granularity. As controls can be
added and removed from the dialog in an editor, the lifetimes of the
controls aren't always going to be tied to the lifetime of the dialog.

  One approach would be to use a different assemblage for each
control, however the current eve_client_holder design doesn't allow
for this (not unless the assemblage member becomes a reference that
can be changed).

  The other approach would be to modify assemblage so that you can
call some kind of "begin/end" functions that would return some
identifier you could use to destroy the things that got created
between begin and end.

  Note that this is something I have to solve for Mission soon (it's
blocking moving to 1.0.23), so I'd rather come up with a solution that
can go back into ASL. Previously the factory_token_t contained a
reference to an assemblage, and I just used a different assemblage for
every view I needed to.

Ralph

[Adobe-source-devel] New Build Documentation

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

All,

I have begun work on new build documentation for ASL. It can be found here:

http://opensource.adobe.com/wiki/index.php/New_Build_Documentation

I would like to replace the current read_me with its contents by the next
release. While better than the previous document, I'm open to any
comments/suggestions people have on improving it. Nevertheless, I'm hoping
it'll shed some light on and otherwise unwieldy build setup.

Blessings,
Foster


--=20
Foster T. Brereton                  <=E1=BC=B0=CF=87=CE=B8=CF=8D=CF=82><                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
"What 99 percent of programmers need to know is not how to build components
but how to use them." -- Alexander Stepanov
"Now we have very simple code and the meaning is perfectly clear. Drink the
Kool-Aid" -- Sean Parent

Re: [Adobe-source-devel] List/Tree View Control for ASL

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

SSBoYXZlIGEgbGlzdCAobm90IHRyZWUpIHZpZXcgd2lkZ2V0IGluIE1pc3Npb24uIEl0J3Mgbm90
IGltcGxlbWVudGVkCmluIHRlcm1zIG9mIGEgcGxhdGZvcm0gdHJlZSB2aWV3IHdpZGdldCwgdGhv
dWdoLiBJdCB3b3JrcyBsaWtlIHRoaXM6CgpAYXJyYXlfaW5fc2hlZXQgY29udGFpbnMgYW4gYXJy
YXkgb2Ygc3RyaW5nczoKCnNjcm9sbHZpZXcoKSB7CiAgY29sdW1uKCkgewogICAgZ2VuZXJhdG9y
KGJpbmQ6IEBhcnJheV9pbl9zaGVldCwgaXRlcmF0b3I6IEBpKSB7CiAgICAgIGR5bmFtaWNfdGV4
dChiaW5kOiBAaSk7CiAgICB9CiAgfQp9CgpUaGlzIG1ha2VzIGEgc2Nyb2xsaW5nIGxpc3Qgb2Yg
dGhlIHRleHQuIEkgaGF2ZSBjb250YWluZXJzIHRoYXQKaGlnaGxpZ2h0IHdoZW4gY2xpY2tlZCBh
bmQgc2V0IGEgdmFsdWUgaW50byBhIGNlbGwgKHNvIHRoZXkgbW9kZWwgdGhlCnNhbWUgY29uY2Vw
dCBhcyBhIHJhZGlvIGJ1dHRvbikuIFRoZXNlIGNhbiBiZSB1c2VkIGZvciBzZWxlY3Rpb24uIFdo
ZW4KY29tYmluZWQgd2l0aCB0aGUgZGF0YXB1bXAgY29uY2VwdCB0aGF0IEkgaGF2ZSwgeW91IGNh
biB1c2UgbXVsdGlwbGUKdmlld3MgZm9yIGFuIGl0ZW06CgpAYXJyYXlfaW5fc2hlZXQgY29udGFp
bnMgYW4gYXJyYXkgb2YgZGljdGlvbmFyaWVzIHsgaWNvbjogImljb24gbmFtZSIsCm5hbWU6ICJ0
ZXh0IiB9OgoKc2Nyb2xsdmlldygpIHsKICBjb2x1bW4oKSB7CiAgICBnZW5lcmF0b3IoYmluZDog
QGFycmF5X2luX3NoZWV0LCBpdGVyYXRvcjogQGkpIHsKICAgICAgcm93KCkgewogICAgICAgIGlj
b24oc2l6ZTogMTYsIGJpbmQ6IGRpY3Rpb25hcnkoIGRpY3Q6IEBpLCBrZXk6ICJpY29uIiApICk7
CiAgICAgICAgZHluYW1pY190ZXh0KGJpbmQ6IGRpY3Rpb25hcnkoIGRpY3Q6IEBpLCBrZXk6ICJu
YW1lIiApICk7CiAgICAgIH0KICAgIH0KICB9Cn0KClRoaXMgYXBwcm9hY2ggd29ya3Mgd2VsbCBm
b3Igc21hbGwgZGF0YSBzZXRzLCBhbmQgdGhlIGNvZGUgdG8KZ2VuZXJhdG9yIGlzIHRvdGFsbHkg
cGxhdGZvcm0gaW5kZXBlbmRlbnRbMV0uIFRoZXJlIGFyZSBzb21lCm9wdGltaXphdGlvbnMgZm9y
IGRlYWxpbmcgd2l0aCBodWdlIGRhdGFzZXRzIHdoZXJlIG9ubHkgdGhlIHZpc2libGUKdmlld3Mg
YXJlIGNyZWF0ZWQsIGJ1dCBvbiBtb3N0IHBsYXRmb3JtcyBzY3JvbGxpbmcgYSBsYXJnZSBudW1i
ZXIgb2YKd2lkZ2V0cyBpcyBzbG93IChNYWNPUyBpcyBhbiBleGNlcHRpb24gdG8gdGhpcywgYnV0
IGJvdGggV2luMzIgYW5kCkdUSysgd2VyZSBzbG93IGF0IHNjcm9sbGluZyBsb3RzIG9mIHdpZGdl
dHMpLgoKVG8gYWRkcmVzcyB0aGUgcGVyZm9ybWFuY2UgcHJvYmxlbXMgd2l0aCBzY3JvbGxpbmcs
IEkgd3JvdGUgYSB2ZXJzaW9uCm9mIGdlbmVyYXRvciB0aGF0IHVzZXMgZmx5d2VpZ2h0IHZpZXdz
IHRvIGRpc3BsYXkgdGhlIGRhdGEuIFRoZQphZHZhbnRhZ2Ugb2YgdGhpcyBhcHByb2FjaCBpcyB0
aGF0IGl0IG1ha2VzIHRoaW5ncyBsaWtlIGNhY2hpbmcKZGVjb2RlZCBpbWFnZXMgbXVjaCBtb3Jl
IHN0cmFpZ2h0Zm9yd2FyZCwgYW5kIGl0J3MgdmVyeSBxdWljayB0bwpzY3JvbGwgYW5kIHJlc2l6
ZS4gVGhlIGRpc2FkdmFudGFnZSBpcyB0aGF0IG1vc3Qgb2YgdGhlIGNvZGUgaXMKcGxhdGZvcm0g
c3BlY2lmaWMuIEkgb25seSBoYXZlIGFuIGltcGxlbWVudGF0aW9uIG9mIG15CmZseXdlaWdodF9n
ZW5lcmF0b3IgZm9yIEd0aysgY3VycmVudGx5LCBhbHRob3VnaCBDb2NvYSAoYW5kIHByb2JhYmx5
CkNhcmJvbikgaGFzIGZseXdlaWdodCB2aWV3cyBhdmFpbGFibGUgaW4gdGhlIHBsYXRmb3JtIChX
aW4zMiB3aWxsIGJlIGEKbGl0dGxlIG1vcmUgd29yaykuCgpJIGxpa2UgdGhlIGlkZWEgb2YgaGF2
aW5nIGEgdHJlZXZpZXcgaW4gdGhlIHBsYXRmb3JtLCBhbmQgYSBzaW1wbGUgb25lCndvdWxkIGJl
IHN1ZmZpY2llbnQgZm9yIEV4cHJlc3NvMiBhbmQgZm9yIHByZWZlcmVuY2UgZGlhbG9ncywgZXRj
LiBJdAp3b3VsZCBiZSBuaWNlIGlmIGl0IGNvdWxkIGJlIGV4dGVuZGVkIHNvIHRoYXQgeW91IGNv
dWxkIGRvIHRoaW5ncyBsaWtlCmxvYWQgcGFydHMgb2YgdGhlIHRyZWUgb24gZGVtYW5kIChpZiB5
b3Ugd2FudGVkIHRvIGRvIGEgdHJlZXZpZXcgb2YKdGhlIGZpbGVzeXN0ZW0gd2l0aG91dCByZWFk
aW5nIGV2ZXJ5IGRpcmVjdG9yeSBpbiBhZHZhbmNlLCBmb3IKZXhhbXBsZSkuCgpUaGUgbWFpbiBp
c3N1ZXMgYXJlOgoKICAtIEhvdyBkbyB5b3Ugc3BlY2lmeSB0aGUgY29udGVudHMgb2YgZWFjaCBy
b3c/IEFyZSBjaGlsZCByb3dzCmFsbG93ZWQgdG8gaGF2ZSBkaWZmZXJlbnQgdmlld3MgaW4gdGhh
biB0aGVpciBwYXJlbnRzIGRvPwogIC0gSG93IGRvIHlvdSBzcGVjaWZ5IHdoaWNoIHZpZXdzIGlu
IGEgcm93IGNvcnJlc3BvbmQgdG8gd2hhdCBkYXRhIGluCnRoZSB0cmVlIG1vZGVsPwogIC0gSG93
IGRvIHlvdSBzcGVjaWZ5IHRoZSB0cmVlIG1vZGVsPyBXaWxsIHRoZXJlIGJlIGEgc3ludGF4IGZv
cgpzcGVjaWZ5aW5nIGEgdHJlZSBhcyBhbiBvdXRwdXQgY2VsbCBpbiBhbiBBZGFtIHNoZWV0Pwog
IC0gSXMgaXQgcG9zc2libGUgdG8gbWluaW1pemUgdGhlIGFtb3VudCBvZiB3b3JrIHRoYXQgaGFz
IHRvIGJlIGRvbmUKd2hlbiB0aGUgbW9kZWwgY2hhbmdlcz8KClRoZXJlIGFyZSBwcm9iYWJseSBt
b3JlIHRoYXQgSSdtIG1pc3NpbmcgYXQgdGhlIG1vbWVudCA6KS4gSSdsbCBhZGQKdGhpcyB0byB0
aGUgd2lraSB0aGlzIGV2ZW5pbmcsIGlmIHlvdSBoYXZlbid0IGFscmVhZHkuCgpUaGFua3MsCiBS
YWxwaAoKWzFdOiBodHRwOi8vbWlzc2lvbmNvZGUuZ29vZ2xlY29kZS5jb20vc3ZuL3RydW5rL3Zp
ZXcvZ2VuZXJpYy9nZW5lcmF0b3IuYysrCihub3RlIHRoYXQgdGhpcyByZXF1aXJlcyByZW1vdmVf
dmlld19lbGVtZW50IGFuZCByZWluc2VydF92aWV3X2VsZW1lbnQKdG8gYmUgaW1wbGVtZW50ZWQg
aW4gRXZlIC0tIHRoaXMgaXMgYSB0cml2aWFsIHNwbGljZSBvZiB0aGUgcHJveGllcwpmb3Jlc3Qp
LiBSZWFsIHVzYWdlIG9mIHRoZSBnZW5lcmF0b3IgaXMgaGVyZToKaHR0cDovL21pc3Npb25jb2Rl
Lmdvb2dsZWNvZGUuY29tL3N2bi90cnVuay9yZXNvdXJjZXMvYXBwcy9waG90by9ldmUKaW4gdGhl
ICJsaXN0IG9mIGFsYnVtcyIuCgpPbiAxLzkvMDcsIEZvc3RlciBULiBCcmVyZXRvbiA8ZmJyZXJl
dG9AYWRvYmUuY29tPiB3cm90ZToKPiBIZXkgYWxsLAo+Cj4gVGhpcyBpcyBzb21ldGhpbmcgb2Yg
YSAnY2FsbCBmb3IgaW5wdXQnIGludG8gdGhlIHByb2plY3QgSSdkIGxpa2UgdG8gZm9jdXMKPiBv
biBuZXh0OiBBIGxpc3QvdHJlZSB2aWV3L2NvbnRyb2xsZXIgZm9yIEFTTC4gVGhpcyB3aWxsIG1v
c3QgbGlrZWx5IGxldmVyYWdlCj4gdGhlIERhdGEgQnJvd3NlciAoQ2FyYm9uKSBhbmQgVHJlZVZp
ZXcgKFdpbjMyKSBjb250cm9sIGltcGxlbWVudGF0aW9ucyBmb3IKPiB0aGUgYmFjayBlbmQuCj4K
PiBUaGUgYmlnIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGlzIHdpZGdldCBhbmQgb3RoZXJzIGlzIHRo
YXQgYSBsaXN0L3RyZWUgdmlldwo+IGlzIGEgcmVwcmVzZW50YXRpb24gb2YgYSBzZXF1ZW5jZSBv
ZiBub2Rlcy4gTXkgY3VycmVudCB0aG91Z2h0IGlzIHRvIGhhdmUKPiB0aGUgZGF0YSBzdHJ1Y3R1
cmUgYmVoaW5kIHRoZSB3aWRnZXQgYmUgYW4gYWRvYmU6OmZvcmVzdC4gVGhpcyBzaG9yZXMgdXAg
dGhlCj4gZnVuY3Rpb25hbGl0eSBhdmFpbGFibGUgdG8gdGhlIHdpZGdldCwgYnV0IHdoYXQgSSdk
IGxpa2UgdG8gZm9jdXMgb24gZm9yCj4gZmVlZGJhY2sgaXMgdGhlIG1lYW5zIGJ5IHdoaWNoIGlu
Zm9ybWF0aW9uIGlzIGNvbW11bmljYXRlZCBiZXR3ZWVuIHRoZQo+IHdpZGdldCBhbmQgdGhlIGNs
aWVudC4gV2hhdCB3b3VsZCBzdWNoIGEgY29tbXVuaWNhdGlvbiBzeXN0ZW0gbG9vayBsaWtlPyBG
b3IKPiBpbnN0YW5jZSwgd2hhdCB3b3VsZCBiZSBhIGdvb2QgZ2VuZXJhbCBzb2x1dGlvbiB0aGF0
IHdvdWxkIHByb3ZpZGUgdGhlCj4gYWJpbGl0eSB0byBub3RpZnkgdGhlIHVzZXIgb2Ygd2hhdCBz
ZXF1ZW5jZSBvZiBub2RlcyBhcmUgY3VycmVudGx5IHZpc2libGUKPiBpbiB0aGUgd2lkZ2V0IHZp
ZXc/Cj4KPiBJIGhhdmUgYmVndW4gYSBicmFpbnN0b3JtaW5nIHBhZ2Ugb24gdGhlIG9wZW5zb3Vy
Y2UuYWRvYmUuY29tIHdpa2k6Cj4KPiBodHRwOi8vb3BlbnNvdXJjZS5hZG9iZS5jb20vd2lraS9p
bmRleC5waHAvTGlzdC9UcmVlX1dpZGdldAo+Cj4gQW55IGNvbnRyaWJ1dGlvbnMgb3IgdGhvdWdo
dHMgeW91IG1pZ2h0IGhhdmUgaW50byB0aGUgdG9waWMgd291bGQgYmUKPiBiZW5lZmljaWFsLgo+
Cj4gKE15IGxvbmcgdGVybSBwbGFuIGlzIHRvIGxldmVyYWdlIHRoZSB3aWRnZXQgaW4gdGhlIGNy
ZWF0aW9uIG9mICJFeHByZXNzbzIiLAo+IGEgdmlzdWFsIGVkaXRvciBmb3Igb3VyIGxheW91dC9w
cm9wZXJ0eSBtb2RlbCBzeXN0ZW0uKQo+Cj4gQmxlc3NpbmdzLAo+IEZvc3Rlcgo+Cj4KPiAtLQo+
IEZvc3RlciBULiBCcmVyZXRvbiAgICAgICAgICAgICAgICAgIDzhvLDPh864z43Pgj48ICAgICAg
ICAgICAgICAgIFJvbWFucyAzOjIxLTI2Cj4gQSBkIG8gYiBlICAgUyBvIGYgdCB3IGEgciBlICAg
VCBlIGMgaCBuIG8gbCBvIGcgeSAgIEwgYSBiCj4gIldoYXQgOTkgcGVyY2VudCBvZiBwcm9ncmFt
bWVycyBuZWVkIHRvIGtub3cgaXMgbm90IGhvdyB0byBidWlsZCBjb21wb25lbnRzCj4gYnV0IGhv
dyB0byB1c2UgdGhlbS4iIC0tIEFsZXhhbmRlciBTdGVwYW5vdgo+ICJOb3cgd2UgaGF2ZSB2ZXJ5
IHNpbXBsZSBjb2RlIGFuZCB0aGUgbWVhbmluZyBpcyBwZXJmZWN0bHkgY2xlYXIuIERyaW5rIHRo
ZQo+IEtvb2wtQWlkIiAtLSBTZWFuIFBhcmVudAo+Cj4KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gVGFr
ZSBTdXJ2ZXlzLiBFYXJuIENhc2guIEluZmx1ZW5jZSB0aGUgRnV0dXJlIG9mIElUCj4gSm9pbiBT
b3VyY2VGb3JnZS5uZXQncyBUZWNoc2F5IHBhbmVsIGFuZCB5b3UnbGwgZ2V0IHRoZSBjaGFuY2Ug
dG8gc2hhcmUgeW91cgo+IG9waW5pb25zIG9uIElUICYgYnVzaW5lc3MgdG9waWNzIHRocm91Z2gg
YnJpZWYgc3VydmV5cyAtIGFuZCBlYXJuIGNhc2gKPiBodHRwOi8vd3d3LnRlY2hzYXkuY29tL2Rl
ZmF1bHQucGhwP3BhZ2U9am9pbi5waHAmcD1zb3VyY2Vmb3JnZSZDSUQ9REVWREVWCj4gX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBBZG9iZS1zb3VyY2Ut
ZGV2ZWwgbWFpbGluZyBsaXN0Cj4gQWRvYmUtc291cmNlLWRldmVsQGxpc3RzLnNvdXJjZWZvcmdl
Lm5ldAo+IGh0dHBzOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL2Fkb2Jl
LXNvdXJjZS1kZXZlbAo+Cg==

[Adobe-source-devel] List/Tree View Control for ASL

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

Hey all,

This is something of a 'call for input' into the project I'd like to focus
on next: A list/tree view/controller for ASL. This will most likely leverag=
e
the Data Browser (Carbon) and TreeView (Win32) control implementations for
the back end.

The big difference between this widget and others is that a list/tree view
is a representation of a sequence of nodes. My current thought is to have
the data structure behind the widget be an adobe::forest. This shores up th=
e
functionality available to the widget, but what I'd like to focus on for
feedback is the means by which information is communicated between the
widget and the client. What would such a communication system look like? Fo=
r
instance, what would be a good general solution that would provide the
ability to notify the user of what sequence of nodes are currently visible
in the widget view?

I have begun a brainstorming page on the opensource.adobe.com wiki:

http://opensource.adobe.com/wiki/index.php/List/Tree_Widget

Any contributions or thoughts you might have into the topic would be
beneficial.

(My long term plan is to leverage the widget in the creation of "Expresso2"=
,
a visual editor for our layout/property model system.)

Blessings,
Foster


--=20
Foster T. Brereton                  <=E1=BC=B0=CF=87=CE=B8=CF=8D=CF=82><                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
"What 99 percent of programmers need to know is not how to build components
but how to use them." -- Alexander Stepanov
"Now we have very simple code and the meaning is perfectly clear. Drink the
Kool-Aid" -- Sean Parent

Re: [Adobe-source-devel] keyboard handling

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

I'll add a little more on where this is going and why -

Most frameworks end up with a "view system" (we call this a display =20
system so as not to confuse it with view in MVC) which also =20
dispatches events and in every framework I've used this ends up being =20=

a fairly large tangled mess. There is only a small correlation =20
between the view hierarchy and the event hierarchy -

To date, with the widget library we've been focused on the controller/=20=

view side of the widget - not how the backend side of the widget (how =20=

does it handle events and drawing) - but we have a rough idea of what =20=

we want for these things - they are containers. A display_t will =20
eventually hold drawable items and a keyboard_t holds key event =20
handlers... Right now, this are small shims over the platform =20
mechanism where how the drawing/event handling happens is platform =20
specific communication between the widget and the system.

Eventually we'll flesh these out to be more complete - and provide a =20
platform independent way to write a widget (though I'd like to keep =20
the ability to use the platform widgets) - I had hoped to use =20
Antigrain as the drawing library for this but their recent move to a =20
GPL license pretty much kills this plan.

Sean

On Jan 8, 2007, at 10:24 AM, Foster T. Brereton wrote:

> Hi Ralph,
>
> keyboard_t is a step in the direction of splitting out the various =20
> event
> trees into their separate components. keyboard_t is intended to be =20
> the event
> tree for all events related to the keyboard. Individual widgets can =20=

> attach
> themselves into the keyboard handler tree if they'd like to receive
> notification of keyboard events in particular. It is our intent to
> eventually have event trees for other events as well (e.g., mouse_t)
>
> The only place keyboard_t is driven is from within handle_dialog. =20
> One of the
> big issues we have yet to tackle is getting this new event mechanism
> integrated into legacy event handling systems. Because we haven't =20
> tackled
> this problem yet, Begin doesn't have a top-level mechanism to =20
> translate
> events from its event handlers (be they win32 or Carbon) to =20
> keyboard_t. We
> started down this road with handle_dialog because it has a subloop =20
> over
> which we have complete control. I'd recommend having a look within
> modal_dialog_interface.cpp, as that's where all the fun is being =20
> had at this
> time.
>
> The underlying_handler routine is an access function for the =20
> keyboard_t
> mechanism so it can get to the platform-specific "thing" that does the
> actual handling of the event. Again, the need for this routine =20
> comes out of
> the need to integrate keyboard_t into the classical event handling =20
> systems
> found in Carbon and win32.
>
> I hope that sheds some light on the subject. If there's anything =20
> more I can
> do to help answer your questions, please let me know.
>
> Blessings,
> Foster
>
>
> On 1/5/07 11:31 p, "Ralph Thomas" <ra...@gm...> wrote:
>
>> Hi list,
>>
>>   How does adobe::keyboard_t work:
>>
>>   - How do keyboard events get put in there? (On Windows I can see
>> that the top-level window puts some in, but it won't get all of them,
>> will it? On Mac I can't see anything that calls
>> keyboard_t::dispatch...)
>>   - What is underlying_handler() used for?
>>
>> Thanks,
>>  Ralph
>>
>> ---------------------------------------------------------------------=20=

>> ----
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to =20
>> share your
>> opinions on IT & business topics through brief surveys - and earn =20
>> cash
>> http://www.techsay.com/default.php?=20
>> page=3Djoin.php&p=3Dsourceforge&CID=3DDEVDEV
>> _______________________________________________
>> Adobe-source-devel mailing list
>> Ado...@li...
>> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel
>
> --=20
> Foster T. Brereton                  <=E1=BC=B0=CF=87=CE=B8=CF=8D=CF=82><=
                =20
> 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
> "What 99 percent of programmers need to know is not how to build =20
> components
> but how to use them." -- Alexander Stepanov
> "Now we have very simple code and the meaning is perfectly clear. =20
> Drink the
> Kool-Aid" -- Sean Parent
>
>
> ----------------------------------------------------------------------=20=

> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to =20
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?=20
> page=3Djoin.php&p=3Dsourceforge&CID=3DDEVDEV
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel

Re: [Adobe-source-devel] keyboard handling

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

Hi Ralph,

keyboard_t is a step in the direction of splitting out the various event
trees into their separate components. keyboard_t is intended to be the even=
t
tree for all events related to the keyboard. Individual widgets can attach
themselves into the keyboard handler tree if they'd like to receive
notification of keyboard events in particular. It is our intent to
eventually have event trees for other events as well (e.g., mouse_t)

The only place keyboard_t is driven is from within handle_dialog. One of th=
e
big issues we have yet to tackle is getting this new event mechanism
integrated into legacy event handling systems. Because we haven't tackled
this problem yet, Begin doesn't have a top-level mechanism to translate
events from its event handlers (be they win32 or Carbon) to keyboard_t. We
started down this road with handle_dialog because it has a subloop over
which we have complete control. I'd recommend having a look within
modal_dialog_interface.cpp, as that's where all the fun is being had at thi=
s
time.

The underlying_handler routine is an access function for the keyboard_t
mechanism so it can get to the platform-specific "thing" that does the
actual handling of the event. Again, the need for this routine comes out of
the need to integrate keyboard_t into the classical event handling systems
found in Carbon and win32.

I hope that sheds some light on the subject. If there's anything more I can
do to help answer your questions, please let me know.

Blessings,
Foster


On 1/5/07 11:31 p, "Ralph Thomas" <ra...@gm...> wrote:

> Hi list,
>=20
>   How does adobe::keyboard_t work:
>=20
>   - How do keyboard events get put in there? (On Windows I can see
> that the top-level window puts some in, but it won't get all of them,
> will it? On Mac I can't see anything that calls
> keyboard_t::dispatch...)
>   - What is underlying_handler() used for?
>=20
> Thanks,
>  Ralph
>=20
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share y=
our
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3DDEVDEV
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel

--=20
Foster T. Brereton                  <=E1=BC=B0=CF=87=CE=B8=CF=8D=CF=82><                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
"What 99 percent of programmers need to know is not how to build components
but how to use them." -- Alexander Stepanov
"Now we have very simple code and the meaning is perfectly clear. Drink the
Kool-Aid" -- Sean Parent

[Adobe-source-devel] keyboard handling

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

Hi list,

  How does adobe::keyboard_t work:

  - How do keyboard events get put in there? (On Windows I can see
that the top-level window puts some in, but it won't get all of them,
will it? On Mac I can't see anything that calls
keyboard_t::dispatch...)
  - What is underlying_handler() used for?

Thanks,
 Ralph

[Adobe-source-devel] ASL 1.0.23 Released

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

Happy New Year!

Version 1.0.23 of the Adobe Source Libraries was released. Highlights of
this release include:

    * Implemented an updated namespace strategy for the widget library
    * Migrated some widget layout attributes from measure() to a table
lookup system
    * GIL bug fixes and updates
    * Other minor bug updates
    * For more information and more changes see the Release Notes

Change list information can be found here:
http://opensource.adobe.com/asl_release_notes.html

Documentation to get started with the release is here:
http://opensource.adobe.com/asl_readme.html

Distribution files can be downloaded from here:
http://sourceforge.net/project/showfiles.php?group_id=132417&package_id=1454
20

Blessings,
Foster

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

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...>]

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...>]

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] GIL still a part of ASL ??

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

 From Lubomir, "I would like to keep opensource.adobe.com be the  
primary site for GIL, the place where people would be able to get the  
latest and greatest updates. "

Sean

On Dec 11, 2006, at 1:59 PM, Haroon Khan wrote:

> Now that GIL has been accepted into Boost, will updates to GIL be
> posted on the Boost CVS exclusively or continue to be posted on
> http://opensource.adobe.com/gil/
>
> Thanks, Haroon
>
> On 12/8/06, Foster T. Brereton <fbr...@ad...> wrote:
>> Version 1.0.22 of the Adobe Source Libraries was released.  
>> Highlights of
>> this release include:
>> * Massive refactoring of the widget library to make each widget a  
>> standalone
>> component
>> * Delayed creation of the platform-widget to display::insert<> time,
>> allowing proper subwindow ownership to take place on win32
>> * Removed more files than you can shake a stick at
>> * Began the documentation process of the individual widgets under  
>> Widget
>> Library
>>
>> Change list information can be found here:
>> http://opensource.adobe.com/asl_release_notes.html
>>
>> Documentation to get started with the release is here:
>> http://opensource.adobe.com/asl_readme.html
>>
>> Distribution files can be downloaded from here:
>> http://sourceforge.net/project/showfiles.php? 
>> group_id=132417&package_id=1454
>> 20
>>
>> Blessings,
>> Foster
>>
>>
>> --------------------------------------------------------------------- 
>> ----
>> 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
>>
>
> ---------------------------------------------------------------------- 
> ---
> 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

[Adobe-source-devel] GIL still a part of ASL ??

[Haroon K. <har...@gm...>]

Now that GIL has been accepted into Boost, will updates to GIL be
posted on the Boost CVS exclusively or continue to be posted on
http://opensource.adobe.com/gil/

Thanks, Haroon

On 12/8/06, Foster T. Brereton <fbr...@ad...> wrote:
> Version 1.0.22 of the Adobe Source Libraries was released. Highlights of
> this release include:
> * Massive refactoring of the widget library to make each widget a standalone
> component
> * Delayed creation of the platform-widget to display::insert<> time,
> allowing proper subwindow ownership to take place on win32
> * Removed more files than you can shake a stick at
> * Began the documentation process of the individual widgets under Widget
> Library
>
> Change list information can be found here:
> http://opensource.adobe.com/asl_release_notes.html
>
> Documentation to get started with the release is here:
> http://opensource.adobe.com/asl_readme.html
>
> Distribution files can be downloaded from here:
> http://sourceforge.net/project/showfiles.php?group_id=132417&package_id=1454
> 20
>
> Blessings,
> Foster
>
>
> -------------------------------------------------------------------------
> 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
>

[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