1

I know, that you won't realize my idea, independently you are like it or not, but maybe for KDE5?

The main problem of window managers is that, they aren't designed to interact with users. The main input focus should have application, that's right, but why any other application(window) can stolen/get focus too simple?

My idea is to make window managers more intuitive/ergonomic/sensitive. To achieve this, WMs shouldn't give focus to application without user permission, with one exception: New window is displayed/created.

Instead of giving input focus, window manager should displayed menu with options:
- Move active window here
- Bring this window to front and activate it
- Bring this window to front, activate it and click
- Drag this item(don't change active window, simulate left mouse button for moment, when user don't click and select drop item)
- Window list(section/contains submenu)
- More actions on active window(close/minimize/maximize/show at top of screen, etc.)
- Change rectangular size of active window

On window list we can bring other window to front and activate it(too simple).

Windows should have only small (4 pixels border independently it is maximized or not). Window border can't contains title/caption, buttons. Once user click on borders, we showing up menu. Active window will works as now.

Window names/caption text will been displayed, one mouse cursor will leave active window and will be hidden when mouse cursor entered into active window. This element should be displayed above the window, not at top of them.

In my opinion it's less space gainful, more intuitive, speeder. Also, it will probably works better with multitouch devices and MPX. I can chose many actions only by puts finger on the screen and select, ex. move active window here.

This are two ideas:
1. Ask for permission when the active windows changes
2. Menu-Activation using the window-border

Right?

Not right.

It's idea to showing menu, when user click outside active(foreground) window.

As now, we change active window or click on the desktop. I think, we should display menu with possible actions, like move active window here.

I think that a great portion of your idea is already done.
If you right click on title-bar of window you'll get a menu with this options (that you also name):
-"Move active window here"-> There's an option to move window to another desktop.
-Move window
-Change rectangular size

Also there is a plasmoid window list, though it's not as sophisticated as your idea.

More or less you want that windows "context" menu is changed to normal menu and that title-bar gets a bit of eye-candy in form of animated title.
The last one is new, all other parts of your idea are more or less already here in some sort. You just want it to be more accessible.
Oh and animated menus, that's new one to. Almost forgot it.
Even if there are other things that are new and I didn't understood them as new, it's still more than one solution per idea. So write a idea just concerning title-bar and idea concerning menu animation, and anything other that is new (please reply to this thread before writing new ideas, I want to see if I got your idea correctly).

I also asks to remove title bar(no title will be displayed, since mouse are above active window). Window will only have small border.

I also talks about clicking action outside active window(whole area across them will behaves very similar to title bar). It will be great, if some WM could display menu, when user left click on area not belongs to active window(but belongs to desktop or another window).

Sorry to shoot you down

Lachu wrote:The main input focus should have application, that's right, but why any other application(window) can stolen/get focus too simple?

There is aready focus stealing prevention in kde

Instead of giving input focus, window manager should displayed menu with options:

So if you have 2 programs open every time you change app you get a menu, that makes multitasking impossible. if you want to get a menu when you click outside ANY window (e.g the desktop) then that's a good idea and was in kde3 where you could set menus for left/middle/right click.

Windows should have only small (4 pixels border independently it is maximized or not).

Currently each decoration chooses the border size, my current decoration is 2px so 4px is more waste.

Window border can't contains title/caption, buttons

clicking on a 4px space (especially with a finger) is going to be tricky, so it's better to have at least one fat border so you can manage the window.

Window names/caption text will been displayed, one mouse cursor will leave active window and will be hidden when mouse

It would be a nice effect to have when your mouse is over the desktop but I still think window boarders are needed for easy moving/resizing.

Also, it will probably works better with multitouch devices and MPX.

MPX and multitouch are two related but different things.

Multitouch, generally refers to multi-fingered mouse gestures, they been around for some time but people are scared to implement it because of apple patents (or something), it allows you to do gestures such as pinch,twist,etc, while it would be cool for kde (and kwin) to support such gestures it doesn't need a new window manager to do it.

MPX, allows multiple independent pointers and as they can be independent i don't think kwin should do anything special for them.

So in summary, I think the only way your ideas should be implemented is if they are only triggered by interaction with the desktop not by focus changes as that would make multitasking impossible.

"
So if you have 2 programs open every time you change app you get a menu, that makes multitasking impossible. if you want to get a menu when you click outside ANY window (e.g the desktop) then that's a good idea and was in kde3 where you could set menus for left/middle/right click."

I don't understand, how it makes multitasking impossible...
I only click on inactive window and select "move to front and click".

Using this menu to desktop are good idea. Desktop are bottom level window, so any interaction with it are painful.
If we display menu with options: Show desktop, Start dragging procedure, Cover whole desktop with active window, it can be great.

I have another idea to putting window list of current application onto title bar or main menu bar. It can be very helpful, to working with application, like GIMP.

When user click on application title, we will show selected window with titlebar position on clicked tab.

KWin will probably have option to enable tabs. It will be good to using also my idea.

Lachu wrote:I don't understand, how it makes multitasking impossible...

http://www.imagebin.ca/view/siIUUw6i.html is a pretty usual set-up, under your plan everytime i switch to the web browser or chat or console I have to click through a menu. In addition if i want to use the systray to do change power/volume/network/torrent settings, i also have to click through a menu, for a pretty trivial task (scrolling over kmix,etc)

I only click on inactive window and select "move to front and click".

Currently you only have to click the inactive window (it will move to front, depending on your settings), adding a custom menu to the possible actions for right/left click might be useful but making everything slower by default won't be.

When user click on application title, we will show selected window with titlebar position on clicked tab.

I don't understand where you slow this info.

Thanks.

Could I reedit this topic or better write new?

Yes, please write a new idea. This will be locked.