Projects/Usability/NWI: Difference between revisions

From KDE TechBase
No edit summary
No edit summary
Line 25: Line 25:
[[File:Sai-konqueror.png|240px|thumb|right|Konqueror in SAI mode]]  
[[File:Sai-konqueror.png|240px|thumb|right|Konqueror in SAI mode]]  


Application can can postpone "real" UI mode — "decide later whether this SAI or TAI". In other words, there is an option "show tabs", which translates to:
Application can can postpone "real" UI mode — "decide later whether this SAI or TAI". In other words, there is an option "show tabs", which translates to:<br>
[ ] start as SAI, user can add another tab later
[ ] start as SAI, user can add another tab later<br>
[x] from the start show as TAI (show even single tab)
[x] from the start show as TAI (show even single tab)


Line 35: Line 35:
GAI is such container that tiles selected windows, so they are close together, next to each other — vertically or/and horizontally. From geometrical point of view GAI container behaves as one window with many panes.  
GAI is such container that tiles selected windows, so they are close together, next to each other — vertically or/and horizontally. 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. By default each application menu stays within its pane but it is possible to configure it so the one menu is displayed per whole container — menu of the active application pane.
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 by like dragging  
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 by like dragging  
Line 60: Line 60:


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.
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.
For containers (non-SAI) by default each application menu stays within its pane but it is possible to configure it so the one menu is displayed per whole container — menu of the active application pane.
<font color=green>make one global option, so it would affect desktop as well and we would have Mac menu for "free"?</font>


== Features ==
== Features ==
Line 131: Line 135:


== Switchers ==
== Switchers ==
Classic alt+tab switch (application switch) now has a bit different meaning — it switches top windows. If top 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.


== Keyboard shortcuts ==
== Keyboard shortcuts ==
Line 145: Line 151:


(Switcher is activated by any of the above and stays active as long as mod is held.)
(Switcher is activated by any of the above and stays active as long as mod is held.)
TAI: Left/right would be configurable to either switch instantly between siblings i.e. like current tab switching, or pop up an alt-tab-like tree switcher (or I suppose, whatever people come up with for fancy switchers). Down/up
would go immediately to the switcher, with up starting at the active window's parent.

Revision as of 17:39, 29 April 2009

This is summary-in-progress, thus there are question notes in the text.

From editor :-) -- how to add [edit] buttons per each section/heading?

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?"). 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.

Why?

It happens almost every day — 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. Would it be useful if those two applications work temporarily as one — a group?

Kpdf + group-wanna-be of KWrite and Konqueror

Let's say you launched Kpdf as well. Traditionally when you switch from Kpdf to KWrite, Window Manager (WM) brings 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.

Whenever you feel it would be more natural to put several applications as one group (because of the common task, or common data, or just for fun), NWI lets you do it — as tiles or as tabs.

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 SAI, GAI and TAI.

Single Application Interface (SAI)

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.

Konqueror in SAI mode

Application can can postpone "real" UI mode — "decide later whether this SAI or TAI". In other words, there is an option "show tabs", which translates to:
[ ] start as SAI, user can add another tab later
[x] from the start show 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 close together, next to each other — vertically or/and horizontally. 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 by 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.

Resizing FAI?

Tabbed Applications Interface (TAI)

You know the special case of TAI already — it is TDI (Tabbed Document Interface). The well-known example of TDI application is 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.


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.

For containers (non-SAI) by default each application menu stays within its pane but it is possible to configure it so the one menu is displayed per whole container — menu of the active application pane.

make one global option, so it would affect desktop as well and we would have Mac menu for "free"?

Features

Containers cannot get focus — only the applications within can get focus.

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 container state as preset (like: Kwrite+Konqueror) and then later launch such group at once — without recreating the group manually.

Taskbar presentation

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.

group list in the taskbar

Actions

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)

Picker for easier selecting? Maybe none, but allowing to run switchers?

Incremental adding in GAI

Creating GAI by adding new application

Incremental adding in FAI

D&D?

Incremental adding in TAI

Just use "create new tab" like in Konqueror.

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, even if the source and target containers are different types (tear off by d&d or explicit RMB and choosing "ungroup"?)

Closing documents, applications and windows

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

  1. close current document
  2. close current application
  3. close current application siblings (i.e. close all except the current one)
  4. close current window/container
  5. close topmost container (not counting desktop)

Options for non SAI containers:

  • do not close the last application in container (on close the application is re-run, so after closing it is empty)
  • close document closes the application also if there are sibling instances of that application within container

Switchers

Classic alt+tab switch (application switch) now has a bit different meaning — it switches top windows. If top 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.

Keyboard shortcuts

  • wm-container-wrap-tabbed
  • wm-container-wrap-tiled
  • wm-container-wrap-floating
  • wm-container-split (win-t?) — the last (not the best name, would need a better description in the actual UI) creates a new 'empty space for child', that will absorb the next-created window. So, new tab, new pane in tiled, new window (meaning a title bar and frame) in floating.
  • historic previous  mod+back
  • historic next      mod+shift-back
  • spatial previous   mod+left  (RTL: mod+right)
  • spatial next       mod+right (RTL: mod+left)

(Switcher is activated by any of the above and stays active as long as mod is held.)

TAI: Left/right would be configurable to either switch instantly between siblings i.e. like current tab switching, or pop up an alt-tab-like tree switcher (or I suppose, whatever people come up with for fancy switchers). Down/up would go immediately to the switcher, with up starting at the active window's parent.