View source for Ideas for a new Window Manager

Cinc: Obviously these ideas are inspired by stuff usually found on X. The WM needed for this project isn't the kind of
WM X uses. I think WM is the wrong word for it anyway. What's needed is primarily a compositing engine which is in charge
of allocating surfaces, giving them to the app, the app draws into them and the compositor puts it on the screen.
Input support is probably needed for this layer, too, so the compositor may move and stack windows correctly.
The final appearance of the graphics drawn on the surfacces is up to the applications not the compositor. It must be
that way IMHO because no compositor coder can imagine what app developer will finally do with a given infrastructure.
E.g. creating close, maximize etc. widgets in the compositor/WM effectively prevents the application developer from
adding his own widgets or removing the given one. OTOH if there's a documented way to tinker with (per window) then it's ok.

The compositor/WM should be inspired by the Presentation manager (PM) found in OS/2. Granted it's old technology it's
unbelievable flexible. It's possible for the coder to alter the handling of every window/widget by subclassing the window procedures
provided by the system. For example the information area found in [http://www.os2world.com/cdwriting WPS-wizard] uses
this feature. PM is directed to order all the window areas differently (titlebar, close/maximize, client area) to give room for the
information area. The coders of PM never thought about the possibility to add such informations to windows back when they
did PM. It's not a hack and there's no need to change any WM code to get this to work.

Lexip: What about the common look and feel of all the headers of the client windows? I'd like to have a common theme for example, and all apps should have a header (with a little icon, and the close/minimize/... buttons) that paints according to that theme file. 

Cinc: ACK. What I mean is the WM should not restrict the developer from adding/removing widgets, from modifying the way how things are done for a particular window (e.g. positioning of widgets). This also applies on how things are painted. If the developer decides to remove all widgets and use an ugly custom theme (which is bad) he should be free to do so.


=== Main Features ===
* Built i18n (internationoalization)
* .prestartup and .poststartup files
* Multiscreen support (with possibility of virtual desktops 1 being on physical screen 1, while having virtual desktop 4 on screen 2)
** Preview of desktop X on desktop Y. Like you have one desktop with the presentation on desktop X and on desktop Y (your main display for example) you see a resizable preview so you could have your script on the main display and still step through the slides
* Anti aliasing
* Virtual desktops (different layouts and number of desktops - 4x2, 3x3, ...)
* Storing sessions. Cinc: not sure the WM should do that
* 100% ewmh complient. Cinc: ???? if this is some X thingie it's probably not needed -> Lexip: yeah, it's X stuff, but if we want to support starting Xapps, and we should do that, then we gotta be ewmh complient with our WM/compositor
* Large desktops (scrolling and paging)
* Themes with possibility of associating a background image or pattern (i.e. blackbox)

=== Client Window Features ===
* Client window header can be top/bottom/right/left (with vertical text if necessary).
* Window manager keeps track of stacking order of all client windows
* Sticky windows - Possibility to show clients on all or few or just one virtual desktop
* Virtual desktops with resolutions different from the physical screen resolution.
* Ability to display multiple virtual desktops on one physical screen.
* Maximization:
** Maximize to given area
** Maximize to actual screen
** Maximize to more than one screen
** Maximize vertically only
** Maximize horizontally only
* Clients can influence their states:
** Maximized
** Stacking order
** Shading
** Stickiness
** Desktop(s)
* Window in Window handling for MDI applications
* Edge snapping while move- resizing a client window
* Client window shading
* Store client window properties per application (size, position, etc)
* Client window can drop shadow
* Application icons in client window headers
* Different focus models (click to focus, focus follows mouse, ...)

=== Docking Area Features ===
* Allow having multiple docking areas
* Docking areas can be hid (approaching mouse makes them appeare)
* Transparency
* Drop shadow

Cinc: The WM should not be in charge of this. The Dock (or whatever) is just an application and should be treated as one.

Lexip: question again about the theme. If the WM/compositor is not in charge of the docker, how can we set a common theme to it?

Cinc: The WM/OS should provide the default bitmaps for it (or better any app) which can be queried by the app. Changing the theme will automatically change these BMPs. For buttons and alike the OS should provide a default drawing function which will ensure every app which uses the default automatically has a similar look and feel.

=== Menu Features ===
* Dynamically filled menus (piped menus). Cinc: That's mostly up to the application IMHO with the exception of system menus.
* Menu configuration can be separated over several files, i.e. one file for each submenu section
* All the submenues can be called separatly (by key combination for example)
* Dockable menues (like blackbox)
* Transparency
* Drop shadow
* Icons for entries

Cinc: I think the WM/compositor should only provide the infrastructure to show menus. The final appearance/usability is up to the app.

Lexip: Here I'm talking about the system menu. The menu where you can start all you apps, or anything that you'd like to have in a menu. System menu is startable by right clicking on an empty spot on the background, or by keying-in some keyboard combination.

Cinc: IMHO such a system menu also should be a dedicated app (so it is replacable without tinkering with the WM). This app monitors the input queue and reacts when the configured message arrives (keyboard/mouse/whatever). Or alternatively the WM sends a message to tell this app to show the menu .

=== Configuration Features ===
* Configuration changes take effect withou restarting the wm
* Every single command is configurable to hava a certain keyboard or mouse click shortcut.
* Shortcuts are simple keyboard shortcuts (i.e. Ctrl+F1), or so called keychains known from Emacs editor (i.e. Alt+e+x)
* The wm allows mouse gestures, and keyboard mouse combined input (i.e. ctrl+mouse1 click, etc.)
* Single, double, or even tripple clicks call different actions (attention with patent from M$ in USA)
* Clicking the client window header is a different action than clicking the clients body for example. Cinc: can easily be done by treating those two as two coupled windows.

=== Extensibility ===
* Programming interface (every single command can be called from outside).
* Allow writing modules and applications that interact with the wm. Cinc: ah ok, addresses some of my concerns from above

=== Other ===
* Ability to play (opengl) games in fullscreen on virtual desktops instead of physical screens. (Today, if a game goes fullscreen, it'll either spread over all physical screens or the other screens are switched off... which is not nice if you would like to have the server stats/a map/whatever on the secondary screen).

Lexip: that sounds as a nice idea to me. we gotta do that

[[Category:Ideas]]