FogBugz (Case [Issue]10386) Spec - Spec Suggestions

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

FogBugz (Case [Issue]10386) Spec - Spec Suggestions

Pharo Issue Tracker
A FogBugz case was edited by Benjamin Van Ryseghem.

Case ID:      10386
Title:        Spec Suggestions
Status:       Work Needed
Category:     Enhancement
Project:      Spec
Area:         Misc
Priority:     3 - Must Fix
Milestone:    Pharo3.0: 29/04/2013
Assigned To:  Benjamin Van Ryseghem

URL:          https://pharo.fogbugz.com/default.asp?10386


Changes:
Image Version changed from (No Value) to 'Pharo3.0'

- 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 :)


You are subscribed to this case.  If you do not want to receive automatic notifications in the future, unsubscribe (https://pharo.fogbugz.com/default.asp?pre=preUnsubscribe&pg=pgEditBug&command=view&ixBug=10386) from this case.

_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker