Summary of NWI -- the page

[Maciej Pilichowski]

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 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. It should stay put until I am 
finished. And I am finished when I close the app, not the doc.

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.

Yet, such simple task, and it is not available for Composer. For some 
reason user has to relaunch Composer each time she/he finished 
his/her previous mail. 

For what _benefit_?

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

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

Cheers,