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
>