pivot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "aappddeevv" <aappdde...@verizon.net>
Subject RE: [jira] Commented: (PIVOT-418) Multiple host windows
Date Sun, 06 Jun 2010 18:14:28 GMT
Okay. I understand your comments. I'll try this out and see how it looks.
And of course, knowing nothing about the rendering layer, perhaps there is a
way that the rendering layer or application context understands when it is a
desktop or not and can do different things. But I'll try the standard
approach before anything else.

> In some frameworks, if you specify a dialog window with a parent of
another window, they are 
> min/max'd together and are not constrained as you described

That is also how Pivot windows behave. However, all Pivot windows live
within the Pivot "display", which is itself entirely contained within a
single native frame or applet (specifically, it lives in a "display host"
which is a child of the native window). That's why Pivot windows appear to
be constrained to the client area of the native window. This is by design -
it gives Pivot complete control over the appearance of all UI elements
including the window and its associated trim, and allows us to create a user
experience that otherwise would not be possible (for example, "sheet"
windows are supported on OS X but not on other platforms). Windows in other
RIA frameworks behave similarly.

However, there may be times when opening multiple native frame windows in a
Pivot application is desirable. Currently, this is possible but not easy.
The solution proposed in this ticket would simplify the process by allowing
an application to create multiple displays, each of which would be contained
in its own display host and native frame.

That said, this is actually considered to be something of an edge case.
Generally, when a Pivot application requires a dialog or an alert, the
recommended practice is to use a sheet or a prompt instead. Sheets are
attached to the top of the owner window and can't be moved by the user. As a
result, they can't be dragged "off screen" like a frame can. Perhaps this
approach would work for your application?

View raw message