Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.0
    • Component/s: None

      Description

      Until now, all Pivot windows run within a single native host window (which can hold child windows). Some applications could, however, benefit greatly from the possibility of having multiple host windows ('parent windows'). For example, one could then use the possibility to use different monitors for each host window in a multi-monitor setup (e.g. one window 1 one monitor 1 for basic tasks, and window 2 on monitor 2 for heavy-duty 3d rendering).

        Activity

        Hide
        Greg Brown added a comment -

        This feature is complete.

        Show
        Greg Brown added a comment - This feature is complete.
        Hide
        Greg Brown added a comment -

        It is now possible to embed a standalone DisplayHost in an arbitrary AWT or Swing component. However, this has not been extensively tested, and some further work is necessary in DesktopApplicationContext.

        Show
        Greg Brown added a comment - It is now possible to embed a standalone DisplayHost in an arbitrary AWT or Swing component. However, this has not been extensively tested, and some further work is necessary in DesktopApplicationContext.
        Hide
        Greg Brown added a comment -

        > 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?

        Show
        Greg Brown added a comment - > 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?
        Hide
        Appddevvv added a comment -

        I need to build some wizards and other top-level windows for the desktop environment (and web I guess) and its important for these to be separate windows from a user experience perspective. I think you are saying that if I want these to be separate windows, I need to program them as such versus dialog windows and provide some plumbing to link them to other windows. 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.

        Show
        Appddevvv added a comment - I need to build some wizards and other top-level windows for the desktop environment (and web I guess) and its important for these to be separate windows from a user experience perspective. I think you are saying that if I want these to be separate windows, I need to program them as such versus dialog windows and provide some plumbing to link them to other windows. 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.
        Hide
        Greg Brown added a comment -

        No - this change will simply make it easier for developers to build applications that use multiple top-level native frames. Pivot dialogs (and all other Pivot windows) will still be constrained to the bounds of the native frame's (or applet's) client area.

        Show
        Greg Brown added a comment - No - this change will simply make it easier for developers to build applications that use multiple top-level native frames. Pivot dialogs (and all other Pivot windows) will still be constrained to the bounds of the native frame's (or applet's) client area.
        Hide
        Appddevvv added a comment -

        Would this address the issues that dialogs seem to only exist within the bounds of the parent window versus a separate free floating window (at least on the desktop)?

        Show
        Appddevvv added a comment - Would this address the issues that dialogs seem to only exist within the bounds of the parent window versus a separate free floating window (at least on the desktop)?
        Hide
        Greg Brown added a comment -

        Moving this to 2.0 since it will be a deeper change.

        • Eliminate suspend()/resume() - these methods are currently driven by the idea that an application is tied to one window, and they aren't supported in the browser at all
        • Remove all instance variables from ApplicationContext; move Display instance into DisplayHost; support multiple displays in DesktopApplicationContext
        • Eliminate DesktopApplicationContext instance; all application contexts will be entirely static
        • Maintain a static list of applications in an application context?
        • Note that there is a potential one-to-many relationship between Application and Display
        • Move HostFrame to top level?
        • Add HostDialog?
        • Move createTimer() call to main() (out of processWindowEvent())
        • Initialize Mac support in main()
        Show
        Greg Brown added a comment - Moving this to 2.0 since it will be a deeper change. Eliminate suspend()/resume() - these methods are currently driven by the idea that an application is tied to one window, and they aren't supported in the browser at all Remove all instance variables from ApplicationContext; move Display instance into DisplayHost; support multiple displays in DesktopApplicationContext Eliminate DesktopApplicationContext instance; all application contexts will be entirely static Maintain a static list of applications in an application context? Note that there is a potential one-to-many relationship between Application and Display Move HostFrame to top level? Add HostDialog? Move createTimer() call to main() (out of processWindowEvent()) Initialize Mac support in main()

          People

          • Assignee:
            Greg Brown
            Reporter:
            Mathias Versichele
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development