36

The idea is similar to what you see on the OSX platform, and some Windows applications; Being able to drag unused areas of chrome similarly to how you might drag the window title, to move the window.

Unsure of how this would be done:
I'm unsure how this might be done, one way might be to have QT register anywhere that is "draggable" and act as an alt+click event (or somehow, a drag event) whenever the cursor is dragged. However GTK applications would not play nice with this.

Another way could be having Kwin monitor the program for events. If a drag-type mouse movement is registered within a toolbar or statusbar, and nothing registers as being dragged, then begin a window drag. The downside with this is the possible exceptions and workarounds for GTK, QT and other toolkits. Downsides might be things such as media players where areas that could be dragged would be ignored.

Either way, beginning to implement chrome-dragging and the basic detection methods for it open very positive usability avenues.

That's what I've been thinking, since I tried out the windows grouping in kde4.4.

If I understand your idea this is already possible in Bespin...
Try it then report if it is what you want.

Well, it's all well and good that it's in Bespin, but with the Oxygen titlebars blending so smoothly with the Oxygen window widgets, it makes sense that this kind of thing happens anyway.

Primoz wrote:If I understand your idea this is already possible in Bespin...
Try it then report if it is what you want.

do you mean the lastest bespin? which version?

Can't you alt + click'n'move a window already?

Tenno Seremel wrote:Can't you alt + click'n'move a window already?

Yes, but that's not immediately obvious. Additionally, with the new Oxygen window artwork, there's little distinction between the title bar and chrome, toolbars, menu or whatever else happens the be immediately under the title bar. That's why it makes sense that empty chrome below the title bar acts like the title bar when clicked.

Personally I don't see a reason to duplicate what's already working though.

Clicking somewhere on the Chrome for moving the window is not working. It's possible to ALT+Click anywhere on the window for moving it, but this is imo not that self-evident (for user not knowing the feature) and something different though.

Tenno Seremel wrote:Personally I don't see a reason to duplicate what's already working though.

Then you should have a problem with moving windows from the title bar and by alt-clicking. Two ways to do the same thing. isn't that duplication?

yunkwan wrote:

Primoz wrote:If I understand your idea this is already possible in Bespin...
Try it then report if it is what you want.

do you mean the lastest bespin? which version?

I use latest svn version, but this was in bespin from almost the beginning...
It's under hacks "allow easy window dragging by clicking empty spaces" it works best on chrome (as there's a lot of empty space there)

Tenno Seremel wrote:Personally I don't see a reason to duplicate what's already working though.

The main reason is consistency; If a window looks like a slab, it should act like a slab. Very similar to OSX.

Another reason is mis-clicking counter-intuitive nondragging; If a user attempts to drag a window near the titlebar - but misses by a pixel, they might believe it's lag, frozen, or misbehaving in some way - even if for that split secnd before they realize, they'll still wonder "why didn't that work, anyway?"

Functionality too. Alt-Dragging isn't necessarily obvious, nor should it be necessary. If I just want to drag a window, why should I either aim for an invisible line or press an arbitrary key, when programs like dolphin have massive ripe valleys for the dragging?

I guess also a bit about choice and options - "Duplication"; Why have an LCD weather plasmoid and a regular weather plasmoid? Why even have alt+click for dragging when the titlebar is perfectly draggable? KDE is about functionality and options, why not have this fairly obvious option? Even if we turn it on/off by default, still have it available.

Madman wrote:Then you should have a problem with moving windows from the title bar and by alt-clicking. Two ways to do the same thing. isn't that duplication?

Some windows do not have title bars. It happens.

Kver wrote:If a user attempts to drag a window near the titlebar - but misses by a pixel, they might believe it's lag, frozen, or misbehaving in some way

I'm not sure "user is always dumb" is such a good idea.

Kver wrote:Alt-Dragging isn't necessarily obvious, nor should it be necessary. If I just want to drag a window, why should I either aim for an invisible line or press an arbitrary key, when programs like dolphin have massive ripe valleys for the dragging?

Aiming for visible title bar is not hard.

Kver wrote:Why have an LCD weather plasmoid and a regular weather plasmoid?

I don't know, neither is working for me.

edit: and here I though double quotation marks issue was fixed.

Tenno Seremel wrote:I'm not sure "user is always dumb" is such a good idea.

Aiming for visible title bar is not hard.

I'm not saying the user is dumb; They are simply unfamilliar. A neurosurgeon can not know how to alt+click, and still be considered a "smart guy".

I've seen with several unrelated people intutivly grabbing chrome when there is no seperator. It's not that their stupid, but they simply are unfamiliar with the limitation. And they point it out, my grandmother pointed out to me, in her exact words, "Well, that's just a silly way of doing it."

But this isn't about the titlebar, or a separator, it's about the chrome. I understand why you're so absolutely against it - it's difficult to initially implement both in terms of X and inconsistent toolkits - but it's a genuinely desirable feature available in some form or another on just about every non-*nix system. Vista/7 can drag anything glass, OSX you can drag anything grey, why, when we create a consistent singular slab look do we have inconsistent behaviour?

The -only- reason it isn't available is because the X window system drew a wall between windows and content and until now we've been too lazy to bridge the gap. This really seems like a "because that's how it is" statement with no other reason than "That's how XP did it". When you think about it, outside of "That's how it's done", why should I be limited to the titlebar? Would you call me a crazy person if I said all dragging should be limited to the statusbar instead? Or the toolbar? Maybe a button in the titlebar - at least we'd be consistent. From someone who doesn't know the technicalities of of X and Linux, this is the argument for artificial limitations we are making.

No matter what, there is one thing you must agree with me on; The empty chrome found in every window of every program is wasted space with no functionality.

If work is started now, even if it's not for KDE 4.5, even if it's not for 4.6, the framework will be there and it's one feature 90% of programs will benefit from.