First, sorry to throw something like this at you at the last second. What
was that Bruce said about getting enough sleep and making good decisions?
The other goal, which I realize know I didn't hit, was to be able to put the
stock header in one spot and the panel it opens or closes in another spot.
It's something I've had to do in real apps surprisingly often, and I thought
I saw an easy way to get there. But because DisclosurePanelHeader isn't
master of its own clickiness, that's a fail.
I'll put DPanel back the way it was, but using ImageResource. (Thanks to git
I have that exact spot working already in my local repository.)
While we're chatting, what do you like better:
<g:DisclosurePanel>
<g:header> Whoopie doo </g:header>
<g:Label>I am the hidden part</g:Label>
</g:DisclosurePanel>
or
<g:DisclosurePanel>
<g:header> Whoopie doo </g:header>
<g:body>
<g:Label>I am the hidden part</g:Label>
</g:body>
</g:DisclosurePanel>
I implemented the former, but know I think the latter is better.
On Wed, Oct 14, 2009 at 8:43 AM, <[email protected]> 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. 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
-~----------~----~----~----~------~----~------~--~---
