Summary of NWI -- the page

[Maciej Pilichowski]

On Wednesday 03 June 2009 21:57:29 Matthew Woehlke wrote:

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

UI redundancy is not a bad thing -- you have menu, toolbar, keyboard 
shortcuts.

> However, I didn't say there is any reason it /can't/ be accessible
> via the application 

I would really opt for removing this remark. It is not the task of NWI 
to talk about UI in general. Adding stuff from other areas (like HIG) 
only will make it harder to manage.

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

KMail Composer, yes, this bug is already reported.

> In some apps, document == 
> window and the app does not allow them to be separated. 

In such case "close document" should be ignored. UI is as good as it 
is uniform. When user has to memorize that he/she cannot (*) close 
the doc with app A, B, C, and can with D, E F it is bad UI.

(*) cannot mentally, because user knows it will cause app close and 
need of launching it again

> Besides, how are you going to convince non-KDE apps that they are
> doing it wrong? ;-)

By talking to developers. Just like with KDE.

> I vote for keeping the list complete. 

I am not opting for keeping this list complete or incomplete, but for 
removing it. Once you touch HIG ground, you can start a debate on HIG 
rules which is not part of NWI. It is out of the scope of NWI, we 
don't control it, we don't encourage or discourage this or that UI 
(because NWI is not HIG), we don't talk about it. We provide such 
solution which is transparent to application internals.

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

And if HIG changes, we should change the summary as well. There should 
be no such dependency in NWI.

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

Ok, but anyway this is talk off the main topic, so this or opposite 
preference is not addressed by NWI.

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

Yup. I prefer opposite -- one of the reason, no to provide false 
comfort of ability to use hardcoded ctrl+ shortcut at the app level. 
And this is exactly what occurred and now we have such discussion. 


The closing section in the summary is now a little blurry -- you wrote 
here that you would like to get rid off the conditional closing an 
app on doc-close but the summary still have it. Can I remove it?
On the other hand you removed two options for controlling 
last-app-close. Since you agreed to those options can I put it back?

Cheers,