Summary of NWI -- the page

Maciej Pilichowski bluedzins at wp.pl
Sat Jun 6 14:58:14 CEST 2009


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.

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

Are you just ok, or you would like to have such options. Because I am 
just ok :-) If there is no real need for those why add it?

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

Sure -- this option. 

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

If you insist on keeping the list, I opt for putting in bold "see HIG 
to check what scenarios are valid" (or something like this) to 
clearly state we put there some random stuff not caring which one is 
legal and which one is not. 

However I still think mixing stuff NWI handles and the rest is 
confusing.

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

I say let's focus on what we actually would like to achieve now. It 
should be blueprint now running ahead. IOW there will be time to 
design NWI 2.0 but it is not now.

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

Misunderstanding then, sorry.

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

Cheers,


More information about the Kde-usability-devel mailing list