Summary of NWI -- the page

[Matthew Woehlke]

Maciej Pilichowski wrote:
> On Saturday 16 May 2009 03:21:24 Matthew Woehlke wrote:
>>> 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.

Ah, yes, much better; thanks.

/me makes note to re-write this part of the wiki into something 
understandable, if you don't do it first

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

Well, I think it does, but I also don't have a doctorate in English, so 
what do I know? ;-)

Looking again, it's a bit obtuse. I'll reword it if I think of something 
better, or let me know if you have ideas.

> 
>> Aaaand... should containers every group in the task bar? If so,
>> how?
> 
> You mean [snip]

Oops, no, that should have been "ever". Should the panel be permitted to 
collapse what would otherwise be multiple top-level entries when those 
entries are containers? If so, what criteria would make sense for 
deciding what to merge?

Right now it's easy; same application is merged. For containers, is 
hard; do you merge all TDI containers? Only containers with "similar" 
contents? (How do you define "similar"?)

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

Wait, did the text change or was I smoking something when I wrote that? ;-)

Let me try again. Do we need a context menu step to say "done selecting 
windows", or can we do this:

- decide to create a {T,F,G}AI container
- select windows mode started by previous action
- select windows as described
- click 'okay' button in corner of screen or hit enter*
- container is created with windows

(* ...or anything else that doesn't involve a popup menu ;-); the fewer 
keys/clicks, the better.)

It wasn't my intent to imply I don't like the selection method; sorry 
for that.

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

Okay. Option is fine, I can understand wanting tearing to be more 
explicit. (Personally I want it to be less effort :-).)

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

Well, complain to Kontact, but I don't think at the WM level we should 
be trying to change what happens when you close a window ;-). Anyway, 
there is no change here from how things work at present.

> * 7 of them were automatically tear off despite I didn't say anything 
> anything about tearing off -- surprising

Ah... no? The windows close, there is no "tearing off" (which I agree, 
would be very surprising). Apps that run without any windows (e.g. 
Kontact, KMixer, also I think Amarok) will still be running.

Also, apps with windows in other containers will still be running. Why 
shouldn't they?

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

Well... yes? (But the windows are closed.)

I suppose it would be good if we could remember if windows should be in 
a container, same way we remember e.g. if they should be maximized, but 
that problem exists regardless.

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