Projects/Usability/NWI

The idea of NWI (Nested Windows Interface) emerged from the discussion about MDI (Multiple Document Interface) — so far each application had to implement the most suitable UI by its own (TDI in Konqueror, SDI in Okular) which led to inconsistent behaviour ("is closing the last document possible?").

Kpdf + manual "grouping" of KWrite and Konqueror

NWI is thought as uniform UI at one hand, while help to increase productivity by extending the idea of tiles and tabs on the other. Consider such example — you edit some data in one application (like html file in KWrite), you view the results using another application (like Konqueror). So despite there is no relation between KWrite and Konqueror, for this task — task you perform right now — those two applications are related. Currently if you run more than those two applications when you switch to KWrite, Window Manager (WM) will bring only KWrite to the front, so you have to bring to front Konqueror by yourself. This tiresome — with grouping, KWrite and Konqueror would act as one — you switch to group, all applications are put in front.

What is it?

Probably you are already familiar with several User Interface kinds — TDI, MDI, SDI, and so on. Some of them proved to be very useful, some of them not especially. In NWI world the most basic, yet the more flexible UI you can think of are those below:

Single Application Interface (SAI)

Konqueror in SAI mode

This is really the simplest UI, no magic here. Just application window with some data — if application window can hold only one document per window, it is SAI. Examples: Kpdf, Okular.

Application can can postpone "real" UI mode — "decide later whether this SAI or TAI". In other words, there is an option "show tabs" (per each application supporting such mode), which translates to:
off → start as SAI, user can add another tab later
on → from the start work as TAI (show even single tab)

Grouped Applications Interface (GAI)

More accurate name would be Tiling Applications Interface, but such name would conflict with Tabbed Applications Interface.

GAI is such container that tiles selected windows, so they are next to each other, vertically or/and horizontally, no space between. From geometrical point of view GAI container behaves as one window with many panes.

GAI has one shared titlebar (for container) plus at user request mini-titlebar for each window embedded into GAI.

When you finish grouping, you still can change the proportions of the group "panes" just like in KMail for example. You can also rearrange them — via context menu or simply like dragging docked windows.

Floating Application Interface (FAI)

The most common FAI container is desktop — you can tell whether container is FAI if the embedded windows can be moved in such way they overlap. Despite KDE desktop runs by default in FAI mode it is possible to switch it to another type.

The FAI container can be any non-root container too — being able to convert to/from any container, FAI helps reorganizing windows inside GAI.

Windows in FAI root container (desktop) can be minimized, in FAI non-root containers when minimized they are shaded instead — so they are directly accessible all the time.

When resizing the parent container the visible portions of the embedded windows are preserved (the embedded windows are "pushed"). If it is no longer possible, they are resized.

{ Other approach: show the scrollbars and allow to scroll the container to reach not visible embedded windows. }

Tabbed Applications Interface (TAI)

You know the special case of TAI already — TDI (Tabbed Document Interface), example: Konqueror. You can launch one Konqueror and then open multiple web pages, each per one tab.

TAI goes a little further — you can arrange several applications in tabs and put them into one window. So in one tab you can have Konqueror displaying web page, and in the second tab you can have Okular displaying pdf file.

By default tabs are shown at the top of the window, but user can configure them to show on left, bottom or right.

Nested Windows Interface (NWI)

Once the container is arranged, you can think of it as a window. And such window you can put into another container — thus nesting containers. So in general, such UI is called NWI, Nested Windows Interface.

You can configure each container type (+ desktop separately) to show shared menu per whole container — menu of the active application pane. Shared menu goes "up" as it can (as far container accepts shared menu).

Shared menu — default settings:
[ ] desktop
[ ] GAI
[ ] FAI
[x] TAI

Features

Containers cannot get focus — only the applications within can get focus, however on the list of the windows they are listed as they could get the focus (you can think of the container as focus-proxy).

Session management

When you turn the session management on (at KDE level), SM not only restores the applications, but also recreates grouping.

It is also possible to save application set of the container as preset (like: Kwrite+Konqueror) and then later launch such group at once — without recreating the group manually.

Taskbar presentation

group list in the taskbar

Taskbar shows the first-class windows — i.e. windows that are not embedded into any containers. When user clicks LMB on container entry in the taskbar, the list of all embedded applications is shown.

Managing the containers

Except for the root container (the desktop) empty containers are not allowed. Thus you have to point out which windows you would like to group or convert one of the windows to be container and add another window to it.

Arranging windows as container

1. launch applications as you like
2. RMB on the desktop to get context menu
3. choose "select windows"
4. select desired windows
5. RMB on the desktop to get context menu again
6. choose "group selection" — container is created

To select windows:

• with Shift+LMB pressed down select region over the windows (like in KSnapshot)
• with Ctrl pressed down click LMB on the window (to deselect click again)

You can also run any switcher when selecting — this is useful for FAI containers.

Incremental adding

Creating GAI by adding hollow application

You can:

• add the application as current one
• add the duplicate of the current application (i.e. it "copies" application and the document)
• add "hollow" application — after that you drag&drop desired application or start new, it will be "sucked" into the container
• drag&drop application directly to the container without creating hollow application

There can be only one hollow application per entire KDE (all desktops). If user tries to create new hollow application, the previous one disappears. Existence of hollow application indicates that the next user action will be adding application to that container (thus drag&drop is easier in such case).

Disassembling the container

• user can convert any container to any other type (for example FAI to GAI)
• user can tear off any window from the container to other container by drag&drop, even if the source and target containers are different types

Tearing off, from accepting container point of view is really adding application.

Please note that moving embedded window within container and tearing it off are two distinct actions, i.e. while moving the application (in FAI for example) the application cannot "fall off" the container.

Closing documents, applications and windows

Empty containers (except for desktop) are not allowed, empty applications (without document opened) are allowed.

• close current document
• close current application
• close current application siblings (i.e. close all children of the parent, except the current one)
• close current window
• close topmost container (not counting desktop)

Default options for non SAI containers:
[ ] closing document closes "its" application if there are sibling instances of that application within container
[x] do not allow to close last application in container
    [x] instead of closing last application in container, close the document only

Closing entire container means each application quits, not just closes its "pane". This difference is important for systray applications — in other words, such applications are not torn off when their parent-container closes.

Special container menu items

Accept new application (add hollow application)
Convert to...

• GAI
• FAI
• TAI

Save set as...

Default key bindings

Closing:

• close current document [ctrl+w]
• close current application [ctrl+q]
• close current application siblings <none>
• close current window [alt+f4]
• close topmost container [alt+shift+f4]

Changing container type:

• to GAI <none>
• to FAI <none>
• to TAI <none>

Adding applications:

• empty copy [ctrl+n]
• duplicate [ctrl+d]
• hollow [ctrl+h]
• start direct dragging [ctrl+LMB]

Switchers

Switcher is a program that lets user switch from application to application. Visual appearance is up to switcher. User can choose switcher which she/he likes as with KDE theme.

There is one primary switcher, additionally having auxiliary switchers is possible. The difference between the primary and auxiliary switcher is how they are used. In order to activate primary switcher user has to press and hold mod key plus navigation key (like [alt+tab]). At that point primary switcher is on and to keep it running user has to hold down the mod key all the time. Switcher will be operational until user commits the switch (releasing mod key) or cancels the switch (mod+[escape]). Auxiliary switcher is triggered by single keystroke (for example [F8]), there is no need of pressing any key all the time as with primary switcher. Switcher will be operational until user commits the switch (pressing the [enter] or clicking LMB) or cancels the switch ([escape]).

One of the auxiliary switcher can be used as primary switcher. Mod is any modifier key except [ctrl] and [shift]. { Original concept — either [alt] or [win] — but it seems limited, why [meta] couldn't be mod key? }

When window is a container, after switch to it, the focus goes not to container but to active application within it. To do so, each container remembers its active application.

Exchange

Switchers are used for switching (focus change) applications but they have another purpose — exchanging applications. User can exchange current application to any other one (not only sibling) — after exchange the current application still has focus (exchange is not switch). Exchange means applications take each other "places" — in geometrical sense and in terms of containers hierarchy.

Keyboard shortcut actions

• (window, desktop) sequence switch
• (window, desktop, global) historic switch
• (window, desktop) spatial switch
• (window) container-smart switch

The ones marked "global" switch through all desktops, marked "desktop" switch only on current desktop, window actions are constrained to current container.

In TAI switches spatial up = spatial left and spatial down = spatial right (because of the tabs placement).

Scope of the switches:

• sequence — direct children only
• historic — direct children only
• spatial — all children (i.e. children, grandchildren, and so on...)

Container smart switches:

• GAI — historic,
• FAI — historic,
• TAI — spatial.

User can choose (option) if she/he prefers switch-wrap on or off (after last comes the first, after rightmost comes the leftmost, etc.) — for each switcher mode separately.

Default settings:
[x] sequence wrap
[x] historic wrap
[ ] spatial wrap

The order of the sequence switching depends on KDE language settings (i.e. it is the same as reading "order").

Default keyboard bindings

How to read it — first goes the container. It means the switch is bounded to that type of container. The second goes action. For example "desktop up" means this actions go to next upper window in current desktop. For auxiliary switchers the default shortcuts are the same, just [mod] key is dropped out (i.e. [left] instead of [win+left]).

Sequence switch:

• window previous [win+backspace]
• window next [win+shift+backspace]
• desktop previous [alt+backspace]
• desktop next [alt+shift+backspace]

Spatial switch:

• window up [win+up]
• window down [win+down]
• window right [win+right]
• window left [win+left]
• desktop up [alt+up]
• desktop down [alt+down]
• desktop right [alt+right]
• desktop left [alt+left]

Historic switch:

• window back [win+pgup]
• window forward [win+pgdn]
• desktop back [alt+pgup]
• desktop forward [alt+pgdn]
• global back [alt+ctrl+pgup]
• global forward [alt+ctrl+pgdn]

Smart switch:

• window previous [win+shift+tab]
• window next [win+tab]
• desktop previous [alt+shift+tab]
• desktop next [alt+tab]

Other actions:

• cancel switch [mod+escape]
• commit switch [mod+enter] (or just release [mod])
• exchange [mod+ins]

Primary switcher is activated by any of the above (except the last section) and stays active as long as mod is held or until user commits or cancels switch. Cancel does not undo exchanges made.