[patch] Grab windows anywhere, not just titlebar

[Stefan Monov]

Hi,

So I saw Frederik's commit 731583:
"Make it possible to move the krunner window by clicking on an empty part
of it and dragging the mouse."

I have always thought it would be great if all KDE windows behaved like that
(btw Mac OS X does it), so I did some copy-paste-fu and here we have a
patch -- attached.

It makes all KMainWindows and KDialogs grabable. cool =)

Unfortunately it doesn't work when you grab:
- the space on the right of menubars
- a groupbox
- a widgetstack
- the space on the right of breadcrumb bars
- etc.

Inherent disadvantages:
- introduces inconsistency with non-kde apps
- anything else?

Would be nice if the code was shared instead of copy-pasted.

It will also let us do away with the titlebar bevel in Oxygen, which we
introduced to make it clear where the grabable titlebar ends (though it
clashes badly with the artistic vision).

Comments? Improvements?
How to make it work on menubars?
Too late for such a big change in 4.0?
Compatibility with other WMs, OSes?

Cheers,
Stefan

ps: hmm, looks like a dot commenter had the same idea ;)

[Dan Meltzer]

Post by Stefan Monov
Hi,
"Make it possible to move the krunner window by clicking on an empty part
of it and dragging the mouse."
I have always thought it would be great if all KDE windows behaved like that
(btw Mac OS X does it), so I did some copy-paste-fu and here we have a
patch -- attached.
It makes all KMainWindows and KDialogs grabable. cool =)

Hi,

While this is a cool change, I feel that it is

A) Not a bugfix. At this point kdelibs is in bugfix only mode afaik,
and therefore this should be postponed.

B) Not Portable. This uses x11 specific stuff, KMainWindow needs to
be usable on both Mac and windows (Not a problem for plasma as it is
only runnable on X11). Therefore this would at a minimum need to be
ifdeffed (ugly) or a more portable way of doing it would need to be
found.

Dan,

Post by Stefan Monov
- the space on the right of menubars
- a groupbox
- a widgetstack
- the space on the right of breadcrumb bars
- etc.
- introduces inconsistency with non-kde apps
- anything else?
Would be nice if the code was shared instead of copy-pasted.
It will also let us do away with the titlebar bevel in Oxygen, which we
introduced to make it clear where the grabable titlebar ends (though it
clashes badly with the artistic vision).
Comments? Improvements?
How to make it work on menubars?
Too late for such a big change in 4.0?
Compatibility with other WMs, OSes?
Cheers,
Stefan
ps: hmm, looks like a dot commenter had the same idea ;)

[Lubos Lunak]

Post by Stefan Monov
Hi,
"Make it possible to move the krunner window by clicking on an empty part
of it and dragging the mouse."
I have always thought it would be great if all KDE windows behaved like
that (btw Mac OS X does it), so I did some copy-paste-fu and here we have a
patch -- attached.
It makes all KMainWindows and KDialogs grabable. cool =)
- the space on the right of menubars
- a groupbox
- a widgetstack
- the space on the right of breadcrumb bars

- something that is not a KMainWindow or KDialog

Post by Stefan Monov
- etc.
- introduces inconsistency with non-kde apps

- introduces inconsistency with kde apps (see above), meaning that's probably
not the right place for it
- possibility to unintentionally move a window with a slightly sloppy click
(am I the only one who hates the "cool" feature of accidentally wheeling over
taskbar/pager)
- hmm, is it really that difficult to hold Alt which works everywhere?

Post by Stefan Monov
- anything else?

How does Mac OS X handle it so that the user doesn't trigger it accidentally
or hunt for "random" parts of the window where it actually works?

[Jakob Petsovits]

Post by Lubos Lunak
- possibility to unintentionally move a window with a slightly sloppy click
(am I the only one who hates the "cool" feature of accidentally wheeling
over taskbar/pager)

(no, you're not.)

[Diego Iastrubni]

Post by Lubos Lunak
(am I the only one who hates the "cool" feature of accidentally wheeling
over taskbar/pager)

amen. Specially on those laptops with this ober-cool wheel mouse (the thing on
the side... I always hit when I try to move the mouse).

[Luciano Montanaro]

Post by Lubos Lunak

Post by Stefan Monov
Hi,
"Make it possible to move the krunner window by clicking on an empty part
of it and dragging the mouse."
I have always thought it would be great if all KDE windows behaved like
that (btw Mac OS X does it), so I did some copy-paste-fu and here we have
a patch -- attached.
It makes all KMainWindows and KDialogs grabable. cool =)
- the space on the right of menubars
- a groupbox
- a widgetstack
- the space on the right of breadcrumb bars

- something that is not a KMainWindow or KDialog

Post by Stefan Monov
- etc.
- introduces inconsistency with non-kde apps

- introduces inconsistency with kde apps (see above), meaning that's
probably not the right place for it
- possibility to unintentionally move a window with a slightly sloppy click
(am I the only one who hates the "cool" feature of accidentally wheeling
over taskbar/pager)
- hmm, is it really that difficult to hold Alt which works everywhere?

Not really. But I hope this new fashion of using undecorated windows does not
spread too much. Actually, another simpler change to fix krunner would be to
let it have its standard window borders.

Luciano

Post by Lubos Lunak

Post by Stefan Monov
- anything else?

How does Mac OS X handle it so that the user doesn't trigger it
accidentally or hunt for "random" parts of the window where it actually
works?

[Aaron J. Seigo]

Post by Luciano Montanaro
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.

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.

(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.

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

Post by Luciano Montanaro
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 ;)

[Jeff Mitchell]

"short lived transient interfaces 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"

Say that five times fast.

[Aaron J. Seigo]

Post by Jeff Mitchell
"short lived transient interfaces 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"
Say that five times fast.

point taken. let me try again without a run on sentence full of jargon.

if an interface is:

- only shown as long as a given action is being prepared or performed
- is shown specifically to aid in the completion of that action or task
- is not part of an application that is typically launched explicitly[2] by
the user (e.g. it appears to be part of the "desktop infrastructure" to the
user)[1]
- or is a notification of an event that needs to appear outside the
application's normal window (e.g. the mainwindow if there is one)

then one may consider using a top level window without decorations.

[1] for items that fail this point but meet the first two, a window overlay
(amarok, dolphin, pixie4 and others do this), a toolbox window or traditional
dialog is more appropriate

[2] this does not mean that the user does not initially turn on the feature.
but once started, it should be self-maintained across sessions. yakuake, the
volume control and amarok's OSD are examples of this "turn on, then forget
because it's infrastructure" type of functionality.

[Lubos Lunak]

Post by Aaron J. Seigo

Post by Luciano Montanaro
Not really. But I hope this new fashion of using undecorated windows does
not spread too much.

...

Post by Aaron J. Seigo

Post by Luciano Montanaro
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 ;)

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)?

[Luciano Montanaro]

Post by Lubos Lunak

Post by Aaron J. Seigo

Post by Luciano Montanaro
Not really. But I hope this new fashion of using undecorated windows
does not spread too much.

...

Post by Aaron J. Seigo

Post by Luciano Montanaro
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 ;)

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)?

This is how I'd like it too! :)
It was on my TODO too... as a last resort.

Luciano

[Aaron J. Seigo]

Post by Lubos Lunak

Post by Aaron J. Seigo
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.

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.

so you can remove this item from your TODO. or ... fork krunner for all i
care, i guess. it's free software, enjoy.

(btw, i'm still catching up with some of this stuff. bibr often gets annoyed
at me for thinking in terms of QWidget versus canvas.)

[Lubos Lunak]

Post by Aaron J. Seigo

Post by Lubos Lunak

Post by Aaron J. Seigo
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?

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.

Post by Aaron J. Seigo
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.

Post by Aaron J. Seigo
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 can
force the borders on with KWin, and assuming the SVG theming is there in
order to actually allow theming, I can also theme it back to normal.

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?

[Aaron J. Seigo]

Post by Lubos Lunak

Post by Aaron J. Seigo

Post by Lubos Lunak

Post by Aaron J. Seigo
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.

Post by Lubos Lunak
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)

Post by Lubos Lunak

Post by Aaron J. Seigo
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.

Post by Lubos Lunak

Post by Aaron J. Seigo
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.

Post by Lubos Lunak
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.

Post by Lubos Lunak
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.

Post by Lubos Lunak
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.

[Lubos Lunak]

Post by Aaron J. Seigo

Post by Lubos Lunak
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.

Hmm. Too bad I don't consider minicli to be anything special - it's just a
dialog that runs a command. Ok, it doesn't have a main window, so what? Is
kcmshell also going to have no decorations in KDE4?

Post by Aaron J. Seigo
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.

It should be as simple as giving me a technical description of what you want,
there's fair chance I would say that I'd give it a try somewhen.

Post by Aaron J. Seigo
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)

Macs are quite rare in these parts. But I've heard they're known for having a
very consistent interface.

Post by Aaron J. Seigo

Post by Lubos Lunak

Post by Aaron J. Seigo
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.

I see. A bit like when I don't like that one Plasma dialog would get a
special placement.

Post by Aaron J. Seigo

Post by Lubos Lunak

Post by Aaron J. Seigo
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.

Me: "I hope ... KRunner is ... flexible enough to look like a normal dialog"
You: "fork krunner"

And I'm threatening and ridiculous?

Post by Aaron J. Seigo
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".

Actually, I think it's "I want it because I use it and there's no good reason
for removing it". Not to mention that you can do some small attempts at
solving the second thing, but you'll be needlessly duplicating the
functionality and you want handle all of it anyway.

Post by Aaron J. Seigo
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.

Right now it's for the bad, since it's broken. It's not very difficult to
click (not just press) the window and see it moving around following the
mouse. Another reason why trying to be inconsistent just for the sake of
being different is bad.

Post by Aaron J. Seigo

Post by Lubos Lunak
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.

It currently cannot override the application, but looks like I'll have to
change it.

[Jeff Mitchell]

Post by Lubos Lunak
Macs are quite rare in these parts. But I've heard they're known for having a
very consistent interface.

Apple wrote a very strict HIG for the Mac, which it now continually
breaks. (No, I don't know the details, I just know I've read about how
iTunes, iPhoto, and most of the other multimedia apps all break their
own HIG.)

There's also apps which are brushed metal and apps which aren't.
Pinstripes are used some places and not other places. Etc, etc. And
that's just in the Apple-provided apps. Not to mention plenty of apps
which still look like they're straight offa OS 9.

So no, the interface isn't terribly consistent.

--Jeff

[Aaron J. Seigo]

Post by Jeff Mitchell

Post by Lubos Lunak
Macs are quite rare in these parts. But I've heard they're known for
having a very consistent interface.

Apple wrote a very strict HIG for the Mac, which it now continually
breaks. (No, I don't know the details, I just know I've read about how
iTunes, iPhoto, and most of the other multimedia apps all break their
own HIG.)

for the curious, there are three reasons i've noticed for this:

- their HIG seems to be constantly evolving internally, even though they keep
the external document fairly rigid

- they seem to realize that usability does not trump everything all the time,
no exceptions. it only trumps nearly everything almost all the time; but
sometimes you want to take look, feel, external product continuity (e.g. iPod
+ software) and even marketing[1] into account.

- they sometimes release an app, then later update their internal user
interface rules and don't get a chance right away to go back and update older
stuff, so inconsistencies start to pile up over time (so i guess this is
related to the first point)

[1] we probably can avoid most marketting concerns from entering into our
technical decisions, i hope. =)

[Gary L. Greene Jr.]

Post by Jeff Mitchell

Post by Lubos Lunak
Macs are quite rare in these parts. But I've heard they're known for
having a very consistent interface.

Apple wrote a very strict HIG for the Mac, which it now continually
breaks. (No, I don't know the details, I just know I've read about how
iTunes, iPhoto, and most of the other multimedia apps all break their
own HIG.)
There's also apps which are brushed metal and apps which aren't.
Pinstripes are used some places and not other places. Etc, etc. And
that's just in the Apple-provided apps. Not to mention plenty of apps
which still look like they're straight offa OS 9.
So no, the interface isn't terribly consistent.
--Jeff

This was rectified on Leopard. Much of the UI that was inconsistent in Panther
and Tiger have been redone to meet all of the HIG requirements.
--
Gary L. Greene, Jr.
Sent from: peorth.tolharadys.net
19:32:32 up 11:19, 1 user, load average: 0.15, 0.71, 0.66
==========================================================================
Developer and Project Lead for the AltimatOS open source project
Volunteer Developer for the KDE open source project
See http://www.altimatos.com/ and http://www.kde.org/ for more information
==========================================================================

Please avoid sending me Word or PowerPoint attachments.

[Jeff Mitchell]

Post by Gary L. Greene Jr.

Post by Jeff Mitchell

Post by Lubos Lunak
Macs are quite rare in these parts. But I've heard they're known for
having a very consistent interface.

Apple wrote a very strict HIG for the Mac, which it now continually
breaks. (No, I don't know the details, I just know I've read about how
iTunes, iPhoto, and most of the other multimedia apps all break their
own HIG.)
There's also apps which are brushed metal and apps which aren't.
Pinstripes are used some places and not other places. Etc, etc. And
that's just in the Apple-provided apps. Not to mention plenty of apps
which still look like they're straight offa OS 9.
So no, the interface isn't terribly consistent.
--Jeff

This was rectified on Leopard. Much of the UI that was inconsistent in Panther
and Tiger have been redone to meet all of the HIG requirements.

AFAIK, what actually changed is they updated their HIG requirements so
that all the multimedia apps that wouldn't fit before, well, now fit,
because now everything else looks like them. So now everything looks
the same, and the HIG accepts it all.

I expect that this moment of peace will last until they decide it's time
for an iTunes revamp.

--Jeff

[Aaron J. Seigo]

Post by Lubos Lunak
Hmm. Too bad I don't consider minicli to be anything special - it's just a
dialog that runs a command. Ok, it doesn't have a main window, so what?

it's the use pattern.

Post by Lubos Lunak
Is kcmshell also going to have no decorations in KDE4?

of course not, that's a rather different use case. kcmshells aren't pulled up
with a global shortcut (unless, of course, specifically set up by the user to
do so) for the sole and express purpose of taking a command string and then
relaying that command to the system before disappearing.

kcmshells, and other config dialogs, don't have menubars, though, and that's a
good thing given their use case. that in spite of the fact that many of them
are more complex than some application main windows.

Post by Lubos Lunak

Post by Aaron J. Seigo
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.

It should be as simple as giving me a technical description of what you
want, there's fair chance I would say that I'd give it a try somewhen.

that would be awesome. essentially, i would like a way to flag a window as
being "document modal"; the parent winId relationship would be enough to
communicate what it is modal to, just like other dialogs. this window hint,
however, would add the extra guidance that this dialog is modal to the
document contained within that window.

here's the relevant page in Apple's HIG:

http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGWindows/chapter_17_section_6.html#//apple_ref/doc/uid/20000961-TPXREF11

and here are some relevant snippets:

"A sheet is a modal dialog attached to a particular document or window,
ensuring that the user never loses track of which window the dialog applies
to. Because a sheet is attached to the window from which it emerges, a sheet
does not have its own title.

The ability to keep a dialog attached to its pertinent window helps users take
full advantage of the Mac OS X window layering model (see “Window Layering”).
Sheets also allow users to perform other tasks before dismissing the dialog,
with no sense of the system being “hijacked” by the application.

You lay out sheets as you would any other dialog in Mac OS X."

later on:

"When to Use Sheets

Use sheets for dialogs specific to a document when the user interacts with the
dialog and dismisses it before proceeding with work. Some examples of when to
use sheets:

A modal dialog for an activity that is specific to a particular document, such
as saving or printing.

A modal dialog that is specific to a single-window application that does not
create documents. A single-window utility program might use a sheet to
request acceptance of a licensing agreement from the user, for example.
Other window-specific dialogs that are typically dismissed by the user before
proceeding. Use a sheet when a dialog benefits from being attached to the
window as a modal dialog, even if you might otherwise design the dialog as a
modeless dialog.

When Not to Use Sheets

Don’t use sheets in the following situations:

For dialogs that apply to several windows. Use sheets only when a particular
dialog is associated with only one window.

For modeless operations in which the dialog should be left open to allow the
user to observe the effects of changes applied. Such tasks (find and replace
operations, for example) are better suited to modeless dialogs, utility
windows, or drawers.

On a window that doesn’t have a title bar. Sheets should emerge from a
definite visual edge.

When the user will need information in the window that is essential to filling
in requested information in the sheet."

Post by Lubos Lunak

Post by Aaron J. Seigo
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)

Macs are quite rare in these parts. But I've heard they're known for
having a very consistent interface.

on the term "consistent", to quote one of my favourite movies, "you keep using
that word, but i do not think it means what you think it means."

Post by Lubos Lunak
mouse. Another reason why trying to be inconsistent just for the sake of
being different is bad.

i'm not going to raise to the bait in your mail, and i'm sorry i did that in
past message. in return, it would be cool if you didn't mischaracterize my
motivations.

Post by Lubos Lunak

Post by Aaron J. Seigo

Post by Lubos Lunak
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.

It currently cannot override the application, but looks like I'll have to
change it.

i've installed some default kwin rules and got rid of the move() code. should
be good now ....

[Lubos Lunak]

Post by Aaron J. Seigo
that would be awesome. essentially, i would like a way to flag a window as
being "document modal"; the parent winId relationship would be enough to
communicate what it is modal to, just like other dialogs. this window hint,
however, would add the extra guidance that this dialog is modal to the
document contained within that window.
http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGui
delines/XHIGWindows/chapter_17_section_6.html#//apple_ref/doc/uid/20000961-T
PXREF11

I must be missing something, because I fail to see the difference:
- it's modal - we have modal dialogs
- it's attached to a specific window - dialogs are attached to their specified
mainwindow
- "Mac OX X layering model" - if I'm getting it right that this is just a name
for keeping the dialog together with the window in the stacking order, then
we have that
- it doesn't have a titlebar - visual difference
- it slides in - visual difference
- "Sheets also allow users to perform other tasks before dismissing the
dialog, with no sense of the system being “hijacked” by the application." -
oh boy, that is from an old HIG version, right?

Where exactly is the absolutely killer feature I don't see?

Post by Aaron J. Seigo

Post by Lubos Lunak

Post by Aaron J. Seigo
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)

Macs are quite rare in these parts. But I've heard they're known for
having a very consistent interface.

on the term "consistent", to quote one of my favourite movies, "you keep
using that word, but i do not think it means what you think it means."

Consistent: marked by harmony, regularity, or steady continuity, free from
variation or contradiction (Merriam-Webster). My mistake about the Macs part,
but as I said I have no experience with them.

Post by Aaron J. Seigo

Post by Lubos Lunak
mouse. Another reason why trying to be inconsistent just for the sake of
being different is bad.

i'm not going to raise to the bait in your mail, and i'm sorry i did that
in past message. in return, it would be cool if you didn't mischaracterize
my motivations.

Quite frankly, to me your motivation seem to be being strongly decided about
how exactly minicli will look like and dismissing any kind of complaint as
not understanding your vision. But now that I know a workaround, I don't feel
like continuing this.

Post by Aaron J. Seigo

Post by Lubos Lunak

Post by Aaron J. Seigo

Post by Lubos Lunak
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.

It currently cannot override the application, but looks like I'll have
to change it.

i've installed some default kwin rules and got rid of the move() code.
should be good now ....

Almost. First of all, that's KWin's configuration -> it belongs to KWin.
Second, I've already said that such rule is not okay for just one dialog -
either it's none, or all of Plasma's dialogs (I suppose I can take that).
Third, the dialog is not going to be called 'Add Widgets' here - the dialog
needs a window role (gee, that seems to be a Qt problem, I know I'm gonna
hate that :( ).

I will move and fix the file, unless you for some reason don't like some of
this.

[Riccardo Iaconelli]

Post by Lubos Lunak

Post by Aaron J. Seigo
http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIG
ui
delines/XHIGWindows/chapter_17_section_6.html#//apple_ref/doc/uid/2000096
1-T PXREF11

- it's modal - we have modal dialogs
- it's attached to a specific window - dialogs are attached to their
specified mainwindow
- "Mac OX X layering model" - if I'm getting it right that this is just a
name for keeping the dialog together with the window in the stacking order,
then we have that
- it doesn't have a titlebar - visual difference
- it slides in - visual difference
- "Sheets also allow users to perform other tasks before dismissing the
dialog, with no sense of the system being “hijacked” by the application." -
oh boy, that is from an old HIG version, right?
 Where exactly is the absolutely killer feature I don't see?

What, visual differences aren't killer features anymore? What is all the
Plasma and Oxygen stuff about then? ;-)

Seriously, what is also the big feature, probably just visually, is that the
window is not perceived as being one: it does not have a entry in the
titlebar, it's is *sticked* to the main window... meaning that when the
window minimizes the sheet does also, when the window moves the sheet
smoothly remain at its place...It's not really the same thing that we have
now. They can also automatically disappear if showing e.g. a progressbar.
Also, there cannot be more than one sheet piling toghether at a time...

In the end it's different, we don't have such a thing yet, not even a similar
one. =)

If you want another example it might be similar to some modal dialogs there
are in some web 2.0 apps... that's probably the best way I can explain it...
if you want to figure out better, please try out a mac into a near computer
reseller. ;-)

Bye,
-Riccardo

[Lubos Lunak]

Post by Riccardo Iaconelli

Post by Lubos Lunak
 Where exactly is the absolutely killer feature I don't see?

What, visual differences aren't killer features anymore? What is all the
Plasma and Oxygen stuff about then? ;-)

I don't consider a visual difference done just for the sake of a visual
difference a killer feature, not even close (well, depends on the meaning of
killer, too). I don't see what should be so cool about doing things
differently just because one can.

Post by Riccardo Iaconelli
Seriously, what is also the big feature, probably just visually, is that
the window is not perceived as being one: it does not have a entry in the
titlebar

Taskbar? Modal dialogs in KDE don't (shouldn't) have taskbar entries.

Post by Riccardo Iaconelli
, it's is *sticked* to the main window

Which may be a problem if you happen to need to look at something in the main
window.

Post by Riccardo Iaconelli
... meaning that when the
window minimizes the sheet does also, when the window moves the sheet
smoothly remain at its place...It's not really the same thing that we have
now.

But we can, it's as simple as somebody adding both of these to KWin.

Post by Riccardo Iaconelli
They can also automatically disappear if showing e.g. a progressbar.

A sheet, i.e. a modal dialog, disappearing just because a progressbar shows?
I must be misunderstanding this.

Post by Riccardo Iaconelli
Also, there cannot be more than one sheet piling toghether at a time...

I suppose this has nothing to do with the visual appearance or the other
features.

Post by Riccardo Iaconelli
In the end it's different, we don't have such a thing yet, not even a
similar one. =)

Besides a modal dialog?

Post by Riccardo Iaconelli
If you want another example it might be similar to some modal dialogs there
are in some web 2.0 apps... that's probably the best way I can explain
it... if you want to figure out better, please try out a mac into a near
computer reseller. ;-)

[Riccardo Iaconelli]

Post by Riccardo Iaconelli
, it's is *sticked* to the main window

 Which may be a problem if you happen to need to look at something in the
main window.

If a sheet is displayed, you don't. As I said, it's a different thing from a
modal dialog. I'm not proposing to get rid of modal dialogs to use sheets
instead. =)

Post by Riccardo Iaconelli
... meaning that when the  
window minimizes the sheet does also, when the window moves the sheet
smoothly remain at its place...It's not really the same thing that we
have now.

 But we can, it's as simple as somebody adding both of these to KWin.

Well... that was the point of discussion. ;-)
If it's so simple, please add them, they would rock. Or let's add a KSheet
class to kdelibs wich does this!

Post by Riccardo Iaconelli
They can also automatically disappear if showing e.g. a progressbar.

 A sheet, i.e. a modal dialog, disappearing just because a progressbar
shows? I must be misunderstanding this.

Let me rephrase:
They can also automatically disappear if they were, for example, showing a
progressbar which was listing the progress of a certain operation, and which
finished. Yes, also dialogs can do that, but that's just another feeling.

As an usecase for them, the first example which comes to my mind might be a
wizard, which has to do a kio job when switching from page n to page n+1.
When the user clicks on "next", before switching page a sheet slides down, and
instead of the so annoying popup, all is done in the same window... and you
get on the other page when the job has finished.

Really, look at them in action, and you'll understand much better the concept
behind them. =)

Bye,
-Riccardo

[Hans Meine]

Post by Riccardo Iaconelli
As an usecase for them, the first example which comes to my mind might be a
wizard, which has to do a kio job when switching from page n to page n+1.
When the user clicks on "next", before switching page a sheet slides down,
and instead of the so annoying popup, all is done in the same window... and
you get on the other page when the job has finished.
Really, look at them in action, and you'll understand much better the
concept behind them. =)

I get the feeling that it would be nice if you could mention some specific
OS X applications/windows where sheets are used in a way you like.

Are sheets always within a window? Or never? I saw also "sheets"(?) that
slide out at the side of an image viewer, showing multiple thumbnails IIRC.
Are these also called sheets? When would you use which?

[Jos Poortvliet]

Post by Hans Meine

Post by Riccardo Iaconelli
As an usecase for them, the first example which comes to my mind might be a
wizard, which has to do a kio job when switching from page n to page n+1.
When the user clicks on "next", before switching page a sheet slides down,
and instead of the so annoying popup, all is done in the same window... and
you get on the other page when the job has finished.
Really, look at them in action, and you'll understand much better the
concept behind them. =)

I get the feeling that it would be nice if you could mention some specific
OS X applications/windows where sheets are used in a way you like.
Are sheets always within a window? Or never? I saw also "sheets"(?) that
slide out at the side of an image viewer, showing multiple thumbnails IIRC.
Are these also called sheets? When would you use which?

You're most likely referring to that sidebar apple invented (or at
least used a lot) some time ago, which slides out of the side of an
application.

The sheets they're talking about are as far as I can tell just a way
of displaying modal dialogs - they slide out of the app, just below
the toolbar, and they stay connected to it. A nice visual
representation - they're closely connected. But, as Lubos already
pointed out, you can't move them out of the way if you want to see
something below them - a real drawback. Their advantage, on the other
hand, is just that they stay with the window and are visually more
connected to it - slightly easier to grasp, I guess.

Post by Hans Meine
--
Ciao, / / .o.
/--/ ..o
/ / ANS ooo

[Aaron J. Seigo]

Post by Lubos Lunak
Where exactly is the absolutely killer feature I don't see?

that it keeps windows properly associated visually with the window they
affect. most people have problems keeping windows sorted out in their head:
which window belongs to which window. this makes it painfully obvious because
document modal dialogs appear as if they are embedded in the window they
belong to. there's no visual separation, so the concept is more clearly
communicated. it's simply an easier way for people to get the concept
that "this window is working on that window".

i know you don't have problems with that, but this software is used by
millions of people ..... many of whom do. most people don't even know
what "modal" means.

if you can, find someone with a mac and try it out, sheets are a simple thing
but really rather nice and it's easiest to understand the concept if you try
it. there are lots of things i don't like about the current macos, but sheets
are a good idea.

Post by Lubos Lunak

Post by Aaron J. Seigo

Post by Lubos Lunak
mouse. Another reason why trying to be inconsistent just for the sake
of being different is bad.

i'm not going to raise to the bait in your mail, and i'm sorry i did that
in past message. in return, it would be cool if you didn't
mischaracterize my motivations.

Quite frankly, to me your motivation seem to be being strongly decided
about how exactly minicli will look like and dismissing any kind of
complaint as not understanding your vision.

that's probably because the complains were not understanding my vision ...
when someone doesn't "get it" after having it explained to them, yeah, that's
a bit frustrating.

Post by Lubos Lunak

Post by Aaron J. Seigo
i've installed some default kwin rules and got rid of the move() code.
should be good now ....

Almost. First of all, that's KWin's configuration -> it belongs to KWin.
Second, I've already said that such rule is not okay for just one dialog -
either it's none, or all of Plasma's dialogs (I suppose I can take that).

all dialogs belonging to plasma? hm. that might work. i honestly haven't gone
through every possible dialog we'll have to see if that makes sense. note
that human beings rarely work (or play) with such all or nothing type rules;
as the point of usability is to make software more approachable to humans,
these "all or nothing" approaches sometimes work against making the software
usable. this is one of the recurring themes in our conversations here: you're
very much about keeping the rules strict in the software (and i understand
where you're coming from as a window manager developer) whereas i'm trying to
introduce more thinking about how people work with that software ... which is
often not "all or nothing".

Post by Lubos Lunak
Third, the dialog is not going to be called 'Add Widgets' here - the dialog
needs a window role (gee, that seems to be a Qt problem, I know I'm gonna
hate that :( ).

mm.. right, it'll get translated. i'll add a window role to it right now ..
*thinks* "addwidgets" sounds about right =)

[Lubos Lunak]

Post by Aaron J. Seigo

Post by Lubos Lunak
Where exactly is the absolutely killer feature I don't see?

that it keeps windows properly associated visually with the window they
which window belongs to which window. this makes it painfully obvious
because document modal dialogs appear as if they are embedded in the window
they belong to. there's no visual separation, so the concept is more
clearly communicated. it's simply an easier way for people to get the
concept that "this window is working on that window".
i know you don't have problems with that, but this software is used by
millions of people ..... many of whom do. most people don't even know
what "modal" means.

They don't need to, just the fact that it happens is enough. It's quite hard
to miss the fact that a modal dialog belongs to the main window when it
covers it and won't let you interact with it. Still, this seems to make
sense.

But how do you want that handled technically? If the application will have to
explicitly specify it, there will be a mess of having sheets somewhere and
dialogs elsewhere. I can do that simply in KWin with all modal dialogs, it's
just keeping them at the right place and removing decoration, but then, what
if the dialog needs resizing?

I could just make modal dialogs work more like sheets, position the titlebar
aligned with the mainwindow's titlebar and move/minimize together with the
mainwindow, but I suppose you woulnd't find that enough?

Post by Aaron J. Seigo

Post by Lubos Lunak
Almost. First of all, that's KWin's configuration -> it belongs to KWin.
Second, I've already said that such rule is not okay for just one dialog
- either it's none, or all of Plasma's dialogs (I suppose I can take
that).

all dialogs belonging to plasma? hm. that might work. i honestly haven't
gone through every possible dialog we'll have to see if that makes sense.

I think that's the best that can be done for 4.0. And it's still better than
having just one random dialog do that.

Post by Aaron J. Seigo
note that human beings rarely work (or play) with such all or nothing type
rules; as the point of usability is to make software more approachable to
humans, these "all or nothing" approaches sometimes work against making the
software usable. this is one of the recurring themes in our conversations
here: you're very much about keeping the rules strict in the software (and
i understand where you're coming from as a window manager developer)
whereas i'm trying to introduce more thinking about how people work with
that software ... which is often not "all or nothing".

It's not about all or nothing, it's about keeping it consistent and
predictable, if there's not a good reason not to. Which is also about using
it - I don't only developer KDE, I also happen to use it.

Post by Aaron J. Seigo

Post by Lubos Lunak
Third, the dialog is not going to be called 'Add Widgets' here - the
dialog needs a window role (gee, that seems to be a Qt problem, I know
I'm gonna hate that :( ).

mm.. right, it'll get translated. i'll add a window role to it right now ..
*thinks* "addwidgets" sounds about right =)

Note that unpatched QWidget::setWindowRole() just plain aborts if the widget
is not created at that time yet (so e.g. QWidget::winId() needs to be
explicitly called first).

[Aaron J. Seigo]

Post by Lubos Lunak
But how do you want that handled technically? If the application will have
to explicitly specify it, there will be a mess of having sheets somewhere
and dialogs elsewhere. I can do that simply in KWin with all modal dialogs,
it's just keeping them at the right place and removing decoration, but
then, what if the dialog needs resizing?

yeah, that's (one reason) why this can't really be done to all dialogs. it's
only document modal dialogs, as well. simple window or application modal
isn't enough information, since those dialogs may not properly associate with
any one window ...

e.g. if we look at something like an image editor, a modal dialog warning
about disk or memoery scratch space being exhausted / too small is
application modal and should not be shown as a sheet. however, a dialog
asking if they user really wants to delete a given image's contents would be.

so i don't see how we can really get around not having an explicitly set flag.
the good news is that we can set this flag in many of our dialog classes
(e.g. file dialogs, for the obvious example =)

Post by Lubos Lunak
I could just make modal dialogs work more like sheets, position the
titlebar aligned with the mainwindow's titlebar and move/minimize together
with the mainwindow, but I suppose you woulnd't find that enough?

if we could do it without the title bar on the dialog (though i suppose we
want the draggable edges, right? is it even possible to do that with kwin's
current clients? probably not, right?) that'd be great ... but even this
would be an improvement ...

as a point of reference: on Mac the sheet appears to be "coming out of" the
title bar (of course they have a cute little animation too; we could probably
do this as well with a composite plugin someday). so really it's just a
non-decorated window centered under the window's title bar with a drag handle
in the lower right corner iirc.

Post by Lubos Lunak

Post by Aaron J. Seigo
all dialogs belonging to plasma? hm. that might work. i honestly haven't
gone through every possible dialog we'll have to see if that makes sense.

I think that's the best that can be done for 4.0. And it's still better
than having just one random dialog do that.

fair enough...

Post by Lubos Lunak

Post by Aaron J. Seigo
window manager developer) whereas i'm trying to introduce more thinking
about how people work with that software ... which is often not "all or
nothing".

It's not about all or nothing, it's about keeping it consistent and
predictable, if there's not a good reason not to.

agreed; it's the "good reason" part we sometimes have a hard time
communicating about ;)

note that we "broke consistency" between the file dialog and konqueror's
toolbar button order purposefuly (and then again after someone
accidently "fixed" it ;) ... so .. it does happen. as you note, there needs
to be a good reason.

so we're on the same page there =)

Post by Lubos Lunak
Which is also about using
it - I don't only developer KDE, I also happen to use it.

yes, i know =))

Post by Lubos Lunak

Post by Aaron J. Seigo

Post by Lubos Lunak
Third, the dialog is not going to be called 'Add Widgets' here - the
dialog needs a window role (gee, that seems to be a Qt problem, I know
I'm gonna hate that :( ).

mm.. right, it'll get translated. i'll add a window role to it right now
.. *thinks* "addwidgets" sounds about right =)

Note that unpatched QWidget::setWindowRole() just plain aborts if the
widget is not created at that time yet (so e.g. QWidget::winId() needs to
be explicitly called first).

so i've noticed =/ uck.

[Riccardo Iaconelli]

Post by Aaron J. Seigo
so really it's just a
non-decorated window centered under the window's title bar with a drag
handle in the lower right corner iirc.

With a fixed % width, IIRC.

Bye,
-Riccardo

[Lubos Lunak]

Post by Aaron J. Seigo

Post by Lubos Lunak
I could just make modal dialogs work more like sheets, position the
titlebar aligned with the mainwindow's titlebar and move/minimize
together with the mainwindow, but I suppose you woulnd't find that
enough?

if we could do it without the title bar on the dialog (though i suppose we
want the draggable edges, right? is it even possible to do that with kwin's
current clients? probably not, right?) that'd be great ... but even this
would be an improvement ...

Just for the record: I think we have both more important things to do right
now and we're in freeze anyway ->
http://bugs.kde.org/show_bug.cgi?id=152945 .

[Aaron J. Seigo]

Post by Lubos Lunak

Post by Aaron J. Seigo

Post by Lubos Lunak
I could just make modal dialogs work more like sheets, position the
titlebar aligned with the mainwindow's titlebar and move/minimize
together with the mainwindow, but I suppose you woulnd't find that
enough?

if we could do it without the title bar on the dialog (though i suppose
we want the draggable edges, right? is it even possible to do that with
kwin's current clients? probably not, right?) that'd be great ... but
even this would be an improvement ...

Just for the record: I think we have both more important things to do
right now and we're in freeze anyway ->
http://bugs.kde.org/show_bug.cgi?id=152945 .

agreed; and thanks for filing a br for it =))

[Luciano Montanaro]

Post by Aaron J. Seigo

Post by Luciano Montanaro
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
customized...

Post by Aaron J. Seigo
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...

Post by Aaron J. Seigo
(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...

Post by Aaron J. Seigo
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
- 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

Post by Luciano Montanaro
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! :)

Luciano

[Aaron J. Seigo]

Post by Luciano Montanaro
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).

you're creating a straw man here; nobody said it had to be blocking. however,
you may have noticed that even in kde3 it was "stay on top".

Post by Luciano Montanaro
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.

what is missing in current svn for you exactly? because you can move it, it
has autocomplete (though once i swap out the lineedit for a combo it'll be
even nicer)

Post by Luciano Montanaro
I tried it again with the debian live image a few days ago -- is the
artwork the final one?

of course not. maybe i should edit all the non-final artwork pieces and put
a "SAMPLE" text in red on them in inkscape so people stop asking me about
this. ;)

Post by Luciano Montanaro
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,

a bit of history: that svg was done in about 5 minutes where the artist
grabbed the icon art they were working on at the time in inkscape and threw
it on a background and emailed it to me. =) the icon thing in the background
is horrific, and we all knew that.

Post by Luciano Montanaro
but I've been said it can be customized...

that's the point of using svg in this case, yes.

Post by Luciano Montanaro
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...

we'll get to that eventually....

Post by Luciano Montanaro

Post by Aaron J. Seigo
(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...

erm, the issue was not "does it need a window border" the issue was "i want to
be able to move it easily". the former is a possible solution, but the latter
was the problem.

Post by Luciano Montanaro

Post by Aaron J. Seigo
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! :)

=/

[Maksim Orlovich]

Post by Aaron J. Seigo
erm, the issue was not "does it need a window border" the issue was "i want to
be able to move it easily". the former is a possible solution, but the latter
was the problem.

Except having a window border means you have a standard interface
for moving the window, which all the applications share. That one can
click in the middle and drag the window is not something I would expect,
since other apps do not work this way.

Of course, it's more than just moving. For example I can shade the KDE3
minicli if I need to double-check something. I can resize it in the
standard way, if I feel it's too short or too long. By using non-standard
UI you're taking away all those conventions, and frankly I don't see any
benefits except for a subjective improvement in appearance. And if one is
using this for 3 seconds, why does appearance matter much?

-Maks

[Aaron J. Seigo]

Post by Maksim Orlovich

Post by Aaron J. Seigo
erm, the issue was not "does it need a window border" the issue was "i want to
be able to move it easily". the former is a possible solution, but the latter
was the problem.

Except having a window border means you have a standard interface
for moving the window, which all the applications share. That one can
click in the middle and drag the window is not something I would expect,
since other apps do not work this way.

yes, there are trade off in the innovate vs status quo decision making
process. people will learn pretty quickly, though.

Post by Maksim Orlovich
Of course, it's more than just moving. For example I can shade the KDE3
minicli if I need to double-check something. I can resize it in the
standard way, if I feel it's too short or too long.

i wonder how many people actually resize the run dialog in kde3.
i wonder how many people actually move the run dialog in kde3. (more than
resize it, in my experience)
i wonder how many people who use something like katapult or quicksilver or
deskbar even care.

=/

Post by Maksim Orlovich
By using non-standard
UI you're taking away all those conventions, and frankly I don't see any
benefits except for a subjective improvement in appearance.

perhaps i've been to hard to understand, then. apologies.

Post by Maksim Orlovich
And if one is
using this for 3 seconds, why does appearance matter much?

if one is using it for 3 seconds, why do they need to shade it? same answers,
i imagine.

i'd also suggest that "it only is the center of attention for 3 seconds at a
time..." has not bearing on whether to neglect its appearance or not.

and before people manage to completely sidetrack us here, there's reason for
this approach that inclues providing a way to identify the interfaces that
are infrastructure, and get them out of my way.

similar to why we don't have passive popups in standard window dressing.

and yes, i know doing *anything* different brings push back, that the push
back is normal, healthy, expected.

[Simon Edwards]

Post by Aaron J. Seigo

Post by Maksim Orlovich
Of course, it's more than just moving. For example I can shade the KDE3
minicli if I need to double-check something. I can resize it in the
standard way, if I feel it's too short or too long.

i wonder how many people actually resize the run dialog in kde3.
i wonder how many people actually move the run dialog in kde3. (more than
resize it, in my experience)
i wonder how many people who use something like katapult or quicksilver or
deskbar even care.

Speaking as a katapult, launchy (win32) whore^W I mean user, if you just
use it for running a gui program from the keyboard then there is no real
need for standard window decorations and functionality. But when people
expand the run dialog to perform other tasks like running complete
command lines with arguments etc or as a calculator, then you will come
up against the use cases which require standard window decorations and
functionality. (e.g. someone composing a long command line with bits cut
and paste from another window etc)

cheers,

[John Tapsell]

For the process list (ctrl+esc) thing, I have set it to be by default
'Always On Top', and grab the focus etc.

However if the user right clicks on the title, and toggles off 'Always
On Top', it remembers that for future launches, until the user toggles
it back on.

That seemed to be the best way to do it for the process list.

John

[Lubos Lunak]

Post by John Tapsell
For the process list (ctrl+esc) thing, I have set it to be by default
'Always On Top', and grab the focus etc.

Hmm? Neither of that seems to work here. The process list is not kept on top
(that may be because the state flags are removed when a window is closed, you
might have placed the reading in a wrong place, but I can't find where it's
handled in the code). And it certainly doesn't have any grabs. Oh wait, "grab
focus"? That doesn't exist a technical term AFAIK :). Assuming you're talking
about explicitly activating the window, the logic should be
if isvisible then activate, raise else just plain show.

Post by John Tapsell
However if the user right clicks on the title, and toggles off 'Always
On Top', it remembers that for future launches, until the user toggles
it back on.
That seemed to be the best way to do it for the process list.

[Martin Koller]

Post by Aaron J. Seigo
i wonder how many people actually resize the run dialog in kde3.
i wonder how many people actually move the run dialog in kde3. (more than
resize it, in my experience)

As I was the one who implemented/fixed the resize-ability of minicli, I can
tell you, I use it. Often.

And this is not the only reason I like to have a window border.
I really like to see where a window ends (in terms of used space) when it
opens on top of another window. Therefore it's nice to have (in my case) a
dark blue border which has a good contrast above the usually white background
of the windows I have open.

[Aaron J. Seigo]

Post by Martin Koller
And this is not the only reason I like to have a window border.
I really like to see where a window ends (in terms of used space) when it

this you don't need a window border for.

[Luciano Montanaro]

Post by Aaron J. Seigo

Post by Luciano Montanaro
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).

you're creating a straw man here; nobody said it had to be blocking.
however, you may have noticed that even in kde3 it was "stay on top".

It was not my intention. It's just that your comment made me wonder if that
was actually needed. Yes I noticed that KDE 3 also does this -- just
recently, has it been so all the time? I think something changed along the
way... for example I think I could click return to dismiss the dialog once.

The behaviour can be changed either temporarily with the kwin menu, or through
kwin ad hoc window settings. Sending the window to the back can be useful,
and I see no harm in that, especially since it can be brought up again with
the same Alt+F2 shortcut, with the typed-in text already there.
But well, I've not needed that in one year or more, so I don't have a great
case there.

Post by Aaron J. Seigo

Post by Luciano Montanaro
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.

what is missing in current svn for you exactly? because you can move it, it
has autocomplete (though once i swap out the lineedit for a combo it'll be
even nicer)

I can't test it at the moment -- I'll have to check it again this weekend.
The fact that it could not be easily moved was my biggest gripe.

Post by Aaron J. Seigo

Post by Luciano Montanaro
I tried it again with the debian live image a few days ago -- is the
artwork the final one?

of course not. maybe i should edit all the non-final artwork pieces and put
a "SAMPLE" text in red on them in inkscape so people stop asking me about
this. ;)

That could help. :)
But it's been like that for so long, that I began to worry. And I actually
preferred the plain window look of the KDE 3 version -- sorry if I repeat
myself. Ruphy has shown me a different "black" version some time ago, that I
find even worse... of course that too was unfinished work.

Post by Aaron J. Seigo

Post by Luciano Montanaro
I'd also like a plainer look,

a bit of history: that svg was done in about 5 minutes where the artist
grabbed the icon art they were working on at the time in inkscape and threw
it on a background and emailed it to me. =) the icon thing in the
background is horrific, and we all knew that.

Post by Luciano Montanaro
but I've been said it can be customized...

that's the point of using svg in this case, yes.

Post by Luciano Montanaro
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...

we'll get to that eventually....

This is good to know.

Post by Aaron J. Seigo

Post by Luciano Montanaro
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...

erm, the issue was not "does it need a window border" the issue was "i want
to be able to move it easily". the former is a possible solution, but the
latter was the problem.

Sure.

Post by Aaron J. Seigo

Post by Luciano Montanaro

Post by Aaron J. Seigo
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! :)

=/

[Lubos Lunak]

Post by Luciano Montanaro

Post by Aaron J. Seigo

Post by Luciano Montanaro
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).

you're creating a straw man here; nobody said it had to be blocking.
however, you may have noticed that even in kde3 it was "stay on top".

It was not my intention. It's just that your comment made me wonder if that
was actually needed. Yes I noticed that KDE 3 also does this -- just
recently, has it been so all the time?

It's been there for a long time. I think that's the only window in KDE that
I've left to set such flag on itself - it kind of makes sense to have minicli
staying on top by default, since you really don't want Alt+F2 to show it
behind something. As you say yourself, you can change this using KWin.

Post by Luciano Montanaro
I think something changed along the
way... for example I think I could click return to dismiss the dialog once.
The behaviour can be changed either temporarily with the kwin menu, or
through kwin ad hoc window settings. Sending the window to the back can be
useful, and I see no harm in that, especially since it can be brought up
again with the same Alt+F2 shortcut, with the typed-in text already there.
But well, I've not needed that in one year or more, so I don't have a great
case there.

[Andreas Pakulat]

Post by Lubos Lunak

Post by Luciano Montanaro

Post by Aaron J. Seigo

Post by Luciano Montanaro
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).

you're creating a straw man here; nobody said it had to be blocking.
however, you may have noticed that even in kde3 it was "stay on top".

It was not my intention. It's just that your comment made me wonder if that
was actually needed. Yes I noticed that KDE 3 also does this -- just
recently, has it been so all the time?

It's been there for a long time. I think that's the only window in KDE that
I've left to set such flag on itself - it kind of makes sense to have minicli
staying on top by default, since you really don't want Alt+F2 to show it
behind something. As you say yourself, you can change this using KWin.

JFYI: I have a similar issue right now on my system with XFCE4, the run
dialog is shown on top of all windows initially. But it doesn't get
focus so I can't directly type in the app to start and as soon as I
accidentally move the mouse a bit focus is lost. Either way I have to
switch via alt-tab to it. _Extremely_ annoying, almost making it
unusable - luckily I don't use XFCE4 that often :)

Andreas

[Cristian Tibirna]

Post by Andreas Pakulat
JFYI: I have a similar issue right now on my system with XFCE4, the run
dialog is shown on top of all windows initially. But it doesn't get
focus so I can't directly type in the app to start and as soon as I
accidentally move the mouse a bit focus is lost. Either way I have to
switch via alt-tab to it. _Extremely_ annoying, almost making it
unusable - luckily I don't use XFCE4 that often :)

This is very probably a consequence of insane focus policies. Does XFCE use
something like focus follows mouse or focus under mouse?

[Andreas Hartmetz]

Post by Cristian Tibirna

Post by Andreas Pakulat
JFYI: I have a similar issue right now on my system with XFCE4, the run
dialog is shown on top of all windows initially. But it doesn't get
focus so I can't directly type in the app to start and as soon as I
accidentally move the mouse a bit focus is lost. Either way I have to
switch via alt-tab to it. _Extremely_ annoying, almost making it
unusable - luckily I don't use XFCE4 that often :)

This is very probably a consequence of insane focus policies. Does XFCE use
something like focus follows mouse or focus under mouse?

KDE has very configurable focus policies, and for the record: I think special
windows should look special. That makes the desktop environment look more
sophisticated and less boring and that's a Good Thing.
Watch Asa Raskin's Google TechTalk about user interfaces and pay special
attention to the part "the toolkit straightjacket".
It's also quite interesting to hear that this guy considers "final" usability
more important than discoverability. Question his authority if you want - I
don't agree with everything he has to say either.

[Jos Poortvliet]

Post by Aaron J. Seigo

Post by Luciano Montanaro
I tried it again with the debian live image a few days ago -- is the
artwork the final one?

of course not. maybe i should edit all the non-final artwork pieces and put
a "SAMPLE" text in red on them in inkscape so people stop asking me about
this. ;)

Serious, I think that would be a smart move. I think I can speak for
everyone who reads & answers questions on forums, mailinglists and
newssites when I say I'm getting tired of having to explain the "it's
not final" thing over and over again.

[Willy De la Court]

Post by Stefan Monov
Hi,
"Make it possible to move the krunner window by clicking on an empty part
of it and dragging the mouse."

I thought this was already possible when pressing the ALT key and then
dragging the window.

- --
Simple things make people happy.
Willy De la Court
PGP Public Key at http://www.linux-lovers.be/download/public_key.asc
PGP Key fingerprint = 784E E18F 7F85 9C7C AC1A D5FB FE08 686C 37C7 A689

[Rafael Fernández López]

Post by Willy De la Court
I thought this was already possible when pressing the ALT key and then
dragging the window.

Indeed. If you read the rest of the thread you will find out that this patch
is not about that. It can drag a window without clicking any other button
(just on an "idle" part of the dialog).

BTW, from my point of view this is a big no-no. It introduces inconsistency
between our apps on different platforms (only that is enough) and does not
respond to the normal behavior of X-libs-based applications. Making the
_whole_ desktop hot-spots is not a brilliant idea from my point of view.

Well, just my 20 cents.


Rafael Fernández López

GPG Fingerprint: B9F4 4730 43F8 FFDD CC5E BA8E 724E 406E 3F01 D070

[Jens Herden]

Hi,

Post by Stefan Monov
- the space on the right of menubars
- a groupbox
- a widgetstack
- the space on the right of breadcrumb bars
- etc.

so from the user perspective it's a kind of lottery if it works or not!
Sounds bad to me. You don't want to explain to the user "sorry, here you have
a widget stack and you can not click here to move the window." The correct
reply to this would be "what the hell is a widget stack?"

Post by Stefan Monov
- introduces inconsistency with non-kde apps
- anything else?

Even more reasons for me not to introduce this feature.

I don't like this kind of inconsistency at all and from my POV it is enough to
have Alt+click

Jens

[David Jarvie]

Post by Jens Herden
Hi,

Post by Stefan Monov
- the space on the right of menubars
- a groupbox
- a widgetstack
- the space on the right of breadcrumb bars
- etc.

so from the user perspective it's a kind of lottery if it works or not!
Sounds bad to me. You don't want to explain to the user "sorry, here you have
a widget stack and you can not click here to move the window." The correct
reply to this would be "what the hell is a widget stack?"

This type of thing could be really frustrating to users. (And of course,
many users won't even realise that the feature exists, unless they make
accidental make the mouse twitch.) It seems like a bad idea to implement
this until all the non-active parts of the dialog are able to be clicked
on to drag the window.