Message from discussion
Ensuring popup is on top
Received: by 10.58.189.35 with SMTP id gf3mr7025359vec.11.1352816553617;
Tue, 13 Nov 2012 06:22:33 -0800 (PST)
X-BeenThere: google-web-toolkit@googlegroups.com
Received: by 10.52.240.239 with SMTP id wd15ls9077278vdc.5.gmail; Tue, 13 Nov
2012 06:21:46 -0800 (PST)
Received: by 10.52.91.109 with SMTP id cd13mr4377283vdb.15.1352816506408;
Tue, 13 Nov 2012 06:21:46 -0800 (PST)
Date: Tue, 13 Nov 2012 06:21:45 -0800 (PST)
From: David <levy...@gmail.com>
To: google-web-toolkit@googlegroups.com
Message-Id: <9b16d463-a7d3-4f47-9bbc-ed05295de525@googlegroups.com>
In-Reply-To: <120fa895-aabf-4419-b8d8-0327935aac54@googlegroups.com>
References: <120fa895-aabf-4419-b8d8-0327935aac54@googlegroups.com>
Subject: Re: Ensuring popup is on top
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_Part_1635_14014442.1352816505903"
------=_Part_1635_14014442.1352816505903
Content-Type: multipart/alternative;
boundary="----=_Part_1636_22183564.1352816505903"
------=_Part_1636_22183564.1352816505903
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
I would think that z-index is the better solution. Your mechanism for
opening the popup ( rather than the popup itself) should be the one making
the determination as to which z-index to use.
Beyond a "system error" type of message, I personally don't think it's good
UX to have popups throwing popups... but a requirement is a requirement.
On Tuesday, November 13, 2012 8:05:04 AM UTC-5, Thomas Lefort wrote:
>
> I have a use case where I do need to show one dialog on top of the other.
> The problem is that those dialogs are reused across the application and if
> the one that should be on top for the use case happens to have been open
> (in another use case) before the one that should be below, it is not
> visible (covered by the other one) because (I believe) it was inserted in
> the DOM before.
>
> Is there an obvious way of doing this? Currently, the two strategies I can
> think of to make sure the show method could always ensure that a dialog is
> on top of the others are the following:
> - zindex, scanning the list of open popups and check for the higfhest
> zindex and setting the zindex of the one I am showing to zindex + 1
> - detach/reattach the popup to the DOM.
>
> I gave a quick try to the later one using the following code, which seems
> to work:
> @Override
> public void show() {
> Widget parent = getParent();
> if(parent instanceof Panel) {
> ((Panel) parent).remove(this);
> ((Panel) parent).add(this);
> }
> // blabla do the rest
> }
>
> Any idea if this detach/reattach strategy can have any side effect?
>
>
>
------=_Part_1636_22183564.1352816505903
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<div>I would think that z-index is the better solution. Your mechanis=
m for opening the popup ( rather than the popup itself) should be the one m=
aking the determination as to which z-index to use. </div><div>=
Beyond a "system error" type of message, I personally don't think it's=
good UX to have popups throwing popups... but a requirement is a requireme=
nt.</div><br><br>On Tuesday, November 13, 2012 8:05:04 AM UTC-5, Thomas Lef=
ort wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I have a use case wh=
ere I do need to show one dialog on top of the other. The problem is that t=
hose dialogs are reused across the application and if the one that should b=
e on top for the use case happens to have been open (in another use case) b=
efore the one that should be below, it is not visible (covered by the other=
one) because (I believe) it was inserted in the DOM before.<br><br>Is ther=
e an obvious way of doing this? Currently, the two strategies I can think o=
f to make sure the show method could always ensure that a dialog is on top =
of the others are the following:<br>- zindex, scanning the list of open pop=
ups and check for the higfhest zindex and setting the zindex of the one I a=
m showing to zindex + 1<br>- detach/reattach the popup to the DOM.<br><br>I=
gave a quick try to the later one using the following code, which seems to=
work:<br> @Override<br> public void sh=
ow() {<br> Widget parent =3D getParent=
();<br> if(parent instanceof Panel) {<=
br> ((Panel) parent=
).remove(this);<br> =
((Panel) parent).add(this);<br> }<br>=
// blabla do the rest<br> &=
nbsp; }<br><br>Any idea if this detach/reattach strategy can have any=
side effect?<br><br><br></blockquote>
------=_Part_1636_22183564.1352816505903--
------=_Part_1635_14014442.1352816505903--