Summary of NWI -- the page

[Matthew Woehlke]

Maciej Pilichowski wrote:
> On Tuesday 19 May 2009 18:58:53 Matthew Woehlke wrote:
>>> I don't think WM should care about any app specific issues. It
>>> should be quite in reverse -- app should provide means to make
>>> other use of this or that shortcut.
>> ...except that you're going against something like 20 years of
>> established convention.
> 
> In such case (like here we have) I try to put history on the side and 
> the future on the other. Do we really have to walk with this history 
> on our back for... how long? 10 more years? 20 more years (and then 
> would be "40 years of established..."). I care about backward 
> compatibility, but when you build a car you don't put a horse inside 
> because of the tradition.

...but you still put wheels on it ;-).

>> You're also assuming that it's even 
>> /possible/ to change CLI applications to use something else. 
> 
> Sure, see VirtualBox. It uses "send xyz" technique. Nice, efficient. 

Gaah!!! Have you ever had to use that? Efficient it is *NOT*. :-)

> What's more you should be able to assign your shortcuts for the 
> actions!
> 
> It means I should be able to press F2, it triggers action "send 
> ctrl+c". Or you could pick up from the menu "send ctrl+c".

That might work for Konsole, but it means you've made xterm unusable 
until the default (WM) keys are changed. Also, do you consider "press X 
to send Y" good usability? (Keep in mind that users are going to need to 
think of it this way in order to cope with CLI documentation, and 
possibly other systems.)

>> I suppose I disagree with you here. Besides, wasn't there a
>> discussion a while back on better separation of keyboard shortcut
>> domains? I think 'ctrl' was on the 'for use by applications' list
>> :-).
> 
> I opt for flexibility.

You can /configure/ the keys to anything you want. I just don't think we 
should start taking over ctrl-<key> as global shortcuts. That way lies 
mass confusion...

> I would really would like not to see another "special key". No matter 
> of the reason. After 20 more years somebody will curse us that we 
> _helped_ to add such hardcoded mod key :-)))

Um... who is hard-coding anything? I'm just saying don't make the 
/defaults/ things that are more likely to add to confusion and possibly 
cause problems. Why is it so important to use ctrl-<key> as default 
anyway? :-)

>>> Btw. ctrl+w is current default shortcut for document close.
>> Right; an /application/ shortcut. We don't have problems now
>> because there are currently no global shortcuts (that I know of,
>> anyway) that use only ctrl.
> 
> Ok, but user uses ctrl+w. She/he is used to it. Why do we use alt+f4? 
> Because it is ergonomic? No. Because users are used to it. I bet 
> Konsole is not used by weekend-user so even if there is a problem, it 
> is easier for power-user to change this than for weekend-user.

...but you've now forced power users to re-learn ctrl-w.

I prefer a solution with neither of these problems. I'm not sure yet 
what that is (from a technical standpoint). What I /want/ it to be is, 
all apps /except/ those for which it is a problem, accept ctrl-w as 
'close document'. "Special" apps use something else (e.g. Konsole uses 
ctrl-shift-w).

I hate to say it, but... I think leaving ctrl-w as an application 
shortcut might be best. Apps will need to integrate with the WM anyway 
for 'new empty sibling' and 'clone', so might as well require that for 
'close document' to integrate with NWI also. Meanwhile, for apps that 
have their own MDI it is probably better if the WM doesn't try to 
second-guess the app; otherwise you end up with ctrl-w closing the whole 
window which has multiple documents.

In fact... until NWI is good enough that everyone agrees there is no 
need for app-level MDI, I think you're stuck with that. Sure it sucks, 
but then so does the alternative.

>>>> What I mean is there is no way for the WM to get an app to quit;
>>> Ok, but can WM _ask_ app to quit?
>> It should be possible; it just means the app needs to handle such a
>> signal. Much is possible an an ideal world, I am just also
>> considering what will be the problems from adoption lag.
> 
> I changed the summary so close container means all embedded windows 
> close as well, so it is up to each app. It is better to test it and 
> see how it works, instead of changing every piece in one step. 

Since that seems to be before my last edit, I assume that by "embedded" 
you mean "children, grandchildren, great-grandchildren, etc...". Which 
is right, of course, because it is recursive. The (sub-)container 
doesn't care if it is being closed because the user clicked it's 'x', or 
because the parent told it to close.

Hmm... that said, I guess containers should stick around until their 
children /actually/ close (or else windows that won't close for whatever 
reason will "detach").

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
Here endeth the rant... which I realize is not likely to Win Friends or 
Influence People, especially the person to whom it was directed.
   -- Charles Wilson (generalized)