closing documents, take 2

[Matthew Woehlke]

Maciej Pilichowski wrote:
> On Tuesday 19 May 2009 22:25:39 Matthew Woehlke wrote:
>> What about this?
>>
>> [ ] Closing a document also closes the window if their are other
>> instances of the application in the container.
>> [X] Do not allow the last instance of an application to be closed
>> by closing the document
> 
> The problem is there were 3 cases, now you have 2.

Actually the above is 4. Something still isn't right :-).

The problem is that the possible choices isn't easily represented in a UI.

We have, basically, two variables: 1) app supports empty state, 2) app 
is last instance. For each state we have two or three options: a) close 
window, b) close doc (empty state), c) do nothing.

I am suggesting that combinations 1c and 3c* make no sense and should 
not be allowed. Given that, there are 2*2*2*2=16 possible combinations 
of behavior. They don't all necessarily make sense.

(* I am using binary-or, so '1' and '3' mean that case 1 is true, and 
case 2 is respectively false and true.)

>> The problem is applications that don't have an empty state, yes?
> 
> No, not at all. 

?

>> if I asked to close the document, that should 
>> happen.
>> Only if the application doesn't have an empty state (i.e. 
>> can close window, can't close document without closing window)
>> should we possibly not do anything.
> 
> Not really, such application should close the doc and "open" blank 
> one. Like Kate in KDE3.

Well we have some (e.g. kjots, Amarok) that really don't have an "empty 
state". Let's see... let's assume that close document may no-op iff we 
have no empty state. That leaves...

{support empty, not last} -> {close, empty} (0:a or b)
{     no empty, not last} -> {close, no-op} (1:a or b)
{support empty,     last} -> {close, empty} (2:a or b)
{     no empty,     last} -> {close, no-op} (3:a or b)

Some combinations (any with 1b+3a) don't make sense, but that still 
leaves quite a lot of choices.

>> (which is more correct from a technical standpoint 
>> without having specified otherwise)... and yes. Start KWrite, hit
>> "New" a few times (you need to type something into the empty
>> documents or it won't make new windows)... you'll get several
>> windows, but only one kwrite process.
> 
> Ok, I get it. And in such case (currently) close window means close 
> this window, and quit app means close all windows and quit the app?

IMO "Quit" should either be the same as close document (I think it is 
for KWrite; can't check right now because my KDE is apparently hosed), 
or "Quit this /application/" (as it is for e.g. Firefox, i.e. quit all 
instances of this application, even if not the same pid).

> On a bright side...? I hope/guess/think it does not interfere with 
> NWI?

Nope :-). My present thinking is that the WM shouldn't touch "Quit"; 
that should be for the application to implement.

> Except...
> 
> Let's say I have TAI with kpdf. 

s/kpdf/Okular/ ? ;-)

> I create another tab. In such case I 
> would really like that this is another tab of the same process, 
> right? Because otherwise find in one tab would be blind of the things 
> I entered in find dialog in other tab.

Hmm. Interesting point :-). (OTOH, separate processes means one won't 
take out the other.) However you can still solve this with IPC (probably 
using dbus). In fact I think it would be better to solve with IPC, 
because then you can work with the WM to automatically associate with 
all application instances in a particular container, even if they were 
started as separate processes (and to rebuild such associations as 
windows are moved around, reparented, etc.).

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
Use the --force, Luke -- Riccardo Iaconelli