For layout constraints I could use Element.setPropertyObject
("layoutData", ...)Based on that, this is a StackLayoutPanel implementation with a VBoxLayout manager: http://69.20.122.77:8880/gwt-layout4/ The EntryPoint class is: http://pastebin.com/m66abdf1d Code: http://69.20.122.77:8880/gwt-layout4/org.gwt20.mosaic.demo.tbz2 How do you handle not visible widgets (display: none) added to LayoutPanel? In my demo I use: public void setVisible(Widget w, boolean visible) { final Element containerElement = ((Layout.Layer) w.getLayoutData ()).getContainerElement(); if (visible) { containerElement.getStyle().setProperty("display", ""); } else { containerElement.getStyle().setProperty("display", "none"); } w.setVisible(visible); } On Aug 12, 5:56 pm, Joel Webber <j...@google.com> wrote: > On Sat, Aug 8, 2009 at 10:27 AM, ggeorg > <georgopoulos.georg...@gmail.com>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 -~----------~----~----~----~------~----~------~--~---
