Joel, this is a very simplified layout system based on: top,bottom,left,right and size CCS attributes. It mimics somehow the existing layout system in gwt-mosaic except of the LayoutData class (layout constraints) which is missing from this implementation. And as you already know it works only on standard mode and not with IE6. ---
Your Layout class is like a wrapper for the widgets and a LayoutData object put together. I am going to use it in the next implementation, just getting familiar with your code (but I have some problems with that class since the wrapper requires border=0px for the child widgets, I did not check for margins so far). About TabbedLayout, SplitLayout and StackLayout this design works very good, see gwt-mosaic demos: http://69.20.122.77/gwt-mosaic/Showcase.html#CwTabLayoutPanel http://69.20.122.77/gwt-mosaic/Showcase.html#CwStackLayoutPanel and for split panel: http://69.20.122.77/gwt-mosaic/Showcase.html#CwBorderLayout In most of the cases they do not require extra code since they rely on the SimpleLayout implementation that renders only the first visible widget. This makes SimpleLayout (or FillLayout in gwt-mosaic) very useful for widgets like DeckLayoutPanel. About switching LayoutManagers the only objects that have to be changed are the LayoutData on each widget (LayoutData <=> Layers without the wrapper) and a call to layout() to render with the new LayoutManager. The LayoutManagers should not keep a list of widgets, they should get the widget list from the LayoutPanel. About the last point, I don't understand you very good :-) I keep trying, is there a demo for the classes you have? 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 -~----------~----~----~----~------~----~------~--~---
