Summary of NWI -- the page

[Maciej Pilichowski]

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.

Above is about principles in general, because in our case -- it is 
history against history :-)

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

> The 
> alternative is to use ctrl-shift-c to cause Konsole to take the
> action as if you had pressed ctrl-c... not good usability IMO.)

If this is hardcoded, I agree.

> 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. I have already problem with [alt], it is the 
special key, because of the history, etc. In the effect I have 
artificial layout, artificial problem, which does not help me working 
at all.

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

Think of make syntax, if I didn't scared you already :-DDD

> IMO the DE should try to avoid gratuitously breaking popular
> applications.

Yes and no. 
Yes -- because _users_ matter (not apps).
No -- because:
a) authors of such apps should finally provide new means of UI
b) it would be test of the flexibility of the environment

ad.b) you won't know what cracks if you don't try to break "common 
wisdom"

ad.yes) case with Win95 and SimCity, great backward compatibility 
hack, but it was made for purpose but also, step by step MS forced 
everybody to stop thinking "memory is mine"

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

Ctrl+c is for niche apps vs. ctrl+w which is used everywhere else.

It can be win+w, sure, or something else, but this would mean two bad 
things:
a) we are getting into the history circle and we are allowing that 
whole DE is driven by its this or that component
b) the shift would cost users more than it is necessary -- what's 
more, that would be a cost for users who would not even use the 
features of NWI


Just to be clear, I am the guy who posted a report to make the magic 
[alt] key configurable. (Wontfix. Why? Because of the history :-D).

We have a chance to break that kind of thinking in small degree. Why 
not use this possibility? Be flexible, expect anything, don't 
hardcode shortcuts. So even for sake of this I think it is worth to 
_keep_ ctrl+w as it is now (now = KDE3, KDE4).

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

Cheers,