adobe-source-devel — ASL development topic discussion

[Adobe-source-devel] ASL 1.0.22 Released

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

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

Re: [Adobe-source-devel] Questions on using Boost

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

VGhhbmtzIGZvciB0aGUgdmVyeSBoZWxwZnVsIHJlc3BvbnNlLiAgVGhhdCBkb2VzIHNvbHZlIG15
IHByb2JsZW0uICBEZXNwaXRlCnRoZSBpbnRlcmVzdGluZyBhdXRvX2xpbmsgZmVhdHVyZSwgaXQg
bG9va3MgbGlrZSBpdCB3aWxsIGJlIGJldHRlciBmb3IgbWUgdG8KdXNlIEJPT1NUX0FMTF9OT19M
SUIgYXMgd2VsbC4KCkknbSBhZnJhaWQgSSBkb24ndCBzcGVhayBiamFtZXNlIGF0IGFsbCB5ZXQs
IHNvIGl0IG1heSBiZSBhIHdoaWxlIGJlZm9yZSBJCmZpeCBhbnkgYnVncyB0aGVyZS4gIDstKQoK
VGhhbmtzLCBhZ2FpbiEKSmFjb2IKCk9uIDExLzEwLzA2LCBGb3N0ZXIgVC4gQnJlcmV0b24gPGZi
cmVyZXRvQGFkb2JlLmNvbT4gd3JvdGU6Cj4KPiBIaSBKYWNvYiwKPgo+IE9uIDExLzEwLzA2IDQ6
MDkgcCwgIlNlYW4gUGFyZW50IiA8c3BhcmVudEBhZG9iZS5jb20+IHdyb3RlOgo+Cj4gPj4gU2Vj
b25kLCBhc3N1bWluZyB0aGVyZSBhcmUgbm8gb2JqZWN0aW9ucyB0byB1c2luZyB0aGUgYWRvYmUv
dGhpcmRfcGFydHkKPiA+PiBmbGF2b3IKPiA+PiBvZiBCb29zdCwgSSBoYXZlIGEgbGlua2luZyBx
dWVzdGlvbi4gIE9uIG15IHN5c3RlbSAoWFAsIFZDODApLCBmb3IKPiBleGFtcGxlLAo+ID4+IEFT
TCBidWlsZHMgdGhlIGRlYnVnIGZpbGVzeXN0ZW0gbGliIG5hbWVkIGFzIGZvbGxvd3M6Cj4gPj4g
Ym9vc3RfZmlsZXN5c3RlbS12YzgwLW10LWQtMV8zMy5saWIKPiA+PiBIb3dldmVyLCBpbmNsdWRp
bmcgYm9vc3QvZmlsZXN5c3RlbSBpbiBteSBvd24gYXBwbGljYXRpb24gdHJpZ2dlcnMgYW4KPiA+
PiBhdXRvX2xpbmsgdy8gdGhlIGZvbGxvd2luZzoKPiA+PiBsaWJib29zdF9maWxlc3lzdGVtLXZj
ODAtbXQtc2dkLTFfMzNfMS5saWIKPiA+Pgo+ID4+IEkgZG8gbm90IHVuZGVyc3RhbmQgd2hlcmUg
dGhlIGRpc2NyZXBhbmNpZXMgaW4gbmFtaW5nIGNvbWUKPiBmcm9tLiAgQXBwYXJlbnRseSwKPiA+
PiB0aGUgQWRvYmUgYnVpbHQgbGliIGlzIGludGVuZGVkIHRvIGJlIHVzZWQgYXMgYSBkeW5hbWlj
YWwgbGliLCBidXQgSSBkbwo+IG5vdAo+ID4+IHNlZSBhIGNvcnJlc3BvbmRpbmcgRExMLiAgQWxz
bywgd2h5IHdvdWxkIHRoZSB2ZXJzaW9ucyBkaWZmZXI/Cj4gPiBIbW0gLSBNYXQgb3IgRm9zdGVy
IG1pZ2h0IGJlIGFibGUgdG8gYW5zd2VyIHRoYXQgb25lLgo+ID4gU2Vhbgo+Cj4gVGhlcmUgYXJl
IHNldmVyYWwgaXNzdWVzIGF0IHBsYXkgaGVyZToKPiAgICAgLSBXaGVuIGNvbXBpbGVkIHdpdGgg
TVNWQyB0aGUgQm9vc3QgbGlicmFyaWVzIHdpbGwgYXV0b21hdGljYWxseQo+IGF0dGVtcHQKPiB0
byBsaW5rIGluIHRoZSBidWlsdCBib29zdCBsaWJyYXJ5IHRoZXkgZGVlbSBtb3N0IGFwcHJvcHJp
YXRlIGJhc2VkIG9uIHRoZQo+IGJ1aWxkIHNldHRpbmdzIG9mIHlvdXIgYXBwbGljYXRpb24uIFRo
aXMgJ2ZlYXR1cmUnIGlzIHRoZSBjYXVzZSBvZiBtYW55Cj4gaGVhZGFjaGVzIGFzIG1hbnkgcGVv
cGxlIGRvIG5vdCBmaWd1cmUgQysrIGNvZGUgd291bGQgYWZmZWN0IHRoZQo+IGRlcGVuZGVuY3kK
PiBsaXN0aW5ncyBzZW50IHRvIHRoZSBsaW5rZXIsIGJ1dCB0aGVyZSB5b3UgaGF2ZSBpdC4gSW4g
b3JkZXIgdG8gdHVybiB0aGlzCj4gb2ZmLCAjZGVmaW5lIEJPT1NUX0FMTF9OT19MSUI9MSBpbiB5
b3VyIGJ1aWxkIHNldHRpbmdzICh3aGljaCB3ZSBkbyB3aGVuCj4gYnVpbGRpbmcgQVNMKS4KPiAg
ICAgLSBUaGUgYWxwaGFiZXQgc291cCBhdCB0aGUgZW5kIG9mIHRoZSBhIGJvb3N0IGxpYnJhcnkg
YXJ0aWZhY3QgaXMKPiBpbnRlbmRlZCB0byBkZXNjcmliZSB0aGUgc2V0dGluZ3MgdW5kZXIgd2hp
Y2ggc2FpZCBsaWJyYXJ5IHdhcyBidWlsdC4gV2hlbgo+IGJ1aWxkaW5nIHVzaW5nIGJqYW0gdGhl
IHRhZ3MgYXJlIGRlcml2ZWQgZnJvbSBhIHByb2NlZHVyZSBjYWxsZWQgJ3JlbmFtZScKPiBpbgo+
IHN0YWdlLmphbSwgd2hpY2ggaXMgZm91bmQgaW4gYm9vc3QvdG9vbHMvYnVpbGQvdjIvdG9vbHMv
c3RhZ2UuamFtLiBXaGVuCj4gdGhlCj4gbGlua2VyIGlzIGdpdmVuIGl0cyBhdXRvLWxpbmsgaW5z
dHJ1Y3Rpb24gZnJvbSB0aGUgYm9vc3QgQysrIHNvdXJjZXMsIHRoZQo+IGxpYnJhcnkgbmFtZSBp
cyBkZXJpdmVkIHdpdGhpbiBib29zdC9jb25maWcvYXV0b19saW5rLmhwcC4gSW4gdGhlIGZvcm1l
cgo+IGNhc2UgYmphbSBhdHRyaWJ1dGVzIChlLmcuLCA8bGluaz5zdGF0aWMpIGFyZSB1c2VkIHRv
IGRlcml2ZSB0aGUgbmFtZSwKPiB3aGVyZWFzIGluIHRoZSBsYXR0ZXIgY2FzZSB0aGUgYnVpbGQg
ZW52aXJvbm1lbnQgaXMgdXNlZC4gSW4gYWxsCj4gbGlrZWxpaG9vZAo+IHdoYXQgaXMgYXJpc2lu
ZyBpcyB0aGF0IHRoZSBidWlsdCBsaWJyYXJpZXMgYXJlIG5hbWVkIGFjY29yZGluZyB0byB0aGUK
PiBiamFtCj4gcnVsZXMsIGJ1dCBiZWNhdXNlIHdlIHNldCBzbyBtYW55IGZsYWdzIGFuZCBwcmVw
cm9jZXNzb3IgZGVmaW5lcyBtYW51YWxseQo+IChub3QgdmlhIGJqYW0gYXR0cmlidXRlcykgdGhl
IGF1dG9fbGluayBjb2RlIGlzIGRlcml2aW5nIGEgc2VwYXJhdGUgc2V0IG9mCj4gZGVjb3JhdGlv
bnMgZm9yIHRoZSBuYW1lIG9mIHRoZSBsaWJyYXJ5Lgo+Cj4gQWxsIHRoYXQgdG8gc2F5IHRoYXQg
dGhpcyBjb3VsZCBiZSBvdXIgYnVnLCBpbiB0aGF0IHdlIHNob3VsZCBiZSB1c2luZyB0aGUKPiBw
cm9wZXIgYmphbWVzZSB0byBnZXQgdGhlIGJ1aWxkIHNldHRpbmdzIHJpZ2h0LCBpbiB3aGljaCBj
YXNlIHRoZSBiamFtCj4gbGlicmFyeSBhcnRpZmFjdHMgd291bGQgbWF0Y2ggdGhlIG5hbWVzIGFz
IHRoZXkgYXJlIGRlcml2ZWQgYnkKPiBhdXRvX2xpbmsuaHBwLiBIb3dldmVyLCBJIGFtIGFsc28g
dW5kZXIgdGhlIHVuZGVyc3RhbmRpbmcgdGhhdCBiamFtIGRvZXMKPiAncmV2ZXJzZSBsb29rdXAn
IG9uIHRoZSBidWlsZCBlbnZpcm9ubWVudCwgYW5kIGlzIGNhcGFibGUgb2YgZGVyaXZpbmcgYWxs
Cj4gdGhlIG5lY2Vzc2FyeSBiamFtIGF0dHJpYnV0ZXMgYmFzZWQgb24gaXQuIEkgY291bGQgYmUg
d3JvbmcgdGhlcmUsIG9yIEkKPiBjb3VsZCBiZSByaWdodCBidXQgdGhlIGZ1bmN0aW9uYWxpdHkg
aXMgbm90IGF0dGFjaGVkIHRvIHRoZSBsaWJyYXJ5Cj4gdGFnZ2luZwo+IG1lY2hhbmlzbS4KPgo+
IFNvLCBpbiBzaG9ydCwgdGhlIGJ1ZyBjb3VsZCBiZSB2ZXJ5IGRpZmZpY3VsdCB0byByZXNvbHZl
IGlmIHlvdSB3b3VsZCBsaWtlCj4gdG8gY29udGludWUgdXNpbmcgYXV0b21hdGljIGxpbmtpbmcg
KHdoaWNoIHdlIGRvIG5vdCByZWNvbW1lbmQpLiBJZiB5b3UgZG8KPiBoYXBwZW4gdG8gY29tZSBh
Y3Jvc3MgdGhlIHJpZ2h0IGZpeCAoYW5kIGl0IGJlbG9uZ3MgaW4gQVNMKSwgd2UnbGwgZ2xhZGx5
Cj4gcGF0Y2ggb3VyIGRpc3RybyBhbmQgZ2l2ZSB5b3UgYWxsIHRoZSBjcmVkaXQuCj4KPiBPdXIg
cmVjb21tZW5kYXRpb24gd291bGQgYmUgdG8gI2RlZmluZSBCT09TVF9BTExfTk9fTElCPTEgYW5k
IHNwZWNpZnkgdGhlCj4gbGlicmFyaWVzIHRvIHdoaWNoIHlvdSB3b3VsZCBsaWtlIHRvIGxpbmsg
ZXhwbGljaXRseS4gSXQgd291bGQgc2VlbSBiamFtCj4gamliZXMgd2l0aCBzdWNoIGEgcHJvY2Vz
cywgYXMgd2UgaGF2ZSBiZWVuIGJ1aWxkaW5nIEFTTCB0aGlzIHdheSBmb3IgbWFueQo+IHJlbGVh
c2VzLgo+Cj4gQmxlc3NpbmdzLAo+IEZvc3Rlcgo+Cj4KPiAtLQo+IEZvc3RlciBULiBCcmVyZXRv
biAgICAgICAgICAgICAgICAgIDzhvLDPh864z43Pgj48ICAgICAgICAgICAgICAgIFJvbWFucyAz
OjIxLTI2Cj4gQSBkIG8gYiBlICAgUyBvIGYgdCB3IGEgciBlICAgVCBlIGMgaCBuIG8gbCBvIGcg
eSAgIEwgYSBiCj4gIldoYXQgOTkgcGVyY2VudCBvZiBwcm9ncmFtbWVycyBuZWVkIHRvIGtub3cg
aXMgbm90IGhvdyB0byBidWlsZAo+IGNvbXBvbmVudHMKPiBidXQgaG93IHRvIHVzZSB0aGVtLiIg
LS0gQWxleGFuZGVyIFN0ZXBhbm92Cj4gIk5vdyB3ZSBoYXZlIHZlcnkgc2ltcGxlIGNvZGUgYW5k
IHRoZSBtZWFuaW5nIGlzIHBlcmZlY3RseSBjbGVhci4gRHJpbmsKPiB0aGUKPiBLb29sLUFpZCIg
LS0gU2VhbiBQYXJlbnQKPgo+Cg==

Re: [Adobe-source-devel] Questions on using Boost

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

Hi Jacob,

On 11/10/06 4:09 p, "Sean Parent" <sp...@ad...> wrote:

>> Second, assuming there are no objections to using the adobe/third_party
>> flavor=20
>> of Boost, I have a linking question.  On my system (XP, VC80), for examp=
le,
>> ASL builds the debug filesystem lib named as follows:
>> boost_filesystem-vc80-mt-d-1_33.lib
>> However, including boost/filesystem in my own application triggers an
>> auto_link w/ the following:
>> libboost_filesystem-vc80-mt-sgd-1_33_1.lib
>>=20
>> I do not understand where the discrepancies in naming come from.  Appare=
ntly,
>> the Adobe built lib is intended to be used as a dynamical lib, but I do =
not
>> see a corresponding DLL.  Also, why would the versions differ?
> Hmm - Mat or Foster might be able to answer that one.
> Sean

There are several issues at play here:
    - When compiled with MSVC the Boost libraries will automatically attemp=
t
to link in the built boost library they deem most appropriate based on the
build settings of your application. This 'feature' is the cause of many
headaches as many people do not figure C++ code would affect the dependency
listings sent to the linker, but there you have it. In order to turn this
off, #define BOOST_ALL_NO_LIB=3D1 in your build settings (which we do when
building ASL).
    - The alphabet soup at the end of the a boost library artifact is
intended to describe the settings under which said library was built. When
building using bjam the tags are derived from a procedure called 'rename' i=
n
stage.jam, which is found in boost/tools/build/v2/tools/stage.jam. When the
linker is given its auto-link instruction from the boost C++ sources, the
library name is derived within boost/config/auto_link.hpp. In the former
case bjam attributes (e.g., <link>static) are used to derive the name,
whereas in the latter case the build environment is used. In all likelihood
what is arising is that the built libraries are named according to the bjam
rules, but because we set so many flags and preprocessor defines manually
(not via bjam attributes) the auto_link code is deriving a separate set of
decorations for the name of the library.

All that to say that this could be our bug, in that we should be using the
proper bjamese to get the build settings right, in which case the bjam
library artifacts would match the names as they are derived by
auto_link.hpp. However, I am also under the understanding that bjam does
'reverse lookup' on the build environment, and is capable of deriving all
the necessary bjam attributes based on it. I could be wrong there, or I
could be right but the functionality is not attached to the library tagging
mechanism.

So, in short, the bug could be very difficult to resolve if you would like
to continue using automatic linking (which we do not recommend). If you do
happen to come across the right fix (and it belongs in ASL), we'll gladly
patch our distro and give you all the credit.

Our recommendation would be to #define BOOST_ALL_NO_LIB=3D1 and specify the
libraries to which you would like to link explicitly. It would seem bjam
jibes with such a process, as we have been building ASL this way for many
releases.

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] Questions on using Boost

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

On Nov 10, 2006, at 3:21 PM, Jacob Foshee wrote:

> I was hoping someone could lend me a hand w/ some questions on Boost.
>
> First, should I use the patched or unpatched version of Boost with  
> my application?  I would just as soon have a single flavor of Boost  
> on my system rather than 2.  So it's no problem to use the adobe/ 
> third_party one.  But, I am also curious if it would cause problems  
> for someone to use the unpatched Boost distribution at the same  
> time as using ASL.

Shouldn't be much of a problem - info on the patches are here:  
<http://opensource.adobe.com/wiki/index.php/About_Boost_Patches>


>
> Second, assuming there are no objections to using the adobe/ 
> third_party flavor of Boost, I have a linking question.  On my  
> system (XP, VC80), for example, ASL builds the debug filesystem lib  
> named as follows:
> boost_filesystem-vc80-mt-d-1_33.lib
> However, including boost/filesystem in my own application triggers  
> an auto_link w/ the following:
> libboost_filesystem-vc80-mt-sgd-1_33_1.lib

Hmm - Mat or Foster might be able to answer that one.
Sean

[Adobe-source-devel] Questions on using Boost

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

I was hoping someone could lend me a hand w/ some questions on Boost.

First, should I use the patched or unpatched version of Boost with my
application?  I would just as soon have a single flavor of Boost on my
system rather than 2.  So it's no problem to use the adobe/third_party one.
But, I am also curious if it would cause problems for someone to use the
unpatched Boost distribution at the same time as using ASL.

Second, assuming there are no objections to using the adobe/third_party
flavor of Boost, I have a linking question.  On my system (XP, VC80), for
example, ASL builds the debug filesystem lib named as follows:
boost_filesystem-vc80-mt-d-1_33.lib
However, including boost/filesystem in my own application triggers an
auto_link w/ the following:
libboost_filesystem-vc80-mt-sgd-1_33_1.lib

I do not understand where the discrepancies in naming come from.
Apparently, the Adobe built lib is intended to be used as a dynamical lib,
but I do not see a corresponding DLL.  Also, why would the versions differ?

Thanks!
Jacob

ps
Nice work on the latest ASL release!  AFAICT, It downloaded and built w/out
a hitch!

[Adobe-source-devel] opensource.adobe.com operational again

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

After some moderate issues opensource.adobe.com and all its services are
back online. Please let me know if you observe any more issues that need to
be resolved.

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

[Adobe-source-devel] FW: Wiki Move Scheduled for This Afternoon

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

FYI everyone -- the wiki will be down for a couple hours this afternoon.

Blessings,
Foster

------ Forwarded Message
From: Jeff Baker
Date: Mon, 6 Nov 2006 10:38:01 -0800
To: Foster Brereton, Sean Parent
Subject: Wiki Move Scheduled for This Afternoon

Hi Sean and Foster,
 
I have been informed by our data center team that the wiki server move will
take place at approximately 1pm PST today. I expect downtime of 1-2 hours
barring any complications.
 
Thanks,
Jeff
------ End of Forwarded Message

[Adobe-source-devel] ASL 1.0.21 Released

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

Highlights of this release include:

    * Replaced value_t with a superior any_regular_t implementation
    * Significant improvements have been made to numerous widget
implementations on both platforms, as well as improved modal dialog behavior
    * Significant GIL updates; please see the Release Notes
    * Added a Cocoa <-> Carbon bridge to allow for Cocoa routines within the
widget library
    * Internationalization support for edit_number widget -- automatic
formatting based on your machine locale
    * For more information and more changes see the Release Notes

Release Notes:
    http://opensource.adobe.com/asl_release_notes.html

Build Instructions / Getting Started:
    http://opensource.adobe.com/asl_readme.html

Downloads:
    
http://sourceforge.net/project/showfiles.php?group_id=132417&package_id=1454
20

Blessings,
Foster

Re: [Adobe-source-devel] View concept singleton state

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

I am also in favour of the first method, for the same reason, so long
as there is a way to register user defined types into the sheet (i.e.:
provide the string->type mapping).

Ralph

On 10/18/06, Sean Parent <sp...@ad...> wrote:
>
> On Oct 18, 2006, at 1:11 PM, Ralph Thomas wrote:
>
> > On 10/17/06, Mat Marcus <mm...@em...> wrote:
> >>  Sean said he would consider adding type constraints to the model.
> >
> > How would this work? What would happen if there was a type violation
> > -- would model throw an exception on set?
>
> There are several ways that I've been considering (but little time to
> explore) -
>
> One option is to add attributes to cells and add an analyze pass to
> the parser which would check for matching attributes and insert
> runtime checks where attributes can't be determined.
>
> Syntax for this would likely be along the lines of C/C++ except allow
> for multiple types.
>
> [number, string]  cell_name <== p ? "Hello" : 20; // OK
> [number] cell_name : "Hello"; // Parse Error
>
> Here the error would be reported as an exception. Ideally I could get
> the parser to construct the cell using a "type list" - this would
> look something like:
>
> add_interface_cell(@number, @std::string)(cell_name, initial_value);
>
> And the cell would be registered with these types. A bind that didn't
> match these types would fail with a cell not found. - There simply
> would not be a way to attach to a cell with a type mismatch (so a
> runtime error but on first connect). Using a type list interface on
> the bind side this could be statically enforced on the C++ code (so
> the client can't lie and claim to set a number but set a string):
>
> set<double>(cell_name, 10.5); // looks for cell matching [number]
> cell_name
>
> -----
>
> Another option is to do the type constraints as pure runtime checks:
>
> cell_name where((typeof(cell_name) == @number) && (cell_name < 10))
> <== 5; // OK
>
> This would be roughly equivalent to:
>
>         cell_name <== 5;
> invariant:
>         valid_cell <== (typeof(cell_name) == @number) && (cell_name < 10);
>
> This is more flexible but defers catching of errors to runtime -
> behavior of the check (throwing an exception vs. acting as an
> invariant) needs some thought and I have to play with use cases. I'm
> currently in favor of pursuing the first option as getting errors
> back as early as possible is a strong goal.
>
> Sean
>
>
> >
> > Ralph
> >
> > --
> > "i have a dream and it's called a crossbar switch/what this will mean
> > is no big data glitch"
> >
> > ----------------------------------------------------------------------
> > ---
> > 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] View concept singleton state

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

On behalf of Sean...:


On Oct 18, 2006, at 1:11 PM, Ralph Thomas wrote:

> On 10/17/06, Mat Marcus <mm...@em...> wrote:
>>  Sean said he would consider adding type constraints to the model.
>
> How would this work? What would happen if there was a type violation
> -- would model throw an exception on set?

There are several ways that I've been considering (but little time to
explore) -

One option is to add attributes to cells and add an analyze pass to
the parser which would check for matching attributes and insert
runtime checks where attributes can't be determined.

Syntax for this would likely be along the lines of C/C++ except allow
for multiple types.

[number, string]  cell_name <== p ? "Hello" : 20; // OK
[number] cell_name : "Hello"; // Parse Error

Here the error would be reported as an exception. Ideally I could get
the parser to construct the cell using a "type list" - this would
look something like:

add_interface_cell(@number, @std::string)(cell_name, initial_value);

And the cell would be registered with these types. A bind that didn't
match these types would fail with a cell not found. - There simply
would not be a way to attach to a cell with a type mismatch (so a
runtime error but on first connect). Using a type list interface on
the bind side this could be statically enforced on the C++ code (so
the client can't lie and claim to set a number but set a string):

set<double>(cell_name, 10.5); // looks for cell matching [number]
cell_name

-----

Another option is to do the type constraints as pure runtime checks:

cell_name where((typeof(cell_name) == @number) && (cell_name < 10))
<== 5; // OK

This would be roughly equivalent to:

    cell_name <== 5;
invariant:
    valid_cell <== (typeof(cell_name) == @number) && (cell_name < 10);

This is more flexible but defers catching of errors to runtime -
behavior of the check (throwing an exception vs. acting as an
invariant) needs some thought and I have to play with use cases. I'm
currently in favor of pursuing the first option as getting errors
back as early as possible is a strong goal.

Sean


>
> Ralph
>
> -- 
> "i have a dream and it's called a crossbar switch/what this will mean
> is no big data glitch"
>
> ----------------------------------------------------------------------
> ---
> 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] View concept singleton state

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

On Oct 18, 2006, at 1:11 PM, Ralph Thomas wrote:

> On 10/17/06, Mat Marcus <mm...@em...> wrote:
>>  Sean said he would consider adding type constraints to the model.
>
> How would this work? What would happen if there was a type violation
> -- would model throw an exception on set?

There are several ways that I've been considering (but little time to  
explore) -

One option is to add attributes to cells and add an analyze pass to  
the parser which would check for matching attributes and insert  
runtime checks where attributes can't be determined.

Syntax for this would likely be along the lines of C/C++ except allow  
for multiple types.

[number, string]  cell_name <== p ? "Hello" : 20; // OK
[number] cell_name : "Hello"; // Parse Error

Here the error would be reported as an exception. Ideally I could get  
the parser to construct the cell using a "type list" - this would  
look something like:

add_interface_cell(@number, @std::string)(cell_name, initial_value);

And the cell would be registered with these types. A bind that didn't  
match these types would fail with a cell not found. - There simply  
would not be a way to attach to a cell with a type mismatch (so a  
runtime error but on first connect). Using a type list interface on  
the bind side this could be statically enforced on the C++ code (so  
the client can't lie and claim to set a number but set a string):

set<double>(cell_name, 10.5); // looks for cell matching [number]  
cell_name

-----

Another option is to do the type constraints as pure runtime checks:

cell_name where((typeof(cell_name) == @number) && (cell_name < 10))  
<== 5; // OK

This would be roughly equivalent to:

	cell_name <== 5;
invariant:
	valid_cell <== (typeof(cell_name) == @number) && (cell_name < 10);

This is more flexible but defers catching of errors to runtime -  
behavior of the check (throwing an exception vs. acting as an  
invariant) needs some thought and I have to play with use cases. I'm  
currently in favor of pursuing the first option as getting errors  
back as early as possible is a strong goal.

Sean


>
> Ralph
>
> -- 
> "i have a dream and it's called a crossbar switch/what this will mean
> is no big data glitch"
>
> ---------------------------------------------------------------------- 
> ---
> 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] View concept singleton state

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

On 10/17/06, Mat Marcus <mm...@em...> wrote:
>  Sean said he would consider adding type constraints to the model.

How would this work? What would happen if there was a type violation
-- would model throw an exception on set?

Ralph

-- 
"i have a dream and it's called a crossbar switch/what this will mean
is no big data glitch"

Re: [Adobe-source-devel] View concept singleton state

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

Hi Mat,

On Oct 17, 2006, at 10:39p, Mat Marcus wrote:

> Hi Foster,
>
> I think you already know my views on this, but I'll repeat them =20
> given that you initiated the wider discussion. First off, when I =20
> suggested that we might make use of the notion of a special state, =20
> the term that I used was "singular", not "singleton". As others =20
> pointed out, the two terms are not interchangeable.

This was my mistake -- I stand corrected.

> At first I was considering adding a hook to any_view providers a =20
> chance to install a "wrong type" handler. But I soon began to sort =20
> my ideas out, and I set this aside when Sean said he would consider =20=

> adding type constraints to the model. I never intended for protocol =20=

> relating to singular to live in any_view. I sketched my reasons =20
> after I noticed that you had added such code to any_view, (before =20
> asking you to remove it). I explained my resistance in a bit more =20
> detail, offering a rationale similar to the one Sean gave above, =20
> after noticing that you added it back to any_view again (before =20
> asking you to remove it a second time). Can you say more about why =20
> you keep aiming to get singular protocol into any_view, especially =20
> in a world where, say, types could be checked in the model and the =20
> concrete view can choose as specific or as general a =20
> view_model_type as they wish?

Originally I didn't think the issue was settled, that there was a =20
viable example for when the model would have information in a cell =20
that an attached view would not be able to handle. After having this =20
discussion, though, I'm convinced there is no place for the singular =20
notion in the view concept.

Blessings,
Foster


--
Foster T. Brereton              <=E1=BC=B0=CF=87=CE=B8=CF=8D=CF=82><     =
         Romans =20
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

Re: [Adobe-source-devel] View concept singleton state

[Mat M. <mm...@em...>]

Hi Foster,

I think you already know my views on this, but I'll repeat them given =
that you initiated the wider discussion. First off, when I suggested =
that we might make use of the notion of a special state, the term that I =
used was "singular", not "singleton". As others pointed out, the two =
terms are not interchangeable.=20

At first I was considering adding a hook to any_view providers a chance =
to install a "wrong type" handler. But I soon began to sort my ideas =
out, and I set this aside when Sean said he would consider adding type =
constraints to the model. I never intended for protocol relating to =
singular to live in any_view. I sketched my reasons after I noticed that =
you had added such code to any_view, (before asking you to remove it). I =
explained my resistance in a bit more detail, offering a rationale =
similar to the one Sean gave above, after noticing that you added it =
back to any_view again (before asking you to remove it a second time). =
Can you say more about why you keep aiming to get singular protocol into =
any_view, especially in a world where, say, types could be checked in =
the model and the concrete view can choose as specific or as general a =
view_model_type as they wish?

- Mat

P.S. Does anyone know how we could get a review daemon installed on =
opensource.adobe.com? Subscriptions in user specs don't seem to work for =
me at the moment.

###

Foster wrote, in two messages:=20

> I think this makes a ton of sense. In all the cases I had=20
> considered, there was no way the widget would be able to=20
> display something reasonable with the invalid data. Your=20
> example of a graph-like widget made a lot of sense, as well=20
> as the notion of extracting as much worthwhile information as=20
> possible and putting it up for display. So, in light of that,=20
> I'd propose add a view concept API to something like:
>=20
> 	void singleton(const model_type& value);
>=20
> We might also want to have a nullary singleton function for=20
> the case when the widget is asked to display something it=20
> can't decipher. For example, an edit text field being asked=20
> to display an icon:
>=20
> 	void singleton();
>=20
> Thoughts?
>=20

> -----Original Message-----
> From: ado...@li...=20
> [mailto:ado...@li...] On=20
> Behalf Of Foster T. Brereton
> Sent: Tuesday, October 17, 2006 4:32 PM
> To: adobe-source developers; ASL Users
> Subject: [Adobe-source-devel] View concept singleton state
>=20
> Hey all,
>=20
> I wanted to email the group regarding something I'm=20
> implementing for the preset widget, because I think it can be=20
> lifted into the View Concept as a whole.
>=20
> A while back Mat and I were talking about the following=20
> problem: what is the proper behavior of a view when it is=20
> asked to display a value it cannot display? As an example,=20
> let us say I have an 'analog clock' =20
> display and it is asked to show the time 25:75. What should=20
> the clock do? To solve this, (thus far) we came up with the=20
> idea that every view should have a singleton state. The=20
> singleton state for a view is entirely=20
> implementation-specific; for instance in the clock example,=20
> the view could set itself to noon and make the clock have a=20
> red background -- something obvious to the user that says "I=20
> no longer accurately reflect the value in the model I have=20
> been asked to display". The instant the model communicates to=20
> the view a new value that it can display, the view should=20
> display the new value normally.
>=20
> The notion of a 'singleton value' does not exist, so the=20
> ability for the user to put a widget into the singleton state=20
> is prohibited. What would trigger the singleton value for a=20
> view usually takes the form of controller 'A' setting the=20
> value of a cell that view 'B' (also bound to the cell) cannot=20
> display. The value would be valid for A as a controller but=20
> not B as a view, so B reverts to the singleton state.
>=20
> Therefore, in the case when the view is also a controller=20
> (aka a widget), there is an additional requirement to be=20
> placed on the widget while in the singleton state. In=20
> addition to the above view requirement, the widget must also=20
> allow for valid user manipulation of the controller while=20
> displaying the singleton state. In the clock example above,=20
> (should the clock view be part of a clock widget), the=20
> singleton state should allow for the user to set another=20
> (valid) time (for example, by dragging the hands of the clock=20
> with the mouse).
>=20
> As a more concrete example, I am reworking the ASL preset=20
> widget so it models the View concept -- it is bound to a=20
> 'result' cell of the property model. When the result cell is=20
> updated, the preset widget compares its list of available=20
> presets against the result cell -- when a preset is found=20
> whose contents are a subset of the result cell, that preset=20
> is selected. The singleton state, then, occurs when the=20
> result cell is in a state for which no preset exists. The=20
> display behavior I am implementing is to append a menu item=20
> named "Custom" to the preset category list. This will still=20
> let the user select a new preset category from the preset=20
> category list, but at the same time clearly tells the user=20
> "the dialog as it stands matches no presets."
>=20
> Thoughts?
>=20
> Blessings,
> Foster
>=20
>=20
> --
> Foster T. Brereton              <=E1=BC=B0=CF=87=CE=B8=CF=8D=CF=82><   =
           Romans =20
> 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=20
> build components but how to use them." -- Alexander Stepanov=20
> "Now we have very simple code and the meaning is perfectly clear. =20
> Drink the Kool-Aid" -- Sean Parent
>=20
>=20
> --------------------------------------------------------------
> -----------
> Using Tomcat but need to do more? Need to support web=20
> services, security?
> Get stuff done quickly with pre-integrated technology to make=20
> your job easier Download IBM WebSphere Application Server=20
> v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&
> dat=3D121642
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel
>=20

Re: [Adobe-source-devel] asl-users: View concept singleton state

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

> Ah, I think we've found a problem in our thinking.

Yes - your are correct - there can't be a singleton value.

> The second API call should be invoked by the model, however, and is  
> indeed the only place where the call can take place.

I disagree with this - if a view wishes to behave in such a way it  
can receive any value and filter internally. If a view can only  
receive data of a given type then an exception would be thrown if it  
were attempted to be notified with a different type. Eventually we'll  
have type constraints on the model to avoid such behavior (or rather  
to check it statically) - but either way it should not impact the  
view interface. Having the model responsible for checking to see if  
data is displayable is backwards - the model is not aware of the  
display.

Sean

Re: [Adobe-source-devel] asl-users: View concept singleton state

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

Eric,

On Oct 17, 2006, at 5:44p, Eric Berdahl wrote:

>
> On Oct 17, 2006, at 5:38 PM, Foster T. Brereton wrote:
>
>> Hi Eric,
>>
>> On Oct 17, 2006, at 5:00p, Eric Berdahl wrote:
>>
>>> [snip]
>>>
>>> Other scenarios are similarly easy to describe where the view may =20=

>>> wish/need to display "as much useful information as can be =20
>>> inferred from the input" while also providing feedback that "the =20
>>> input cannot be accurately represented in this view".
>>
>> I think this makes a ton of sense. In all the cases I had =20
>> considered, there was no way the widget would be able to display =20
>> something reasonable with the invalid data. Your example of a =20
>> graph-like widget made a lot of sense, as well as the notion of =20
>> extracting as much worthwhile information as possible and putting =20
>> it up for display. So, in light of that, I'd propose add a view =20
>> concept API to something like:
>>
>> 	void singleton(const model_type& value);
>>
>> We might also want to have a nullary singleton function for the =20
>> case when the widget is asked to display something it can't =20
>> decipher. For example, an edit text field being asked to display =20
>> an icon:
>>
>> 	void singleton();
>>
>> Thoughts?
>
> My only thought now is that the name "singleton" may be misleading =20
> because, as I understand your proposed usage (apply sanity checks =20
> as appropriate), there may be multiple objects in existence at any =20
> point in time, each one providing the "display model" for a given =20
> view. Thus, there is no "singleton" (as described by the classic =20
> use of the design pattern) in the system.

Ah, I think we've found a problem in our thinking. The problem is =20
that the model is not aware what a view's display capabilities are. =20
It simply pipes information to the view. The only case when the first =20=

'singleton' call is ever invoked, then, is when you're inside the =20
view itself (because only the view knows if it itself can display a =20
value it receives), and so should not be a requirement on the view =20
concept. The former 'singleton' call, instead, should just be the =20
view's display().

The second API call should be invoked by the model, however, and is =20
indeed the only place where the call can take place. The model has =20
square data that it's trying to hammer into a round hole, and cannot, =20=

so should notify the view accordingly. Since there is no legitimate =20
conversion from the data type present in the model to the type =20
expected through the view's display() call, the only option is the =20
nullary 'singleton' function. Thus, I think the name of the API in =20
the latter case is still appropriate.

> The term "display model" here being one I'm inventing to =20
> differentiate the model used to actually render the view from that =20
> which is manipulated by the user and may more accurately called the =20=

> "data model". Following this terminology, a "data model" is =20
> transformed into a "display model" when the view needs to create =20
> its presentation. When the data model is "sensible", the display =20
> model may, in fact, be a copy-on-write or other direct reference to =20=

> the data model itself. However, the display model is essentially =20
> read-only. Any interaction with the widget causes changes to the =20
> data model only.

Yes; in the View and Controller concepts we claim that neither a View =20=

nor a Controller necessarily hold any state at all, and so is not a =20
requirement on the concepts. (An example of a stateless view might be =20=

the screen of your television; an example of a stateless controller =20
would be a microphone.) However, in the world of UI widget =20
implementations this is not the case -- they hold state (often lots =20
of it) so they can successfully model the view and controller =20
concepts. Nevertheless, the widget types that model these concepts =20
should 'behave' as if they hold no state at all. (I would imagine =20
this is akin to using an adobe::dictionary_t as a regular type even =20
though under the hood it is ref-counted; it 'behaves' like a regular =20
type so we really don't care what the implementation actually is.) =20
Your "data model" we call the "property model", and is the Adam sheet =20=

in our implementations. All that to say there is a lot of parallel =20
between your last comment and the property model/widget system we =20
have in place within ASL.

Blessings,
Foster


--
Foster T. Brereton              <=E1=BC=B0=CF=87=CE=B8=CF=8D=CF=82><     =
         Romans =20
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

Re: [Adobe-source-devel] asl-users: View concept singleton state

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

Hi Eric,

On Oct 17, 2006, at 5:00p, Eric Berdahl wrote:

> [snip]
>
> Other scenarios are similarly easy to describe where the view may =20
> wish/need to display "as much useful information as can be inferred =20=

> from the input" while also providing feedback that "the input =20
> cannot be accurately represented in this view".

I think this makes a ton of sense. In all the cases I had considered, =20=

there was no way the widget would be able to display something =20
reasonable with the invalid data. Your example of a graph-like widget =20=

made a lot of sense, as well as the notion of extracting as much =20
worthwhile information as possible and putting it up for display. So, =20=

in light of that, I'd propose add a view concept API to something like:

	void singleton(const model_type& value);

We might also want to have a nullary singleton function for the case =20
when the widget is asked to display something it can't decipher. For =20
example, an edit text field being asked to display an icon:

	void singleton();

Thoughts?

Blessings,
Foster

--
Foster T. Brereton              <=E1=BC=B0=CF=87=CE=B8=CF=8D=CF=82><     =
         Romans =20
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

Re: [Adobe-source-devel] asl-users: View concept singleton state

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

I think for the widget set this is a valid solution - and there are =20
similar cases:

* For a checkbox if the bound value doesn't match either the true or =20
false value you get the dash displayed.
* For a radio button if the bound value doesn't match the radio value =20=

then the radio button is off.

All three of these should be handled consistently - but I don't know =20
that we need, say, a state for an edit_text field if the bound item =20
doesn't contain text.

I have considered the similar case where a value is being display =20
which is poisoned (a value which is derived from a cell which =20
contributes to a false invariant).

For this case I've wanted to display a small caution icon to the left =20=

of the control - along with a message box (a caution icon and text =20
associated with the invariant) at the bottom - and dimming the okay =20
button. There is also a possibility to provide a button to restore to =20=

a good state. There are few dialogs, however, that require such =20
handling so this has been low on the priority list.

Sean

On Oct 17, 2006, at 4:31 PM, Foster T. Brereton wrote:

> Hey all,
>
> I wanted to email the group regarding something I'm implementing =20
> for the preset widget, because I think it can be lifted into the =20
> View Concept as a whole.
>
> A while back Mat and I were talking about the following problem: =20
> what is the proper behavior of a view when it is asked to display a =20=

> value it cannot display? As an example, let us say I have an =20
> 'analog clock' display and it is asked to show the time 25:75. What =20=

> should the clock do? To solve this, (thus far) we came up with the =20
> idea that every view should have a singleton state. The singleton =20
> state for a view is entirely implementation-specific; for instance =20
> in the clock example, the view could set itself to noon and make =20
> the clock have a red background -- something obvious to the user =20
> that says "I no longer accurately reflect the value in the model I =20
> have been asked to display". The instant the model communicates to =20
> the view a new value that it can display, the view should display =20
> the new value normally.
>
> The notion of a 'singleton value' does not exist, so the ability =20
> for the user to put a widget into the singleton state is =20
> prohibited. What would trigger the singleton value for a view =20
> usually takes the form of controller 'A' setting the value of a =20
> cell that view 'B' (also bound to the cell) cannot display. The =20
> value would be valid for A as a controller but not B as a view, so =20
> B reverts to the singleton state.
>
> Therefore, in the case when the view is also a controller (aka a =20
> widget), there is an additional requirement to be placed on the =20
> widget while in the singleton state. In addition to the above view =20
> requirement, the widget must also allow for valid user manipulation =20=

> of the controller while displaying the singleton state. In the =20
> clock example above, (should the clock view be part of a clock =20
> widget), the singleton state should allow for the user to set =20
> another (valid) time (for example, by dragging the hands of the =20
> clock with the mouse).
>
> As a more concrete example, I am reworking the ASL preset widget so =20=

> it models the View concept -- it is bound to a 'result' cell of the =20=

> property model. When the result cell is updated, the preset widget =20
> compares its list of available presets against the result cell -- =20
> when a preset is found whose contents are a subset of the result =20
> cell, that preset is selected. The singleton state, then, occurs =20
> when the result cell is in a state for which no preset exists. The =20
> display behavior I am implementing is to append a menu item named =20
> "Custom" to the preset category list. This will still let the user =20
> select a new preset category from the preset category list, but at =20
> the same time clearly tells the user "the dialog as it stands =20
> matches no presets."
>
> Thoughts?
>
> Blessings,
> Foster
>
>
> --
> Foster T. Brereton              <=E1=BC=B0=CF=87=CE=B8=CF=8D=CF=82><   =
           Romans =20
> 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
>

[Adobe-source-devel] View concept singleton state

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

Hey all,

I wanted to email the group regarding something I'm implementing for =20
the preset widget, because I think it can be lifted into the View =20
Concept as a whole.

A while back Mat and I were talking about the following problem: what =20=

is the proper behavior of a view when it is asked to display a value =20
it cannot display? As an example, let us say I have an 'analog clock' =20=

display and it is asked to show the time 25:75. What should the clock =20=

do? To solve this, (thus far) we came up with the idea that every =20
view should have a singleton state. The singleton state for a view is =20=

entirely implementation-specific; for instance in the clock example, =20
the view could set itself to noon and make the clock have a red =20
background -- something obvious to the user that says "I no longer =20
accurately reflect the value in the model I have been asked to =20
display". The instant the model communicates to the view a new value =20
that it can display, the view should display the new value normally.

The notion of a 'singleton value' does not exist, so the ability for =20
the user to put a widget into the singleton state is prohibited. What =20=

would trigger the singleton value for a view usually takes the form =20
of controller 'A' setting the value of a cell that view 'B' (also =20
bound to the cell) cannot display. The value would be valid for A as =20
a controller but not B as a view, so B reverts to the singleton state.

Therefore, in the case when the view is also a controller (aka a =20
widget), there is an additional requirement to be placed on the =20
widget while in the singleton state. In addition to the above view =20
requirement, the widget must also allow for valid user manipulation =20
of the controller while displaying the singleton state. In the clock =20
example above, (should the clock view be part of a clock widget), the =20=

singleton state should allow for the user to set another (valid) time =20=

(for example, by dragging the hands of the clock with the mouse).

As a more concrete example, I am reworking the ASL preset widget so =20
it models the View concept -- it is bound to a 'result' cell of the =20
property model. When the result cell is updated, the preset widget =20
compares its list of available presets against the result cell -- =20
when a preset is found whose contents are a subset of the result =20
cell, that preset is selected. The singleton state, then, occurs when =20=

the result cell is in a state for which no preset exists. The display =20=

behavior I am implementing is to append a menu item named "Custom" to =20=

the preset category list. This will still let the user select a new =20
preset category from the preset category list, but at the same time =20
clearly tells the user "the dialog as it stands matches no presets."

Thoughts?

Blessings,
Foster


--
Foster T. Brereton              <=E1=BC=B0=CF=87=CE=B8=CF=8D=CF=82><     =
         Romans =20
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

Re: [Adobe-source-devel] Build system (Was: Re: Fwd: Contact from Texas A&M IAP)

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

I will be happy to share my results as I attempt to integrate ASL into
our build system.

On 10/17/06, Mat Marcus <mm...@em...> wrote:
> Thanks for your interest in contributing a build configurations.
>
> ASL's principal build system is currently an enhanced version of boost build
> version 2/bjam (bbv2). This is the only system that we officially support.
> All code must compile using bbv2 (without warnings) on Mac os X and windows
> (MSVC 8.0) and pass all the test suites (automated via bbv2 and begin
> examples) before being checked in to the ASL main line.
>
> As a less-than-100% supported service we try to also keep MSVC 7.1 builds
> and cygwin builds functoining properly. As another unsupported service we
> offer IDE projects. These are written by hand, leveraging  the
> vsprops/xcconfig mechanism to centralize compiler options and track the
> boost build file structure as closely as possible.
>
> There are various other interesting build systems, but I currently lean
> against supporting yet more build flavors in the main line. We might
> consider creating an "unsupported" directory for such contributions.
> Alternatively, we might include a reference to your cmake system from the
> opensource site.
>
>
>
> > -----Original Message-----
> > From: ado...@li...
> > [mailto:ado...@li...] On
> > Behalf Of Hubert Figuiere
> > Sent: Tuesday, October 17, 2006 10:50 AM
> > To: Foster T. Brereton
> > Cc: adobe-source developers
> > Subject: [Adobe-source-devel] Build system (Was: Re: Fwd:
> > Contact from Texas A&M IAP)
> >
> > > We have the vcproj files hand-made at this point due to the
> > fact that
> > > we make heavy use of vsprops files to put our settings
> > external to the
> > > vc projects themselves. We haven't played with CMake before.
> >
> > I have been working on making it build with GNU automake
> > because that is what I know best (almost work on both Mac and
> > Linux), but recently I tried CMake on another project of
> > mine, and I like it... so I have been pondering.
> >
> > I'm wondering whether a complete CMake support would be
> > accepted in the main tree? Given that CMake works on Mac,
> > Windows and UNIX, and for the first 2 can generate project
> > files to be build with the IDEs...
> >
> >
> > Hub
> >
> > --------------------------------------------------------------
> > -----------
> > 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
> >
>
>
> -------------------------------------------------------------------------
> 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] Build system (Was: Re: Fwd: Contact from Texas A&M IAP)

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

AFAIK, CMake does support such tests.  There is a macro called
CheckCXXSourceCompiles.  (I am assuming you can just put NOT in front
of the resultant.)  And there are even macros that generate code &
attempt to build (e.g. to determine if a function exists).

On 10/17/06, Hubert Figuiere <hu...@fi...> wrote:
>  Sean Parent wrote:
> >>
> >> I'm wondering whether a complete CMake support would be accepted in the
> >> main tree? Given that CMake works on Mac, Windows and UNIX, and for the
> >> first 2 can generate project files to be build with the IDEs...
> >
> > We would take a look - despite the headaches of bjam, when it does work
> > it does a nice job of handling complete builds, regression tests,
> > compilation tests, and negative tests (test that are expected _not_ to
> > compile or not to execute).
>
> CMake has support of tests. I don't know how easy it is to handle
> negative test.
> Is there a list of all these test? Or are the jam files the only source.
>
>
> Hub
>
> -------------------------------------------------------------------------
> 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] Build system (Was: Re: Fwd: Contact from Texas A&M IAP)

[Mat M. <mm...@em...>]

Thanks for your interest in contributing a build configurations.

ASL's principal build system is currently an enhanced version of boost build
version 2/bjam (bbv2). This is the only system that we officially support.
All code must compile using bbv2 (without warnings) on Mac os X and windows
(MSVC 8.0) and pass all the test suites (automated via bbv2 and begin
examples) before being checked in to the ASL main line.

As a less-than-100% supported service we try to also keep MSVC 7.1 builds
and cygwin builds functoining properly. As another unsupported service we
offer IDE projects. These are written by hand, leveraging  the
vsprops/xcconfig mechanism to centralize compiler options and track the
boost build file structure as closely as possible.

There are various other interesting build systems, but I currently lean
against supporting yet more build flavors in the main line. We might
consider creating an "unsupported" directory for such contributions.
Alternatively, we might include a reference to your cmake system from the
opensource site.



> -----Original Message-----
> From: ado...@li... 
> [mailto:ado...@li...] On 
> Behalf Of Hubert Figuiere
> Sent: Tuesday, October 17, 2006 10:50 AM
> To: Foster T. Brereton
> Cc: adobe-source developers
> Subject: [Adobe-source-devel] Build system (Was: Re: Fwd: 
> Contact from Texas A&M IAP)
> 
> > We have the vcproj files hand-made at this point due to the 
> fact that 
> > we make heavy use of vsprops files to put our settings 
> external to the 
> > vc projects themselves. We haven't played with CMake before.
> 
> I have been working on making it build with GNU automake 
> because that is what I know best (almost work on both Mac and 
> Linux), but recently I tried CMake on another project of 
> mine, and I like it... so I have been pondering.
> 
> I'm wondering whether a complete CMake support would be 
> accepted in the main tree? Given that CMake works on Mac, 
> Windows and UNIX, and for the first 2 can generate project 
> files to be build with the IDEs...
> 
> 
> Hub
> 
> --------------------------------------------------------------
> -----------
> 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] Build system (Was: Re: Fwd: Contact from Texas A&M IAP)

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

Sean Parent wrote:
>>
>> I'm wondering whether a complete CMake support would be accepted in the
>> main tree? Given that CMake works on Mac, Windows and UNIX, and for the
>> first 2 can generate project files to be build with the IDEs...
> 
> We would take a look - despite the headaches of bjam, when it does work
> it does a nice job of handling complete builds, regression tests,
> compilation tests, and negative tests (test that are expected _not_ to
> compile or not to execute).

CMake has support of tests. I don't know how easy it is to handle
negative test.
Is there a list of all these test? Or are the jam files the only source.


Hub

Re: [Adobe-source-devel] Build system (Was: Re: Fwd: Contact from Texas A&M IAP)

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

>
> I'm wondering whether a complete CMake support would be accepted in  
> the
> main tree? Given that CMake works on Mac, Windows and UNIX, and for  
> the
> first 2 can generate project files to be build with the IDEs...

We would take a look - despite the headaches of bjam, when it does  
work it does a nice job of handling complete builds, regression  
tests, compilation tests, and negative tests (test that are expected  
_not_ to compile or not to execute).

Sean

[Adobe-source-devel] Build system (Was: Re: Fwd: Contact from Texas A&M IAP)

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

> We have the vcproj files hand-made at this point due to the fact that  
> we make heavy use of vsprops files to put our settings external to  
> the vc projects themselves. We haven't played with CMake before.

I have been working on making it build with GNU automake because that is
what I know best (almost work on both Mac and Linux), but recently I
tried CMake on another project of mine, and I like it... so I have been
pondering.

I'm wondering whether a complete CMake support would be accepted in the
main tree? Given that CMake works on Mac, Windows and UNIX, and for the
first 2 can generate project files to be build with the IDEs...


Hub