adobe-source-devel — ASL development topic discussion

[Adobe-source-devel] Re: asl-users: Widget Parenting Issues

[Tony V. E. <to...@ad...>]

If it helps with implementation issues, you can easily reparent a Window 
to another parent using SetParent() (at least within the same process). 
  I suspect all controls could start with the same parent - an invisible 
window hiding somewhere, and then be reparented 'when the time is right'.


Tony Van Eerd
Adobe Waterloo
-via Thunderbird-

Tom Pinkerton wrote:
> Hi All,
> 
> While digging into my Qt implementation of the widgets library, I've noticed
> that a widget's parent appears to be set after the underlying platform
> widget itself is created. On MacOS this is not a problem because a control
> can be initially created without a parent. However, the existing Windows
> implementation uses some kind of 'invisible parent' member as an initial
> parent when a control is created. In Qt, like on Windows, a widget needs a
> parent at creation time, so I'm wondering if I will need a similar
> 'invisible parent' mechanism for my Qt implementation. Does Eve somehow rely
> upon setting the parent after a widget is initially created? Is the sole
> purpose of the display_t object to provide a way to set the widget's parent
> hierarchy? Will the parent hierarchy ever change for a given Eve layout
> after the initial layout is created?
> 
> Thanks,
> 
> Tom
> 
> 

Re: [Adobe-source-devel] Re: asl-users: Widget Parenting Issues

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

On 1/30/06, Sean Parent <sp...@ad...> wrote:
> The engine does support adding nodes to the graph post initial layout
> - although we don't make use if it in the current code (as Foster
> points out, Ralph is making use of it). It doesn't currently support
> removing nodes (the optional panel is handled by filtering nodes
> within the layout, not removing them). The ability to remove nodes
> may be added in the future if there is strong demand - but it is
> generally a risky prospect. If you remove a node you would invalidate
> any iterators to that node or it's children and widgets currently
> communicate with the layout by hanging onto their position. Robust
> support for remove would require something like slots/signals to
> notify connected items that they were being disconnected. I haven't
> found a use case for this yet.

The only reason I've been able to get away with removing and sorting
widgets so far is that:

 1. I always remove the widget and all of it's children (I create an
assemblage for each child widget to ensure this).
 2. I don't have any optional_panel children, so none of the widgets
use the iterator that they have into Eve.

I don't understand why you would need a signal/slot system to support
(re)move, you could just have another function in the signal_suite for
"your eve iterator has changed". There might be problems if you tried
to change anything in Eve when you received that signal though!

Ralph

[Adobe-source-devel] MSVC manifest file issues

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

ASL community,

Mat and I have been receiving several strange bugs where basic UI  
functionality isn't working at all. In each case when we try to  
regress them locally we are unable to reproduce the problem. Today  
Mat and I were researching a small warning we're getting from the  
resource compiler that the macro ADOBE_VER has been  declared twice.  
We have discovered that, when using bjam, the initialization code is  
executed twice and in each pass one or the other ADOBE_VER macro  
definition is globbed into the resource compiler settings. We suspect  
that bjam is making a pass over the configuration for each compiler  
it is trying to target (in our case, msvc 7.1 and msvc 8), but that  
the settings themselves are all getting globbed together. This would  
result in the possibility of the wrong manifest file being bound to  
an compiled binary, leaving it generally up in the air as to what  
compatibility issues may come out of it. It is this issue that we  
suspect may be at the heart of many of the UI problems we are seeing.  
I have sent an email off to the boost build mailing list in hopes of  
getting more information.

We are still in the process of exploring the bug and evaluating  
workarounds. If you are trying to build with BBv2 please consult  
their documentation regarding user-config.jam files. One possible  
(unverified) workaround is to remove usage of msvc-config from your  
user-config.jam and being explicit about which compiler you're  
targeting. We'll keep you posted as things come up.

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

[Adobe-source-devel] Re: asl-users: Widget Parenting Issues

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

On Jan 30, 2006, at 2:26 PM, Foster T. Brereton wrote:

> On Jan 30, 2006, at 01:58p, Tom Pinkerton wrote:
>
>> Hi All,
>>
>> While digging into my Qt implementation of the widgets library,  
>> I've noticed
>> that a widget's parent appears to be set after the underlying  
>> platform
>> widget itself is created. On MacOS this is not a problem because a  
>> control
>> can be initially created without a parent. However, the existing  
>> Windows
>> implementation uses some kind of 'invisible parent' member as an  
>> initial
>> parent when a control is created. In Qt, like on Windows, a widget  
>> needs a
>> parent at creation time, so I'm wondering if I will need a similar
>> 'invisible parent' mechanism for my Qt implementation.
>
> Yes, you will need to do the same for Qt.

The rational for display_t was to begin to abstract away the notion  
of a view hierarchy from the widgets that the hierarchy contains -  
we're going for an STL container model here as opposed to an  
obtrusive "every object has it's own list of children".

The principal of minimal requirements for an interface then implies  
that a widget would not have knowledge of this container, but rather  
would be associated with the view hierarchy after construction.

Because display_t actually lives within the framework (Win32, QT,  
whatever) - our implementation is a thin interface shim (much as  
checkbox_t is a thin shim on the platform checkbox interface). The  
invisible window is a hack so that checkbox_t and display_t can  
maintain a correct interface.

>
>> Does Eve somehow rely
>> upon setting the parent after a widget is initially created?
>
> Yes -- this is due to the fact that the widgets themselves aren't  
> supposed to manage their child-parent relationships; this is  
> modeled currently by the separation of the ui_core from the display  
> code. The display's intent is to manage parent/child relationships  
> within the visual heirarchy, completely separate from the widgets  
> themselves. A widget is first created in the ui_core, then it is  
> attached to the visual hierarchy through the display code. Thus, it  
> must exist before it can be attached, requiring the invisible  
> window for platforms where widgets must be contained by a window at  
> all times.

To correct Foster, The Eve layout engine does not make such an  
assumption - Eve doesn't even deal with the construction pass at all.  
This is handled through the eve_evaluate code (which exists to make  
it easier to connect the data coming out of the eve parser with a  
widget factory and an eve layout). The design here is purely part of  
the widget library. Eve can be wired to an existing framework without  
going through the widget library - in fact the widget library started  
life as throw away code in Begin to demonstrate how to Eve up to a  
framework (the original implementation was done with the proxy  
objects direct to Mac Carbon controls). It became apparent that have  
a thin "widget library" would make adoption of Adam and Eve simpler  
so we've been working to rework the widget library in a way which is  
intended to be framework independent.

>
>> Is the sole
>> purpose of the display_t object to provide a way to set the  
>> widget's parent
>> hierarchy?
>
> Yes. Sean had other justifications for the display code, but I  
> can't remember them currently.
>
>> Will the parent hierarchy ever change for a given Eve layout
>> after the initial layout is created?
>
> No -- the description of the layout specifies the hierarchy, and it  
> is parsed only when the view is first created. Ralph Thomas has  
> done some work with populating parents dynamically with children as  
> an optimization (e.g., only populating a scrollable list of image  
> thumbnails with those thumbs that are currently in the view  
> clipping rect) but it's not a part of ASL currently. Note this is a  
> different behavior from hiding and showing widgets, however (which  
> is something we do support).

The engine does support adding nodes to the graph post initial layout  
- although we don't make use if it in the current code (as Foster  
points out, Ralph is making use of it). It doesn't currently support  
removing nodes (the optional panel is handled by filtering nodes  
within the layout, not removing them). The ability to remove nodes  
may be added in the future if there is strong demand - but it is  
generally a risky prospect. If you remove a node you would invalidate  
any iterators to that node or it's children and widgets currently  
communicate with the layout by hanging onto their position. Robust  
support for remove would require something like slots/signals to  
notify connected items that they were being disconnected. I haven't  
found a use case for this yet.

>
> Keep the questions coming!
>
> 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
>
>

[Adobe-source-devel] Re: asl-users: Widget Parenting Issues

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

On Jan 30, 2006, at 01:58p, Tom Pinkerton wrote:

> Hi All,
>
> While digging into my Qt implementation of the widgets library,  
> I've noticed
> that a widget's parent appears to be set after the underlying platform
> widget itself is created. On MacOS this is not a problem because a  
> control
> can be initially created without a parent. However, the existing  
> Windows
> implementation uses some kind of 'invisible parent' member as an  
> initial
> parent when a control is created. In Qt, like on Windows, a widget  
> needs a
> parent at creation time, so I'm wondering if I will need a similar
> 'invisible parent' mechanism for my Qt implementation.

Yes, you will need to do the same for Qt.

> Does Eve somehow rely
> upon setting the parent after a widget is initially created?

Yes -- this is due to the fact that the widgets themselves aren't  
supposed to manage their child-parent relationships; this is modeled  
currently by the separation of the ui_core from the display code. The  
display's intent is to manage parent/child relationships within the  
visual heirarchy, completely separate from the widgets themselves. A  
widget is first created in the ui_core, then it is attached to the  
visual hierarchy through the display code. Thus, it must exist before  
it can be attached, requiring the invisible window for platforms  
where widgets must be contained by a window at all times.

> Is the sole
> purpose of the display_t object to provide a way to set the  
> widget's parent
> hierarchy?

Yes. Sean had other justifications for the display code, but I can't  
remember them currently.

> Will the parent hierarchy ever change for a given Eve layout
> after the initial layout is created?

No -- the description of the layout specifies the hierarchy, and it  
is parsed only when the view is first created. Ralph Thomas has done  
some work with populating parents dynamically with children as an  
optimization (e.g., only populating a scrollable list of image  
thumbnails with those thumbs that are currently in the view clipping  
rect) but it's not a part of ASL currently. Note this is a different  
behavior from hiding and showing widgets, however (which is something  
we do support).

Keep the questions coming!

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

[Adobe-source-devel] Widget Parenting Issues

[Tom P. <tpi...@ad...>]

Hi All,

While digging into my Qt implementation of the widgets library, I've noticed
that a widget's parent appears to be set after the underlying platform
widget itself is created. On MacOS this is not a problem because a control
can be initially created without a parent. However, the existing Windows
implementation uses some kind of 'invisible parent' member as an initial
parent when a control is created. In Qt, like on Windows, a widget needs a
parent at creation time, so I'm wondering if I will need a similar
'invisible parent' mechanism for my Qt implementation. Does Eve somehow rely
upon setting the parent after a widget is initially created? Is the sole
purpose of the display_t object to provide a way to set the widget's parent
hierarchy? Will the parent hierarchy ever change for a given Eve layout
after the initial layout is created?

Thanks,

Tom

[Adobe-source-devel] sandbox begin crash

[Thomas W. <wi...@ac...>]

On VC8 + XP SP2 the following leads to a crash:

Compile + Run begin Debug version from sandbox. Load the image_size  
example. Type a digit in the width field of the dialog.

Regards

Thomas

Thomas Witt
wi...@ac...

Re: [Adobe-source-devel] Handling dates

[Thomas W. <wi...@ac...>]

On Jan 19, 2006, at 6:02 PM, Sean Parent wrote:

> A quick glance at the sources and I see where missing a little bit  
> (but not much)...
>
> Internally, Adam operates on adobe::value_t for the values in cells  
> (these are similar to boost any - but the type requirements are a  
> bit stronger, the type passed to a value_t must be equality  
> comparable and if ADOBE_SERIALIZATION is defined then it must  
> support operator << on an ostream. The serialization should go  
> through the Adobe formatting code (but that's a loose requirement)  
> - ADOBE_SERIALIZATION predates the boost serialization code but it  
> isn't complete and although I like some of the ideas better we'll  
> likely replace it with boost serialization. For now, it is only  
> used for debugging.
>
> The virtual machine has a pair of callbacks for user defined  
> functions (one which takes named parameters and hands off a  
> dictionary_t, and one that takes unnamed parameters and hands off  
> an array_t) -
>
> So all you need to do is write the functions you need for your  
> dates in terms if the function interface for the virtual machine -  
> and plug it in to the (non-existent but trivial to add) interface  
> to Adam.

I've added the interface and added a bunch of functions using  
boost.date_time works beautifully.

Thanks!

Thomas


Thomas Witt
wi...@ac...

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] win32 group_window_proc

[Thomas W. <wi...@ac...>]

On Jan 23, 2006, at 9:02 PM, Ralph Thomas wrote:

> I just committed the fix for this to sandbox, as well as the fix for
> another issue that Thomas found -- when there are many items in a
> popup widget it will occupy the entire screen (and some items are
> inaccessible).
>

Thanks! This was really keeping me from making progress.

Thomas

Thomas Witt
wi...@ac...

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
>

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/

[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

[Adobe-source-devel] window_server_t improvements

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

Hi guys,

  Foster told me that some work was being done on window_server_t. It
would be really nice if the new window server interface allowed the
user to specify the array and dictionary function lookups as used by
the Eve VM (it would be good if there was a way of specifying them for
the Adam VM too).

  I have a few custom functions in my code (for creating binders), I
can see that ASL will need some in the future for things like resource
loading, etc.

Thanks!
 Ralph

Re: [Adobe-source-devel] win32 group_window_proc

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

I just committed the fix for this to sandbox, as well as the fix for
another issue that Thomas found -- when there are many items in a
popup widget it will occupy the entire screen (and some items are
inaccessible).

Ralph

On 1/20/06, Ralph Thomas <ra...@gm...> wrote:
> Unfortunately my text editor (notepad!) changed the line endings from
> what is in CVS so I can't post a diff, but one "fix" is to change
> group_window_proc to this:
>
> // Forward any WM_COMMAND on to the widget that needs to receive it.
>
> LRESULT CALLBACK group_window_proc (HWND window, UINT message, WPARAM
> wParam, LPARAM lParam)
>
> {
>
>     if (message =3D=3D WM_COMMAND)
>     {
>         bool unused (false);
>         return event_dispatcher::event( message, wParam, lParam, unused )=
;
>     }
>
>
>    // do default button message processing
>
>    control_t*   control(reinterpret_cast<control_t*>(get_user_reference(w=
indow)));
>
>    return CallWindowProc (control->default_window_proc_m, window,
> message, wParam, lParam);
>
> }
>
> But then there's not much difference between group_window_proc and
> container_window_proc which doesn't seem to be being used anymore (?)
> so I think the best fix is to remove group_window_proc completely and
> just use container_window_proc in  place of it.
>
> The event_dispatcher (which container_window_proc) uses works by
> assigning each control a menu id when the control is created. All
> WM_COMMAND and WM_NOTIFYs contain the menu id as LOWORD(wParam), the
> event_dispatcher can look up the control_t* to call when it encounters
> a menu id that it assigned.
>
> After this change it looks like slider_suite still works, as does
> image_size (I put the buttons into a group), and the example that
> Thomas sent for unit_text now works too.
>
> Ralph
>
> On 1/20/06, Niki Spahiev <nik...@gm...> wrote:
> > ATL supports message reflection. IIRC it's source is available.
> >
> > http://msdn.microsoft.com/library/en-us/dnvc60/html/atlwindow.asp?frame=
=3Dtrue#atlwindow_topic11
> >
> > HTH
> > Niki Spahiev
> >
> >
> > -------------------------------------------------------
> > 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?cmdlnk&kid=103432&bid#0486&dat=121642
> > _______________________________________________
> > Adobe-source-devel mailing list
> > Ado...@li...
> > https://lists.sourceforge.net/lists/listinfo/adobe-source-devel
> >
>

Re: [Adobe-source-devel] win32 group_window_proc

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

Unfortunately my text editor (notepad!) changed the line endings from
what is in CVS so I can't post a diff, but one "fix" is to change
group_window_proc to this:

// Forward any WM_COMMAND on to the widget that needs to receive it.

LRESULT CALLBACK group_window_proc (HWND window, UINT message, WPARAM
wParam, LPARAM lParam)

{

    if (message =3D=3D WM_COMMAND)
    {
        bool unused (false);
        return event_dispatcher::event( message, wParam, lParam, unused );
    }


   // do default button message processing

   control_t*=09control(reinterpret_cast<control_t*>(get_user_reference(win=
dow)));

   return CallWindowProc (control->default_window_proc_m, window,
message, wParam, lParam);

}

But then there's not much difference between group_window_proc and
container_window_proc which doesn't seem to be being used anymore (?)
so I think the best fix is to remove group_window_proc completely and
just use container_window_proc in  place of it.

The event_dispatcher (which container_window_proc) uses works by
assigning each control a menu id when the control is created. All
WM_COMMAND and WM_NOTIFYs contain the menu id as LOWORD(wParam), the
event_dispatcher can look up the control_t* to call when it encounters
a menu id that it assigned.

After this change it looks like slider_suite still works, as does
image_size (I put the buttons into a group), and the example that
Thomas sent for unit_text now works too.

Ralph

On 1/20/06, Niki Spahiev <nik...@gm...> wrote:
> ATL supports message reflection. IIRC it's source is available.
>
> http://msdn.microsoft.com/library/en-us/dnvc60/html/atlwindow.asp?frame=
=3Dtrue#atlwindow_topic11
>
> HTH
> Niki Spahiev
>
>
> -------------------------------------------------------
> 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?cmdlnk&kid=103432&bid#0486&dat=121642
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel
>

Re: [Adobe-source-devel] edit_number win32

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

I can't see what the problem is on my machine (XP MCE, MSVC 2003). I
made a screenshot of the given UI with and without the patch applied
here:

http://www.infinite-imagination.com/software/asl/screenshots/witt-patch.png

Note that this was on sandbox that I checked out earlier tonight, so
perhaps somebody fixed the problem already. What OS and compiler are
you using?

Thanks,
 Ralph

On 1/18/06, Sean Parent <sp...@ad...> wrote:
>
> On Jan 18, 2006, at 3:16 PM, Thomas Witt wrote:
>
> > Sean Parent wrote:
> >> On Jan 17, 2006, at 6:35 PM, Thomas Witt wrote:
> >>> the attached patch fixes a edit_number layout issue in the win32
> >>> implementation. In more complex layouts the popup is not
> >>> displayed correctly because eve adjusts the poi that is used to
> >>> store the popup position but not the the overall widget length. I
> >>> am not sure whether this might actually be an eve issue, but the
> >>> patch makes edit_number work and brings its logic in line with
> >>> the Mac implementation that does not use a poi for this AFAICS.
> >> For leaf nodes Eve moves the widget for the first poi (and adjusts
> >> the width after that) - for an edit_number, the widget shouldn't
> >> be stretching since there is just a single poi.
> >
> > This is true for Mac afaics. The win32 implementation stores a
> > second horizontal poi at the popup widget position and that does
> > not work.
>
> I'll take a look at your example - two issues here...
>
> Windows should be consistent with Mac - (one poi is sufficient - at
> least until I get named poi's implemented).
>
> With two pois the behavior should be to offset to align the first
> poi, and stretch to align the second. I'll have to check the code...
>
> Thanks!
> Sean
>
> >
> >> Can you send an example?
> >
> > See attached sheets. The edit_numbers in the "Analysis" group
> > should show the problem.
> >
> > Thomas
> >
> > --
> > Thomas Witt
> > wi...@ac...
> > /*
> >       Copyright 2005 Zephyr Assoc. Inc.
> > */
> >
> >
> >
> > sheet parameter
> >
> > {
> > constant:
> >       most_recent_units_monthly: [ {name: "Years", bind: @last_years},
> > {name: "Quarters", bind: @last_quarters}, {name: "Months", bind:
> > @last_months} ];
> >       most_recent_units_quarterly: [ {name: "Years", bind: @last_years}=
,
> > {name: "Quarters", bind: @last_quarters} ];
> >
> > interface:
> >       periodicity: @monthly;
> >
> >       most_recent_units: most_recent_units_monthly <=3D=3D (periodicity=
 =3D=3D
> > @monthly) ? most_recent_units_monthly : most_recent_units_quarterly;
> >
> >       use_latest: @period;
> >
> >       last_years : 5;
> >       last_quarters : 5;
> >       last_months : 12;
> >
> >       recent_period_unit: 5;
> >
> >       period_spec: @range;
> >       constraint_spec: @long;
> >
> > }
> >
> > /*
> >       Copyright 2005 Zephyr Assoc. Inc.; All Rights Reserved.
> > */
> >
> > dialog(name: "Parameter", placement: place_column, grow: true)
> > {
> >       row()
> >       {
> >
> >               column()
> >               {
> >
> >                       group (name: "Analysis")
> >                       {
> >
> >                               row(child_horizontal: align_left, horizon=
tal: align_fill)
> >                               {
> >                                       popup(name: "Periodicity", bind: =
@periodicity, items: [ {name:
> > "Quarterly", value: @quarterly}, {name: "Monthly", value:
> > @monthly} ]);
> >                               }
> >
> >
> >                               row()
> >                               {
> >                                       radio_button( name: "", bind: @pe=
riod_spec, value: @range );
> >                                       popup(name: "From", items: [  {na=
me: "01/01/1979", value: 1},
> > {name: "11/30/2005", value: 2} ]);
> >                                       popup(name: "To", items: [  {name=
: "01/01/1979", value: 1},
> > {name: "11/30/2005", value: 2} ]);
> >                               }
> >
> >
> >                               row( guide_mask: [ @guide_label ] )
> >                               {
> >                                       radio_button( name: "Use latest",=
 bind: @period_spec, value:
> > @latest );
> >
> >                                       column()
> >                                       {
> >
> >                                       edit_number( name: "edit_number",=
 horizontal: align_left,
> > units: [ {name: "Years", bind: @last_years}, {name: "Quarters",
> > bind: @last_quarters}, {name: "Months", bind: @last_months} ] );
> >
> >                                       popup ( name: "ending",
> >                                                    bind: @use_latest,
> >                                                    items: [
> >                                               {name: "most recent perio=
d", value: @most_recent_period},
> >                                               {name: "most recent quart=
er", value: @most_recent_quarter},
> >                                               {name: "most recent calen=
dar year", value:
> > @most_recent_calendar_year},
> >                                               {name: "most recent fisca=
l year", value:
> > @most_recent_fiscal_year},
> >                                               {name: "a period of time =
ago", value: @period},
> >                                               {name: "on a specific dat=
e", value: @specific_date} ] );
> >
> >                                       row()
> >                                       {
> >                                       overlay()
> >                                       {
> >                                               panel( bind: @use_latest,=
 value: @period )
> >                                               {
> >                                                       edit_number(name:=
 "Ends:", units: [ {name: "Years", bind:
> > @last_years}, {name: "Quarters", bind: @last_quarters}, {name:
> > "Months", bind: @last_months} ]);
> >                                               }
> >
> >                                               panel( bind: @use_latest,=
 value: @specific_date )
> >                                               {
> >                                                       popup(name: "To",=
 items: [  {name: "01/01/1979", value: 1},
> > {name: "11/30/2005", value: 2} ]);
> >                                               }
> >                                       }
> >                                       }
> >                                       }
> >                               }
> >
> >                               checkbox( name: "Don't limit dates to com=
mon periods.", value:
> > 1 );
> >
> >                       }
> >
> >
> >                       group ( name: "Computation", horizontal: align_fi=
ll, guide_mask:
> > [ @guide_label ] )
> >                       {
> >                               edit_number( name: "Trailing window size =
(Months):" );
> >                               popup(name: "Move computation window", it=
ems: [  {name:
> > "Monthly", value: @monthly}, {name: "Quarterly", value:
> > @quarterly},  {name: "Annually", value: @annually} ]);
> >                               popup(name: "Performance", items: [ {name=
: "In-Sample", value:
> > 1}, {name: "Out-of-sample", value: 2} ]);
> >                               edit_number( name: "Number of computation=
 points:" );
> >                       }
> >
> >                       popup(name: "Currency", items: [ {name: "US-Dolla=
r (USD)",
> > value: @usd}, {name: "Euro (EUR)", value: @eur} ]);
> >
> >               }
> >
> >
> >               column()
> >               {
> >                       group ( name: "Constraints" )
> >                       {
> >                               radio_button( name: "Long only", bind: @c=
onstraint_spec, value:
> > @long );
> >                               row()
> >                               {
> >                                       radio_button( name: "Max % in sho=
rt", bind: @constraint_spec,
> > value: @short );
> >                               }
> >                       }
> >               }
> >
> >       }
> >
> >       separator();
> >
> >
> >       row(child_horizontal: align_right, horizontal: align_fill)
> >       {
> >
> >               button(name: "Ok", default: true, action: @ok, horizontal=
:
> > align_right);
> >               button(name: "Cancel", action: @cancel, horizontal: align=
_right);
> >       }
> >
> > }
>
>
>
> -------------------------------------------------------
> 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
>

Re: asl-users: Re: [Adobe-source-devel] Code formatting

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

Have you checked scintilla/scite? It can handle many tab+indent
combinations and also can use per-directory tab/indent settings.

Niki Spahiev

Re: [Adobe-source-devel] win32 group_window_proc

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

ATL supports message reflection. IIRC it's source is available.

http://msdn.microsoft.com/library/en-us/dnvc60/html/atlwindow.asp?frame=3Dt=
rue#atlwindow_topic11

HTH
Niki Spahiev

Re: [Adobe-source-devel] Handling dates

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

A quick glance at the sources and I see where missing a little bit  
(but not much)...

Internally, Adam operates on adobe::value_t for the values in cells  
(these are similar to boost any - but the type requirements are a bit  
stronger, the type passed to a value_t must be equality comparable  
and if ADOBE_SERIALIZATION is defined then it must support operator  
<< on an ostream. The serialization should go through the Adobe  
formatting code (but that's a loose requirement) -  
ADOBE_SERIALIZATION predates the boost serialization code but it  
isn't complete and although I like some of the ideas better we'll  
likely replace it with boost serialization. For now, it is only used  
for debugging.

The virtual machine has a pair of callbacks for user defined  
functions (one which takes named parameters and hands off a  
dictionary_t, and one that takes unnamed parameters and hands off an  
array_t) -

So all you need to do is write the functions you need for your dates  
in terms if the function interface for the virtual machine - and plug  
it in to the (non-existent but trivial to add) interface to Adam.

Programatically, you can set any value_t into an Adam sheet and it  
will carry through calculations (the type system is open).

I don't yet have operator overloading (working on how you recover an  
"any addable type" from an "any type"). A long term goal is to  
eliminate the dependency tracking in the VM and then the interface to  
Adam will be simple function objects (instead of "byte codes" in an  
array_t).

Sean

On Jan 19, 2006, at 5:36 PM, Thomas Witt wrote:

>
> Hi,
>
> For the prototype I am currently building I need to do date  
> computations in adam. AFAICS I need to be able to convert adam cell  
> values to dates and need to be able to supply a number of  
> operations on dates. Any advice on how to achieve this would be  
> greatly appreciated.
>
> Thanks
>
> Thomas
>
> -- 
> Thomas Witt
> wi...@ac...
>
>
> -------------------------------------------------------
> 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

Re: asl-users: Re: [Adobe-source-devel] Code formatting

[Thomas W. <wi...@ac...>]

Tony,

Tony Van Eerd wrote:
> I've found that a workable rule for tabs is to only allow tabs at the 
> beginning of a line.  ie ONLY for indentation.  ie NOT for aligning 
> #defines, etc.
> 
> Thus, it doesn't matter what tab setting you use, the indents still work.
> 
> If you convert your tabs to spaces, then the spaces have effectively 
> *forced* a tab/indent size upon everyone.  I think that is worse.
> 
> 
> If everyone followed my rule, we'd all be happy.  :-)

I agree ;-). Seriously the problem I was talking about is not so much 
the indentation level but consistency. While I certainly prefer to have 
the right (read my preferred) indent size I can basically live with any 
amount of indentation as long as it is consistent and that's where the 
catch is with tabs. Making sure that you always use tabs in the right 
way is hard (at least to me) if the right way differs on an hourly bases 
when switching projects. It is always easy to spot if you broke 
indentation by adding the wrong amount of spaces. If you add spaces 
instead of tabs (or the other way round) you might not notice but your 
poor colleague using a different tab size will.

I guess my point is that it is easier to maintain consistency when using 
spaces only. It takes one probable cause of annoyance out of the 
collaboration process.

Thomas

-- 
Thomas Witt
wi...@ac...

[Adobe-source-devel] Handling dates

[Thomas W. <wi...@ac...>]

Hi,

For the prototype I am currently building I need to do date computations 
in adam. AFAICS I need to be able to convert adam cell values to dates 
and need to be able to supply a number of operations on dates. Any 
advice on how to achieve this would be greatly appreciated.

Thanks

Thomas

-- 
Thomas Witt
wi...@ac...

Re: asl-users: Re: [Adobe-source-devel] Code formatting

[Tony V. E. <to...@ad...>]

Yeah, I wish there was an editor which handled this.  I hold down space 
bar.  Even in the mixed case, I do <tab><space><space>....column2.

If there was a shortcut key to toggle 'turn tabs into spaces' on and 
off, then it might not be so bad.  ie turn it on when aligning stuff, 
shut it back off when 'coding'.

Actually, I suspect I could do this one way or the other in MSVC at 
least.  hmmm....

Tony Van Eerd
Adobe Waterloo
-via Thunderbird-

Sean Parent wrote:
> Unfortunately none of my editors have such a mode (and I'm not going  to 
> manually align items by holding down the space bar the right  number of 
> times) it also fails in the mixed case:
> 
> <tab>column1<spaces>column2
> <tab>       <tab>   column2
> 
> Sean
> 
> On Jan 19, 2006, at 3:51 PM, Tony Van Eerd wrote:
> 
>> I've found that a workable rule for tabs is to only allow tabs at  the 
>> beginning of a line.  ie ONLY for indentation.  ie NOT for  aligning 
>> #defines, etc.
>>
>> Thus, it doesn't matter what tab setting you use, the indents still  
>> work.
>>
>> If you convert your tabs to spaces, then the spaces have  effectively 
>> *forced* a tab/indent size upon everyone.  I think that  is worse.
>>
>>
>> If everyone followed my rule, we'd all be happy.  :-)  I say that  
>> only half in jest.  ie you could say that (in jest) about almost  any 
>> rule, but in the tab-for-indent-only case, everyone ***still  gets 
>> whatever indent size they like***.  None of the other rules  (fixed 
>> tab size or fixed # of spaces) leaves everyone with their  indent 
>> preference in tack.
>>
>> Tony Van Eerd
>> Adobe Waterloo
>> -via Thunderbird-
>>
>> Sean Parent wrote:
>>
>>> I'm also sending this to the internal Adobe list (so for Adobe  
>>> folks  - there are external people on this list).
>>> The tabs (with a width of 4) is a _long_ time Adobe standard but   
>>> trying several editors it doesn't bother me either way though   
>>> generally I prefer the notion of tabs over spaces.
>>> If detab-ed is the general consensus then we can convert  (probably  
>>> for the next release - we should do it in one swoop).
>>> For if statements - I'm fine with code either way - I tend to  write  
>>> single line and just set the break point in the assembly  view if I  
>>> need to break after the conditional (or loop or  whatever). I'll try  
>>> to remember to split mine up - but since that  isn't just an editor  
>>> setting I'm sure it will take awhile to  train my fingers.
>>> Sean
>>> On Jan 19, 2006, at 2:51 PM, Thomas Witt wrote:
>>>
>>>>
>>>> Hi,
>>>>
>>>> The good news:
>>>>     I am not going to talk about curly braces.
>>>>
>>>> The bad news:
>>>>     I am still going to talk about code formatting.
>>>>
>>>>
>>>> The following issues are things that make my life hard when  
>>>> dealing  with asl code. I bring these up because I think that  there 
>>>> is at  least a chance that the potential benefits from  doing it the 
>>>> way it  is done now don't outweigh the burden it  puts on me and 
>>>> potentially  others working with the code.
>>>>
>>>> Tabs-vs-spaces:
>>>>
>>>> ASL code currently uses TAB's for indentation. While they might   
>>>> work well when working only on a single project. They are a pain  
>>>> if  you work on multiple projects with different conventions at  
>>>> the  same time. It is so much easier to check whether your  
>>>> indentation  level is correct than it is to check whether you  used 
>>>> the right  indentation character. I tried to do this for my  asl 
>>>> work and I am  getting it wrong time and again. Other  opensource 
>>>> projects (eg.  boost) have settled on spaces just  because they are 
>>>> less brittle in  a multiple contributors scenario.
>>>>
>>>> if statements:
>>>>
>>>> Recently I came across a lot of one-line if statements like
>>>>
>>>> if (in_good_mood) do_good();
>>>>
>>>> there are readability arguments about code like this but this is   
>>>> not my issue with that. My problem is that they don't allow me  to  
>>>> easily set breakpoints for the true case in Visual Studio.  You can  
>>>> only do that when do_good() is on its own line. And yes  I hate to  
>>>> format my code according to tool limitation but in the  end tool  
>>>> limitations are a fact of life and we need to get a job  done.
>>>>
>>>> Curly braces:
>>>>
>>>> Just kidding ;-)
>>>>
>>>>
>>>> Thanks for bearing with me. Comments?
>>>>
>>>> Thomas
>>>>
>>>> -- 
>>>> Thomas Witt
>>>> wi...@ac...
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> 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
> 
> 
> 

Re: asl-users: Re: [Adobe-source-devel] Code formatting

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

Unfortunately none of my editors have such a mode (and I'm not going  
to manually align items by holding down the space bar the right  
number of times) it also fails in the mixed case:

<tab>column1<spaces>column2
<tab>       <tab>   column2

Sean

On Jan 19, 2006, at 3:51 PM, Tony Van Eerd wrote:

> I've found that a workable rule for tabs is to only allow tabs at  
> the beginning of a line.  ie ONLY for indentation.  ie NOT for  
> aligning #defines, etc.
>
> Thus, it doesn't matter what tab setting you use, the indents still  
> work.
>
> If you convert your tabs to spaces, then the spaces have  
> effectively *forced* a tab/indent size upon everyone.  I think that  
> is worse.
>
>
> If everyone followed my rule, we'd all be happy.  :-)  I say that  
> only half in jest.  ie you could say that (in jest) about almost  
> any rule, but in the tab-for-indent-only case, everyone ***still  
> gets whatever indent size they like***.  None of the other rules  
> (fixed tab size or fixed # of spaces) leaves everyone with their  
> indent preference in tack.
>
> Tony Van Eerd
> Adobe Waterloo
> -via Thunderbird-
>
> Sean Parent wrote:
>> I'm also sending this to the internal Adobe list (so for Adobe  
>> folks  - there are external people on this list).
>> The tabs (with a width of 4) is a _long_ time Adobe standard but   
>> trying several editors it doesn't bother me either way though   
>> generally I prefer the notion of tabs over spaces.
>> If detab-ed is the general consensus then we can convert  
>> (probably  for the next release - we should do it in one swoop).
>> For if statements - I'm fine with code either way - I tend to  
>> write  single line and just set the break point in the assembly  
>> view if I  need to break after the conditional (or loop or  
>> whatever). I'll try  to remember to split mine up - but since that  
>> isn't just an editor  setting I'm sure it will take awhile to  
>> train my fingers.
>> Sean
>> On Jan 19, 2006, at 2:51 PM, Thomas Witt wrote:
>>>
>>> Hi,
>>>
>>> The good news:
>>>     I am not going to talk about curly braces.
>>>
>>> The bad news:
>>>     I am still going to talk about code formatting.
>>>
>>>
>>> The following issues are things that make my life hard when  
>>> dealing  with asl code. I bring these up because I think that  
>>> there is at  least a chance that the potential benefits from  
>>> doing it the way it  is done now don't outweigh the burden it  
>>> puts on me and potentially  others working with the code.
>>>
>>> Tabs-vs-spaces:
>>>
>>> ASL code currently uses TAB's for indentation. While they might   
>>> work well when working only on a single project. They are a pain  
>>> if  you work on multiple projects with different conventions at  
>>> the  same time. It is so much easier to check whether your  
>>> indentation  level is correct than it is to check whether you  
>>> used the right  indentation character. I tried to do this for my  
>>> asl work and I am  getting it wrong time and again. Other  
>>> opensource projects (eg.  boost) have settled on spaces just  
>>> because they are less brittle in  a multiple contributors scenario.
>>>
>>> if statements:
>>>
>>> Recently I came across a lot of one-line if statements like
>>>
>>> if (in_good_mood) do_good();
>>>
>>> there are readability arguments about code like this but this is   
>>> not my issue with that. My problem is that they don't allow me  
>>> to  easily set breakpoints for the true case in Visual Studio.  
>>> You can  only do that when do_good() is on its own line. And yes  
>>> I hate to  format my code according to tool limitation but in the  
>>> end tool  limitations are a fact of life and we need to get a job  
>>> done.
>>>
>>> Curly braces:
>>>
>>> Just kidding ;-)
>>>
>>>
>>> Thanks for bearing with me. Comments?
>>>
>>> Thomas
>>>
>>> -- 
>>> Thomas Witt
>>> wi...@ac...
>>>
>>>
>>> -------------------------------------------------------
>>> 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

Re: asl-users: Re: [Adobe-source-devel] Code formatting

[Tony V. E. <to...@ad...>]

I've found that a workable rule for tabs is to only allow tabs at the 
beginning of a line.  ie ONLY for indentation.  ie NOT for aligning 
#defines, etc.

Thus, it doesn't matter what tab setting you use, the indents still work.

If you convert your tabs to spaces, then the spaces have effectively 
*forced* a tab/indent size upon everyone.  I think that is worse.


If everyone followed my rule, we'd all be happy.  :-)  I say that only 
half in jest.  ie you could say that (in jest) about almost any rule, 
but in the tab-for-indent-only case, everyone ***still gets whatever 
indent size they like***.  None of the other rules (fixed tab size or 
fixed # of spaces) leaves everyone with their indent preference in tack.

Tony Van Eerd
Adobe Waterloo
-via Thunderbird-

Sean Parent wrote:
> I'm also sending this to the internal Adobe list (so for Adobe folks  - 
> there are external people on this list).
> 
> The tabs (with a width of 4) is a _long_ time Adobe standard but  trying 
> several editors it doesn't bother me either way though  generally I 
> prefer the notion of tabs over spaces.
> 
> If detab-ed is the general consensus then we can convert (probably  for 
> the next release - we should do it in one swoop).
> 
> For if statements - I'm fine with code either way - I tend to write  
> single line and just set the break point in the assembly view if I  need 
> to break after the conditional (or loop or whatever). I'll try  to 
> remember to split mine up - but since that isn't just an editor  setting 
> I'm sure it will take awhile to train my fingers.
> 
> Sean
> 
> On Jan 19, 2006, at 2:51 PM, Thomas Witt wrote:
> 
>>
>> Hi,
>>
>> The good news:
>>     I am not going to talk about curly braces.
>>
>> The bad news:
>>     I am still going to talk about code formatting.
>>
>>
>> The following issues are things that make my life hard when dealing  
>> with asl code. I bring these up because I think that there is at  
>> least a chance that the potential benefits from doing it the way it  
>> is done now don't outweigh the burden it puts on me and potentially  
>> others working with the code.
>>
>> Tabs-vs-spaces:
>>
>> ASL code currently uses TAB's for indentation. While they might  work 
>> well when working only on a single project. They are a pain if  you 
>> work on multiple projects with different conventions at the  same 
>> time. It is so much easier to check whether your indentation  level is 
>> correct than it is to check whether you used the right  indentation 
>> character. I tried to do this for my asl work and I am  getting it 
>> wrong time and again. Other opensource projects (eg.  boost) have 
>> settled on spaces just because they are less brittle in  a multiple 
>> contributors scenario.
>>
>> if statements:
>>
>> Recently I came across a lot of one-line if statements like
>>
>> if (in_good_mood) do_good();
>>
>> there are readability arguments about code like this but this is  not 
>> my issue with that. My problem is that they don't allow me to  easily 
>> set breakpoints for the true case in Visual Studio. You can  only do 
>> that when do_good() is on its own line. And yes I hate to  format my 
>> code according to tool limitation but in the end tool  limitations are 
>> a fact of life and we need to get a job done.
>>
>> Curly braces:
>>
>> Just kidding ;-)
>>
>>
>> Thanks for bearing with me. Comments?
>>
>> Thomas
>>
>> -- 
>> Thomas Witt
>> wi...@ac...
>>
>>
>> -------------------------------------------------------
>> 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
> 
> 
>