adobe-source-devel

[Adobe-source-devel] Re: asl-users: Experimental Rewrite of 'Begin'

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

Hi Tom,

I am forwarding this to <ado...@li...>,  
so there are folks outside Adobe who are now in on this conversation.

On Jan 24, 2006, at 09:55a, Tom Pinkerton wrote:

> Hello again.
>
> As an experimental exercise, I'm attempting to write a version of  
> the Adobe
> Begin test app based on the Qt framework (as opposed to native OS  
> widgets).
> I was hoping someone might be able to save me a little time by  
> helping me
> isolate those files that implement the OS specific UI (widgets and  
> windows)
> from other files that contribute to this app in a platform agnostic  
> way. In
> other words, what is the minimum I need to rewrite to make a  
> version of
> Adobe Begin that's based on a UI platform other than the native OS  
> widget
> system currently provided in the existing Adobe Begin app?

What you're aiming to do is great! -- we have at least one other  
developer who has ported ASL's widgets library to another UI platform  
(the FLTK framework, by Ralph Thomas), so the community as a whole  
might be able to further help you. I'll give an overview of the  
changes that need to be made below.

> I currently have things narrowed down to the ASL_Widgets project.  
> Within
> that, I have two categories:

Yes -- all your changes will impact the widgets library alone.

> Keep Unmodified
> ---------------
> assemblage.cpp

Correct (Keep Unmodified) -- The assemblage is something of a  
"runtime class" that allows you to connect runtime-generated objects  
to it so they are destroyed when the assemblage is destroyed. This is  
how we bind up all the runtime-allocated UI widgets in a way that  
they are all destroyed at the same time, and in a reasonable way.

> factory.hpp

I beleive you are correct (Keep Unmodified) --  The factory header is  
a dispatch mechanism written by Ralph Thomas to allow for your UI to  
use more than one widget set at a time. Ralph can give you more  
insights here.

> Not Sure
> --------
> client_assembler.cpp
> ui_core_common.cpp
> ui_core.cpp

These need not be modified -- client_assembler is the glue code that  
binds all the modules together -- Adam, Eve, their parsers, and the  
UI core. It relays pertinent information to the module that needs it,  
so no module is aware of any other in the system directly. The  
ui_core API is our work-in-progress for making a "generic" UI API,  
and (ideally) is the same for all platforms. The ui_core_common file  
is a small collection of utility functions that have been lifted out  
of ui_core_implementation.cpp because they are platform-independent.

> Needs Rewrite
> -------------
> display.cpp
> metrics.cpp
> ui_core_implementation.cpp
> ui_overlay.cpp

This is where the nitty-gritty happens.

display.cpp is the module that handles parent-child relationships  
within the visual heirarchy. You'll notice that there is no  
"set_parent" call in the UI widget API. That is because the  
relationship between a child and a parent widget in our setup is  
handled by the display code. The display code also has the hooks to  
convert from a platform-specific widget token (HIViewRef, HWND, etc)  
to a wrapped version of that token (that can be used generically in  
other parts of the code) and back again.

The metrics.cpp files are platform-dependent utility routines to get  
detailed information about the metrics of a widget. On Windows, this  
is done via the UXTheme API. On the Mac the metrics code is an  
augmentation to the metrics that are obtained via GetBestControlRect,  
as we've found GetBestControlRect is pathologically inaccurate. On  
FLTK, the metrics code is contained entirely within  
ui_core_implementation. Your mileage may vary as to what your  
implementation requires in the way of widget metrics.

ui_core_implementation is where you'll be doing the great bulk of  
your work. This is where the platform-specific controls are created  
and managed via the ui_core API calls. Each ui_core widget has a  
private implementation that is fleshed out in this file. In the  
current Mac and Win32 implementations we take advantage of C++  
inheritance rules to do some of the work for us. In retrospect we've  
found this to be a burdensome way to implement this code, and would  
write it differently if given a second chance. You're welcome to  
manage this file however you see fit, in a way that helps you  
maximize the platform you're targeting.

ui_overlay can be stubbed out for the time being -- it's a debug- 
level piece of code that is used to draw widget boundaries directly  
over the widgets themselves in the window -- something you need not  
worry about immediately.

> How am I doing? Any suggestions?

You're clearly on the right path, and your grasp of the code base  
leads me to believe you can make this a successful port. If you have  
any questions moving forward, please email both the internal <asl- 
us...@ad...> and external (when appropriate) <adobe-source- 
de...@li...> mailing lists so you can get as wide a  
help base as possible.

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
"The fact is that the author of STL does not know how to write min,  
the author of C++ is not quite sure, and the standards committee is  
at a loss." -- Alexander Stepanov

Re: [Adobe-source-devel] Re: asl-users: Experimental Rewrite of 'Begin'

[David C. <unc...@un...>]

On Jan 24, 2006, at 10:32 AM, Foster T. Brereton wrote:
> In the current Mac and Win32 implementations we take advantage of C+ 
> + inheritance rules to do some of the work for us. In retrospect  
> we've found this to be a burdensome way to implement this code, and  
> would write it differently if given a second chance.

I'm curious - why is that? How would you have done it differently?

-- 
David Catmull
unc...@un...
http://www.uncommonplace.com/

Re: [Adobe-source-devel] Re: asl-users: Experimental Rewrite of 'Begin'

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

David,

The simple answer is "programmer's remorse" -- that is, the feeling  
you get after your code has aged about 6 months that a) it's  
horrible, b) you were a moron to implement it this way in the first  
place, and c) given a total rewrite it'd be half the size with half  
the bugs and twice the features.

The long answer is that I was originally hoping the inheritance tree  
I'd created for the controls would have helped in shoring up some of  
the more commonly-used functionality into control_t (an internal  
class from which all the widgets inherit). The problem has quickly  
become an issue of readability and maintainability. I find that I  
can't go back in to ui_core_implementation and pick it up very  
quickly, that the structure in the file (using C++ inheritance)  
doesn't reflect accurately the structure I'm trying to represent (a  
bunch of individual widgets).

The biggest thing I take issue with is not so much the use of  
inheritance, but rather the means by which inheritance was introduced  
into the solution. It was introduced like this:

"I'll use inheritance to solve this problem"!

And like that -- inheritance was in. I'm not saying that inheritance  
itself is fatally flawed, and it may turn out in the end that some  
use of inheritance will prove beneficial to the implementation. The  
problem is that I used inheritance without really thinking about the  
problem, and what came about was an implementation that looks 90%  
"right", but there's some strongarming going on in order to get that  
final 10% working.

A better tack, I believe, would be something of a bottom-up approach.  
It would involve writing all of the widgets independently of one  
another, then finding commonalities between the implementations and  
bubbling them up, hopefully to the point where you can talk in terms  
of generic concepts about some of them.

Another problem we're trying to solve is winning "widget  
independence". Ralph Thomas has done a lot of work in this direction  
with the factory code, and we hope to leverage that going forward so  
you're not limited to "our UI set or theirs" when you are looking to  
develop the widget set for an app. Inheritance make going in this  
direction that much more difficult.

I hope that answers some of your questions.

Blessings,
Foster


On Jan 24, 2006, at 10:50a, David Catmull wrote:

> On Jan 24, 2006, at 10:32 AM, Foster T. Brereton wrote:
>> In the current Mac and Win32 implementations we take advantage of C 
>> ++ inheritance rules to do some of the work for us. In retrospect  
>> we've found this to be a burdensome way to implement this code,  
>> and would write it differently if given a second chance.
>
> I'm curious - why is that? How would you have done it differently?
>
> -- 
> David Catmull
> unc...@un...
> http://www.uncommonplace.com/
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through  
> log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD  
> SPLUNK!
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> 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
"The fact is that the author of STL does not know how to write min,  
the author of C++ is not quite sure, and the standards committee is  
at a loss." -- Alexander Stepanov

Re: [Adobe-source-devel] Re: asl-users: Experimental Rewrite of 'Begin'

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

Hi Tom,

  The FLTK implementation is a good place to start from as it is
probably the smallest and simplest implementation (as FLTK provides a
fairly nice API, as does Qt). Foster's mail sums up the required work
well, basically you only need to worry about ui_core_implementation
and display for now.

  I started the FLTK port by writing an implementation of the
control_t and window_t classes, and then stubbing out all of the other
classes. I then wrote a simple implementation of display and was able
to run a little test app that only used the window widget.

  The hardest part of writing any implementation is calculating the
widget metrics. It took ages to get the Win32 stuff to where it is,
and it still isn't perfect!

Ralph

PS: You should be able to write a small test program that does
something like this:

adobe::sheet_t sheet;
eve_client::window_server_t ws( "", _sheet );
std::ifstream eve_stream( "my_gui.eve" );
ws.push_back( eve_stream, adobe::line_position_t::ident_pair_t(
    adobe::name_t( "my_gui" ), 0 ), size_normal_s );
QtMainLoopFunction();

On 1/24/06, Foster T. Brereton <fbr...@ad...> wrote:
> Hi Tom,
>
> I am forwarding this to <ado...@li...>,
> so there are folks outside Adobe who are now in on this conversation.
>
> On Jan 24, 2006, at 09:55a, Tom Pinkerton wrote:
>
> > Hello again.
> >
> > As an experimental exercise, I'm attempting to write a version of
> > the Adobe
> > Begin test app based on the Qt framework (as opposed to native OS
> > widgets).
> > I was hoping someone might be able to save me a little time by
> > helping me
> > isolate those files that implement the OS specific UI (widgets and
> > windows)
> > from other files that contribute to this app in a platform agnostic
> > way. In
> > other words, what is the minimum I need to rewrite to make a
> > version of
> > Adobe Begin that's based on a UI platform other than the native OS
> > widget
> > system currently provided in the existing Adobe Begin app?
>
> What you're aiming to do is great! -- we have at least one other
> developer who has ported ASL's widgets library to another UI platform
> (the FLTK framework, by Ralph Thomas), so the community as a whole
> might be able to further help you. I'll give an overview of the
> changes that need to be made below.
>
> > I currently have things narrowed down to the ASL_Widgets project.
> > Within
> > that, I have two categories:
>
> Yes -- all your changes will impact the widgets library alone.
>
> > Keep Unmodified
> > ---------------
> > assemblage.cpp
>
> Correct (Keep Unmodified) -- The assemblage is something of a
> "runtime class" that allows you to connect runtime-generated objects
> to it so they are destroyed when the assemblage is destroyed. This is
> how we bind up all the runtime-allocated UI widgets in a way that
> they are all destroyed at the same time, and in a reasonable way.
>
> > factory.hpp
>
> I beleive you are correct (Keep Unmodified) --  The factory header is
> a dispatch mechanism written by Ralph Thomas to allow for your UI to
> use more than one widget set at a time. Ralph can give you more
> insights here.
>
> > Not Sure
> > --------
> > client_assembler.cpp
> > ui_core_common.cpp
> > ui_core.cpp
>
> These need not be modified -- client_assembler is the glue code that
> binds all the modules together -- Adam, Eve, their parsers, and the
> UI core. It relays pertinent information to the module that needs it,
> so no module is aware of any other in the system directly. The
> ui_core API is our work-in-progress for making a "generic" UI API,
> and (ideally) is the same for all platforms. The ui_core_common file
> is a small collection of utility functions that have been lifted out
> of ui_core_implementation.cpp because they are platform-independent.
>
> > Needs Rewrite
> > -------------
> > display.cpp
> > metrics.cpp
> > ui_core_implementation.cpp
> > ui_overlay.cpp
>
> This is where the nitty-gritty happens.
>
> display.cpp is the module that handles parent-child relationships
> within the visual heirarchy. You'll notice that there is no
> "set_parent" call in the UI widget API. That is because the
> relationship between a child and a parent widget in our setup is
> handled by the display code. The display code also has the hooks to
> convert from a platform-specific widget token (HIViewRef, HWND, etc)
> to a wrapped version of that token (that can be used generically in
> other parts of the code) and back again.
>
> The metrics.cpp files are platform-dependent utility routines to get
> detailed information about the metrics of a widget. On Windows, this
> is done via the UXTheme API. On the Mac the metrics code is an
> augmentation to the metrics that are obtained via GetBestControlRect,
> as we've found GetBestControlRect is pathologically inaccurate. On
> FLTK, the metrics code is contained entirely within
> ui_core_implementation. Your mileage may vary as to what your
> implementation requires in the way of widget metrics.
>
> ui_core_implementation is where you'll be doing the great bulk of
> your work. This is where the platform-specific controls are created
> and managed via the ui_core API calls. Each ui_core widget has a
> private implementation that is fleshed out in this file. In the
> current Mac and Win32 implementations we take advantage of C++
> inheritance rules to do some of the work for us. In retrospect we've
> found this to be a burdensome way to implement this code, and would
> write it differently if given a second chance. You're welcome to
> manage this file however you see fit, in a way that helps you
> maximize the platform you're targeting.
>
> ui_overlay can be stubbed out for the time being -- it's a debug-
> level piece of code that is used to draw widget boundaries directly
> over the widgets themselves in the window -- something you need not
> worry about immediately.
>
> > How am I doing? Any suggestions?
>
> You're clearly on the right path, and your grasp of the code base
> leads me to believe you can make this a successful port. If you have
> any questions moving forward, please email both the internal <asl-
> us...@ad...> and external (when appropriate) <adobe-source-
> de...@li...> mailing lists so you can get as wide a
> help base as possible.
>
> 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
> "The fact is that the author of STL does not know how to write min,
> the author of C++ is not quite sure, and the standards committee is
> at a loss." -- Alexander Stepanov
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel
>