Hello List,
I have a design issue with Desktop and WindowManager in 0.8.3. I have had a quick look at 1.0, and it appears to be the same. Here are two use cases that (IMHO) don't work well in the current design: 1) Implement a Window "Dock" that is visually synchronised with the DeskTop. 2) Allow the user to toggle between various views (including "tabbed", "windowed", "tree" etc.) of n many items. Both of these use cases require essentially the same design; A "model" which manages a collection of content, and several "views" of that content. In the first use case, two views are visible simultaneously. In the second use case, the user toggles between views with only one visible at a time. All of the above is possible, of course -- I have just spent a day getting use case 1 to work. My concern is that this is not elegant with the existing framework because 1) WindowManager and Desktop are tightly coupled, and 2) the seperation of responsibilities between WindowManager and Desktop doesn't seem right. Please enlighten me if I am missing something, but shouldn't the WindowManager be responible for managing a collection of Window instances in memory? Shouldn't the DeskTop be responsible for rendering the desktop view of that collection of windows that WindowManager is managing? I am thinking of a relationship very similar to the one between RadioGroup and RadioButton. As it is, WindowManager doesn't support add or remove or a bunch of other "management" methods -- which are mostly on DeskTop. So if I want to provide my own implementation of WindowManager, it seems I have to go to the trouble of extending or overriding DeskTop too. And since most of the behaviours are actually down in mixins, this isn't exactly nice to do. Conversely, WindowManager is required by IWindowManager to implement updateStack. Surely this method should be the responsibility of DeskTop? Desktop is the rendered widget, and updateStack is all about the rendered z-Order. Why should WindowManager know the details of how one possible view of its windows is rendered? If, for example, I am creating a gallery of windows in a flow layout, there is no reason for my WindowManager to provide an updateStack implementation. So I guess in summary, it seems to me that the Window package could be more elegant to facilitate developers doing more with less effort. I don't expect anyone to do anything about this so soon after the big 1.0, but it would be nice to be able to discuss potential redesign that I might need to do for my app. Any advice or input most welcome, Simon ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
