Smalltalk › Cincom › VisualWorks

conceptual question about UISpec

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

6 messages Options

stephane ducasse-2

conceptual question about UISpec

hi guys

I would like to know how extensible is the VW approach of UISpec (ie using an interpreter of a literal and widgets agnostic order to create a
window) in face of new widgets.

Stef
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Ralph Johnson

Re: conceptual question about UISpec

It has been a long time since I have looked inside the window builder, so my knowledge is rusty. But I often find that a not-very-good answer prompts better answers.

There is a tool that creates specs and a tool that uses them to build windows. The window builder is very extensible; you can make a new widget and then create a new spec for that widget and then the window builder works automatically. However, the screen painter, which is the main tool that creates specs, had to be customized separately. I recall that it took us some time to figure out how to expand it, but that it was expandable, too.

Note that the literal did not specify widgets directly, it specified specs for widgets. In other words, the symbols embedded in the literal were names of spec classes, not widget classes. This added level of indirection is used by the system to account for different look and feels.

On Wed, Nov 3, 2010 at 3:39 AM, stephane ducasse <[hidden email]> wrote:

hi guys

I would like to know how extensible is the VW approach of UISpec (ie using an interpreter of a literal and widgets agnostic order to create a
window) in face of new widgets.

Stef
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

stephane ducasse-2

Re: conceptual question about UISpec

Thanks ralph

> It has been a long time since I have looked inside the window builder, so my knowledge is rusty. But I often find that a not-very-good answer prompts better answers.
>
> There is a tool that creates specs and a tool that uses them to build windows. The window builder is very extensible; you can make a new widget and then create a new spec for that widget and then the window builder works automatically.

I imagine that this is because there is a basic vocabulary based on which the other can be expressed.
Now I was thinking can we add accordion widgte for example, if we originally only have button, combobox, radio and list....
This is the kind of questions I have.

> However, the screen painter, which is the main tool that creates specs, had to be customized separately. I recall that it took us some time to figure out how to expand it, but that it was expandable, too.
>
> Note that the literal did not specify widgets directly, it specified specs for widgets. In other words, the symbols embedded in the literal were names of spec classes, not widget classes. This added level of indirection is used by the system to account for different look and feels.

yes this last point is important.

> On Wed, Nov 3, 2010 at 3:39 AM, stephane ducasse <[hidden email]> wrote:
> hi guys
>
> I would like to know how extensible is the VW approach of UISpec (ie using an interpreter of a literal and widgets agnostic order to create a
> window) in face of new widgets.
>
> Stef
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Dave Stevenson-3

Re: conceptual question about UISpec

Once I understood the points Ralph made, I found it a reasonable effort to add new widgets and extend existing widgets and specs.

One application I wrote is a dynamic form generator for end users. The editor uses HotDraw to allow the end user to drop certain types of specs onto a drawing (InputFieldSpec, BuyButtonSpec, LineSegmentSpec, ImageSpec, LabelSpec, RegionSpec, TextEditorSpec), and save the form to the database. The string representation of each literal spec is saved as a varchar record. This scheme was vastly more flexible than the older system, which had relational fields for spec attributes. In particular, a spec's properties dictionary means I could store whatever I want. Each read-only spec has attributes (tab-order, for example), and the writable ones (input fields, buy buttons, text editors) have a datum number. In production, the widgets are displayed in a subcanvas (not a HotDraw drawing), the users fill in forms as needed, and each completion of a form saves the data as a set.

Dave Stevenson
[hidden email]

From: stephane ducasse <[hidden email]>
To: Ralph Johnson <[hidden email]>
Cc: vwnc nc <[hidden email]>
Sent: Wed, November 3, 2010 5:44:57 AM
Subject: Re: [vwnc] conceptual question about UISpec

Thanks ralph

> It has been a long time since I have looked inside the window builder, so my knowledge is rusty. But I often find that a not-very-good answer prompts better answers.
>
> There is a tool that creates specs and a tool that uses them to build windows. The window builder is very extensible; you can make a new widget and then create a new spec for that widget and then the window builder works automatically.

I imagine that this is because there is a basic vocabulary based on which the other can be expressed.
Now I was thinking can we add accordion widgte for example, if we originally only have button, combobox, radio and list....
This is the kind of questions I have.

> However, the screen painter, which is the main tool that creates specs, had to be customized separately. I recall that it took us some time to figure out how to expand it, but that it was expandable, too.
>
> Note that the literal did not specify widgets directly, it specified specs for widgets. In other words, the symbols embedded in the literal were names of spec classes, not widget classes. This added level of indirection is used by the system to account for different look and feels.

yes this last point is important.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Holger Kleinsorgen-4

Re: conceptual question about UISpec

In reply to this post by stephane ducasse-2

The good parts:

- it's still Smalltalk-ish enough (Symbols, bindings), so
renaming/browsing works

The bad parts:

- the UI code that creates a look-specific widget from a specification
is a good example of how *not* to do it. Quite often it forces
developers of widgets/look policies to copy large amount of code.

Examples: compare

UILookPolicy>>checkBox:into: and UILookPolicy>>radioButton:into:
UILookPolicy>>progress:into: and MacOSXLookPolicy>>progress:into:

and spot the differences

- building specs programmatically is a bit difficult, especially with
regard to the layout of the created spec

Am 03.11.2010 09:39, schrieb stephane ducasse:
> I would like to know how extensible is the VW approach of UISpec (ie
> using an interpreter of a literal and widgets agnostic order to create a
> window) in face of new widgets.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

stephane ducasse-2

Re: conceptual question about UISpec

Thanks!

Stef

On Nov 3, 2010, at 4:07 PM, Holger Kleinsorgen wrote:

> The good parts:
>
> - it's still Smalltalk-ish enough (Symbols, bindings), so
> renaming/browsing works
>
> The bad parts:
>
> - the UI code that creates a look-specific widget from a specification
> is a good example of how *not* to do it. Quite often it forces
> developers of widgets/look policies to copy large amount of code.
>
> Examples: compare
>
> UILookPolicy>>checkBox:into: and UILookPolicy>>radioButton:into:
> UILookPolicy>>progress:into: and MacOSXLookPolicy>>progress:into:
>
> and spot the differences
>
> - building specs programmatically is a bit difficult, especially with
> regard to the layout of the created spec
>
> Am 03.11.2010 09:39, schrieb stephane ducasse:
>> I would like to know how extensible is the VW approach of UISpec (ie
>> using an interpreter of a literal and widgets agnostic order to create a
>> window) in face of new widgets.
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc