Hi, I don't have the time to quote on all statements so here's just some thoughts on widget hierarchy and stateful layouts:
[...] >>> These properties are available on the widget because they describe >>> the internal state of a widget. It describes how the preferred size >>> of the widget is and how it can be resized. The preferred size of the >>> widget is something, which is important for almost any layout and is >>> a property, which the widget keeps if it is moved from one layout to >>> another. The "left" and "top" property are properties, which relate >>> to the widget's parent and must be evaluated in the context of the parent's layout. >>> >>> In general we used the rule of thumb to put properties in the widget >>> if it is sensible to keep the information if the widget moves from >>> one layout to another. Information, which is specific to a layout is >>> stored in the layout. This makes the widget lighter and reduces the API complexity. >>> >> >> I do not agree to this statement for several reasons. Top and left are >> status infos that belong to the widget itself. Together with width and >> height they specify where the widget wants to be placed in the parent >> container and what area is occupied by it. A layout manager should >> basically be implemented using the strategy pattern. >> This means that it provides algorithms to calculate the position of a >> widget in the parents client area, but does not hold any status >> information at all (except some internal buffers for speeding up the >> calculation maybe). >> >We thought about stateless layout managers in the beginning but soon > realized that some properties have to be managed by the layout manager > itself. Take for example the "spacing" property in box or grid layouts. > How would you map this to a widget property. All layout manager APIs > I looked at (Qt, ATW, SWT) use stateful layout managers. That state what you are talking about is configuration data of the layout algorithm itself and this of course belongs to the layoutmanager. This doesn't change anything about the statement that layout managers work stateless regarding the parent child relation and of course the position of a widget. The widget position is a result of the layout-manager's calculation not a state that belongs to him. Besides this config-state SWT standard layout manager for example work completely stateless. In generel widgets are operating system resources, that know only about parent child relations. Parent widgets provide a client-area with a coordinate-system and child-widgets contain a position to locate themself in that system. That's it - no layout managers at all. Layoutmanagers are a more high-level concept that helps to ease the positioning task. So from that point of view your abstraction seems at least unusual. As I stated at other occasions, we do need good arguments to keep Qooxdoo accepted in the RAP community - because of this it goes further than simply finding a solution for implementating our stuff with the new approach. Ciao Frank ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ qooxdoo-devel mailing list qooxdoo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
