[patch] Grab windows anywhere, not just titlebar

Luciano Montanaro mikelima at gmail.com
Wed Nov 7 21:04:59 GMT 2007

Il Wednesday 07 November 2007 21:22:02 Aaron J. Seigo ha scritto:
> On Wednesday 07 November 2007, Luciano Montanaro wrote:
> > Not really. But I hope this new fashion of using undecorated windows does
> > not spread too much.
> modal dialogs are also bad. but not always. sometimes they are what is
> needed (though we could present those better, e.g. as in-window sheets; oh
> no! more undecorated windows? ;). there are times when undecorated windows
> are absolutely the perfect approach. it would probably help to define that
> in the HIG.

It may make sense to have in-window sheets. They do not block the whole 
desktop however.

Does the Alt+F2 dialog have to be a blocking window? It may be useful to make 
it go to the background or move it around (maybe to select some text to paste 
in there).

It's OK to have undecorated menus... Even the logout panel.

Maybe most of the time I just need to type two characters, arrow down and 
enter to launch my application, but at times I need to move it around. So for 
me the KDE4 "runner" is a step backwards compared to what KDE 3 provided.

I tried it again with the debian live image a few days ago -- is the artwork 
the final one? the panel having no borders makes it hard to understand where 
the background ends and the panel begins, being mostly white-gray as most 
windows are. I'd also like a plainer look, but I've been said it can be 

> the idea is something like: short lived transient interfaces that are not,
> from the user's POV, directly associated with a given application which
> show primarily interim information tangential to the actual task may opt
> for a non-invasive top level window without decorations. transient
> notifications are another example of when this is a desirable approach.

Transient notifications are OK, for me: they get out of the way by themselves.
As long as they don't pop up too often. Otherwise, I'd prefer notifications to 
be grouped...

> (note: i'm not using the x11 definition of "transient" in the above, but
> the standard english language meaning of the word)
> so something that reflects the volume change or a window that helps process
> a command to be run or a notification popup all fit that concept.

Maybe, for very simple tasks you are right. But I know I'm not happy with the 
new runner at all. And I'm not the only one, since the click-to-move feature 
has been proposed as a workaround...

> the result is it keeps "windows" (or what users perceive as windows) within
> the real of "actual" applications and not feedback or system helpers. this
> has several nice effects:
> - it makes these kinds of windows more identifiable to the user
> - we can make these windows much more visually appropriate (and therefore
> appealing)
> - it limits on-screen clutter and noise where it isn't needed
> > Actually, another simpler change to fix krunner would
> > be to let it have its standard window borders.
> i hope the above helps explain why this would be a step backwards. though i
> suppose that's predicated on people actualy agreeing with the above ;)

I'm unconvinced. Maybe I'm getting old and inflexible. Ugh! :)


More information about the kde-core-devel mailing list