WM: grouping applications (TAI)

Maciej Pilichowski bluedzins at wp.pl
Sat Mar 14 23:04:31 CET 2009


And yet another thoughts:

* I am more and more convinced the order
tabs
menu

for TAI which you opted for is not only the better but correct one. 
This provides more clear distinction between container and the 
windows

* ... and this also indicates that container is just, well, container, 
it does not have any logic, like open the file, go to this URL. Which 
means than besides being resized, closed, it does nothing.

* and this along with need for consistency brings me to this issue. 
"
When discussing things at first about GAI we assumed (agreed) that we 
could switch windows that are embedded. However with introduction of 
TAI and mixed mode, we should revise this I think. i.e. having
* Kate
* GAI(Konq,Konsole)

Konsole is active, I am able to alt-tab switch to Kate<->GAI(Konsole) 
but not Konq. If I would like to switch to Konq from Kate I have to 
use another shortcuts, or combine them.
"

This needs clarification, Kate is active, I press alt-tab. What is 
active (focused) next? GAI container or Konsole within it?

a) GAI -- it would be very difficult to perform tasks as today, 
because I often copy data from app to app, and GAI is not an app

b) Konsole -- ok, this is useful, but this would mean (because of 
consistency need) that user is not able to switch to any container 
using up/down/left/next/whatever except for structure actions -- go 
to parent, go to child.

ad.b) it has another reasons: how often you resize app compared to 
using this app? And closing -- since we talk about containers here, 
it would be even better if closing it (which means closing all apps!) 
would require extra step (activate parent). The problem is I see 
already now if user would have actually not fully TAI but TDI -- then 
user is used to ability to close whole container directly from 
document level

Or maybe I rephrase this -- how (using keyboard) we close windows in 
TAI/GAI mode (let's put systray apps aside for a while), so we have
* close doc
* close app

?

Close doc seems to works as closing the lowest-active window, but then 
what would close app do? Close parent of such lowest-active window?

This brings dangerous if SDI is put inside any GAI/TAI, because its 
parent is directly the container.

If above I am right we would need to rethink idea of SDI -- SDI would 
be then special case of TAI, with hidden interface of multidocument.
Thus SDI would be degenerated container, containing doc inside, but in 
visually hidden way.

So this would solve the problem with closing -- for SDI there would be 
still lowest-level window inside, and the parent would be SDI itself. 


Ok, enough of thinking for today :-), I have more and more clear 
vision of this, and what to put in summary, but I'll wait for your 
comments.

Cheers,


More information about the Kde-usability-devel mailing list