[patch] Grab windows anywhere, not just titlebar

[Aaron J. Seigo]

On Wednesday 07 November 2007, Lubos Lunak wrote:
> On st 7. listopadu 2007, Aaron J. Seigo wrote:
> > On Wednesday 07 November 2007, Lubos Lunak wrote:
> > > > 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 ;)
> > >
> > >  Actually, I have this step "backwards" somewhere in my TODO. I hope
> > > when KRunner is so flexible that it can use SVG it can be also flexible
> > > enough to look like a normal dialog (which it is, to me, and I prefer
> > > being consistent to being cool)?
> >
> > if you think this is only about looking cool, you missed the content of
> > my previous emails.
>
>  Which part, the one claiming that a dialog that appears usually only for a
> short while doesn't need decorations because if people actually do need
> them they use it unusually, or the one claiming that a system dialog should
> look unusually to make it obvious that it's unusual?

the latter is a good start. i would phrase it differently, but i can 
understand how you would see it and therefore word it that way.

>  Also, "only shown as long as a given action is being prepared or
> performed" either does not apply to minicli or applies to quite many
> things, depending on the interpretation, and "is shown specifically to aid
> in the completion of that action or task" is true for every dialog, not
> just minicli.

which is why there's more than one point in the list. i could also point out 
that some dialogs don't seem to be particularly related to a given 
application. on it's own that's meaningless.

if you read the footnotes in that email you'll also notice that i really think 
in-window-sheets (well, to the user they'd look like they were "in window", 
though they'd still be top level windows technically) are probably better for 
a lot of common modal dialogs. too bad even the modern window managers on x11 
still don't let us do these things. this would be an absolutely killer 
feature for kwin, imho.

that they work has been proven pretty well by other operating systems that 
have less trouble with such "innovative" ideas (the same one(s) that tend to 
have a better reputation with users, btw)

> > while i appreciate contribution and efforts, i really don't appreciate
> > people screwing things up based on ideas that simply don't belong. i'm
> > already dealing with enough of that crap in plasma.
> >
> > e.g. wonder why the clock in the panel doesn't line up properly on second
> > start? yep.
>
>  No. I wonder what a wrong position of the clock has to do with minicli.

the commonality: me caving to people pushing for things i know are not right.

> > so you can remove this item from your TODO. or ... fork krunner for all i
> > care, i guess. it's free software, enjoy.
>
>  Oh, so we're to fork basic components just in order to get normal widgets
> and normal borders on them? That's a) rather ridiculous, b) not necessary -

i consider people threatening to patch code just to get their preference to be 
high on rediculous quotient. after a while it gets amazingly tedious to deal 
with the "we must not change things because anything different is not the way 
it was!" way of being.

the summary of the reasons people want a window border is: "that's what i'm 
used to." or "i want to do $SOMETHING with window that i know how to with the 
standard decorations". the latter i can do things about (or in this case, 
frederikh got around to it first), the former is what happens when things 
change. when that change is not for the bad, it's often worth it.

> I can force the borders on with KWin, 

yep ... i can't get that to work atm, however, with kwin from trunk... maybe 
the window is being too agressive; but this is perhaps a decent way to get 
what everyone wants.

> and assuming the SVG theming is there 
> in order to actually allow theming, I can also theme it back to normal.

yep =) just pop a blank svg in your $KDEHOME.

>  Hmm, which, thinking of it, means there's no need to continue this
> discussion, problem solved, case closed. Does fixing KRunner's possible
> insufficient theming support also require forking?

nope.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20071107/d54066a0/attachment.sig>