[gwt-contrib] Re: Initial implementation of layout system, along with the first two layout widgets.
Looks good. A couple of nitpicks, and I want to see it in action, but no problems so far. http://gwt-code-reviews.appspot.com/51830/diff/1/2 File layout/Layout.gwt.xml (right): http://gwt-code-reviews.appspot.com/51830/diff/1/2#newcode17 Line 17: Fix indent spacing http://gwt-code-reviews.appspot.com/51830/diff/1/2#newcode19 Line 19: Fix indent spacing http://gwt-code-reviews.appspot.com/51830/diff/1/5 File layout/client/Layout.java (right): http://gwt-code-reviews.appspot.com/51830/diff/1/5#newcode68 Line 68: * This code should be moved to the examples directory. http://gwt-code-reviews.appspot.com/51830/diff/1/5#newcode102 Line 102: * warning. Use at your own risk. Do we need a TODO to remove this when we release? Or are we going to change the layout after we release? http://gwt-code-reviews.appspot.com/51830/diff/1/5#newcode154 Line 154: Object userData; Should this be a parameterized type? http://gwt-code-reviews.appspot.com/51830/diff/1/5#newcode177 Line 177: * This is the element that sits between the parent and child elements. It typo - "It is normally", not "It normally" http://gwt-code-reviews.appspot.com/51830/diff/1/3 File layout/client/LayoutImpl.java (right): http://gwt-code-reviews.appspot.com/51830/diff/1/3#newcode2 Line 2: * Copyright 2008 Google Inc. 2009 http://gwt-code-reviews.appspot.com/51830/diff/1/4 File layout/client/LayoutImplIE6.java (right): http://gwt-code-reviews.appspot.com/51830/diff/1/4#newcode2 Line 2: * Copyright 2008 Google Inc. 2009 http://gwt-code-reviews.appspot.com/51830/diff/1/11 File user/client/ui/LayoutPanel.java (right): http://gwt-code-reviews.appspot.com/51830/diff/1/11#newcode41 Line 41: * // Attach two child widgets, laying them out horizontally, splitting at 50%. This code should be moved to the examples directory. http://gwt-code-reviews.appspot.com/51830/diff/1/11#newcode142 Line 142: assert child.getParent() == this : "TODO"; You should put a message here http://gwt-code-reviews.appspot.com/51830/diff/1/12 File user/client/ui/RootLayoutPanel.java (right): http://gwt-code-reviews.appspot.com/51830/diff/1/12#newcode48 Line 48: * // Attaches a pair of widgets to the RootLayoutPanel Move to examples directory http://gwt-code-reviews.appspot.com/51830 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Initial implementation of layout system, along with the first two layout widgets.
This work is really awesome Joel. I know that the code stills at early stage but if I can give you a first feedback ... -> Using CSS positioning is really a nice idea, I definitively buy it. -> I have always been dubious about how GWT mix the concept of Layout and the concept of Panel. If we take a look at Swing/AWT or Windows Forms/WPF, layout are clearly separated from Panels (sure DOM doesn't help to do that). wouldn't it be better to do : DockLayout dl = new DockLayout(constraints) SimplePanel sp = new SimplePanel(); sp.setLayout(dl); Instead of : DockPanel d = new DockPanel(); -> In the modified Widget class, I'm not a big fan of the circular reference between layer and widget in the add(widget) method : // Physical attach. Layer layer = layout.attachChild(widget.getElement()); layer.setUserData(widget); widget.setLayoutData(layer); I understand that widget class should know the nature of the layout constraints, but there are probably too much concepts, UserData, LayoutData, etc ... a bit confusing You have also layout.attach() and layout.layout() and layout.attachChild() ... also a bit confusing, we have to dig into the source code to really understand that layout.attach() is about mem leak and layout.layout() updates the layout children -> I have tried to mix LayoutPanel and Panels that don't hold any positioning styles (HorizontalPanels, FlexTable, TabPanel, ...). The way you inject positioning attributes on any div element with attachChild() is really cool. Please correct me if I'm wrong but say that you want to add a FlexTable to an already attached parent, one have to write : LayoutPanel leftTopLayout = new LayoutPanel() leftTopLayout.add(tableHorizPanel); // This a normal HorizontalPanel we wrap it with a Layout // Want to inject a basic table div // We should be able to get the parent underlying layout created previously instead of re-creating a new one Layout layout = new Layout(tableHorizPanel.getElement()); layout.attachChild(myflexTable.getElement()); tableHorizPanel.add(myflexTable); We have to DOM add and Layout attach, don't you find the code redundant ? -> and this would be my last remark ;-) The following demo doesn't run in a consistent manner across all the browsers, the page is in standards mode, you will find a link pointing to the source code. http://www.dng-consulting.com/blogs/media/users/sami/demogwt/MyGWTDemo.html Hope this helps, Sami On Mon, Aug 3, 2009 at 10:14 PM, wrote: > > Looks good. A couple of nitpicks, and I want to see it in action, but > no problems so far. > > > http://gwt-code-reviews.appspot.com/51830/diff/1/2 > File layout/Layout.gwt.xml (right): > > http://gwt-code-reviews.appspot.com/51830/diff/1/2#newcode17 > Line 17: > Fix indent spacing > > http://gwt-code-reviews.appspot.com/51830/diff/1/2#newcode19 > Line 19: > Fix indent spacing > > http://gwt-code-reviews.appspot.com/51830/diff/1/5 > File layout/client/Layout.java (right): > > http://gwt-code-reviews.appspot.com/51830/diff/1/5#newcode68 > Line 68: * > This code should be moved to the examples directory. > > http://gwt-code-reviews.appspot.com/51830/diff/1/5#newcode102 > Line 102: * warning. Use at your own risk. > Do we need a TODO to remove this when we release? Or are we going to > change the layout after we release? > > http://gwt-code-reviews.appspot.com/51830/diff/1/5#newcode154 > Line 154: Object userData; > Should this be a parameterized type? > > http://gwt-code-reviews.appspot.com/51830/diff/1/5#newcode177 > Line 177: * This is the element that sits between the parent and child > elements. It > typo - "It is normally", not "It normally" > > http://gwt-code-reviews.appspot.com/51830/diff/1/3 > File layout/client/LayoutImpl.java (right): > > http://gwt-code-reviews.appspot.com/51830/diff/1/3#newcode2 > Line 2: * Copyright 2008 Google Inc. > 2009 > > http://gwt-code-reviews.appspot.com/51830/diff/1/4 > File layout/client/LayoutImplIE6.java (right): > > http://gwt-code-reviews.appspot.com/51830/diff/1/4#newcode2 > Line 2: * Copyright 2008 Google Inc. > 2009 > > http://gwt-code-reviews.appspot.com/51830/diff/1/11 > File user/client/ui/LayoutPanel.java (right): > > http://gwt-code-reviews.appspot.com/51830/diff/1/11#newcode41 > Line 41: * // Attach two child widgets, laying them out horizontally, > splitting at 50%. > This code should be moved to the examples directory. > > http://gwt-code-reviews.appspot.com/51830/diff/1/11#newcode142 > Line 142: assert child.getParent() == this : "TODO"; > You should put a message here > > http://gwt-code-reviews.appspot.com/51830/diff/1/12 > File user/client/ui/RootLayoutPanel.java (right): > > http://gwt-code-reviews.appspot.com/51830/diff/1/12#newcode48 > Line 48: * // Attaches a pair of widgets to the RootLayoutPanel > Move to examples directory > > http://gwt-code-reviews.appspot.com/51830 > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~
[gwt-contrib] Re: Initial implementation of layout system, along with the first two layout widgets.
http://gwt-code-reviews.appspot.com/51830/diff/1/3 File layout/client/LayoutImpl.java (right): http://gwt-code-reviews.appspot.com/51830/diff/1/3#newcode116 Line 116: return fixedRuler.getOffsetWidth() / 2.36; Aren't these numbers subject to change based on display resolution? http://gwt-code-reviews.appspot.com/51830 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Initial implementation of layout system, along with the first two layout widgets.
On Tue, Aug 4, 2009 at 11:00 AM, Sami Jaber wrote: > This work is really awesome Joel. > I know that the code stills at early stage but if I can give you a first > feedback ... > Glad to have all the feedback I can get. Better now than later :) -> Using CSS positioning is really a nice idea, I definitively buy it. > -> I have always been dubious about how GWT mix the concept of Layout and > the concept of Panel. If we take a look at Swing/AWT or Windows Forms/WPF, > layout are clearly separated from Panels (sure DOM doesn't help to do that). > > > wouldn't it be better to do : > DockLayout dl = new DockLayout(constraints) > SimplePanel sp = new SimplePanel(); > sp.setLayout(dl); > > Instead of : > DockPanel d = new DockPanel(); > We considered doing something like this originally, and I think it's the right approach for Swing/SWT. However, when you have to implement these layouts in terms of the HTML DOM, the Layout that you choose for a panel can have a huge effect on the DOM structure you have to create, affecting pretty much every method, so that the common "Panel" class ends up being nothing but a simple façade for its associated Layout. To make matters worse, it's damned near impossible to change a panel's layout after it's constructed, because it forces you to reconstruct the entire DOM. -> In the modified Widget class, I'm not a big fan of the circular reference > between layer and widget in the add(widget) method : > > // Physical attach. > Layer layer = layout.attachChild(widget.getElement()); > layer.setUserData(widget); > widget.setLayoutData(layer); > > I understand that widget class should know the nature of the layout > constraints, but there are probably too much concepts, UserData, LayoutData, > etc ... a bit confusing > LayoutData has always been there, but it was just package-protected. The doc states explicitly that it may only be used by the panel that owns the widget, and it really does help avoid lots of extra maps, which can get pretty expensive. The userData on Layer should probably have been called userObject (like in TreeItem), and I should have made it invariant rather than having a setter (the next patch will include this change). I admit it's a bit odd, but the "user data" pattern (to the extent one can call it a pattern) can really make things a lot easier in this case. It's also worth pointing out that most users won't really be exposed to Layer.userObject, since they'll mostly be using panels and widgets. You have also layout.attach() and layout.layout() and layout.attachChild() > ... also a bit confusing, we have to dig into the source code to really > understand that layout.attach() is about mem leak and layout.layout() > updates the layout children > I'm not a huge fan of attach() and detach() either, now that I think of it (actually, I *really* wish I could get rid of them, but this appears to be impossible because of requirements imposed by the IE6 implementation). What about calling them something like onElement[De A]ttached()? Would that make it a bit clearer? -> I have tried to mix LayoutPanel and Panels that don't hold any > positioning styles (HorizontalPanels, FlexTable, TabPanel, ...). The way you > inject positioning attributes on any div element with attachChild() is > really cool. Please correct me if I'm wrong but say that you want to add a > FlexTable to an already attached parent, one have to write : > > LayoutPanel leftTopLayout = new LayoutPanel() > leftTopLayout.add(tableHorizPanel); // This a normal HorizontalPanel we > wrap it with a Layout > > // Want to inject a basic table div > // We should be able to get the parent underlying layout created previously > instead of re-creating a new one > Layout layout = new Layout(tableHorizPanel.getElement()); > layout.attachChild(myflexTable.getElement()); > tableHorizPanel.add(myflexTable); > > We have to DOM add and Layout attach, don't you find the code redundant ? > Actually, if you're using a LayoutPanel (or similar widget, more are on their way, such as DockLayoutPanel, StackLayoutPanel, and the like), you shouldn't ever have to use the Layout class directly. The above code could simply be: LayoutPanel leftTopLayout = new LayoutPanel(); leftTopLayout.add(tableHorizPanel); Layer layer = leftTopLayout.getLayer(tableHorizPanel); layer.setLeftRight(...); layer.setTopBottom(...); leftTopLayout.layout(); Does that make sense? I would prefer to modify add() to return the Layer directly, but it's inherited from HasWidgets (unfortunately, it was a bad idea to have add() there in the first place, but it's too late to fix now). -> and this would be my last remark ;-) > The following demo doesn't run in a consistent manner across all the > browsers, the page is in standards mode, you will find a link pointing to > the source code. > > http://www.dng-consulting.com/blogs/media/users/sami/demogwt/MyGWTDemo.html > I haven't gone through this code completely, but at first glance it appears t
[gwt-contrib] Re: Initial implementation of layout system, along with the first two layout widgets.
The next patch set will also contain the following changes: - HasLayout has become RequiresLayout and ProvidesLayout (just a tag interface). The original design conflated the concepts of "This method (layout) needs to be called whenever you update any of my childrens' layers" and "This widget needs to be informed whenever its size changes". - For the above reason, it is now necessary to call layout() explicitly when childrens' layers are updated, even on RootLayoutPanel. - Layer.userData (now userObject) has been made invariant. http://gwt-code-reviews.appspot.com/51830/diff/1/2 File layout/Layout.gwt.xml (right): http://gwt-code-reviews.appspot.com/51830/diff/1/2#newcode17 Line 17: On 2009/08/03 20:14:01, jlabanca wrote: > Fix indent spacing Done. http://gwt-code-reviews.appspot.com/51830/diff/1/2#newcode19 Line 19: On 2009/08/03 20:14:01, jlabanca wrote: > Fix indent spacing Done. http://gwt-code-reviews.appspot.com/51830/diff/1/5 File layout/client/Layout.java (right): http://gwt-code-reviews.appspot.com/51830/diff/1/5#newcode68 Line 68: * On 2009/08/03 20:14:01, jlabanca wrote: > This code should be moved to the examples directory. Done. http://gwt-code-reviews.appspot.com/51830/diff/1/5#newcode102 Line 102: * warning. Use at your own risk. On 2009/08/03 20:14:01, jlabanca wrote: > Do we need a TODO to remove this when we release? Or are we going to change the > layout after we release? I've got a personal TODO to come back and clean all these up when we release. http://gwt-code-reviews.appspot.com/51830/diff/1/5#newcode154 Line 154: Object userData; On 2009/08/03 20:14:01, jlabanca wrote: > Should this be a parameterized type? Not really. It's up to the user to decide what they need to put there, and it could be heterogeneous. And we'd have to put the type parameter on the Layout class, which would be kind of weird and hard to fathom, I think. http://gwt-code-reviews.appspot.com/51830/diff/1/5#newcode177 Line 177: * This is the element that sits between the parent and child elements. It On 2009/08/03 20:14:01, jlabanca wrote: > typo - "It is normally", not "It normally" Done. http://gwt-code-reviews.appspot.com/51830/diff/1/3 File layout/client/LayoutImpl.java (right): http://gwt-code-reviews.appspot.com/51830/diff/1/3#newcode2 Line 2: * Copyright 2008 Google Inc. On 2009/08/03 20:14:01, jlabanca wrote: > 2009 Done. http://gwt-code-reviews.appspot.com/51830/diff/1/3#newcode112 Line 112: return fixedRuler.getOffsetWidth() * 2.54; Whoops, * is a typo. Should be /. Fixed by changing all operators to / for clarity. http://gwt-code-reviews.appspot.com/51830/diff/1/3#newcode116 Line 116: return fixedRuler.getOffsetWidth() / 2.36; On 2009/08/04 15:43:56, bobv wrote: > Aren't these numbers subject to change based on display resolution? Ha, nope! The shared fixedRuler element is precisely 1 in in size. All of these other measurements can be derived from an "inch" with a known ratio. I picked inch because it's the largest available unit, and thus the least susceptible to aliasing (when converted to integral pixels). http://gwt-code-reviews.appspot.com/51830/diff/1/4 File layout/client/LayoutImplIE6.java (right): http://gwt-code-reviews.appspot.com/51830/diff/1/4#newcode2 Line 2: * Copyright 2008 Google Inc. On 2009/08/03 20:14:01, jlabanca wrote: > 2009 Done. http://gwt-code-reviews.appspot.com/51830/diff/1/11 File user/client/ui/LayoutPanel.java (right): http://gwt-code-reviews.appspot.com/51830/diff/1/11#newcode41 Line 41: * // Attach two child widgets, laying them out horizontally, splitting at 50%. On 2009/08/03 20:14:01, jlabanca wrote: > This code should be moved to the examples directory. Done. http://gwt-code-reviews.appspot.com/51830/diff/1/11#newcode142 Line 142: assert child.getParent() == this : "TODO"; On 2009/08/03 20:14:01, jlabanca wrote: > You should put a message here Done. http://gwt-code-reviews.appspot.com/51830/diff/1/12 File user/client/ui/RootLayoutPanel.java (right): http://gwt-code-reviews.appspot.com/51830/diff/1/12#newcode48 Line 48: * // Attaches a pair of widgets to the RootLayoutPanel On 2009/08/03 20:14:01, jlabanca wrote: > Move to examples directory Done. http://gwt-code-reviews.appspot.com/51830 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Initial implementation of layout system, along with the first two layout widgets.
http://gwt-code-reviews.appspot.com/51830 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Initial implementation of layout system, along with the first two layout widgets.
On 2009/08/04 16:16:59, jgw wrote: > The next patch set will also contain the following changes: > - HasLayout has become RequiresLayout and ProvidesLayout (just a tag interface). > The original design conflated the concepts of "This method (layout) needs to be > called whenever you update any of my childrens' layers" and "This widget needs > to be informed whenever its size changes". > - For the above reason, it is now necessary to call layout() explicitly when > childrens' layers are updated, even on RootLayoutPanel. > - Layer.userData (now userObject) has been made invariant. > http://gwt-code-reviews.appspot.com/51830/diff/1/2 > File layout/Layout.gwt.xml (right): > http://gwt-code-reviews.appspot.com/51830/diff/1/2#newcode17 > Line 17: > On 2009/08/03 20:14:01, jlabanca wrote: > > Fix indent spacing > Done. > http://gwt-code-reviews.appspot.com/51830/diff/1/2#newcode19 > Line 19: > On 2009/08/03 20:14:01, jlabanca wrote: > > Fix indent spacing > Done. > http://gwt-code-reviews.appspot.com/51830/diff/1/5 > File layout/client/Layout.java (right): > http://gwt-code-reviews.appspot.com/51830/diff/1/5#newcode68 > Line 68: * > On 2009/08/03 20:14:01, jlabanca wrote: > > This code should be moved to the examples directory. > Done. > http://gwt-code-reviews.appspot.com/51830/diff/1/5#newcode102 > Line 102: * warning. Use at your own risk. > On 2009/08/03 20:14:01, jlabanca wrote: > > Do we need a TODO to remove this when we release? Or are we going to change > the > > layout after we release? > I've got a personal TODO to come back and clean all these up when we release. > http://gwt-code-reviews.appspot.com/51830/diff/1/5#newcode154 > Line 154: Object userData; > On 2009/08/03 20:14:01, jlabanca wrote: > > Should this be a parameterized type? > Not really. It's up to the user to decide what they need to put there, and it > could be heterogeneous. And we'd have to put the type parameter on the Layout > class, which would be kind of weird and hard to fathom, I think. > http://gwt-code-reviews.appspot.com/51830/diff/1/5#newcode177 > Line 177: * This is the element that sits between the parent and child elements. > It > On 2009/08/03 20:14:01, jlabanca wrote: > > typo - "It is normally", not "It normally" > Done. > http://gwt-code-reviews.appspot.com/51830/diff/1/3 > File layout/client/LayoutImpl.java (right): > http://gwt-code-reviews.appspot.com/51830/diff/1/3#newcode2 > Line 2: * Copyright 2008 Google Inc. > On 2009/08/03 20:14:01, jlabanca wrote: > > 2009 > Done. > http://gwt-code-reviews.appspot.com/51830/diff/1/3#newcode112 > Line 112: return fixedRuler.getOffsetWidth() * 2.54; > Whoops, * is a typo. Should be /. Fixed by changing all operators to / for > clarity. > http://gwt-code-reviews.appspot.com/51830/diff/1/3#newcode116 > Line 116: return fixedRuler.getOffsetWidth() / 2.36; > On 2009/08/04 15:43:56, bobv wrote: > > Aren't these numbers subject to change based on display resolution? > Ha, nope! The shared fixedRuler element is precisely 1 in in size. All of these > other measurements can be derived from an "inch" with a known ratio. I picked > inch because it's the largest available unit, and thus the least susceptible to > aliasing (when converted to integral pixels). > http://gwt-code-reviews.appspot.com/51830/diff/1/4 > File layout/client/LayoutImplIE6.java (right): > http://gwt-code-reviews.appspot.com/51830/diff/1/4#newcode2 > Line 2: * Copyright 2008 Google Inc. > On 2009/08/03 20:14:01, jlabanca wrote: > > 2009 > Done. > http://gwt-code-reviews.appspot.com/51830/diff/1/11 > File user/client/ui/LayoutPanel.java (right): > http://gwt-code-reviews.appspot.com/51830/diff/1/11#newcode41 > Line 41: * // Attach two child widgets, laying them out horizontally, splitting > at 50%. > On 2009/08/03 20:14:01, jlabanca wrote: > > This code should be moved to the examples directory. > Done. > http://gwt-code-reviews.appspot.com/51830/diff/1/11#newcode142 > Line 142: assert child.getParent() == this : "TODO"; > On 2009/08/03 20:14:01, jlabanca wrote: > > You should put a message here > Done. > http://gwt-code-reviews.appspot.com/51830/diff/1/12 > File user/client/ui/RootLayoutPanel.java (right): > http://gwt-code-reviews.appspot.com/51830/diff/1/12#newcode48 > Line 48: * // Attaches a pair of widgets to the RootLayoutPanel > On 2009/08/03 20:14:01, jlabanca wrote: > > Move to examples directory > Done. I also forgot to add that I removed HasAnimatedLayout altogether, and changed both animate() methods to simply be layout(), which now has three overloads, since they all ultimately do the same thing in slightly different ways. http://gwt-code-reviews.appspot.com/51830 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Initial implementation of layout system, along with the first two layout widgets.
A couple minor notes.
http://gwt-code-reviews.appspot.com/51830/diff/2003/2004
File user/javadoc/com/google/gwt/examples/LayoutPanelExample.java
(right):
http://gwt-code-reviews.appspot.com/51830/diff/2003/2004#newcode32
Line 32: Widget childOne = new HTML(), childTwo = new HTML();
You should add some text to these HTML widgets so that if somebody uses
the example they will actually see childOne and childTwo.
http://gwt-code-reviews.appspot.com/51830/diff/2003/2010
File user/src/com/google/gwt/layout/client/Layout.java (right):
http://gwt-code-reviews.appspot.com/51830/diff/2003/2010#newcode302
Line 302: public void animate(int duration) {
Didn't we agree that this would become layout(int duration)? I see that
we now have LayoutPanel#layout(int), but why not here?
http://gwt-code-reviews.appspot.com/51830/diff/2003/2010#newcode313
Line 313: public void animate(int duration, final AnimationCallback
callback) {
And this would be layout(int duration, final AnimationCallback
callback)?
http://gwt-code-reviews.appspot.com/51830/diff/2003/2014
File user/src/com/google/gwt/user/client/ui/ProvidesLayout.java (right):
http://gwt-code-reviews.appspot.com/51830/diff/2003/2014#newcode29
Line 29: * public void onLayout() {
Can we move this to a static helper method in this interface to avoid
code duplication? It could take an Iterator and look for instances
of RequiresLayout.
http://gwt-code-reviews.appspot.com/51830/diff/2003/2006
File user/test/com/google/gwt/layout/client/LayoutTest.java (right):
http://gwt-code-reviews.appspot.com/51830/diff/2003/2006#newcode57
Line 57: return "com.google.gwt.layout.Layout";
Should be com.google.gwt.layout.LayoutTest
http://gwt-code-reviews.appspot.com/51830
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Initial implementation of layout system, along with the first two layout widgets.
> We considered doing something like this originally, and I think it's the
> right approach for Swing/SWT. However, when you have to implement these
> layouts in (...) impossible to change a panel's layout after it's
> constructed, because it forces you to reconstruct the entire DOM.
>
I understand, It could be interesting to have a look at how GXT guys have
solved this pb, I guess they have this separation between
XXLayout/ContentPanel
LayoutData has always been there, but it was just package-protected. The doc
> states explicitly that it may only be used by the panel that owns the
> widget, and it really does help avoid lots of extra maps, which can get
> pretty expensive. The userData on Layer should probably have been called
> userObject (like in TreeItem), and I should have made it invariant rather
> than having a setter (the next patch will include this change). I admit it's
> a bit odd, but the "user data" pattern (to the extent one can call it a
> pattern) can really make things a lot easier in this case. It's also worth
> pointing out that most users won't really be exposed to Layer.userObject,
> since they'll mostly be using panels and widgets.
>
Ok I understand.
>
> I'm not a huge fan of attach() and detach() either, now that I think of it
> (actually, I *really* wish I could get rid of them, but this appears to be
> impossible because of requirements imposed by the IE6 implementation). What
> about calling them something like onElement[De A]ttached()? Would that make
> it a bit clearer?
>
That would definitively be better names
>
> Actually, if you're using a LayoutPanel (or similar widget, more are on
> their way, such as DockLayoutPanel, StackLayoutPanel, and the like), you
> shouldn't ever have to use the Layout class directly. The above code could
> simply be:
>
> Does that make sense? I would prefer to modify add() to return the Layer
> directly, but it's inherited from HasWidgets (unfortunately, it was a bad
> idea to have add() there in the first place, but it's too late to fix now).
>
Yes, that's right. That said, I would have probably chosen a name like
"LayerConstraints" instead of "Layer" because of the specific nature of the
data passed to attachChild
> explicitly). The RootLayoutPanel is meant to solve this problem in a pretty
> simple way -- please let me know if it's not sufficient for some reason I'm
> not seeing.
>
That's it. I have replaced RootPanel by RootLayoutPanel and things are
better. I still have the problem to find an equivalent of
RootPanel.get("slotId").
As it is designed, that seems difficult. Does it mean that embedding
LayoutPanel in an existing DOM will be forbidden by design ? I don't see how
you could infer the existing raw HTML to add all the layout data stuff
> Also, I can't quite follow all the logic here, but do remember that you
> have to explicitly call layout() on these LayoutPanel (and RootLayoutPanel)
> instances once all the children are added and their layers' constraints set.
> Once I get the patch updated to take this (and other) feedback into account,
> I'll have a deeper look at the code to provide a simple example that I
> believe captures what it's trying to do.
>
Ok great
> I realize it's probably not immediately obvious quite how all these classes
> fit together, so please let me know if you have any ideas on how I can make
> it clearer. Once it's all done, we'll be updating the samples, which should
> help, but I'm open to other ideas as well.
>
With those explanations, things are clearer. That said, I still have a
problem with my previous sample. I have updated it to reflect the changes
you made in LayoutPanelExample and I want to be sure I didn't make any
mistake. Here is a small snippet
//HorizontalPanel hp = new HorizontalPanel();
LayoutPanel hp = new LayoutPanel();
Widget childOne = hp, childTwo = getTabPanel();
FlexTable ft = getTable() ;
hp.add(ft);
hp.layout();
childOne.setStyleName("red");
childTwo.setStyleName("yellow");
LayoutPanel p = new LayoutPanel();
p.add(childOne);
p.add(childTwo);
Layer layerOne = p.getLayer(childOne), layerTwo = p.getLayer(childTwo);
layerOne.setBottomHeight(0, Unit.PCT, 50, Unit.PCT);
layerTwo.setTopHeight(0, Unit.PCT, 50, Unit.PCT);
p.layout();
RootLayoutPanel rp = RootLayoutPanel.get();
rp.add(p);rp.layout();
When I use a LayoutPanel ("hp" reference), the FlexTable would shrink as
expected in terms of height and width (don't behave consistently across all
browsers). When I use an HorizontalPanel, the childs components won't grow
to fill all the parent space. This use case will be very common in the
future as many users will try to compose legacy panels with the new Layout
widgets.
Do you see a simple way to apply the layout to the newly added FlexTable if
its parent is not a LayoutPanel ?
>
> Ça aide beaucoup, merci :)
>
I have been told that your French was excellent, that's proved now ;-)
Many thanks for you help Joel.
Sami
--~--~-~--~~~---~--~~
[gwt-contrib] Re: Initial implementation of layout system, along with the first two layout widgets.
On Wed, Aug 5, 2009 at 8:32 AM, Sami Jaber wrote:
>
> We considered doing something like this originally, and I think it's the
>> right approach for Swing/SWT. However, when you have to implement these
>> layouts in (...) impossible to change a panel's layout after it's
>> constructed, because it forces you to reconstruct the entire DOM.
>>
>
> I understand, It could be interesting to have a look at how GXT guys have
> solved this pb, I guess they have this separation between
> XXLayout/ContentPanel
>
As I understand it, GXT uses the same structural model for all containers,
and all their layouts are built with explicit Java code to manage the
positions and sizes of their children. Unless I'm missing something, this
explicitly precludes a particular layout implementation using a different
DOM structure (i.e., other than ()*). It's a different,
but perfectly valid, set of tradeoffs. For GWT proper, I think it's better
that we stick with a model that allows us to model arbitrary DOM structures,
even if it's at the expense of a degree of generality.
LayoutData has always been there, but it was just package-protected. The doc
>> states explicitly that it may only be used by the panel that owns the
>> widget, and it really does help avoid lots of extra maps, which can get
>> pretty expensive. The userData on Layer should probably have been called
>> userObject (like in TreeItem), and I should have made it invariant rather
>> than having a setter (the next patch will include this change). I admit it's
>> a bit odd, but the "user data" pattern (to the extent one can call it a
>> pattern) can really make things a lot easier in this case. It's also worth
>> pointing out that most users won't really be exposed to Layer.userObject,
>> since they'll mostly be using panels and widgets.
>>
>
> Ok I understand.
>
>>
>> I'm not a huge fan of attach() and detach() either, now that I think of it
>> (actually, I *really* wish I could get rid of them, but this appears to be
>> impossible because of requirements imposed by the IE6 implementation). What
>> about calling them something like onElement[De A]ttached()? Would that make
>> it a bit clearer?
>>
>
> That would definitively be better names
>
>
Done, in the next patch (onAttached, onDetached).
Actually, if you're using a LayoutPanel (or similar widget, more are on
>> their way, such as DockLayoutPanel, StackLayoutPanel, and the like), you
>> shouldn't ever have to use the Layout class directly. The above code could
>> simply be:
>>
>> Does that make sense? I would prefer to modify add() to return the Layer
>> directly, but it's inherited from HasWidgets (unfortunately, it was a bad
>> idea to have add() there in the first place, but it's too late to fix now).
>>
>
> Yes, that's right. That said, I would have probably chosen a name like
> "LayerConstraints" instead of "Layer" because of the specific nature of the
> data passed to attachChild
>
It really came down to a tradeoff between correctness and brevity. You end
up with the name of this class all over your layout code, which can get to
be a bit much if it's really long. I was also inspired (at least a little
bit) by the Core Animation concept of a "layer".
explicitly). The RootLayoutPanel is meant to solve this problem in a pretty
>> simple way -- please let me know if it's not sufficient for some reason I'm
>> not seeing.
>>
>
> That's it. I have replaced RootPanel by RootLayoutPanel and things are
> better. I still have the problem to find an equivalent of
> RootPanel.get("slotId").
> As it is designed, that seems difficult. Does it mean that embedding
> LayoutPanel in an existing DOM will be forbidden by design ? I don't see how
> you could infer the existing raw HTML to add all the layout data stuff
>
I've been banging my head on this problem for a while. The issue is this:
RootLayoutPanel *could* provide the option of attaching itself to an
arbitrary in the page, but it would then lose the ability to notify
its children of onLayout() -- because there's no way to know when an
arbitrary element on the page changes size.
You *could* implement something like this by hand, as long as you were
willing to either (a) explicitly size the root element so that it's size
doesn't change arbitrarily, or (b) accept that the RequiresLayout contract
will be broken. Like so:
class MyRoot extends LayoutPanel {
private static MyRoot singleton;
public static MyRoot get(String id) {
if (singleton == null) {
singleton = new MyRoot();
RootPanel.get(id).add(singleton);
}
return singleton;
}
private MyRoot() {
}
@Override
protected void onLoad() {
getLayout().onAttached();
getLayout().fillParent();
}
}
Note that this class can't "provide layout", because it has no way of
following that contract. You could do so correctly as long as you found a
way to fix the element's size and inform your children whenever you change
it.
Also, I can't quite follow all the logic here, but d
[gwt-contrib] Re: Initial implementation of layout system, along with the first two layout widgets.
Since this was committed TBR last night, I've added all the changes
discussed here to http://gwt-code-reviews.appspot.com/55804
http://gwt-code-reviews.appspot.com/51830/diff/2003/2004
File user/javadoc/com/google/gwt/examples/LayoutPanelExample.java
(right):
http://gwt-code-reviews.appspot.com/51830/diff/2003/2004#newcode32
Line 32: Widget childOne = new HTML(), childTwo = new HTML();
On 2009/08/04 23:34:58, jlabanca wrote:
> You should add some text to these HTML widgets so that if somebody
uses the
> example they will actually see childOne and childTwo.
Done.
http://gwt-code-reviews.appspot.com/51830/diff/2003/2010
File user/src/com/google/gwt/layout/client/Layout.java (right):
http://gwt-code-reviews.appspot.com/51830/diff/2003/2010#newcode302
Line 302: public void animate(int duration) {
On 2009/08/04 23:34:58, jlabanca wrote:
> Didn't we agree that this would become layout(int duration)? I see
that we now
> have LayoutPanel#layout(int), but why not here?
Whoops. I changed these in the widgets, but not in the Layout class.
Done.
http://gwt-code-reviews.appspot.com/51830/diff/2003/2010#newcode313
Line 313: public void animate(int duration, final AnimationCallback
callback) {
On 2009/08/04 23:34:58, jlabanca wrote:
> And this would be layout(int duration, final AnimationCallback
callback)?
Done.
http://gwt-code-reviews.appspot.com/51830/diff/2003/2014
File user/src/com/google/gwt/user/client/ui/ProvidesLayout.java (right):
http://gwt-code-reviews.appspot.com/51830/diff/2003/2014#newcode29
Line 29: * public void onLayout() {
On 2009/08/04 23:34:58, jlabanca wrote:
> Can we move this to a static helper method in this interface to avoid
code
> duplication? It could take an Iterator and look for instances of
> RequiresLayout.
That would be nice, wouldn't it? Unfortunately, Java, in its infinite
wisdom (ha!), doesn't allow static methods on interfaces.
I thought about putting it on LayoutPanel, or something like that, but
it just didn't seem right. Other ideas welcome.
http://gwt-code-reviews.appspot.com/51830/diff/2003/2006
File user/test/com/google/gwt/layout/client/LayoutTest.java (right):
http://gwt-code-reviews.appspot.com/51830/diff/2003/2006#newcode57
Line 57: return "com.google.gwt.layout.Layout";
On 2009/08/04 23:34:58, jlabanca wrote:
> Should be com.google.gwt.layout.LayoutTest
Done.
http://gwt-code-reviews.appspot.com/51830
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Initial implementation of layout system, along with the first two layout widgets.
> AFAICT, what's happening here is that the layout works "properly" in the > sense that the tables inside the various LayoutPanels are in fact laid out > as requested. The problem is that children nested *inside* table cells don't > take up the entire cell in standards mode, even if their width/height are > set to 100%. This is one of the biggest mistakes (IMNSHO) in the CSS > standard, but there's little to be done about that now. > > I believe Tab/DeckPanel are going to have to be among the widgets for which > we build layout-aware implementations. This would eliminate this problem by > eliminating the . I'm going to be reviewing and checking in > implementations of the widgets described in the layout design doc over the > next week or so. Any help you could provide by reviewing their APIs and > behaviors would be greatly appreciated. > Thanks a lot Joel for your precious answer. This topic is really challenging and the idea that consist to build an entire layout framework on top of 4 CSS properties is just crazy. Looking forward for the next patches/evolutions and you can obviously count on me for any kind of review I could provide (let me know if you prefer private mails or a contrib broadcasted mail) Sami ps: I will probably tease bobv now that I have spent time on the last deRPC changes ;-) --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Initial implementation of layout system, along with the first two layout widgets.
Thanks, Sami. I'll keep sending reviews to gwtc, and copy you on them -- this stuff needs all the vetting it can get. On Wed, Aug 5, 2009 at 6:13 PM, Sami Jaber wrote: > > AFAICT, what's happening here is that the layout works "properly" in the >> sense that the tables inside the various LayoutPanels are in fact laid out >> as requested. The problem is that children nested *inside* table cells don't >> take up the entire cell in standards mode, even if their width/height are >> set to 100%. This is one of the biggest mistakes (IMNSHO) in the CSS >> standard, but there's little to be done about that now. >> >> I believe Tab/DeckPanel are going to have to be among the widgets for >> which we build layout-aware implementations. This would eliminate this >> problem by eliminating the . I'm going to be reviewing and checking >> in implementations of the widgets described in the layout design doc over >> the next week or so. Any help you could provide by reviewing their APIs and >> behaviors would be greatly appreciated. >> > > Thanks a lot Joel for your precious answer. This topic is really > challenging and the idea that consist to build an entire layout framework on > top of 4 CSS properties is just crazy. Looking forward for the next > patches/evolutions and you can obviously count on me for any kind of review > I could provide (let me know if you prefer private mails or a contrib > broadcasted mail) > > Sami > > ps: I will probably tease bobv now that I have spent time on the last deRPC > changes ;-) --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Initial implementation of layout system, along with the first two layout widgets.
Hi, I work for gwt-mosaic and implemented an "Absolute Javascript Layout" system based on AbsolutePanel and (like SWING) on various LayoutManagers: http://code.google.com/p/gwt-mosaic/source/browse/branches/GWT-1.6/src/org/gwt/mosaic/ui/client/layout/LayoutPanel.java http://code.google.com/p/gwt-mosaic/source/browse/branches/GWT-1.6/src/org/gwt/mosaic/ui/client/layout/LayoutManager.java I use the package protected method Widget.setLayoutData() for the various layout hints. So far it works good, at least I could port JGoodies Forms: http://69.20.122.77/gwt-mosaic/Showcase.html#CwQuickStartExample Other LayoutManagers are: FillLayout, BoxLayout, BorderLayout and GridLayout. The layout cascade in gwt-mosaic is based on HasLayoutManager interface, that a container (panel) has to implement: http://code.google.com/p/gwt-mosaic/source/browse/branches/GWT-1.6/src/org/gwt/mosaic/ui/client/layout/HasLayoutManager.java Any widget can be added to a container that implements HasLayoutManager there is no RequiresLayout interface. I am interested in this topic because I want to adapt my code to the new classes you provide and also I want to try if its possible to port https://designgridlayout.dev.java.net/ to GWT 2.0 new layout system. Kind Regards, George. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Initial implementation of layout system, along with the first two layout widgets.
George, The main difference between this layout system and that in gwt-mosaic (or ext, for that matter), is that it performs nearly zero work in Javascript (the one exception is that the layout widget hierarchy *does* have a provision for a post-layout fixup pass, but it's expected to do nothing 99% of the time). It requires that the layout you wish to achieve be expressible through the CSS properties left:, right:, top:, bottom:, width:, and height:. As I discuss in the design doc, this makes a huge difference in performance. To the extent that you can express mosaic layouts using the constraints available in the Layout class, it may be possible to merge the two. As for DesignGridLayout, I'm not entirely sure that Layout would be the right way to achieve this, but I could be wrong. It's been a while since I played with DesignGrid, and it would probably be better if we could find a way to express it as an html , though I haven't investigated whether or not this is possible. Cheers, joel. On Thu, Aug 6, 2009 at 10:27 AM, ggeorg wrote: > > Hi, > > I work for gwt-mosaic and implemented an "Absolute Javascript Layout" > system based on AbsolutePanel and (like SWING) on various > LayoutManagers: > > > http://code.google.com/p/gwt-mosaic/source/browse/branches/GWT-1.6/src/org/gwt/mosaic/ui/client/layout/LayoutPanel.java > > http://code.google.com/p/gwt-mosaic/source/browse/branches/GWT-1.6/src/org/gwt/mosaic/ui/client/layout/LayoutManager.java > > I use the package protected method Widget.setLayoutData() for the > various layout hints. > > So far it works good, at least I could port JGoodies Forms: > > http://69.20.122.77/gwt-mosaic/Showcase.html#CwQuickStartExample > > Other LayoutManagers are: FillLayout, BoxLayout, BorderLayout and > GridLayout. > > The layout cascade in gwt-mosaic is based on HasLayoutManager > interface, that a container (panel) has to implement: > > > http://code.google.com/p/gwt-mosaic/source/browse/branches/GWT-1.6/src/org/gwt/mosaic/ui/client/layout/HasLayoutManager.java > > Any widget can be added to a container that implements > HasLayoutManager there is no RequiresLayout interface. > > I am interested in this topic because I want to adapt my code to the > new classes you provide and also I want to try if its possible to port > https://designgridlayout.dev.java.net/ to GWT 2.0 new layout system. > > Kind Regards, > George. > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Initial implementation of layout system, along with the first two layout widgets.
Yes I know there is a big difference about the two layout systems but we could use the same interfaces and base classes. This is easy to do, I think, since both layout systems will use a layout cascade (RootLayoutPanel and Viewport for gwt-mosaic) and things like that. Later today I will try to use the latest from GWT trunk and work with your code. About the class names that are almost identical I am afraid that there will be a confusion in the imports. This is why I want to merge this your code. Sorry for posting this many times, I am new to the contributors list and I found later out that the posts are moderated. George. On Aug 6, 8:17 pm, Joel Webber wrote: > George, > The main difference between this layout system and that in gwt-mosaic (or > ext, for that matter), is that it performs nearly zero work in Javascript > (the one exception is that the layout widget hierarchy *does* have a > provision for a post-layout fixup pass, but it's expected to do nothing 99% > of the time). It requires that the layout you wish to achieve be expressible > through the CSS properties left:, right:, top:, bottom:, width:, and > height:. As I discuss in the design doc, this makes a huge difference in > performance. To the extent that you can express mosaic layouts using the > constraints available in the Layout class, it may be possible to merge the > two. > > As for DesignGridLayout, I'm not entirely sure that Layout would be the > right way to achieve this, but I could be wrong. It's been a while since I > played with DesignGrid, and it would probably be better if we could find a > way to express it as an html , though I haven't investigated whether > or not this is possible. > > Cheers, > joel. > > On Thu, Aug 6, 2009 at 10:27 AM, ggeorg > wrote: > > > > > Hi, > > > I work for gwt-mosaic and implemented an "Absolute Javascript Layout" > > system based on AbsolutePanel and (like SWING) on various > > LayoutManagers: > > >http://code.google.com/p/gwt-mosaic/source/browse/branches/GWT-1.6/sr... > > >http://code.google.com/p/gwt-mosaic/source/browse/branches/GWT-1.6/sr... > > > I use the package protected method Widget.setLayoutData() for the > > various layout hints. > > > So far it works good, at least I could port JGoodies Forms: > > >http://69.20.122.77/gwt-mosaic/Showcase.html#CwQuickStartExample > > > Other LayoutManagers are: FillLayout, BoxLayout, BorderLayout and > > GridLayout. > > > The layout cascade in gwt-mosaic is based on HasLayoutManager > > interface, that a container (panel) has to implement: > > >http://code.google.com/p/gwt-mosaic/source/browse/branches/GWT-1.6/sr... > > > Any widget can be added to a container that implements > > HasLayoutManager there is no RequiresLayout interface. > > > I am interested in this topic because I want to adapt my code to the > > new classes you provide and also I want to try if its possible to port > >https://designgridlayout.dev.java.net/to GWT 2.0 new layout system. > > > Kind Regards, > > George. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Initial implementation of layout system, along with the first two layout widgets.
George, Please do have a look and see what might be done to make this easier. The names are definitely the most negotiable part of the design, and I'm definitely open to other ways of handling the "RootLayoutPanel" problem. The biggest issue I have with it at present is that there's no way to get() a RootLayoutPanel for an arbitrary element -- I think this is impossible in the general case, because there's no way to know when an arbitrary element's size has changed. The other design problem that I'm not terribly happy with is that there's no way to enforce that a widget that "RequiresLayout" be added to a panel that "ProvidesLayout". Again, I'm not sure that there's a perfect solution to this problem, but I'm quite open to ideas. Also, are your posts being moderated? If so, let me know and I'll make sure that gets fixed. Cheers, joel. On Thu, Aug 6, 2009 at 1:33 PM, ggeorg wrote: > > Yes I know there is a big difference about the two layout systems but > we could > use the same interfaces and base classes. This is easy to do, I think, > since both > layout systems will use a layout cascade (RootLayoutPanel and Viewport > for > gwt-mosaic) and things like that. > > Later today I will try to use the latest from GWT trunk and work with > your code. > About the class names that are almost identical I am afraid that there > will be > a confusion in the imports. This is why I want to merge this your > code. > > Sorry for posting this many times, I am new to the contributors list > and I found later > out that the posts are moderated. > > George. > > On Aug 6, 8:17 pm, Joel Webber wrote: > > George, > > The main difference between this layout system and that in gwt-mosaic (or > > ext, for that matter), is that it performs nearly zero work in Javascript > > (the one exception is that the layout widget hierarchy *does* have a > > provision for a post-layout fixup pass, but it's expected to do nothing > 99% > > of the time). It requires that the layout you wish to achieve be > expressible > > through the CSS properties left:, right:, top:, bottom:, width:, and > > height:. As I discuss in the design doc, this makes a huge difference in > > performance. To the extent that you can express mosaic layouts using the > > constraints available in the Layout class, it may be possible to merge > the > > two. > > > > As for DesignGridLayout, I'm not entirely sure that Layout would be the > > right way to achieve this, but I could be wrong. It's been a while since > I > > played with DesignGrid, and it would probably be better if we could find > a > > way to express it as an html , though I haven't investigated > whether > > or not this is possible. > > > > Cheers, > > joel. > > > > On Thu, Aug 6, 2009 at 10:27 AM, ggeorg >wrote: > > > > > > > > > Hi, > > > > > I work for gwt-mosaic and implemented an "Absolute Javascript Layout" > > > system based on AbsolutePanel and (like SWING) on various > > > LayoutManagers: > > > > >http://code.google.com/p/gwt-mosaic/source/browse/branches/GWT-1.6/sr. > .. > > > > >http://code.google.com/p/gwt-mosaic/source/browse/branches/GWT-1.6/sr. > .. > > > > > I use the package protected method Widget.setLayoutData() for the > > > various layout hints. > > > > > So far it works good, at least I could port JGoodies Forms: > > > > >http://69.20.122.77/gwt-mosaic/Showcase.html#CwQuickStartExample > > > > > Other LayoutManagers are: FillLayout, BoxLayout, BorderLayout and > > > GridLayout. > > > > > The layout cascade in gwt-mosaic is based on HasLayoutManager > > > interface, that a container (panel) has to implement: > > > > >http://code.google.com/p/gwt-mosaic/source/browse/branches/GWT-1.6/sr. > .. > > > > > Any widget can be added to a container that implements > > > HasLayoutManager there is no RequiresLayout interface. > > > > > I am interested in this topic because I want to adapt my code to the > > > new classes you provide and also I want to try if its possible to port > > >https://designgridlayout.dev.java.net/to GWT 2.0 new layout system. > > > > > Kind Regards, > > > George. > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Initial implementation of layout system, along with the first two layout widgets.
On Thu, Aug 6, 2009 at 1:41 PM, Joel Webber wrote: > Please do have a look and see what might be done to make this easier. The > names are definitely the most negotiable part of the design, and I'm > definitely open to other ways of handling the "RootLayoutPanel" problem. The > biggest issue I have with it at present is that there's no way to get() a > RootLayoutPanel for an arbitrary element -- I think this is impossible in > the general case, because there's no way to know when an arbitrary element's > size has changed. The other design problem that I'm not terribly happy with > is that there's no way to enforce that a widget that "RequiresLayout" be > added to a panel that "ProvidesLayout". Again, I'm not sure that there's a > perfect solution to this problem, but I'm quite open to ideas. > I think you could have an "ExternallySizedLayoutPanel" that acts like a RootLayoutPanel but it is up to the user to let it know when its size changed. You could then inject it into an existing page, but you would be responsible for sizing it appropriately. This is assuming I understand the fundamental limitation you are worried about. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Initial implementation of layout system, along with the first two layout widgets.
On Thu, Aug 6, 2009 at 1:43 PM, John Tamplin wrote: > On Thu, Aug 6, 2009 at 1:41 PM, Joel Webber wrote: > >> Please do have a look and see what might be done to make this easier. The >> names are definitely the most negotiable part of the design, and I'm >> definitely open to other ways of handling the "RootLayoutPanel" problem. The >> biggest issue I have with it at present is that there's no way to get() a >> RootLayoutPanel for an arbitrary element -- I think this is impossible in >> the general case, because there's no way to know when an arbitrary element's >> size has changed. The other design problem that I'm not terribly happy with >> is that there's no way to enforce that a widget that "RequiresLayout" be >> added to a panel that "ProvidesLayout". Again, I'm not sure that there's a >> perfect solution to this problem, but I'm quite open to ideas. >> > > I think you could have an "ExternallySizedLayoutPanel" that acts like a > RootLayoutPanel but it is up to the user to let it know when its size > changed. You could then inject it into an existing page, but you would be > responsible for sizing it appropriately. > > This is assuming I understand the fundamental limitation you are worried > about. > That's precisely the issue. And you can get that now with by just instantiating a LayoutPanel, setting its size, and calling onLayout() directly. Perhaps there's something we could do to make this more obvious. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Initial implementation of layout system, along with the first two layout widgets.
LayoutPanel#setSize(String width, String height, boolean propagate) On Thu, Aug 6, 2009 at 10:49 AM, Joel Webber wrote: > On Thu, Aug 6, 2009 at 1:43 PM, John Tamplin wrote: > >> On Thu, Aug 6, 2009 at 1:41 PM, Joel Webber wrote: >> >>> Please do have a look and see what might be done to make this easier. The >>> names are definitely the most negotiable part of the design, and I'm >>> definitely open to other ways of handling the "RootLayoutPanel" problem. The >>> biggest issue I have with it at present is that there's no way to get() a >>> RootLayoutPanel for an arbitrary element -- I think this is impossible in >>> the general case, because there's no way to know when an arbitrary element's >>> size has changed. The other design problem that I'm not terribly happy with >>> is that there's no way to enforce that a widget that "RequiresLayout" be >>> added to a panel that "ProvidesLayout". Again, I'm not sure that there's a >>> perfect solution to this problem, but I'm quite open to ideas. >>> >> >> I think you could have an "ExternallySizedLayoutPanel" that acts like a >> RootLayoutPanel but it is up to the user to let it know when its size >> changed. You could then inject it into an existing page, but you would be >> responsible for sizing it appropriately. >> >> This is assuming I understand the fundamental limitation you are worried >> about. >> > > That's precisely the issue. And you can get that now with by just > instantiating a LayoutPanel, setting its size, and calling onLayout() > directly. Perhaps there's something we could do to make this more obvious. > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Initial implementation of layout system, along with the first two layout widgets.
Yeah, I was just thinking the same thing, except that there's never a case where it shouldn't propagate (onLayout() is purely informative, for those widgets that occasionally need to do fixup work). I'll go stick that in now. On Thu, Aug 6, 2009 at 2:06 PM, Ray Ryan wrote: > LayoutPanel#setSize(String width, String height, boolean propagate) > > > On Thu, Aug 6, 2009 at 10:49 AM, Joel Webber wrote: > >> On Thu, Aug 6, 2009 at 1:43 PM, John Tamplin wrote: >> >>> On Thu, Aug 6, 2009 at 1:41 PM, Joel Webber wrote: >>> Please do have a look and see what might be done to make this easier. The names are definitely the most negotiable part of the design, and I'm definitely open to other ways of handling the "RootLayoutPanel" problem. The biggest issue I have with it at present is that there's no way to get() a RootLayoutPanel for an arbitrary element -- I think this is impossible in the general case, because there's no way to know when an arbitrary element's size has changed. The other design problem that I'm not terribly happy with is that there's no way to enforce that a widget that "RequiresLayout" be added to a panel that "ProvidesLayout". Again, I'm not sure that there's a perfect solution to this problem, but I'm quite open to ideas. >>> >>> I think you could have an "ExternallySizedLayoutPanel" that acts like a >>> RootLayoutPanel but it is up to the user to let it know when its size >>> changed. You could then inject it into an existing page, but you would be >>> responsible for sizing it appropriately. >>> >>> This is assuming I understand the fundamental limitation you are worried >>> about. >>> >> >> That's precisely the issue. And you can get that now with by just >> instantiating a LayoutPanel, setting its size, and calling onLayout() >> directly. Perhaps there's something we could do to make this more obvious. >> >> >> > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Initial implementation of layout system, along with the first two layout widgets.
I can imagine, if I squint just right, wanting to set the size a few times before kicking off the possibly expensive chain event of child calls. Perhaps setSize() should default to announcing, and the overload with the boolean is there to allow avoiding the side effect? On Thu, Aug 6, 2009 at 11:09 AM, Joel Webber wrote: > Yeah, I was just thinking the same thing, except that there's never a case > where it shouldn't propagate (onLayout() is purely informative, for those > widgets that occasionally need to do fixup work). I'll go stick that in now. > > > On Thu, Aug 6, 2009 at 2:06 PM, Ray Ryan wrote: > >> LayoutPanel#setSize(String width, String height, boolean propagate) >> >> >> On Thu, Aug 6, 2009 at 10:49 AM, Joel Webber wrote: >> >>> On Thu, Aug 6, 2009 at 1:43 PM, John Tamplin wrote: >>> On Thu, Aug 6, 2009 at 1:41 PM, Joel Webber wrote: > Please do have a look and see what might be done to make this easier. > The names are definitely the most negotiable part of the design, and I'm > definitely open to other ways of handling the "RootLayoutPanel" problem. > The > biggest issue I have with it at present is that there's no way to get() a > RootLayoutPanel for an arbitrary element -- I think this is impossible in > the general case, because there's no way to know when an arbitrary > element's > size has changed. The other design problem that I'm not terribly happy > with > is that there's no way to enforce that a widget that "RequiresLayout" be > added to a panel that "ProvidesLayout". Again, I'm not sure that there's a > perfect solution to this problem, but I'm quite open to ideas. > I think you could have an "ExternallySizedLayoutPanel" that acts like a RootLayoutPanel but it is up to the user to let it know when its size changed. You could then inject it into an existing page, but you would be responsible for sizing it appropriately. This is assuming I understand the fundamental limitation you are worried about. >>> >>> That's precisely the issue. And you can get that now with by just >>> instantiating a LayoutPanel, setting its size, and calling onLayout() >>> directly. Perhaps there's something we could do to make this more obvious. >>> >>> >>> >> >> >> > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Initial implementation of layout system, along with the first two layout widgets.
Hi have a look at the code in LayoutPanel (mosaic) lines (446-450): http://code.google.com/p/gwt-mosaic/source/browse/branches/GWT-2.0/src/org/gwt/mosaic/ui/client/layout/LayoutPanel.java I use a ResizableWidgetCollection from GWT Incubator, it works but I don't think its a very good idea. On Aug 6, 9:15 pm, Ray Ryan wrote: > I can imagine, if I squint just right, wanting to set the size a few times > before kicking off the possibly expensive chain event of child calls. > Perhaps setSize() should default to announcing, and the overload with the > boolean is there to allow avoiding the side effect? > > On Thu, Aug 6, 2009 at 11:09 AM, Joel Webber wrote: > > Yeah, I was just thinking the same thing, except that there's never a case > > where it shouldn't propagate (onLayout() is purely informative, for those > > widgets that occasionally need to do fixup work). I'll go stick that in now. > > > On Thu, Aug 6, 2009 at 2:06 PM, Ray Ryan wrote: > > >> LayoutPanel#setSize(String width, String height, boolean propagate) > > >> On Thu, Aug 6, 2009 at 10:49 AM, Joel Webber wrote: > > >>> On Thu, Aug 6, 2009 at 1:43 PM, John Tamplin wrote: > > On Thu, Aug 6, 2009 at 1:41 PM, Joel Webber wrote: > > > Please do have a look and see what might be done to make this easier. > > The names are definitely the most negotiable part of the design, and I'm > > definitely open to other ways of handling the "RootLayoutPanel" > > problem. The > > biggest issue I have with it at present is that there's no way to get() > > a > > RootLayoutPanel for an arbitrary element -- I think this is impossible > > in > > the general case, because there's no way to know when an arbitrary > > element's > > size has changed. The other design problem that I'm not terribly happy > > with > > is that there's no way to enforce that a widget that "RequiresLayout" be > > added to a panel that "ProvidesLayout". Again, I'm not sure that > > there's a > > perfect solution to this problem, but I'm quite open to ideas. > > I think you could have an "ExternallySizedLayoutPanel" that acts like a > RootLayoutPanel but it is up to the user to let it know when its size > changed. You could then inject it into an existing page, but you would > be > responsible for sizing it appropriately. > > This is assuming I understand the fundamental limitation you are worried > about. > > >>> That's precisely the issue. And you can get that now with by just > >>> instantiating a LayoutPanel, setting its size, and calling onLayout() > >>> directly. Perhaps there's something we could do to make this more obvious. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Initial implementation of layout system, along with the first two layout widgets.
Hi Joel, 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 Kind Regards, George. On Aug 6, 8:17 pm, Joel Webber wrote: > George, > The main difference between this layout system and that in gwt-mosaic (or > ext, for that matter), is that it performs nearly zero work in Javascript > (the one exception is that the layout widget hierarchy *does* have a > provision for a post-layout fixup pass, but it's expected to do nothing 99% > of the time). It requires that the layout you wish to achieve be expressible > through the CSS properties left:, right:, top:, bottom:, width:, and > height:. As I discuss in the design doc, this makes a huge difference in > performance. To the extent that you can express mosaic layouts using the > constraints available in the Layout class, it may be possible to merge the > two. > > As for DesignGridLayout, I'm not entirely sure that Layout would be the > right way to achieve this, but I could be wrong. It's been a while since I > played with DesignGrid, and it would probably be better if we could find a > way to express it as an html , though I haven't investigated whether > or not this is possible. > > Cheers, > joel. > > On Thu, Aug 6, 2009 at 10:27 AM, ggeorg > wrote: > > > > > Hi, > > > I work for gwt-mosaic and implemented an "Absolute Javascript Layout" > > system based on AbsolutePanel and (like SWING) on various > > LayoutManagers: > > >http://code.google.com/p/gwt-mosaic/source/browse/branches/GWT-1.6/sr... > > >http://code.google.com/p/gwt-mosaic/source/browse/branches/GWT-1.6/sr... > > > I use the package protected method Widget.setLayoutData() for the > > various layout hints. > > > So far it works good, at least I could port JGoodies Forms: > > >http://69.20.122.77/gwt-mosaic/Showcase.html#CwQuickStartExample > > > Other LayoutManagers are: FillLayout, BoxLayout, BorderLayout and > > GridLayout. > > > The layout cascade in gwt-mosaic is based on HasLayoutManager > > interface, that a container (panel) has to implement: > > >http://code.google.com/p/gwt-mosaic/source/browse/branches/GWT-1.6/sr... > > > Any widget can be added to a container that implements > > HasLayoutManager there is no RequiresLayout interface. > > > I am interested in this topic because I want to adapt my code to the > > new classes you provide and also I want to try if its possible to port > >https://designgridlayout.dev.java.net/to GWT 2.0 new layout system. > > > Kind Regards, > > George. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Initial implementation of layout system, along with the first two layout widgets.
> 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 -~--~~~~--~~--~--~---
[gwt-contrib] Re: Initial implementation of layout system, along with the first two layout widgets.
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 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 -~--~~~~--~~--~--~---
[gwt-contrib] Re: Initial implementation of layout system, along with the first two layout widgets.
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 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 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 -~--~~~~--~~--~--~---
[gwt-contrib] Re: Initial implementation of layout system, along with the first two layout widgets.
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 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 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 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 -~--~~~~--~~--~--~---
[gwt-contrib] Re: Initial implementation of layout system, along with the first two layout widgets.
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 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 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 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 -~--~~~~--~~--~--~---
[gwt-contrib] Re: Initial implementation of layout system, along with the first two layout widgets.
Joel, I love how this is turning out so far, great work. While this system handles a vast majority of layout situations, correct me if I'm wrong, but I think it breaks down with non-100% height layouts that require a footer. An example: a header area, followed by a horizontally split content area (body and side nav), followed by a footer. I can't think of a way you could represent this using absolute positioning that would guarantee the footer area isn't encroached upon. Any thoughts on how LayoutPanel would handle this? Maybe this doesn't fall under "desktop-like" layouts and it's handled with floats (which aren't so terrible in this particular case)? - Amir On Mon, Aug 3, 2009 at 12:13 PM, wrote: > > Reviewers: jlabanca, > > > > Please review this at http://gwt-code-reviews.appspot.com/51830 > > Affected files: > A layout/Layout.gwt.xml > A layout/client/Layout.java > A layout/client/LayoutImpl.java > A layout/client/LayoutImplIE6.java > A layout/client/UserAgent.java > A user/client/ui/HasAnimatedLayout.java > A user/client/ui/HasLayout.java > A user/client/ui/LayoutComposite.java > A user/client/ui/LayoutPanel.java > A user/client/ui/RootLayoutPanel.java > M user/client/ui/Widget.java > > > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Initial implementation of layout system, along with the first two layout widgets.
Amir, this is the exact case I am working on. I'm trting to implement an interface not dissimilar to Google Reader. It has a footer at the bottom of the grid for next prev buttons. Can this layout handle this? Excellent work as always. I'm keenly following this. Can't get it quick enough :) On Aug 10, 9:26 am, Amir Kashani wrote: > Joel, > I love how this is turning out so far, great work. While this system handles > a vast majority of layout situations, correct me if I'm wrong, but I think > it breaks down with non-100% height layouts that require a footer. An > example: a header area, followed by a horizontally split content area (body > and side nav), followed by a footer. I can't think of a way you could > represent this using absolute positioning that would guarantee the footer > area isn't encroached upon. > > Any thoughts on how LayoutPanel would handle this? Maybe this doesn't fall > under "desktop-like" layouts and it's handled with floats (which aren't so > terrible in this particular case)? > > - Amir > > On Mon, Aug 3, 2009 at 12:13 PM, wrote: > > > Reviewers: jlabanca, > > > Please review this athttp://gwt-code-reviews.appspot.com/51830 > > > Affected files: > > A layout/Layout.gwt.xml > > A layout/client/Layout.java > > A layout/client/LayoutImpl.java > > A layout/client/LayoutImplIE6.java > > A layout/client/UserAgent.java > > A user/client/ui/HasAnimatedLayout.java > > A user/client/ui/HasLayout.java > > A user/client/ui/LayoutComposite.java > > A user/client/ui/LayoutPanel.java > > A user/client/ui/RootLayoutPanel.java > > M user/client/ui/Widget.java --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Initial implementation of layout system, along with the first two layout widgets.
Amir, Kango, A UI like Reader is very easy to formulate (it will be a lot easier when I check in DeckLayoutPanel). If you imagine a DeckPanel where 100% height actually works properly, you would write something like this: p.add(header, NORTH); p.add(navPane, WEST); p.add(footer, SOUTH); p.add(content, CENTER); Amir's right to point out that this *doesn't* work if you don't want the layout to be 100% height (or some other fixed height, but where there's no scrollbar on the body element). But that actually already works just fine with plain old CSS or DockPanels. It's the 100% height and interior scrolling that's hard to do at present. Cheers, joel. On Mon, Aug 10, 2009 at 6:34 PM, Kango_V wrote: > > Amir, this is the exact case I am working on. I'm trting to implement > an interface not dissimilar to Google Reader. It has a footer at the > bottom of the grid for next prev buttons. > > Can this layout handle this? > > Excellent work as always. I'm keenly following this. Can't get it > quick enough :) > > On Aug 10, 9:26 am, Amir Kashani wrote: > > Joel, > > I love how this is turning out so far, great work. While this system > handles > > a vast majority of layout situations, correct me if I'm wrong, but I > think > > it breaks down with non-100% height layouts that require a footer. An > > example: a header area, followed by a horizontally split content area > (body > > and side nav), followed by a footer. I can't think of a way you could > > represent this using absolute positioning that would guarantee the footer > > area isn't encroached upon. > > > > Any thoughts on how LayoutPanel would handle this? Maybe this doesn't > fall > > under "desktop-like" layouts and it's handled with floats (which aren't > so > > terrible in this particular case)? > > > > - Amir > > > > On Mon, Aug 3, 2009 at 12:13 PM, wrote: > > > > > Reviewers: jlabanca, > > > > > Please review this athttp://gwt-code-reviews.appspot.com/51830 > > > > > Affected files: > > > A layout/Layout.gwt.xml > > > A layout/client/Layout.java > > > A layout/client/LayoutImpl.java > > > A layout/client/LayoutImplIE6.java > > > A layout/client/UserAgent.java > > > A user/client/ui/HasAnimatedLayout.java > > > A user/client/ui/HasLayout.java > > > A user/client/ui/LayoutComposite.java > > > A user/client/ui/LayoutPanel.java > > > A user/client/ui/RootLayoutPanel.java > > > M user/client/ui/Widget.java > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Initial implementation of layout system, along with the first two layout widgets.
You mean DockLayoutPanel, right? Anyway, makes perfect sense. The true challenge has always been with the 100% height desktop-app style layouts, which the new stuff will handle beautifully. Thanks. - Amir On Tue, Aug 11, 2009 at 12:38 PM, Joel Webber wrote: > Amir, Kango, > A UI like Reader is very easy to formulate (it will be a lot easier when I > check in DeckLayoutPanel). If you imagine a DeckPanel where 100% height > actually works properly, you would write something like this: > > p.add(header, NORTH); > p.add(navPane, WEST); > p.add(footer, SOUTH); > p.add(content, CENTER); > > Amir's right to point out that this *doesn't* work if you don't want the > layout to be 100% height (or some other fixed height, but where there's no > scrollbar on the body element). But that actually already works just fine > with plain old CSS or DockPanels. It's the 100% height and interior > scrolling that's hard to do at present. > > Cheers, > joel. > > > On Mon, Aug 10, 2009 at 6:34 PM, Kango_V wrote: > >> >> Amir, this is the exact case I am working on. I'm trting to implement >> an interface not dissimilar to Google Reader. It has a footer at the >> bottom of the grid for next prev buttons. >> >> Can this layout handle this? >> >> Excellent work as always. I'm keenly following this. Can't get it >> quick enough :) >> >> On Aug 10, 9:26 am, Amir Kashani wrote: >> > Joel, >> > I love how this is turning out so far, great work. While this system >> handles >> > a vast majority of layout situations, correct me if I'm wrong, but I >> think >> > it breaks down with non-100% height layouts that require a footer. An >> > example: a header area, followed by a horizontally split content area >> (body >> > and side nav), followed by a footer. I can't think of a way you could >> > represent this using absolute positioning that would guarantee the >> footer >> > area isn't encroached upon. >> > >> > Any thoughts on how LayoutPanel would handle this? Maybe this doesn't >> fall >> > under "desktop-like" layouts and it's handled with floats (which aren't >> so >> > terrible in this particular case)? >> > >> > - Amir >> > >> > On Mon, Aug 3, 2009 at 12:13 PM, wrote: >> > >> > > Reviewers: jlabanca, >> > >> > > Please review this athttp://gwt-code-reviews.appspot.com/51830 >> > >> > > Affected files: >> > > A layout/Layout.gwt.xml >> > > A layout/client/Layout.java >> > > A layout/client/LayoutImpl.java >> > > A layout/client/LayoutImplIE6.java >> > > A layout/client/UserAgent.java >> > > A user/client/ui/HasAnimatedLayout.java >> > > A user/client/ui/HasLayout.java >> > > A user/client/ui/LayoutComposite.java >> > > A user/client/ui/LayoutPanel.java >> > > A user/client/ui/RootLayoutPanel.java >> > > M user/client/ui/Widget.java >> >> > > > > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Initial implementation of layout system, along with the first two layout widgets.
Joel, 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. Thanks, George. On Aug 11, 10:38 pm, Joel Webber wrote: > Amir, Kango, > A UI like Reader is very easy to formulate (it will be a lot easier when I > check in DeckLayoutPanel). If you imagine a DeckPanel where 100% height > actually works properly, you would write something like this: > > p.add(header, NORTH); > p.add(navPane, WEST); > p.add(footer, SOUTH); > p.add(content, CENTER); > > Amir's right to point out that this *doesn't* work if you don't want the > layout to be 100% height (or some other fixed height, but where there's no > scrollbar on the body element). But that actually already works just fine > with plain old CSS or DockPanels. It's the 100% height and interior > scrolling that's hard to do at present. > > Cheers, > joel. > > On Mon, Aug 10, 2009 at 6:34 PM, Kango_V wrote: > > > Amir, this is the exact case I am working on. I'm trting to implement > > an interface not dissimilar to Google Reader. It has a footer at the > > bottom of the grid for next prev buttons. > > > Can this layout handle this? > > > Excellent work as always. I'm keenly following this. Can't get it > > quick enough :) > > > On Aug 10, 9:26 am, Amir Kashani wrote: > > > Joel, > > > I love how this is turning out so far, great work. While this system > > handles > > > a vast majority of layout situations, correct me if I'm wrong, but I > > think > > > it breaks down with non-100% height layouts that require a footer. An > > > example: a header area, followed by a horizontally split content area > > (body > > > and side nav), followed by a footer. I can't think of a way you could > > > represent this using absolute positioning that would guarantee the footer > > > area isn't encroached upon. > > > > Any thoughts on how LayoutPanel would handle this? Maybe this doesn't > > fall > > > under "desktop-like" layouts and it's handled with floats (which aren't > > so > > > terrible in this particular case)? > > > > - Amir > > > > On Mon, Aug 3, 2009 at 12:13 PM, wrote: > > > > > Reviewers: jlabanca, > > > > > Please review this athttp://gwt-code-reviews.appspot.com/51830 > > > > > Affected files: > > > > A layout/Layout.gwt.xml > > > > A layout/client/Layout.java > > > > A layout/client/LayoutImpl.java > > > > A layout/client/LayoutImplIE6.java > > > > A layout/client/UserAgent.java > > > > A user/client/ui/HasAnimatedLayout.java > > > > A user/client/ui/HasLayout.java > > > > A user/client/ui/LayoutComposite.java > > > > A user/client/ui/LayoutPanel.java > > > > A user/client/ui/RootLayoutPanel.java > > > > M user/client/ui/Widget.java --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Initial implementation of layout system, along with the first two layout widgets.
On Sat, Aug 8, 2009 at 10:27 AM, ggeorg 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 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 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 -~--~~~~--~~--~--~---
[gwt-contrib] Re: Initial implementation of layout system, along with the first two layout widgets.
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 wrote:
> On Sat, Aug 8, 2009 at 10:27 AM, ggeorg
> 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
> 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 L
[gwt-contrib] Re: Initial implementation of layout system, along with the first two layout widgets.
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 wrote:
> On Sat, Aug 8, 2009 at 10:27 AM, ggeorg
> 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
> 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 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
[gwt-contrib] Re: Initial implementation of layout system, along with the first two layout widgets.
On Wed, Aug 12, 2009 at 2:36 PM, ggeorg wrote:
> 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
I was thinking that new panels that needed to use the widgets' or layers'
"extra" data fields would simply use the Layout class directly, rather than
wrapping LayoutPanel. That would give you free reign to use these fields
however you need to.
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);
}
This is kind of a tricky question, and I haven't built a good solution yet.
I started to write a method called setWidgetVisible(Widget, boolean) into
LayoutPanel, which did exactly what you describe above, but it just didn't
feel right. However, the current situation leads you to believe you can just
use Widget.setVisible() which leads to surprising behavior like events
getting eaten by the container element. I'm quite open to any ideas on how
this could be solved more cleanly!
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Initial implementation of layout system, along with the first two layout widgets.
maybe:
for (Layer l : layers) {
Object o = l.getUserObject();
if (o instanceof Widget) {
Element widgetElement = ((Widget) o).getElement();
UIObject.setVisible(l.getContainerElement(),
UIObject.isVisible(widgetElement));
if (!UIObject.isVisible(widgetElement)) {
continue;
}
}
...
}
On Aug 17, 9:30 pm, Joel Webber wrote:
> On Wed, Aug 12, 2009 at 2:36 PM, ggeorg
> wrote:
>
> > 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
>
> I was thinking that new panels that needed to use the widgets' or layers'
> "extra" data fields would simply use the Layout class directly, rather than
> wrapping LayoutPanel. That would give you free reign to use these fields
> however you need to.
>
> 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);
>
> }
>
> This is kind of a tricky question, and I haven't built a good solution yet.
> I started to write a method called setWidgetVisible(Widget, boolean) into
> LayoutPanel, which did exactly what you describe above, but it just didn't
> feel right. However, the current situation leads you to believe you can just
> use Widget.setVisible() which leads to surprising behavior like events
> getting eaten by the container element. I'm quite open to any ideas on how
> this could be solved more cleanly!
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
