LGTY for now?
http://gwt-code-reviews.appspot.com/78820/diff/1/2 File user/javadoc/com/google/gwt/examples/TabLayoutPanelExample.java (right): http://gwt-code-reviews.appspot.com/78820/diff/1/2#newcode41 Line 41: rp.layout(); On 2009/10/14 21:06:03, Ray Ryan wrote: > I wonder if we could tie into the FinallyCommand mechanism to automate and batch > these initial layout calls? Not today, obviously, but food for thought. Definitely want to think about this a bit more. I've got a comment to this effect in one of my git branches. It's a bit tricky because some panels want to allow animated layout(), but I still think we can do better than this. http://gwt-code-reviews.appspot.com/78820/diff/1/4 File user/src/com/google/gwt/user/client/ui/TabLayoutPanel.java (right): http://gwt-code-reviews.appspot.com/78820/diff/1/4#newcode61 Line 61: */ On 2009/10/14 21:06:03, Ray Ryan wrote: > When I provide my own widget, will it be able to receive events? E.g., will I be > able to implement a tab with a close box on it? Yes, this works fine (I've tested it by hand in a local project). Yes, I need to add actual JUnit tests for this as well. > We had talked about allowing the client to provide a tab factory. Why didn't > that work out? Kelly and I sat down to talk about it, and came to the conclusion that it would be about a bazillion times easier to just create two divs for each tab, which can be used for the majority of rounded-corner tricks one might want. This drastically simplifies the API surface area, because the Tab itself becomes a private implementation detail. We may need to revisit it later to make sure we haven't missed any reasonable styling cases, but I think we'll be fine (also remember that you can, if absolutely necessary, add extra elements to a widget, added to a tab, for styling purposes -- but I expect this won't ever really be necessary). http://gwt-code-reviews.appspot.com/78820/diff/1/4#newcode387 Line 387: public void setTabHTML(int index, String text) { On 2009/10/14 21:06:03, Ray Ryan wrote: > I'd still rather see something like: > panel.getTab(i).setHTML(), etc. You'd have so many fewer methods. I'm willing to consider it, but was mainly aiming to get something close enough to the existing TabPanel that it wouldn't be hard to port. Maybe we can revisit this again after MS2 (I still have a nasty warning in the javadoc about the API changing without warning)? http://gwt-code-reviews.appspot.com/78820 --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
