closing documents, take 2

Matthew Woehlke mw_triad at users.sourceforge.net
Thu May 21 21:59:42 CEST 2009


Maciej Pilichowski wrote:
>>> b) there is container (except for desktop!) with only one app
>>> inside -- user tries to close the app window --> what to do then?
>> Huh? If you ask to close the window, the window had better have a
>> good reason for not closing. 
> 
> Yes, it has -- launching app is expensive. Example -- Konqueror. 
> Remember in NWI the tab is Konqueror. So it requires from user to 
> close entire container, not just one tab.
> 
> I like this behaviour a lot (btw. please note in TAI world user would 
> think in terms of tabs, just like today, so it is more "please don't 
> close the last tab").
> 
>> Asking to save the document is such a 
>> reason.
> 
> No, it is just postponed, this is not the case.

Technically you can choose "cancel" :-). But yes, generally if you close 
a window, the window closes.

Hence I don't understand what you said above. You didn't say close 
document, you said close /window/. Typo?

>>> ad.a) we agreed that it could (option) cause app window close as
>>> well, if there are local siblings of that application kind
>> If it is not last, doesn't have an "empty state", and this option
>> is not set... is 'close document' a no-op? Should it still close
>> the window in this case? Should it /always/ close the window if
>> there is no "empty state"? Should it be possible to control any of
>> this with options?
>>
>> You start with sixteen possible combinations of behavior, some of
>> which make no sense, but there are still something like twelve
>> choices. I am trying to figure out what subset of that we want to
>> be available. From there I'll figure out what the options need to
>> be.
> 
> I don't follow. I don't see those numbers at all -- 16, 12, where did 
> they come from?

You can be in four possible states:
- The window may or may not be the last instance of an application
- The window may or may not support "empty documents"

For each state, you can either close the window, or not close the window.

You can, theoretically, define the behavior as any combination of the 
possible choices for each state.

Thus, 2*2*2*2 = 16.

Some of those don't make sense, as previously mentioned. What I am 
trying to do is reach on consensus on more possibilities that don't make 
sense.

For example, should we allow close/no-close behavior to be different for 
windows that do/don't support empty state? I could see wanting to close 
AI's* with no empty state, but not close AI's with empty state. Should 
we allow that?

(* application instance)

>> Would it help if I wrote all behavior combinations so we can
>> eliminate those we don't want?
> 
> Ok, however I don't understand :-)

Okay, choices are:

nnnn
nnnc - already discarded
nncn
nncc - already discarded
ncnn
ncnc
nccn
nccc
cnnn
cnnc - already discarded
cncn
cncc - already discarded
ccnn
ccnc
cccn
cccc

As example, "cnnc" means:
supports empty, not last -> close ("c???")
       no empty, not last -> no-op ("?n??")
supports empty,     last -> no-op ("??n?")
       no empty,     last -> close ("???c")

As previously stated, this combination is moderately riddiculous, so 
I've already declared it "off limits". That still leaves 12.

Here's a question. Does it make sense to close the last window if it 
supports empty, and no-op if it doesn't support empty? I'd guess "no", 
which is another four we can drop. Any more?

>> Have you filed bug(s)? :-)
> 
> Did you see me not filling a bug report? :-DDD Sure. Till now not 
> fixed though.

Okay. Was just curious.

> Matthew, I am redirecting it to ML, we are not discussing anything 
> private, or classified, and I have difficulties in keeping threads of 
> priv. mail and ML on the same subject. I hope it is ok with you.

True, but at this point we *are* co-opting the list for a discussion 
that really doesn't need to be public. (OTOH it's much, much easier for 
me to deal with replies here as well... sigh :-).) It's not that I want 
this to be "secret", just that I don't see the /value/ in it being 
public, and I do eventually feel guilty using list resources just so I 
can use Thunderbird instead of horribly outpoop to reply.

I was, of course, planning to make sure the result of this made it 
somewhere public.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
This is not a sig. I am too lazy to steal one, perhaps you could loan me 
yours? -- Unknown



More information about the Kde-usability-devel mailing list