Popups that are "tied" to other components

[Todd Volkert <tv...@gmail.com>]

Right now, our Popup class has the notion of an affiliate component,
which effectively ties the popup to that component.  Specifically, it
aggressively closes the popup if the "showing" state of the affiliate
changes, the absolute location of the affiliate changes, or the
ancestry of the affiliate changes. This behavior dictates that
PopupSkin listen for events from the whole ancestor hierarchy of the
affiliate component, which is arguably not the prettiest thing in the
world to do.  We're considering bagging this concept, but I wanted to
see what you guys thought.  Consider the following points:

Arguments in favor in keeping this concept:

* Eliminating this would mean that if you programatically caused the
affiliate to move, the popup would be out of place.  Take, for
example, a ListButton.  The user clicks to open the popup, then your
application gets a data update from a messaging service you've set up,
causing you to update the UI and causing the ListButton to move down.
Now, the popup looks "disconnected" from the button that opened it.

Arguments in favor of eliminating this concept:

* WPF explicitly documents that it does not handle this.  Users of
this list can attest to how Swing handles it, but my guess is that
they don't.  So other toolkits have punted, which gives us precedence
to do so as well.  After all, the use case listed above is a corner
case that won't happen very often.

* The affiliate concept as it's currently defined adds to the
complexity of the class, both in terms of design and implementation.
It's not a "one-size-fits-all" tool, already having caused us to keep
on adding definitions of what it means for a popup to have an
affiliate, which is often indicative of a misguided design.

Thoughts?
-T

Re: Popups that are "tied" to other components

[Todd Volkert <tv...@gmail.com>]

Thanks for the input Noel and Chris; we're gonna get rid of the affiliate.

-T

On Mon, Mar 23, 2009 at 7:45 AM, Noel Grandin <no...@gmail.com> wrote:
>
> Swing requires the programmer to explicitly move/hide the popup himself
> if the parent component changes position/visibility.
>
>
>

Re: Popups that are "tied" to other components

[Noel Grandin <no...@gmail.com>]

Swing requires the programmer to explicitly move/hide the popup himself
if the parent component changes position/visibility.

Re: Popups that are "tied" to other components

[Christopher Brind <br...@brindy.org.uk>]

Hi,

>From a Flex point of view most popups are driven by the mouse position on
the stage, derived from the component that was clicked.  As such, the popup
remains where it was opened.

The same is also said for those components which aren't opened explicitly
through a show function, e.g. ComboBox.  If the combobox moves the popup
stays at the position it was opened at.  (Sample MXML and SWF attached)

Besides which, does the user want to be chasing popups all over the screen?
If they have clicked to open something it should stay near at the position
it was opened regardless of whatelse is happening, IMHO.

So I think this is pretty much expected, thus I vote for eliminating the
affiliate.

Cheers,
Chris



2009/3/22 Todd Volkert <tv...@gmail.com>

> Right now, our Popup class has the notion of an affiliate component,
> which effectively ties the popup to that component.  Specifically, it
> aggressively closes the popup if the "showing" state of the affiliate
> changes, the absolute location of the affiliate changes, or the
> ancestry of the affiliate changes. This behavior dictates that
> PopupSkin listen for events from the whole ancestor hierarchy of the
> affiliate component, which is arguably not the prettiest thing in the
> world to do.  We're considering bagging this concept, but I wanted to
> see what you guys thought.  Consider the following points:
>
> Arguments in favor in keeping this concept:
>
> * Eliminating this would mean that if you programatically caused the
> affiliate to move, the popup would be out of place.  Take, for
> example, a ListButton.  The user clicks to open the popup, then your
> application gets a data update from a messaging service you've set up,
> causing you to update the UI and causing the ListButton to move down.
> Now, the popup looks "disconnected" from the button that opened it.
>
> Arguments in favor of eliminating this concept:
>
> * WPF explicitly documents that it does not handle this.  Users of
> this list can attest to how Swing handles it, but my guess is that
> they don't.  So other toolkits have punted, which gives us precedence
> to do so as well.  After all, the use case listed above is a corner
> case that won't happen very often.
>
> * The affiliate concept as it's currently defined adds to the
> complexity of the class, both in terms of design and implementation.
> It's not a "one-size-fits-all" tool, already having caused us to keep
> on adding definitions of what it means for a popup to have an
> affiliate, which is often indicative of a misguided design.
>
> Thoughts?
> -T
>