RSS Feed

Spec

Suggestions made in the mailing list

On Sat, Oct 13, 2012 at 1:43 AM, Igor Stasenko <[hidden email]> wrote:
> Pavel, since i am potential user of Spec, i would like to know more details.
> I know it takes more time to explain what exactly you don't like and
> propose better alternative,
> instead of just generic "i don't like it".

Well, some points:

- bindings management. Currently if you want to use different
binding/platform, you have to specify it for every single widget. It
doesn't use platform of the parent. Notice that I had to create own
binding even in case I wanted to use smaller font for lists or iconic
buttons.

- bindings extensions. Imagine the situation when you want to use some
special widget in Morphic, let's say some new button type. Currently
you create own binding class. But in case that you will want to use
something different from Morphic (eg. HTML) you are in trouble because
you already used custom binding mechanism for extension of set of the
widgets, not for UI framework independence. Spec should provide a way
how to offer both - UI independence and widgets extensibility (with
fallback mechanism in case that the special widget has no
implementation in the currently used UI - in our case a normal button
would be used).

- layout management. The layout management is taken directly from
Morphic. Imagine you should create a HTML binding. Direct ratios and
size values!!! are used everywhere. Why to specify how thick a bar
with buttons should be? Widgets should know their own optimal size.
Look at our current retina display issues. Flex mechanism from XUL is
quite nice here
(https://developer.mozilla.org/en-US/docs/XUL_Tutorial/Using_Spacers).

- Morphic... look at Nautilus (eg. buildMiddlePlugins message) how
Spec based tool must look now.

[1] http://forum.world.st/Interconnection-of-Morphic-and-Spec-was-ANN-Phobos-td4650812.html

- bindings management. Currently if you want to use different
binding/platform, you have to specify it for every single widget. It
doesn't use platform of the parent. Notice that I had to create own
binding even in case I wanted to use smaller font for lists or iconic
buttons.

Wrong. You specify it when you build a widget, all its subwidgets will use the same bindings.
About the font, it's just because it's not yet supported in Spec, but should be soon.

- bindings extensions. Imagine the situation when you want to use some
special widget in Morphic, let's say some new button type. Currently
you create own binding class. But in case that you will want to use
something different from Morphic (eg. HTML) you are in trouble because
you already used custom binding mechanism for extension of set of the
widgets, not for UI framework independence. Spec should provide a way
how to offer both - UI independence and widgets extensibility (with
fallback mechanism in case that the special widget has no
implementation in the currently used UI - in our case a normal button
would be used).

The use of another framework (like HTML) will not be solved by using the same widgets with another bindings (at least the picture I have in mind, we will see during this summer how it will be resolved).
By the way, the fallback mechanism already exists in bindings. (see on class side). Moreover, if you subclass a bindings class, let's say MorphicBindings, you have your fallback by design.

- layout management. The layout management is taken directly from
Morphic. Imagine you should create a HTML binding. Direct ratios and
size values!!! are used everywhere. Why to specify how thick a bar
with buttons should be? Widgets should know their own optimal size.
Look at our current retina display issues. Flex mechanism from XUL is
quite nice here

The layout management is clearly now an issue, since it's in SpecLayout. It the first issue to tackle right now. For a toolbar it could make sense not specify its size, but for all the other widgets, the size clearly depends of how you want it to be presented. Hard coding the size in the widget would mainly reduce the reusability.

An idea here would be to use the layout to set the "displayBounds" of each widget, and them according to the widget and the framework, transform it. Then at display time, just reuse this "displayBounds".

As I already said, Spec is young, still a lot need to be improved, I am still a student, and Spec had more important issues to be fixed than this right now :(

Hope this summer will be beneficial for Spec :)