On 2009/10/14 16:45:38, t.broyer 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). [Repeat of what I said earlier on email but should have said here] How's this sound for a proposal to wrap all this up, then: - Drop the public DisclosureHeader class, as Ray suggested earlier. - Implement the <g:header/><g:body/> version of the parser (I agree it's probably clearer). - Create a separate issue (possibly eclipsing issue 1449, possibly simply clarifying it), that captures the desire to be able to add focusable widgets to the header without conflicting with the anchor. ? http://gwt-code-reviews.appspot.com/78817 --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
