Hi Joel, second attempt :-) now based on your code (some things I still do not understand like the LayoutPanel.onLayout() method).
I don't think that layout managers are a bad idea because you don't have to switch the panel widget in order to change the layout (switching panels involves dettaching widgets, and IFRAMEs will be forced to reload on each onLoad()). My second demo expand LayoutPanel and adds support for layout managers. All layout managers are using the Layout class to add layout constraints to the widgets Layer object, and finally Container.layout () method will call super.layout(). Demo: http://69.20.122.77:8880/gwt-layout2/ Code: http://69.20.122.77:8880/gwt-layout2/org.gwt20.mosaic.demo.tbz2 The EntryPoint class looks like this: http://pastebin.com/m49019b8 The highlighted lines shows how easy it is to switch layout managers. Now lets say I want to use "high level" layout hints. I was using Widget.setLayoutData(Object o) so far. But now this is a place where you store all the "low level" layout hints. It would be nice if Layer could be used also for "high level" hints like Region.NORTH, Region.SOUTH, ... for a BorderLayoutManager. So far there is no way to extend Layer. A workaround would be to add a Map to Layer. By the way I like all this new classes and the animation support added to Layout, and try to find a way to use and extend them for gwt- mosaic. The drawbacks of using CSS based layouts is that border and margin CSS attributes (see borders in the demo) will need extra code. Kind Regards, George. On Aug 7, 10:05 pm, Joel Webber <[email protected]> wrote: > George, > This is nice, and I can't think of any reason why it couldn't use the Layout > class I just checked in. In particular, this code won't work on IE6 because > its left/right/top/bottom CSS implementation is hopelessly broken. > > Looking over this, it does remind me why I'm a little uncomfortable with the > idea of decoupling Panels from LayoutManagers: > - It works well for cases like the ones you've implemented here, but it > could become rather more awkward for cases like SplitLayout, TabbedLayout, > StackLayout, and others that require "extra" structure. > - You have to deal with the case when a LayoutManager is changed on an > already-existing panel. Depending upon the manager, this could require a lot > of cleanup, which would be easy to get wrong (you'd probably have to allow > the previous manager to clean up after itself to make this work in general. > - You might be able to mitigate this somewhat by making the LayoutPanel's > manager a construction-time invariant. > > Cheers, > joel. > > On Fri, Aug 7, 2009 at 5:41 AM, ggeorg <[email protected]>wrote: > > > > > Just to keep LayoutPanel class simple with only the required methods > > added to AbsolutePanel widget: > > >http://pastebin.com/m7fc7deb0 > > > I agree, LayoutData should for that purpose. Something like: > > > LayoutPanel.add(Widget w, LayoutData data) should replace > > AbsolutePanel.add(). > > > On Aug 7, 10:42 am, Johan Rydberg <[email protected]> wrote: > > > > I did a very-very simplified layout system based on > > > > top,bottom,left,right,width and height CSS attributes: > > > > >http://69.20.122.77:8880/gwt-layout/ > > > > > So far SimpleLayout, HBoxLayout & VBoxLayout are implemented. > > > > > Source files: > >http://69.20.122.77:8880/gwt-layout/org.gwt20.mosaic.demo.tbz2 > > > > > The EntryPoint class for the demo is:http://pastebin.com/m27e7a4e7 > > > > Nice work as always George, > > > > But why use a widget wrapper to define alignments for a child of the > > > container? I must say I like the idea of passing layout-data to the > > > add() method better. --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
