[patch] Grab windows anywhere, not just titlebar

[Aaron J. Seigo]

On Thursday 08 November 2007, Lubos Lunak wrote:
> On Thursday 08 of November 2007, Aaron J. Seigo wrote:
> > On Wednesday 07 November 2007, Lubos Lunak wrote:
>  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.

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

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

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

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

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

-- 
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/20071108/4f5259e0/attachment.sig>