Yes, the animation extension in Layout class is perfect. Yes 'north' is a widget that should be added in LayoutPanel (DockLayout).
A possible workaround for north.getOffsetHeight() added in this simplified DockLayoutManager demo: http://69.20.122.77:8880/gwt-layout3/ is (but I need to test it, maybe it does not scale): private int[] getPreferredSize(LayoutPanel layoutPanel, Widget w) { int[] prefSize; if (w instanceof HasLayoutManager) { prefSize = ((HasLayoutManager) w).getPreferredSize(); } else { Element clonedElem = w.getElement().cloneNode(true).cast(); layoutPanel.getElement().appendChild(clonedElem); Style style = clonedElem.getStyle(); style.setPosition(Position.STATIC); style.setProperty("width", "auto"); style.setProperty("height", "auto"); prefSize = new int[] { clonedElem.getOffsetWidth(), clonedElem.getOffsetHeight() }; layoutPanel.getElement().removeChild(clonedElem); return prefSize; } return prefSize; } See DockLayoutManager code: http://pastebin.com/m3b757c5a In gwt-mosaic a totally different approach is used, but I am not sure if you are interested about that. About adding extra layout constrains to a widget, I am not sure if Layout.attachChild() helps, since that is used internally by LayoutPanel. For the demo my workaround was to make the DockLayoutManager class abstract and the EntryPoint class looks not very good, see: http://pastebin.com/m244ef110 On Aug 12, 5:56 pm, Joel Webber <[email protected]> wrote: > On Sat, Aug 8, 2009 at 10:27 AM, ggeorg > <[email protected]>wrote: > > > > > > > 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. > > Actually, you can hang an arbitrary object from the Layer by passing it as > the second argument to Layout.attachChild(). The LayoutPanel uses it to > remember which widget is associated with a 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. > > Thanks, and I'm eager to see what use you may be able to make of it. When I > went to implement an animated StackPanel equivalent, I found that it was > actually impossible without building animation into the Layout system, > because the calculations for transitioning among constraint-sets (e.g. > left+width => left+right) can't be easily performed outside of the Layout > class. > > The drawbacks of using CSS based layouts is that border and margin CSS > > > attributes (see borders in the demo) will need extra code. > > Thanks for pointing this out. I actually did a lot of work to ensure that > you could add arbitrary decorations (margins, borders, and padding) to child > elements of a Layout. Which I seem to have screwed up by adding a default > width/height of 100% to children when they're attached. I did this because > it fixed a problem where left/right/top/bottom:0 wasn't enough to make > <table> elements consume the available space in their parent elements. I'll > have to go back to the drawing board on this, but suffice it to say that you > *will* be able to do this when I get this bug fixed :) > > is there a way to get the widget's default width/height? Maybe I do > > > something wrong, but this code > > > layer.setTopHeight(0, Unit.PX, north.getOffsetHeight(), Unit.PX); > > > does not work, returned height is too small. > > I assume 'north' refers to a widget that's added to the LayoutPanel. This > widget will be absolutely positioned, so it's no longer possible to get its > 'natural' size. This is an unavoidable consequence of any > absolutely-positioned layout. The only way around it that I'm aware of is to > try and calculate its natural size by putting it somewhere hidden in the > DOM, measure its size, then put it in the absolute layout. But this can also > get very expensive in practice, because you end up forcing a reflow every > time you do it. > > Also, remember that you have to measure it under essentially the same > width/height constraints it's going to be under when made visible. As an > example, imagine that you're asking for the natural size of a <div> with a > bunch of text in it. You can only correctly ask for its natural height when > its width is constrained, because of text flow. > > I've chosen to stay away from this problem, because it almost invariably > ends up being slower than you'd like, and you can usually choose reasonable > size values in terms of font-relative units such as EMs. For layout on > fine-grained things like form elements, I think it's better to avoid > absolute layouts altogether, using more 'standard' CSS layout. --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
