Broadly, I'm not entirely sure what we're trying to achieve by promoting DisclosurePanelHeader to a public top-level class. It's pretty complex, for a seemingly simple problem. If you were to replace it wholesale within an application, you will pretty much be replacing the entire widget.
It seems that being able to (a) replace the images, and (b) replace the header contents with an arbitrary widget, would handle all reasonable use-cases. And it doesn't really solve the problem Thomas mentions with the focusable part of the header (i.e., the anchor) interfering with form elements placed within it. Am I missing something here? http://gwt-code-reviews.appspot.com/78817/diff/15/1029 File user/src/com/google/gwt/user/client/ui/DisclosurePanel.java (right): http://gwt-code-reviews.appspot.com/78817/diff/15/1029#newcode62 Line 62: super(DOM.createAnchor()); On 2009/10/14 12:33:13, t.broyer wrote: > Couldn't you use a FocusImpl instead, and therefore fix issue 1449? > (might have implications with using focusable widgets within the header though, > particularly when using FocusImplOld, so maybe there rather shouldn't be a > ClickableHeader at all within DisclosurePanel, and defer the focus/open/close > handling to the header widget instead; and provide a wrapper equivalent to this > ClickableHeader for non-focusable/non-clickable widgets) I don't actually believe that switching from using an anchor to FocusImpl will make much of a difference. They both have the effect of wrapping the contained widget in a "focusable" area, which is necessary to make them keyboard-accessible. It's not immediately obvious how we could *both* make the header focusable, *and* not interfere with form elements stuck inside it. http://gwt-code-reviews.appspot.com/78817 --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
