Renovating Wrapper: Suggestions

>
> Although I've had occasional trouble with "Wrapper", I don't think
> it's hopelessly lost. It may not be as "modern" as other more current
> frameworks, but I am confident it can be modernized and streamlined
> significantly with relatively moderate effort. I'd like to share some
> considerations that kept my head busy this morning:
>
> 1. Component Builders
>
> I very much enjoy using MenuBuilder due to its clean and simple API.
> Building Wrapper UIs programatically would become fairly easy, if
> there were component builders similar to MenuBuilder. A
> ComponentBuilder could take care of adding layout frames, borders,
> scrollbars, context menus, etc. and provides a linear, easy to
> remember API for that.
>
> The necessary code already exsits. It just needs a convenient
> interface at the component level. In the long term, once the majority
> of applications uses the ComponentBuilder API, the underlying GUI
> implementation could even be replaced without breaking client code
> anymore (a revival of Widgetry?).
>
>        2. Incremental Improvements
>
> There are a number of tasks that can be accomplished incrementally
> over time without affecting client code:
>    - Cleanup or rewrite questionable implementations
>    - Get rid of direct drawing to the screen
>    - Get rid of GC copying where possible
>    - Employ new graphics frameworks that better suit modern platforms
>
>
> 3. SpecWrappers
>
> IMHO, one of the most ad-hoc and disrupting things with Wrapper is the
> inclusion of SpecWrappers in the container chain. While nesting
> layouts, borders, passivity, translation etc. in a container hierarchy
> isn't practically as useful as it should be, it is at least homogene
> and straight on the conceptual level. I would rather like to see spec
> properties attached to (or included with) the widgets directly in some
> form and keep them away from the hierarchy.
>
> Such a major change would of course break some client code in that
> "container container container"-like messages will fail. If the change
> however is well documented, the required "patches" for client code
> should be minimal. The "container container ..." message pattern is
> easily locatable with the rewrite tool.
>
>
> 4. Hierarchy Accessors
>
> Instead of writing "container container container" it would be much
> better to implement generic meaningful accessors like
> #enclosingBorderWrapper, #enclosingSpecs, #enclosingScrollbar, etc.
> that answer the desired component or nil if there is none. This will
> make the code (1) more readable and (2) robust against framework
> redesigns.
>
>
> 5. Documentation
>
> A general revision of the GUI docs would contribute to a better
> accessability of the UI framework a lot.  Me personally, I'd like to
> see GUI docs in the style of an API reference (similar to the Cocoa
> docs).
>
>
> Alltogether, these measures will make living with Wrapper easier and
> remove much of the bemourned clutter at least from the visible API.
>
> Anyone disagree? Objections? Further suggestions?
>
> Andre
>

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> Sent: Monday, September 17, 2007 8:32 AM
> To: vwnc-list
> Subject: Renovating Wrapper: Suggestions
>
>
> Although I've had occasional trouble with "Wrapper", I don't think it's
> hopelessly lost. It may not be as "modern" as other more current
> frameworks, but I am confident it can be modernized and streamlined
> significantly with relatively moderate effort. I'd like to share some
> considerations that kept my head busy this morning:
>
> 1. Component Builders
>
> I very much enjoy using MenuBuilder due to its clean and simple API.
> Building Wrapper UIs programatically would become fairly easy, if there
> were component builders similar to MenuBuilder. A ComponentBuilder could
> take care of adding layout frames, borders, scrollbars, context menus,
> etc. and provides a linear, easy to remember API for that.
>
> The necessary code already exsits. It just needs a convenient interface
> at the component level. In the long term, once the majority of
> applications uses the ComponentBuilder API, the underlying GUI
> implementation could even be replaced without breaking client code
> anymore (a revival of Widgetry?).
>
>
> 2. Incremental Improvements
>
> There are a number of tasks that can be accomplished incrementally over
> time without affecting client code:
>     - Cleanup or rewrite questionable implementations
>     - Get rid of direct drawing to the screen
>     - Get rid of GC copying where possible
>     - Employ new graphics frameworks that better suit modern platforms
>
>
> 3. SpecWrappers
>
> IMHO, one of the most ad-hoc and disrupting things with Wrapper is the
> inclusion of SpecWrappers in the container chain. While nesting layouts,
> borders, passivity, translation etc. in a container hierarchy isn't
> practically as useful as it should be, it is at least homogene and
> straight on the conceptual level. I would rather like to see spec
> properties attached to (or included with) the widgets directly in some
> form and keep them away from the hierarchy.
>
> Such a major change would of course break some client code in that
> "container container container"-like messages will fail. If the change
> however is well documented, the required "patches" for client code
> should be minimal. The "container container ..." message pattern is
> easily locatable with the rewrite tool.
>
>
> 4. Hierarchy Accessors
>
> Instead of writing "container container container" it would be much
> better to implement generic meaningful accessors like
> #enclosingBorderWrapper, #enclosingSpecs, #enclosingScrollbar, etc. that
> answer the desired component or nil if there is none. This will make the
> code (1) more readable and (2) robust against framework redesigns.
>
>
> 5. Documentation
>
> A general revision of the GUI docs would contribute to a better
> accessability of the UI framework a lot.  Me personally, I'd like to see
> GUI docs in the style of an API reference (similar to the Cocoa docs).
>
>
> Alltogether, these measures will make living with Wrapper easier and
> remove much of the bemourned clutter at least from the visible API.
>
> Anyone disagree? Objections? Further suggestions?
>
> Andre