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 |
Free forum by Nabble | Edit this page |