Summary of NWI -- the page

[Maciej Pilichowski]

On Saturday 16 May 2009 03:21:24 Matthew Woehlke wrote:

> 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.

Sure, thanks.

> 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.)

I was focusing on adding all information from ML to summary, thus the 
terminology mess :-))

> > 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.)

Remember the discussion if the menu in GAI should be shown per each 
pane or only single menu for entire container (shared menu)? The 
latter means, the menu goes from pane to container. But since 
container can be pane, it goes "up" again, if the parent-container 
has also shared menu.

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

Added section, I add some content there later.

> > 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?

Yes, it is much better. I only have problem with my English "be they 
leaves or containers", is this really correct? I know what it means, 
because I know what we talk about.

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

You mean -- should containers _list_ every group? Every = every direct 
desktop child? For me, yes. Normally. Every = every group. In 
submenu, in submenu of the submenu etc. So it would reflect the 
hierarchy.

> > 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?

a) "combine" means -- with every selected window it is immediately 
groupped, if yes, we discussed this and you agreed that two modes are 
possible, this one (not combined) and combined (incrementally 
adding).
b) if yes -- this workflow, select and then group, lets user work in 
his/her own pace, think about windows, _de_select something (very 
easily done)

> > 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'.)

It is safer for the user if she/he wants to move, not tear. With such 
difference you can move outside and the window still be moved -- this 
means we have infinitive space (see Mac menu case), which is good 
because you can safely (more safely) arrange the container.

So if you really hate it I would suggest option, because not that I 
hate opposite, but I work too many hours at computer and I appreciate 
UI safety (doing X I like to do it safely, and when I do Y, I would 
like to make explicit action for Y).

> > Default options for non-FAI containers:
>
> I have some comments here, need to re-check the thread. More later.
> (Hopefully not too /much/ later ;-).)

ok :-)

> > 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?)

I don't use Kontact and what you said is for me quite surprising. Here 
is the principle of the least surprise. I put into GAI let's say 17 
applications. I close then entire GAI and all of the sudden (for me) 
10 of them were closed as I would expect but 7 of them kept running. 
This means:
* 7 of them were not closed (quit) -- surprising
* 7 of them were automatically tear off despite I didn't say anything 
anything about tearing off -- surprising

Grouping meant to "act as one". It is hard to think of a group if on 
close each app is on its own.

After all closing container means closing _parent_. Why child should 
survive?

To extreme you can think of grouping all systray apps (no other kind), 
closing container which lead to just ungrouping.

> > Default key bindings > Adding applications
>
> Konsole will hate you for 'hollow'. 

:-) This is just a suggestion rather, not a final version :-D.

> 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?

You mean alt+LMB should be direct dragging? Current binding of alt 
means resize.

Direct dragging (not just dragging) requires some mod key to make the 
difference between just dragging (moving).

> > 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.

I was unsure that's why I was asking, you have much greater expertise 
so it is safer to ask :-)

> > Keyboard shortcut actions (switching, under exchange)
>
> Need separate mail for this also.

Ok :-).

Cheers,