Summary of NWI -- the page

[Matthew Woehlke]

Maciej Pilichowski wrote:
> On Monday 18 May 2009 20:18:00 Matthew Woehlke wrote:
> 
>>>> 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"?)
> 
> Well, here I does not have opinion because I dislike merging, and I 
> think the need of doing it will vanish with NWI.

It's... of arguable usefulness. It's somewhat useful if you have a lot 
of windows that aren't necessarily related (which happens to me at 
times*), but reasonable use of containers can probably eliminate the 
need to group containers.

(* I have six right now, none of which would be sufficiently improved by 
containerizing to justify the effort. Well, the two Firefox windows are 
effectively already TAI ;-), but that would just mean I would have a lot 
MORE windows, but many of them in two TAI containers, and still have six 
children of root.)

The problem is that our panel is drifting to where about four items is 
"full", and you start compressing after that :-).

> So personally I would remove such feature, but on the other hand can 
> we force users to use NWI? I think not. So auto-collapsing the same 
> entries should be possible. 
> ( ) collapse SAI only
> ( ) collapse similar

Okay.

> X1, X2, X3 -- sets (containers) of apps
> n -- intersection
> u -- sum
>
> similar(X1,X2) = [X1 n X2] >= [(X1 u X2) \ (X1 n X2)]

Um. Well, grouping applications is somewhat obvious. For containers I 
think I would only want to group them if they have similar semantics... 
but that's not a question that can be answered by inspecting the windows.

I've been sort-of assuming we need to be able to name containers (i.e. 
user-assigned caption). Maybe there should be a class also; if 
non-empty, containers with the same class can group. Otherwise 
containers don't group. (And perhaps auto-assign class to certain 
containers; for example any TAI created by app request. As a specific 
example, the TAI you get from ctrl-t in konq, so TAI containers of 
konq's would generally get grouped.)

> or 
> there is X3 such that similar(X1,X3) and similar(X2,X3)  

I think that would be too complicated to solve in a reasonable manner ;-).

>>>>> 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? ;-)
> 
> :-DDD
> 
>> 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
>>
>> [stuff about creating containers]
> 
> Nice, better! I change the summary accordingly.

Thanks. I made one further change to the menu text and added a mention 
of picking the container type.

Is putting it in the "confirm" dialog okay? It should be the same number 
of clicks (maybe more mousing, though) and lets you change your mind any 
time before confirming.

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

Thanks :-).

>> 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.
> 
> I wrote whole long part of why apps should quite, or more precisely:
> "
> That's exactly my point -- WM should send "signal" quit. If you don't 
> send signal "quit" but only "close" how can app tell it was asked to 
> quit?
> "
> 
> but! I think systray apps are "odd" anyway so, what the heck... after 
> container close regular applications quit, systray apps close their 
> windows (if configured so).
> 
> Ok?

Yes. I'm not sure if I want closing containers to be like "quit" 
(especially as I want "quit" to be "this application /kind/ goes away", 
when there is such a functionality distinct from closing the window).

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
Here endeth the rant... which I realize is not likely to Win Friends or 
Influence People, especially the person to whom it was directed.
   -- Charles Wilson (generalized)