On 2009/10/14 15:43:38, jgw wrote: > 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. Say I want to add an "online indicator" as in the chat panel in GMail? or I want to add a button in the header (my use case: I have a disclosure panel for data filters, much similar to GMail saved searches or labels, and initially I'd have liked to put the "create filter" button in the header, but that would have meant re-implementing the image toggle, so I gave up in included it within the disclosure panel's content)? also think about Reader's menu in its left pane panels. > 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. The only issue if you replace the anchor with a FocusImpl is in the case it is a FocusImplOld (i.e. in WebKit, although Safari 4 and Chrome 3 now correctly implement tabIndex as a way to make any element focusable –I don't know about mobile webkits such as the iPhone and Android, but they're not officially supported afaik–, and in "old gecko", which was still supported only because of the hosted mode), because it'll steal the focus from a focusable child (see issue 1471) 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 15:43:39, jgw wrote: > 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. but the anchor impacts your CSS, as you'll inherit its color:blue style in your header text. > It's not immediately obvious how we could *both* make the > header focusable, *and* not interfere with form elements stuck inside it. Hence my other proposition, to have two public disclosure headers: one that can only contain text, as is the case today, and one that can contain widget (in this case, only the image is focusable and clickable). And if you want to replace the whole header with your own (which handles the image display, as of today), that's still possible, but you'd also have to handle focusability and clicks (for backwards compatibility, widgets that do not implement OpensAndCloses –or should it be OpensAndCloses.Handler?– would automatically be wrapped within a special, private header based on e.g. a FocusPanel). http://gwt-code-reviews.appspot.com/78817 --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
