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

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

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

regards,
Niki Spahiev

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

> 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

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

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
>

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

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

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
>

> 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?

Our contention is that if you are coding to the semantics of the 
widget, beating on the platform widget directly should not be 
necessary. If you are finding a need to do so, you should ask yourself:

Am I trying to do something that would go against the semantics of the 
widget (irrespective of the API)? If yes, consider another widget for 
what you are trying to do. If not, what is lacking in the API that 
would improve its reflection of the semantics of the widget? The answer 
to this could be a good change to the API for the widget.

> If not, is it
> important to implement the same C++ interfaces on every platform so
> long as the interface from Eve is the same?

Yes.

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