Thomas, this all makes sense but I don't think we can make it happen for 2.0. Certainly not MS2, and probably not for the RC (though it's tempting, DisclosurePanel is so close to being so much more useful). Do you mind creating an issue on the public tracker capturing this?
On Wed, Oct 14, 2009 at 9:45 AM, <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
