closing documents, take 2
Matthew Woehlke
mw_triad at users.sourceforge.net
Wed May 20 23:02:00 CEST 2009
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
More information about the Kde-usability-devel
mailing list