Summary of NWI -- the page

[Matthew Woehlke]

(Want to say something more about shortcuts, but no time now, probably 
not until Monday.)

Maciej Pilichowski wrote:
> 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.

Well, it is up to apps. I don't care so much, I just think it's 
redundant. And as I said, there is nothing stopping apps from having it 
now, but I can't think of any that do. Probably because most app authors 
feel it is silly and redundant :-). (Or it's labeled "quit".)

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

I'll agree that makes sense for "one-doc applications" (i.e. programmer 
too lazy to implement re-opening doc), but those probably don't have 
"close document" anyway. I don't see why it is a problem for 
kmail/kopete/etc, where you have "the main window" that is 
document-free, and you open documents (mails, chat windows) in their own 
windows. There is no 'application has gone away' in such cases.

I guess I prefer maximizing (power) user efficiency over rigid 
enforcement of homogeneity.

IOW I'm okay with 'close document must not close the window unless a: 
there is a sibling instance of the same kind, or b: the window is a 
"satellite" of a different 'main' class belonging to a process that will 
not be exiting (e.g. most IM clients, many mail clients' compose windows)'.

> I am not opting for keeping this list complete or incomplete, but for 
> removing it.

Where then does conditional closing get discussed? It is very much an 
NWI topic, I don't think it should be omitted.

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

...or reword it 'may be prohibited' or some such, with 'see 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.)
> 
> Ok, but anyway this is talk off the main topic, so this or opposite 
> preference is not addressed by NWI.

Not entirely, since the only way this is possible is:

- app sends signal to WM that it wants some action button in decoration
- WM sends signal to app when that button is pressed

...so the WM has to specifically allow this. True it's not "NWI design" 
as such, but it's still relevant to the WM at the technical level.

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

When did I write that? I said that I wanted to avoid two possible 
conditions: instance has siblings of any type, instance is not unique in 
whole session. That leaves instance has siblings of same type, which I 
thought is what I wrote, which I am okay with.

> On the other hand you removed two options for controlling 
> last-app-close. Since you agreed to those options can I put it back?

Which? The ones (I thought we agreed?) would be app-specific? My 
understanding was the latest decision was it is up to app what to do on 
close-document, i.e. if it should close the window or not. And I thought 
I finally convinced you that close-window can only be disabled when only 
one window in a container?

-- 
Matthew
ENOWIT: .sig file for this machine not set up yet