Summary of NWI -- the page

Matthew Woehlke mw_triad at users.sourceforge.net
Sat May 16 03:21:24 CEST 2009


Maciej Pilichowski wrote:
> http://techbase.kde.org/Projects/Usability/NWI

I've now done a proofreading pass as well as some (hopefully 
non-controversial :-) ) changes. You probably want to check the diffs 
and/or re-read the page.

I've added some possible discussion points as green text, following the 
convention in the FAI summary. I've also replaced "application" with 
"window" in a number of places. Maybe I'm being technically pedantic 
(i.e. imposing correct-as-according-to-a-coder), but to me "application" 
is a synonym either for "process" or "binary" (and in this case, more 
the latter than the former), both of which are supersets of "window". Of 
course, one of the goals of NWI is to make "process" much closer to a 
synonym for "window" :-). (Especially for Konsole, which IMO most 
desperately needs it.)

> You can configure each container type (+ desktop separately) to show
> shared menu per whole container — menu of the active application
> pane. Shared menu goes "up" as it can (as far container accepts
> shared menu).

Parse error :-). (IOW I didn't understand what this sentence is supposed 
to mean.)

Hmm, and we should probably write a glossary :-).

> The task bar shows the first-class windows ...

I changed the stuff about "first-class windows" quite a bit. It's more 
technical but also more correct (and I'm not much on the term 
"first-class window" :-) ). Is this okay or should we try for better 
wording?

Aaaand... should containers every group in the task bar? If so, how?

> Arranging windows as container

Okay, I'd have to go digging for the discussion on this. You list 
'select windows' and 'create group' as separate steps; is there a reason 
not to combine them?

> Please note that moving embedded windows within a container and
> tearing them off are two distinct actions

Okay, I think I hate that ;-). I don't think it is important except for 
FAI, and if we say you can't move window outside visible area, is it 
even needed? (I'd be fine if the distinction was 'cursor must be outside 
container border by at least X pixels'.)

> Default options for non-FAI containers:

I have some comments here, need to re-check the thread. More later. 
(Hopefully not too /much/ later ;-).)

> Closing a entire container means each application quits, not just 
> closes its "pane".

This to me makes no sense. How would you enforce it? Why should it be 
any different from closing all windows in the container? (I don't get 
the systray example either. Right now I have kopete; if I close the 
contact list, kopete is still running. Why should this change if the 
contact list is in an NWI container?)

> Default key bindings > Adding applications

Konsole will hate you for 'hollow'. Actually, none of these can be 
global keys, but I think they need application support anyway, so it's a 
moot point for 'empty copy' and 'duplicate'. Why does dragging need 
ctrl? If it is a WM handle (i.e. tab, title bar), why do I need ctrl? If 
I want it to work anywhere, why not use alt+LMB which is the current 
binding?

> why [meta] couldn't be mod key

Did I ever say it couldn't? If so, don't know what I was thinking. It 
can be any key X allows to be used as a modifier. (I'd even say allow 
ctrl/shift; or is putting a safety on the gun that important? ;-) ) 
Anyway, wiki updated accordingly.

> Keyboard shortcut actions (switching, under exchange)

Need separate mail for this also.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"Please remain calm... I may be mad, but I am a professional."
   -- Mad Scientist (actual author unknown)



More information about the Kde-usability-devel mailing list