Bug 59338

The Enlightenment window manager (http://enlightenment.org) has IMHO the most 
versatile management of screen real estate.  The concept Enlightenment has that 
I would strongly like to see in Kwin is to have both "virtual desktops" and 
"multiple desktops".  In Enlightenment terminology, a "virtual desktop" can be 
bigger than the screen size: it is an NxN square arrangement of screens.  Kwin, 
by comparison, when using the maximum 16 desktops, is in an 8x2 configuration.  
At a higher level of organization are Enlightenment "multiple desktops".  You 
set the size of your "virtual desktops" to, say, 3 (meaning 3x3), and you set 
the number of "multiple desktops" to, say, 5.  You then have 5 virtual desktops, 
each of which is an area 9 times larger than the screen size, organized in a 
grid of 3 by 3.  What is valuable about this organization is that one can have a 
desktop larger than one screenful devoted to a particular task: one can devote a 
3x3 grid to a task.  Different keyboard shortcuts move between multiple desktops 
and within a desktop that is larger than one screen (within a virtual desktop).  
 The difference is more than just convenience of navigation around your screens; 
one could emulate this usage by opening task windows in Kwin with some empty 
surrounding windows, spacing them say in desktops 1-4 and 7-10 and 11-14, but 
the geometry is here limited to 2x2 clusters, and you can't expand that or 
change it on the fly.

Enlightenment is apparently still under some development but there has not been 
a significant release in years, and as XFree86 develops, Enlightenment is 
showing more and more problems.  This is forcing me into trying new things, such 
as KDE, which has much else to offer, but Kwin does not yet have the flexibility 
of Enlightenment in several key areas: the scheme for using multiple/virtual 
desktops is one of the two most important (configurability of mouse and keyboard 
events is the second).

*** Bug 78319 has been marked as a duplicate of this bug. ***

*** Bug 56157 has been marked as a duplicate of this bug. ***

*** Bug 124141 has been marked as a duplicate of this bug. ***

Three things for an IonMode 
1. IonMode should be easy to configure (ION is it not - what the hell is LUA? ;)).
2. IonMode-tabs can resized easily and other windows will be resized too.
3. Every IonMode-tab should have an shortcut.

In my opinion IonMode will be a great improvement for handicapped and old users too.

Actually, Victor's #3 is an interesting idea.  It could work like Konqueror's "CTRL-" mode.  You'd press CTRL, and each window would get a pop-up hotkey.  Maybe the Window key would be a better default mapping, but still, I like the idea.

Ok, I should not talk about an IonMode - better is a wmii-mode :) The arguments about a dynamic window managment in this text are interesting: http://wmii.de/index.php/WMII/DynamicWM

How can I change the default wm für KDE?

Using different WM with KDE: http://ktown.kde.org/~seli/kdewm/

I think it's not a solution to use another WM with KDE, you will miss all the configuration options kwin has.
This bug doesn't mean that other WMs are better, they just have one certain feature kwin is missing to be near perfection ;)

You 're right, Dennis, and a lot of WM's can't work without problems with the KDE-Desktop. 

And a lot of KDE-Features are too limited (WIMPish) that they ever would work well with the LarsWM-, Ion-, or wmii-concepts of _managing_ windows. The basic difference between Kwin and the mentioned WMs is, that Kwin simply delegates the _management_ task to the user and only provides an management-input interface (well actually most other WMs do so, but that shows how limited they are).

Besides this, Kwin concentrates on tasks which have nothing todo with window _management_, like drawing a fancy border around client windows, delegating special ICCCM-breaking classes of applications to complex addons like the kicker and so on...

any development on this?
anyone tried getting ion-like tiling in kwin?

*** Bug 133927 has been marked as a duplicate of this bug. ***

*** Bug 107554 has been marked as a duplicate of this bug. ***

wish exactly the same features (like in wmii, with split move : left , right , up, down)
nobody allready done a mode like that ? 

*** Bug 141910 has been marked as a duplicate of this bug. ***

Could fakexinerama be used as a workaround to get the tiling?

No, that would miss many of the features, like being able to change the size of the tiling.

My suggestion is in the same direction. For the benefit of quicker reference: http://bugs.kde.org/show_bug.cgi?id=120595

*** Bug 164985 has been marked as a duplicate of this bug. ***

If anyone has any ideas or concepts that have not yet been outlined in this bug or its duplicates please add a comment or E-mail either myself or the KWin mailing list. I would like to have a final implementation plan completed by the time 4.1 is tagged (July 22nd).

Lucas: Now that 4.1 was not just tagged but released, do you have an implementation plan? Maybe it would be nice to share it on the list for discussion.

To summarize, I think the most important parts of the implementations should be:
1.) Empty desktop->new window: Make it maximized
2.) Add a second window it would get split horizontally in the half
3.) If you resize the border between the two windows, one gets larger, the other smaller, so there is never! some part of the desktop visible (if you have >=1 window open).
4.) If you have a many open windows in this tile layout, it is absolutely required to have directional navigation (go to the window above/below/left/right)
5.) Some kind of tabbing (or for my personal opinion even better, stacking the column like in wmii) is absolutely required, if you want to manager more than let's say 4-5 windows efficiently on a desktop.
6.) (Fixed size only?) dialog windows should be placed above the tiling layer.

Actually these are IMHO the points which have all tiling WMs in common, they just differ in small things, whether the windows are just presented in a linked list, and the first is in the first column, or whether they are "column-based" like wmii, which IMHO works best for managing lots of windows.

Implementation-wise, do you think all this is possible as a KWin plugin (last time i looked and talked to Aaron (or was it Lubos?)) or would it be a  core part or KWin (option checkbox disabled by default)?

I do think, that such a feature is probably for now more orientated at power users, but this is just because no "big" DE ever implemented something like this. Remember browser tabs (a similar concept) was at first also probably quite "geeky", but nowadays every browser (=nearly every user) uses them, why not do the same for tabbed application windows? 

I had a plan ready but after some experimentation I found that it just didn't work in reality. So instead of writing up a plan first I think I'm just going to do it by ear, seeing what works and what doesn't.

From your list:
1) I have it so that there must be at least two "frames" in the grid, if you try to "add" a window to an empty grid the command automatically gets changed to "split" instead
2) Already done (I'm working in branches/work/kwin-grid, lots of hardcoded settings, highly unstable and only the ability to add windows to the grid at the moment)
3) Done
4) Planned
5) Window tabbing is a separate feature, I have made it tabbing-safe however so as soon as support is written it will immediately work with the grid. Noone is saying you can't still use the task manager though.
6) Currently I have it planned that if a window is opened that is smaller than the parent frame it is displayed as a floating window, if it's larger it gets added to the frame

I'm adding this directly to the KWin core and it will be possible to have it half-enabled (Always open windows floating, but can manually add to grid) by default as it does not interfere with the current floating user interface.

With larger and larger screens tiling is becoming a less and less poweruser thing. I would really like to have the basic add/remove/split functionality so easy to use that casual users can make use of it (Need some way of making graphical overlays that show how windows will behave, might need to rely on compositing for this bit).

For those interested this is a direct copy/paste from my tiling TODO, it wasn't written to be published so some points may be confusing/duplicated/contradictory. Also keep in mind that I don't think some of these will work in reality so there is no guarantee any of them will make it in:

Window grid/Ion functionality:
    ! http://bugs.kde.org/show_bug.cgi?id=59338
    ! http://bugs.kde.org/show_bug.cgi?id=107554
    ! http://bugs.kde.org/show_bug.cgi?id=165933
    ! Alt move can also be changed to meta, somehow handle this?
    ! Somehow don't conflict with modifiers for window movement
        - Button needs to be pressed when the mouse button is released to activate grid switch. This means it
          will not interfere while keeping the previous features.
    ! Draw borders seperately to window decorations, this is so empty frames that are not merged will still
      have their borders shown
    Definitions:
        - Grid   - The underlying grid (Also refers to all tiled windows?)
        - Cell   - A single cell of the grid
        - Frame  - One or more cells in a rectangular pattern that is used to contain a window
        - Border - The space between and around frames, used for changing the grid sizes
        ? Decoration - The non-tiled window border decoration
    - Configuration:
        - Resizing a window in the grid will...
            - ... resize the grid
            - ... span the window across frames
        - [X] Add new windows directly to the grid
            - New windows are added to the frame...
                - ... of the currently active window
                - ... that the mouse cursor is currently hovering
        ? Maximize windows to...
            - ... the screen
            - ... the surrounding frame
    - The plan is to make it possible to move windows into and out of a grid seamlessly as easily
    ! Is it possible to resize just one size of a grip (Creates a new frame?)
    - Borders are always 4px in width by default
        - Add new decoration components for horizontal and vertical borders and corners
            - Seperate intersections to corners?
        - Display borders just like how decorations are done, i.e. per window, when window is on
          top display the borders that touch it
        - Don't display off-screen borders as they will interfere with other screens
    - Grid has grips as borders, just click and drag to resize (Lock supported)
    - Grid is defined on a per-screen basis, grids can by copied to other desktops if needed
    - Grid behaves exactly like QGridLayout
    - Remove window decoration
    - Once frame as been created do not remove when window is removed (How to remove easily?)
    - Unused frames display the desktop
    - Right-clicking on a border brings up a context menu with:
        - Configure grid: New window that has a diagram of the grid, allows entering exact sizes
            - Can add rules to frames, e.g. locked size, can grow, can shrink, accept windows, etc.
            - Default grid is applied to all desktops with no windows
        - Copy to desktop: Creates an empty grid on the selected desktop
        - Lock grid: Locks the entire grid (Single border locking is useless)
        - Do we need to add load and save support?
    - Default grid is immutable normally (Allows user controlled "maximize areas")
    - Save grids with session
    - Windows that cover multiple frames hide the internal borders
    - Need to add grid composite API functions (See dim idea), allows a "show grid" effect
        - All effects will be handled by compositing
    - If a child window's default size is smaller than the parent's frame add a window decoration to
      it instead, if it's larger add it to the parent's frame
    - If windows automatically change the grid size remember the user defined positions and revert
      to them when possible
    - Maximizing the window will default to maximizing to screen, holding Ctrl will maximize to the
      frame that is under the center of the window
    - When moving a window hitting Ctrl will split the hovered area in two parts (Take into account
      max window size?) temporarily in the orientation determined by the position of the cursor
      (See alt resizing), a second press or moving out of the area will cancel the split operation.
        - Actually I think using "A" for add and "S" for split would be easier.
    - Using Alt+Right click resize shortcut allows windows already in the grid to take up adjacant
      frames
    - When moving a window hitting meta(?) or dragging onto the window titlebar(?) will cause the window
      to fill the frame under the cursor (If there is no grid it will maximize to the full screen
      only when hitting meta)
    - Each screen has, by default, a 1x1 grid frame. (Overlapping portions of a Xinerama setup will also
      result in overlapping grids)
    - Give each window a grid position with size and a grid base pointer
    - Keyboard operation: Use center (top left if even) grid position of the current frame to
      determine neighbouring frames. If no window in the frame move right/down.
        - Ignore hidden frames (Under multi-frame windows)
        ??? Also need a method to jump between each window instantly (When key pressed every frame
          gets a hotkey)
    - Moving a window in a frame will keep it in the grid, hit meta to remove it
        - When over another frame move it to that frame immediately, use the frame of the top window
          in that frame. I.e. if the window covers two frames make the dragged window two frames
          as well
        - Uses identical keyboard operation as window selection
    - Automatically tiling windows selected from the taskbar groups and all windows (Bug 165933)
    - Dragging a window from the taskbar to a frame should maximize it there
    ??? When launching new applications are they added to the grid or float? [Configurable]
        - If there is a grid on the screen with the cursor it's added to the grid while if
          there is no grid on the screen make it float
        - Window either opens in active window's frame or the frame with the cursor
    ??? How to automatically rearrange? When no grid at all, when adding just one more frame, etc.
    ??? If no window in adjacent frames keep grid but hide seperating border
    - First SVN change: Change maximize behaviour, add 1x1 grid to every screen
        - What does the "MaximizeArea" enum become?
    - Future improvements:
        - Should integrate nicely with window tabs
            - Child windows larger than frame get added to tab instead
        - Floating windows snap to frames if they are similar in size and position [Configurable]

I'd like to see some kind of simpler addition to the minimise maximise button area to cater for wide screens.  It would be nice to have a simple one click button that maximised to left or right half of screen and perhaps left as simple as that.  There's nothing really to utilise this new screen space we all have without manually resizing windows (I've heard programmers cursing widescreens many times can saying they're not widescreens they're narrow height screens :)) 

All the fancy stuff could be a plugin, or maybe someone could come up with something that hooks the two together, but I could envisage we could fundamentally shift the way this works if we're clever, much like the start button in win95 did.

> 6) Currently I have it planned that if a window is opened that is smaller than
> the parent frame it is displayed as a floating window, if it's larger it gets
> added to the frame

I think that's just wrong. There are ways to really identify child windows (like the transient_for hint or checking for non-resizeability), but just judging by the size does not work well. Assume the user has split the screen with 2 terminals side by side. Then he opens a new terminal, which usually is just 80x25 chars tall (=quite small). This probably is smaller than the already visible terminals and the terminal becoms floating instead of just tiling on of these 2 columns again (this time vertically).

I meant that for child windows yes, not any window.

Like Quentin (#24) said: how about a very easy grid-layout system, where you can just drop a floating window into the grid.
For example, drag a window with the middle mouse button (or holding down another key, like Ctrl) and then the grid will be drawn (highlighted), and you can then just drop the window in the corresponding grid, where it automatically fits in the grid spot.

Window tiling has been put on the shelf indefinitely.

If anyone would like to add this feature themselves feel free to contact me as I am fine with mentoring, just keep in mind that it will require a large amount of time and commitment to implement completely (Leaving it uncompleted will make it useless so it's pretty much an all-or-nothing feature). I have a nice stash of ideas and techniques that could be used of both static and dynamic tiling in KWin that could be of use.

Hi,
i'm wondering if you've ever heard about xmonad? 
http://xmonad.org/
http://en.wikipedia.org/wiki/Xmonad
seems to work already really well (according to what you can read on internet pages e.g. blogs..). perhaps you can adopt some ideas from it or reuse several code parts from it.
furthermore, microsoft is something similar planning for win7. i've just watched this video on ars:
http://arstechnica.com/news.ars/post/20081030-more-on-the-windows-7-ui-new-taskbar-will-be-mandatory.html (there's a video embedded)
this video-docking seeems really interesting, too.
i've just want to point this out here, perhaps it could help or give you some inspiration :)
thanks & greets

Xmonad heavily revolves around a configuration file that the user must edit to get what they want, this is not very good for granny-usage. It is also written in Haskell which is completely different to C++ so reusing any existing code is impossible.

That Windows 7 docking thing is exactly what the current kwin-grid branch already does, except of dragging to the screen edge you just hit the shortcut on the keyboard.

once again... read a short article about awesome (http://en.wikipedia.org/wiki/Awesome_(window_manager)). i quote its man-page: "In tiled layout windows are managed in a master and stacking area. The master area contains windows which currently need most attention, whereas the stacking area contains all other windows. In floating layout windows can be resized and moved freely. Dialog windows are always managed floating, regardless of the layout applied."
perphaps there are some useful algorithms ( i really like this feature to be in kwin, although i can't offer 500$ bucks like others ;) )

*** Bug 177739 has been marked as a duplicate of this bug. ***

*** Bug 182532 has been marked as a duplicate of this bug. ***

Compiz fusion grid plugin, integrated into kwin and made configurable. (size of grid, layout of grid, etc) http://wiki.compiz-fusion.org/Plugins/Grid

Re #34: 

Unfortunately, I'd probably just end up disabling the grid plugin and continuing to use my own quicktile.py script. Last time I tried it, it seemed to be going in the wrong direction. (More towards AwesomeWM or XMonad than WinSplit)

*** Bug 189096 has been marked as a duplicate of this bug. ***

Hi,

I'm working on an application that does this..

It's a stand-alone application that you embed other windows into, then tab through them with short-cuts (or the mouse and the tabs at the bottom). At the moment it just supports a "full window" tabbed view, but I'm adding tiling views and other ion-type features into it.

The code:

git clone git://afterclap.com/kittens

It's a kde application with the normal cmake way of building, try it out it's quite interesting and already usable.

James

Just for reference, on kde-usability-devel ML there has been discussed concept of Nested Windows Interface, the summary is here:
http://techbase.kde.org/Projects/Usability/NWI

Kwin-tiling project aims to develop this feature:

http://www.youtube.com/watch?v=faOQAgapQYQ

http://websvn.kde.org/branches/work/kwin-tiling/ is the place to test kwin-tiling if you are interested.

@Nikhil: when the development will be completed, is it planned to be added to the default KDE ?

(In reply to comment #41)
> @Nikhil: when the development will be completed, is it planned to be added to
> the default KDE ?
Of course we want to integrate it into default KDE. There is no sense in having a fork of kwin in branches/work :-)

is this likely to make it into kde 4.4? currently i don't see any feature plans listed for the 4.4 release.

(In reply to comment #43)
> is this likely to make it into kde 4.4? currently i don't see any feature plans
> listed for the 4.4 release.

Quote:
"After discussing the current state of KWin trunk and branches with Martin we have come to the conclusion that the tiling branch merge will unfortunately have to be postponed until KDE 4.5. We would like the tabbing branch merged first and as it looks like that branch will be scraping it in near the hard feature freeze date it will not leave enough time left to ensure that the tiling features are of release quality."
http://lists.kde.org/?l=kwin&m=125541992730386&w=2

MS Windows (98, Me, XP, etc) has a ***very*** useful feature named "Tile
windows vertically / horizontally" and if this is you are talking about you have my vote also.

I'm a newby, but if this will be a feature of KWin, those who are not having 3D drivers or prefer Compiz will not be able to enjoy tiling of windows ?

(In reply to comment #45)
> MS Windows (98, Me, XP, etc) has a ***very*** useful feature named "Tile
> windows vertically / horizontally" and if this is you are talking about you
> have my vote also.

That is a different feature and it actually used to be in KDE 3.5 but has yet to be ported to KDE 4.

(In reply to comment #46)
Is this feature still in 3.5? How is it called?
I can only find the "unclutter windows" feature wich just arranges the windows position so they hopefully do not overlap but it does no resizing, hence they are not really tiled.

(In reply to comment #46)
> (In reply to comment #45)
> > MS Windows (98, Me, XP, etc) has a ***very*** useful feature named "Tile
> > windows vertically / horizontally" and if this is you are talking about you
> > have my vote also.
> 
> That is a different feature and it actually used to be in KDE 3.5 but has yet
> to be ported to KDE 4.

i have tried reading the wish-bugs and can't tell which one, if any, definitively asks for exactly this, which is to say, i want in KDE/kwin exactly the functionality mentioned as being present in MS Windows 9x thru XP (i haven't tried anything later than XP) of being able to tile any windows that are on the desktop (not minimized) with at most two clicks.  so i don't know whether to just go through and vote for every wish that mentions tiling, or make a new one and trust someone that knows more to mark it as a duplicate of the right one.

I'd also want to be able to tile windows vert / horiz like in MS Windows (they
have this feature for a long time ago): you just right click on the taskbar and have the option of tiling windows vert/horiz. Please note that the tiling aplies to maximized or restored windows (minimized windows are ignored).

I suspect this feature request is a duplicate of:
   Bug 165933 -  Tile windows vertically / horizontally


PS: That bug has fewer votes but a more clear title / name.

@eternus, @Andrei -- MS Windows does not have this feature. MS Windows is only capable of setting new geometry for windows and that's it. Dynamic tiling once turned on means that window A constantly influences window B.

When referring to other reports it is always problem if somebody means static (like MS Windows) or dynamic tiling. The other report is about static tiling, thus those two reports are _not_ duplicates.

Ok, I understand now... I'm interested just in static tiling.

In my opinion, *** static *** tiling is necessary and sufficient for very practical uses: compare side-by-side two documents, pictures etc.

Dynamic tiling would:
   - be an overkill
   - require more work
   - require more time
   - and thus, be more bug prone than static tiling (as in MS Windows)

@51: And yet people like me care enough to be slowly re-implementing KWin's default behaviours in the config files of tiling WMs like Awesome.

Now that static and dynamic tiling are implemented in 4.5.0, do any of you want to test the feature and give feedback?

Yes. I've tested it quickly a few days ago. It was not easy to enable.
Once enabled, was not easy to discover how it works. An short quick start text near the checkbox would be cool and greatly improve the experience with the feature.

Then I guess it's because of my dual screen setup, it was very buggy. Windows changing screen, locked on one or the other. I know it's not usable feedback : i haven't got anything better for now, i tested this quickly on work hours. I hope I'll be able to submit precise bug reports later.

Thanks to the developer,I guess we're just a couple fixes away from greatness :D

I am using it since yesterday, and first I want to thx the devs who added that ! 
Merci.

Feedback: 
As said before, it was difficult to found where to activate it..
after changing the shortcut (to correspond to my keyboard layout), it works fine, and I enjoy it.

I think that some features still missing :
- in column mode I am unable to change the height of a tiled window (only width is changeable)
- no way to make 3 or more columns
- unable to maximised one window in its column only (as in wmii with alt-shift s or p )
- unable to have multiple window in the left column.. etc..

- Documentation or a text howto presenting all features will be helpfull too.

(in fact I am not sure to understand the spiral and column mode implemented in kwin. I only used wmii before, and the placement of windows was easier. You can move window to the place you wanted without predefined/fix placement.)


again thx for you work.

Hm.

 * A lot of crashes, some of which disable the keyboard (actually firefox crashed while I was writing the first version of this comment).
 * Windows keep ending up with "Float" and/or "Maximize" set for whatever reason I can't imagine, then when enabling tiling it appears to be all broken, until you realise kwin has messed everything up again and the options have to be taken off.
 * Tiling mode (and whether tiling is turned on) not remembered when restarting kde.
 * No documentation available and after using it for several hours still no clear idea of how the various tiling concepts really work.
 * You should be able to change tiling mode for each virtual desktop.

More things:
  * Windows keep ending up with an ugly black line (about 3-5 pixels high) seperating the window content from the content. This doesn't seem to trigger without tiling enabled.
 * Windows like pidgin that enforce a minimum window width.. when resizing a column to be smaller than this width, the effects work temporarily, before the window resizes itself. "awesome" manages to obey the user settings, which I think would be better.

Another comment, when using mouseless operation, the window titles aren't necessary.

So I'd like an option to allow tiling mode to automatically turn off window title bars.

the black pixel spacing below the title bar and menu content.. I think is due to disparity between the size of the tiling grid and the appliation content size. If there is a positive difference between the available space, and desired space.. the black space fills in the gap.

I have a kde developer account so I could work on some of this stuff, and also I suppose I should open seperate bugs rather than leaving the issues here.

I would like to draw the attention to Amarok layout management (launch Amarok and uncheck "View/Lock Layout" to test it).

It allows to easily change layout, change a window in tab and make window float. It is intuitive, powerful and can be applied to windows management.

I know it differ from Xmonad/Awesome/Ion behavior, but it can give ideas.

Given that tiling is available in KWin I dare to set this feature request as resolved :-) If you have specific further wishes to the ongoing implementation feel free to open new feature requests.

Most important: the feature still needs some love. This means you have to test and report issues, even better if you find the time to look at the code and provide some patches :-) The code is rather self contained and easy to grab.

Thanks to all

Since this was removed from KDE 4.10 (do to a lot of problems such as unmaintained code, bugs, no support for new features and so on) is there a chance to re-open this bug?

i know that the idea is to make this available using scripts but i suppose this would be a good place to track the feature

(In reply to comment #61)
> Since this was removed from KDE 4.10 (do to a lot of problems such as
> unmaintained code, bugs, no support for new features and so on) is there a
> chance to re-open this bug?
I change the bug status accordingly. Given the experience we had I don't think we will ever allow to have an implementation go in, even a script would have to live as third party. This means it's a wontfix.