adobe-source-devel — ASL development topic discussion

Re: [Adobe-source-devel] Adding new (object-like) types to Adam

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

On Mar 11, 2005, at 5:10 PM, Ralph Thomas wrote:

> Hi there,
>
>   I (think that I) want to add a new type to Adam. My program is MVC
> based, and the model is always instanciated from a string (a URL or
> serialized model). I understand that I could define a sheet like:
>
> sheet my_model {
>   interface:
>     name : "";
>     mime_type: "";
>     parent : ""; // will be the model's parent's serialized string
> ...
> };
>
> and then bind widgets to @name or @mime_type (and write the glue code
> to hookup name, mime_type and parent to the model). What I'd really
> like to do is more like:
>
> sheet my_sheet {
>   interface:
>     my_model : "serialized-model-string";
> };
>
> and then bind widgets to @my_model.name or @my_model.mime_type. And
> perhaps even change the model string when a button is pressed (e.g.:
> make my_model = my_model.parent).

Adam supports dictionaries and arrays. So you could do this as:

my_model : {name: "", mime_type: "", parent: ""};

You can then refer to an element such as my_model.parent - although 
there is no binding to a piece of a cell like this (dependencies aren't 
tracked through the aggregate types). You can also refer to an element 
in a dictionary with the syntax my_model[@parent]. The advantage here 
is you can use an expression, my_model[pred ? @parent : @name].

Because you can only bind against a cell (not part of a value) you can 
split this out:

sheet my_sheet {
	interface:
		parent: ""; // bind to these
		name: "";
		mime_type: "";
	output:
		my_model <== { name: name, mime_type: mime_type, parent: parent }; // 
use this as the result.
}

The image size example takes this approach. At some point I'd like to 
tackle how to embed a sheet in a sheet (an interesting dependency 
problem). This approach works pretty well though. Note that from C++ 
you can set cells in an Adam sheet to any regular type (see the docs on 
the regular type concept and there is a little blurb about using custom 
types with Adam in the language reference). By providing functions that 
generate and operate on your types you can extend Adam with whatever 
types you want.

Sean

>
> Is this within the scope of Adam? It's not really important that
> my_model be a string and something else, it could just as easily be a
> special sheet (which my code can recognize and glue to a model
> factory).
>
> Best regards,
>  Ralph
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real 
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel

[Adobe-source-devel] Adding new (object-like) types to Adam

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

Hi there,

  I (think that I) want to add a new type to Adam. My program is MVC
based, and the model is always instanciated from a string (a URL or
serialized model). I understand that I could define a sheet like:

sheet my_model {
  interface:
    name : "";
    mime_type: "";
    parent : ""; // will be the model's parent's serialized string
...
};

and then bind widgets to @name or @mime_type (and write the glue code
to hookup name, mime_type and parent to the model). What I'd really
like to do is more like:

sheet my_sheet {
  interface:
    my_model : "serialized-model-string";
};

and then bind widgets to @my_model.name or @my_model.mime_type. And
perhaps even change the model string when a button is pressed (e.g.:
make my_model = my_model.parent).

Is this within the scope of Adam? It's not really important that
my_model be a string and something else, it could just as easily be a
special sheet (which my code can recognize and glue to a model
factory).

Best regards,
 Ralph

Re: [Adobe-source-devel] win32 and linux backends?

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

Okay -- now I understand where you want to go. 

I've been working on a little toolkit which essentially does the same
thing. At the moment I have implementations for MacOS and Win32 (I
have a GTK+ version, too, but I haven't ported my test tool to X11
yet, so I don't know if it's really up to snuff).

The idea you describe (of having "widget styles defined in terms of
widget usage, rather than widget appearance") is the only sensible way
of writing this, in my experience.

How much interaction is there supposed to be between the ui-core code
(window_t, button_t...) and application code? Is it all meant to
happen through Adam and Eve, is there ever a circumstance where you
want to touch a button_t directly from application code? If not, is it
important to implement the same C++ interfaces on every platform so
long as the interface from Eve is the same?

Best regards,
  Ralph

On Fri, 11 Mar 2005 11:01:38 -0800, Foster T. Brereton
<fbr...@ad...> wrote:
> On Mar 10, 2005, at 11:40p, Ralph Thomas wrote:
> 
> > Are you planning on making the toolkit interface exactly the same for
> > Windows and MacOS (so that the same eve files could be used on both
> > platforms)?
> 
> Yes.
> 
> We are trying to do more than provide a common API for all platforms. A
> point we are trying to achieve is to distill the semantics of these
> widgets down to their minimum requirements, completely separated from
> platform-specific UI APIs. We then want to conform the ui_core API to
> those semantic needs instead of tying it to a specific platform and
> forcing the other platforms to "catch up". In this sense, then, all the
> platforms are playing "catch up", because there are varying degrees of
> functionality across them, and all should strive to achieve good
> implementations for these semantics. Obtaining the ideal dimensions of
> a widget is a good example of this-- neither platform does it
> perfectly, and yet ultimately that is the behavior you are striving
> for.
> 
> What we have found is that the client has a specific intention and
> purpose for a widget. With APIs that let clients set various attributes
> of a widget (font size and style, event handlers, etc) the client will
> set these various attributes for each to match this intention. For
> example, buttons in palettes will have a certain "look and feel", as
> will buttons in a standard dialog, though the "looks and feels" could
> be very different between the two. What we are doing with ui_core is
> coding the API to the "look and feel" and not to the minutiae of
> achieving that look. More formally, we are writing the API to the
> behavior requirements (semantics) of the widget, instead of forcing the
> client to define those semantics implicitly through their tweaking of
> the widget's minor attributes (font size and style, event handlers,
> etc).
> 
> As a specific API example, we do not have "set_font_size" anywhere in
> the ui_core API. But we do have a more general "set_theme" (which even
> now is still not where we want it). Please keep in mind the ui_core API
> is in need of a lot of work, but I hope this gives you a general idea
> of the direction we are interested in taking it.
> 
> It is a start, we believe a good start, but only a start...
> 
> Blessings,
> Foster
> 
> --
> Foster T. Brereton              <}}}><              Romans 3:21-26
> A d o b e   S o f t w a r e   T e c h n o l o g y   L a b
> "What 99 percent of programmers need to know is not how to build
> components but how to use them." -- Alexander Stepanov
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel
>

Re: [Adobe-source-devel] win32 and linux backends?

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

On Mar 10, 2005, at 11:40p, Ralph Thomas wrote:

> Are you planning on making the toolkit interface exactly the same for
> Windows and MacOS (so that the same eve files could be used on both
> platforms)?

Yes.

We are trying to do more than provide a common API for all platforms. A 
point we are trying to achieve is to distill the semantics of these 
widgets down to their minimum requirements, completely separated from 
platform-specific UI APIs. We then want to conform the ui_core API to 
those semantic needs instead of tying it to a specific platform and 
forcing the other platforms to "catch up". In this sense, then, all the 
platforms are playing "catch up", because there are varying degrees of 
functionality across them, and all should strive to achieve good 
implementations for these semantics. Obtaining the ideal dimensions of 
a widget is a good example of this-- neither platform does it 
perfectly, and yet ultimately that is the behavior you are striving 
for.

What we have found is that the client has a specific intention and 
purpose for a widget. With APIs that let clients set various attributes 
of a widget (font size and style, event handlers, etc) the client will 
set these various attributes for each to match this intention. For 
example, buttons in palettes will have a certain "look and feel", as 
will buttons in a standard dialog, though the "looks and feels" could 
be very different between the two. What we are doing with ui_core is 
coding the API to the "look and feel" and not to the minutiae of 
achieving that look. More formally, we are writing the API to the 
behavior requirements (semantics) of the widget, instead of forcing the 
client to define those semantics implicitly through their tweaking of 
the widget's minor attributes (font size and style, event handlers, 
etc).

As a specific API example, we do not have "set_font_size" anywhere in 
the ui_core API. But we do have a more general "set_theme" (which even 
now is still not where we want it). Please keep in mind the ui_core API 
is in need of a lot of work, but I hope this gives you a general idea 
of the direction we are interested in taking it.

It is a start, we believe a good start, but only a start...

Blessings,
Foster


--
Foster T. Brereton              <}}}><              Romans 3:21-26
A d o b e   S o f t w a r e   T e c h n o l o g y   L a b
"What 99 percent of programmers need to know is not how to build
components but how to use them." -- Alexander Stepanov

Re: [Adobe-source-devel] win32 and linux backends?

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

On Mar 10, 2005, at 11:40p, Ralph Thomas wrote:

> Are you planning on making the toolkit interface exactly the same for
> Windows and MacOS (so that the same eve files could be used on both
> platforms)?

Yes.

We are trying to do more than provide a common API for all platforms. A 
point we are trying to achieve is to distill the semantics of these 
widgets down to their minimum requirements, completely separated from 
platform-specific UI APIs. We then want to conform the ui_core API to 
those semantic needs instead of tying it to a specific platform and 
forcing the other platforms to "catch up". In this sense, then, all the 
platforms are playing "catch up", because there are varying degrees of 
functionality across them, and all should strive to achieve good 
implementations for these semantics. Obtaining the ideal dimensions of 
a widget is a good example of this-- neither platform does it 
perfectly, and yet ultimately that is the behavior you are striving 
for.

What we have found is that the client has a specific intention and 
purpose for a widget. With APIs that let clients set various attributes 
of a widget (font size and style, event handlers, etc) the client will 
set these various attributes for each to match this intention. For 
example, buttons in palettes will have a certain "look and feel", as 
will buttons in a standard dialog, though the "looks and feels" could 
be very different between the two. What we are doing with ui_core is 
coding the API to the "look and feel" and not to the minutiae of 
achieving that look. More formally, we are writing the API to the 
behavior requirements (semantics) of the widget, instead of forcing the 
client to define those semantics implicitly through their tweaking of 
the widget's minor attributes (font size and style, event handlers, 
etc).

As a specific API example, we do not have "set_font_size" anywhere in 
the ui_core API. But we do have a more general "set_theme" (which even 
now is still not where we want it). Please keep in mind the ui_core API 
is in need of a lot of work, but I hope this gives you a general idea 
of the direction we are interested in taking it.

It is a start, we believe a good start, but only a start...

Blessings,
Foster


--
Foster T. Brereton              <}}}><              Romans 3:21-26
A d o b e   S o f t w a r e   T e c h n o l o g y   L a b
"What 99 percent of programmers need to know is not how to build
components but how to use them." -- Alexander Stepanov

Re: [Adobe-source-devel] win32 and linux backends?

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

Personally I've found Win32 is more honest about control dimensions
than MacOS (i.e.: controls don't go outside the rectangle you tell
them to stay in, so you don't need the same "fudges" present in the
MacOS test/visual code).

Win32 doesn't have a GetBestControlRect analog, so you end up writing
your own. I've always ended up having to fudge the values given by
GetTextExtentPoint32W when calculating the best rectangle for text
containing controls (e.g.: button).

Are you planning on making the toolkit interface exactly the same for
Windows and MacOS (so that the same eve files could be used on both
platforms)?

Ralph

On Thu, 10 Mar 2005 15:50:29 -0800, Sean Parent <sp...@ad...> wrote:
> Hi Niki,
> Starting to use our stuff is always good - We actually aren't doing
> Cocoa at the moment (it's Carbon, although there is some stuff being
> done with A&E internally in Cocoa). I would say there are two places
> where you could jump in -
> 
> We don't have Python bindings and I think they would be an interesting
> thing to have (and probably pretty simple to do - if you look at the
> command-line tutorial it is surprisingly simple to hook up). If you
> wanted to jump in on the Win32 side - I'd start with working on how to
> get good geometry out of controls (coordinate with Foster on that). I'd
> also love to have someone doing bindings to XAML.
> Sean
> 
> On Mar 9, 2005, at 12:54 AM, Niki Spahiev wrote:
> 
> >> A Win32 backend is definitely on our to do list, however we cannot
> >> give
> >> it as much time as we would like. There is no reasonable estimate as
> >> to
> >> when it will be ready for public release. In the meantime you can
> >> still
> >> see what Adam has to offer in the Adam command-line tutorial that was
> >> recently posted to CVS.
> >
> > Ok but command-line is not fun. Should i start porting from Cocoa to
> > win32 or wait?
> > Do you have python bindings? I tend to do all experiments in python
> > and will start to make python interface.
> >
> > regards,
> > Niki Spahiev
> >
> >
> > -------------------------------------------------------
> > SF email is sponsored by - The IT Product Guide
> > Read honest & candid reviews on hundreds of IT Products from real
> > users.
> > Discover which products truly live up to the hype. Start reading now.
> > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> > _______________________________________________
> > Adobe-source-devel mailing list
> > Ado...@li...
> > https://lists.sourceforge.net/lists/listinfo/adobe-source-devel
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel
>

Re: [Adobe-source-devel] win32 and linux backends?

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

Hi Niki,
Starting to use our stuff is always good - We actually aren't doing 
Cocoa at the moment (it's Carbon, although there is some stuff being 
done with A&E internally in Cocoa). I would say there are two places 
where you could jump in -

We don't have Python bindings and I think they would be an interesting 
thing to have (and probably pretty simple to do - if you look at the 
command-line tutorial it is surprisingly simple to hook up). If you 
wanted to jump in on the Win32 side - I'd start with working on how to 
get good geometry out of controls (coordinate with Foster on that). I'd 
also love to have someone doing bindings to XAML.
Sean

On Mar 9, 2005, at 12:54 AM, Niki Spahiev wrote:

>> A Win32 backend is definitely on our to do list, however we cannot 
>> give
>> it as much time as we would like. There is no reasonable estimate as 
>> to
>> when it will be ready for public release. In the meantime you can 
>> still
>> see what Adam has to offer in the Adam command-line tutorial that was
>> recently posted to CVS.
>
> Ok but command-line is not fun. Should i start porting from Cocoa to
> win32 or wait?
> Do you have python bindings? I tend to do all experiments in python
> and will start to make python interface.
>
> regards,
> Niki Spahiev
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real 
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel

Re: [Adobe-source-devel] win32 and linux backends?

[Niki S. <nik...@gm...>]

> A Win32 backend is definitely on our to do list, however we cannot give
> it as much time as we would like. There is no reasonable estimate as to
> when it will be ready for public release. In the meantime you can still
> see what Adam has to offer in the Adam command-line tutorial that was
> recently posted to CVS.

Ok but command-line is not fun. Should i start porting from Cocoa to
win32 or wait?
Do you have python bindings? I tend to do all experiments in python
and will start to make python interface.

regards,
Niki Spahiev

Re: [Adobe-source-devel] win32 and linux backends?

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

Niki,

A Win32 backend is definitely on our to do list, however we cannot give 
it as much time as we would like. There is no reasonable estimate as to 
when it will be ready for public release. In the meantime you can still 
see what Adam has to offer in the Adam command-line tutorial that was 
recently posted to CVS.

Blessings,
Foster

On Mar 8, 2005, at 02:09a, Niki Spahiev wrote:

> Any plans for win32 and linux backends?
> I have no access to mac :-(
>
> regards,
> Niki Spahiev
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real 
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel
>
>
--
Foster T. Brereton              <}}}><              Romans 3:21-26
A d o b e   S o f t w a r e   T e c h n o l o g y   L a b
"What 99 percent of programmers need to know is not how to build
components but how to use them." -- Alexander Stepanov

[Adobe-source-devel] win32 and linux backends?

[Niki S. <nik...@gm...>]

Any plans for win32 and linux backends?
I have no access to mac :-(

regards,
Niki Spahiev