Summary of NWI -- the page

[Matthew Woehlke]

Maciej Pilichowski wrote:
> On Saturday 27 June 2009 00:42:26 Matthew Woehlke wrote:
>> Maciej Pilichowski wrote:
>>> On Thursday 04 June 2009 17:17:30 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).)
>>>> 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.
>>> Ok, but since it is legal, I opt for removing such remarks from
>>> NWI summary.
>> Remind me, is this on the wiki somewhere? Or just here?
> 
> _This_ remark -- only here (AFAIK). _Such_ remark -- in wiki too.

I'm sorry, I must be blind. I'd like to revisit this, but I am not 
seeing what part of the wiki it is I need to revisit. Can you please be 
specific? Again, sorry...

>> I believe 'close document' (or at least ctrl-D) should be permitted
>> for "satellite" windows (e.g. kmail, kopete, similar.) 
> 
> I agree.
> 
>> and should 
>> close the window.
> 
> I disagree. Application launch costs, and user should not control all 
> the time if this app quits, or not.

Um... but the point is, closing the window does *not* close the app in 
these cases. (Well maybe if mail editor is separate app, but I think 
not; certainly for e.g. kopete is not separate.) And if it is expensive 
to relaunch such satellite window, IMO app is doing something wrong.

(Okay, for kopete is marginally expensive in that you might have to 
reopen main window to get "document" back, but...)

As far as when close doc /would/ close an app, we have options for that, 
and I think we agree on how that should work.

> It should stay put until I am finished. And I am finished when I
> close the app, not the doc.

I am certainly finished chatting with someone without closing kopete!

> It is striking me for Composer (KMail) -- Composer is just an editor 
> with the ability to queue mail. Who saw an editor which is incapable 
> of editing 2 documents?
> 
> I am not aware of any metaphor from real world which can be compared 
> with Composer -- I bought typewriter, I use one sheet of paper, I am 
> not afraid of rolling in another sheet. Meanwhile typewriter does not 
> vanish. Composer vanishes. I would like to say to Composer:
> 
> -- I launched you, because I have to write 5 emails. So stay put and 
> don't go anywhere.

Hmm... is the problem that you need a "send and start writing new" 
button, or that composer takes too long to re-launch from "write new" 
button in kmail? If it was near-instant to launch, would you still have 
a problem with close-document closing composer (but only if launched 
from e.g. kmail and not launched stand-alone)?

>> Closing when there are siblings is a little different, but I
>> suspect there would be bug reports when using TAI-used-to-be-TDI
>> applications otherwise.
> 
> I don't see it, but ok.

Let's say I have three konq tabs. Right now they are TDI and ctrl-W 
closes tabs if >1 tab left. Now with TAI (each tab == separate app 
instance, own process, etc.) would you be confused if ctrl-W just made 
tab empty? This is what I mean.

Actually, after Diego's, er... persistent persuasion, I am starting to 
agree with you in all things close-document related ;-). But I'm not 
sure, because I think it /will/ be surprising and confusing (at least, 
at first) to users.

Hmm...

>>>>> 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?
>>> We agreed that closing document is app specific, not
>>> last-app-close (AFAIR).
>>>
>>> I am talking about those -- _last_ window inside container, user
>>> actions:
>>> [ ] ignore closing app completely
>>>    [ ] close the document instead
>> Remind me what action was invoked that this comes into play?
>> close-window or close-document?
> 
> State: last window app in the container.
> 
> Action: user closes the application window.
> 
> Possible effects (set by user globally):
> a) entire container closes
> b) nothing happens (action is ignored)
> c) application goes to "blank state"
> 
> So do you agree user should have such choice to select which a/b/c 
> she/he would like the best?

Yes, I think so.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
You're on your own for the pony. -- Richard Hughes, on feature requests