Summary of NWI -- the page

[Matthew Woehlke]

Maciej Pilichowski wrote:
> On Tuesday 02 June 2009 21:46:19 Matthew Woehlke wrote:
>> The close-window action is generally /not/ accessible via the
>> application's interfaces. (Of course, the application is always
>> permitted to close its window(s).)
> 
> I think it would be odd -- you have to have "quit" so why not "close"?

Well, it's an action usually in the purview of the WM. It's accessible 
from the WM context menu, which makes having it in the application menu 
seem a bit redundant.

However, I didn't say there is any reason it /can't/ be accessible via 
the application (nothing stops applications from deciding to close 
windows for any reason; menu, toolbar, because it is now Tuesday...). 
Just that it usually isn't. (Though I would also argue there is a reason 
for that; see above.)

>> - Some applications (e.g. kopete, KMail's mail composition windows)
>> will *always* close the window.
> 
> As it is against HIG we should not be so specific, because once HIG is 
> changed we would have to change NWI spec as well. I think we should 
> stick with "safe" examples and focus (in those examples) what happens 
> to _document_ not window.
> -> document is closed, no document is created
> -> document is closed, empty document is created
> -> document is not closed

Does kopete violate the HIG? kmail? In some apps, document == window and 
the app does not allow them to be separated. (Basically this is apps 
where a window is created for a particular document, and they have no 
provision for repurposing that window to a different document or an 
empty document, or even some "neutral state". Like some I've written. 
Like kmail and kopete.)

 From a philosophical perspective, one solution is to say that these 
must fall into the "doesn't implement close-document action" category, 
but I don't expect that to go over well with users.

Besides, how are you going to convince non-KDE apps that they are doing 
it wrong? ;-) I vote for keeping the list complete. If it is a violation 
of KDE's HIG, we should add the note "this is a violation of KDE HIG, 
but some apps do it anyway".

>> I'm more generally opposed to allowing an instance to close itself
>> if it has /any/ siblings, though that would be possible.
> 
> So maybe we would get rid of it, because if you don't like it, I don't 
> like it and it is better not to encourage odd designs.

Sure, no problem. I mentioned it here as a possibility, but I didn't put 
it on the wiki.

Likewise for 'may close if there are instances of same kind anywhere in 
the session'; it's technically possible, I'm generally against it, and 
it isn't mentioned on the wiki.

> But we would not say that explicitly because it is HIG task.

True. Since we've punted what happens to application-choice, it is 
clearly under HIG purview. This won't be the last time the HIG will need 
to address NWI-integration at the application level (i.e. where things 
need to be done a certain way /in an app/, not in the WM, to conform to 
HIG).

>> A "close document" action may be present in e.g. a toolbar; in
>> general I would prefer trying to have close-document activated from
>> a widget in the WM decoration.
> 
> Hmm, actually nice idea, especially when you think that menu could be 
> merged with titlebar. I hope someday it will happen.

Um... actually a "not" seems to have been lost from that sentence :-). I 
would prefer that there is /not/ a close-document in WM decoration. 
(Also, doing so increases technical complexity.)

>> As for other ctrl-<letter> shortcuts; I still want to avoid them as
>> globals. 
> 
> In sense:
> a) you don't want ctrl
> b) you want to make them local
> 
> ?

Let me try again :-):

I prefer to not have any global shortcuts (global = handled by the DE, 
not the app, and so cannot be overridden or even used by app) that are 
ctrl-<letter>. App shortcuts are fine. Shared/standard (i.e. defined 
globally, implemented by app and may be overridden) shortcuts are 
encouraged, even.

More understandable?

>> For TAI [choice of window to give focus after closing another 
>> window] could be optional (prev-historic or prev-spatial) but I
>> prefer not offering this until/unless we get requests for it.
> 
> I really mean that when I say I request (well, ask) for that.

I know :-). (FTR, this was further discussed in private mail after the 
previous message was sent, and it's on the wiki as "yes we will provide 
the option". Since as you say, /you/ are asking for it :-), which 
satisfies my aforementioned criteria.)

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
'$ time make world' -> real 5d:14h:37m:5.291s  user 0m:0.000s  sys 
4d:2h:14m:43.712s