Summary of NWI -- the page

[Matthew Woehlke]

Maciej Pilichowski wrote:
> On Saturday 16 May 2009 04:04:11 Matthew Woehlke wrote:
>> Matthew Woehlke wrote:
>>> Maciej Pilichowski wrote:
>>>> http://techbase.kde.org/Projects/Usability/NWI
>>>> Default options for non-FAI containers:
>>> I have some comments here, need to re-check the thread. More
>>> later. (Hopefully not too /much/ later ;-).)
>> Oy. On re-reading the thread, I think the problem here is just that
>> "app" is really confusing (unfortunately) in this context :-(.
>>
>> I rewrote this in a way that I can understand it; I don't think I
>> changed any of your intent (with one exception), but...
>>
>> The one change I did make is to remove the "not-FAI" part. Any
>> reason FAI should behave differently? (Do we need this configurable
>> per-container? I think my preference is to not do that.)
> 
> I cannot tell because I didn't find any reference to "default options 
> for non-FAI containers" phrase or any similar. The only similar 
> section is about SAI not FAI, and it is justified because SAI is not 
> container per se, and those options does not make any sense for SAI.

Maybe that's why I am confused. There really isn't even such thing as 
SAI, you're just talking about only one window. (I've been reading SAI 
as being more-or-less FAI.)

Well, right now the only "SAI" reference is at the beginning. From my 
end, the current wording is okay.

>> Okay... from a technical standpoint the WM and app have to
>> cooperate for 'close document' (it may be possible for the WM to
>> accept the key combo and decide if it should send the app a close
>> document or close window signal, which would be ideal; better
>> integration with non-KDE apps, less app code needs to change), but
>> then ctrl-w can't be used :-(.
> 
> Why?

ctrl-<anything> can't be used as global shortcuts; they break terminal 
emulators. You must either implement it at application level and let the 
application work with the WM, or else add another modifier.

The reason you need the app to cooperate is because otherwise the best 
the WM can do when you /don't/ want to close the window is push a 
predefined key combination to the app's event queue and hope for the best.

>> Currently it's up to the app to implement this, but come to think
>> of it, it may be possible for the WM to do it, which might make it
>> more consistent (but I think wouldn't actually quit apps that don't
>> go away when all their windows are closed, e.g. systray apps). 
> 
> But you can close such app (and then it stays), quit means quit (like 
> today).

What I mean is there is no way for the WM to get an app to quit; the 
best the WM can manage is tell all the app's windows to close (which 
doesn't necessarily play nicely with apps that do their own session 
management - i.e. Firefox). For "quit" to work, it really needs to be 
handled by the app, not the WM.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"For UNIX thou art, and to UNIX thou shalt return"
The voice of Freedom speaks to the Internet