MultiView Layout

Overview

This document describes possible configurations to enable the user to change the layout of multiviews.

Docking Windows

• One possible solution is that we make the render view frames dockable frames.
• If I remeber correctly, this alternative was discarded since the Qt docking windows sometimes behaved unpredictably.

Drag And Drop

• This configuration can handle rearranging visible windows.
• Each View frame's title bar can be treated as a dragging handle
• Once clicks the handle for any view frame and drags it over another view frame and drops it there. As a consequence, the two view are swapped.

Pros

• Possible to pop a view frame out and maximize it, if required.
• All render windows are visible at all time (except when one maximizes a poped-out view), hence one does not have to name or identify the views explicitly.

Cons

• Split layout cannot be changed once created without destroying the render windows and recreating them.

eg.

Cannot change from old layout to new layout without having destroyed and recreated atleast one render window.

Are you referring to Qt not being able to go from the old layout to new layout without destroying and recreating a render window? Or are you referring to our implementation of multiview? We can enhance our multiview implementation to support this (which means it isn't currently support, so this is a con for all suggestions on this page, not just drag & drop), and I believe we can do it without destroying and recreating a render window. Clinton 15:09, 25 Aug 2006 (EDT)

I am referring to our implementation. Utkarsh 14:08, 29 Aug 2006 (EDT)

On further thinking, this is not true. One can split the views such that there are 4 windows move the views around and then remove the extra view to acheive the above. Utkarsh 16:21, 5 Sep 2006 (EDT)

Window Selection Menu

• It may be possible for the user to create empty view frames without any render windows in them.
• It may be possible for the user to close view frames without destroying the render module that the frame contained.
• Every render window is automatically given an editable title.
• Every view frame shows a window selection menu with names of all the render windows available. Some of these render windows may be hidden, while others may be already placed in some view frame. The menu should visibly distinguish between the two.
• When the user selects a render window from the menu, that render window becomes visible in the selected frame. If the render window was already visible in some other frame, that frame becomes empty.

Pros

• Possible to pop a view frame out and maximize it, if required.
• Split layout changing and render window creation/destruction are decoupled.

Cons

• Render Window have to be named. These names will generally be arbitrary (unlike VolView where they are "Left|Right|Top|Bottom" views etc.
• Since render window deletion is decoupled from frame closing, the user needs to explicitly remove unused render windows.
• There's added complexity since we increased the available number of tasks: create/delete frames, create/delete render windows, name/rename render windows.