When I first read Josh's post, I agreed. Just at that time I was making use of several different "tab" systems at once: linux virtual terminals; Win XP running in a VM; a Windows e-book application that had it's own tabbing system; firefox; and awesome's system (which comes in two parts: applications on a given tag, and the various tags themselves.) Each of these systems had its own clever keyboard shortcuts to easily flip from view to view, but I was going crazy, pressing the wrong one all the time. So I certainly am sympathetic to Josh's quest, and by the answers of Julien and Matthias. A unification of the view-managing (tabbing or tagging or whatever it turns out to be) systems should be done whenever possible. The unix philosophy helps on this point.
But Martin's post convinced me quickly, however, that in in the case of browsers and other applications which manage a lot of "views" with very specific management requirements, that it is is more efficient to let the application manage them. Otherwise every new and cool idea that the application developers (or application extension developers) have about how to display windows (sidebars, parallel browser windows, tab grouping, grouped bookmarking, etc) has to ultimately find its interface in the wm. That means that the user gets no benefit of new or application-specific display ideas until the wm developers (and this means the developers of every wm) know and take seriously the new requirements of that particular innovation. This is again no problem if the innovation only has the typical management needs of all windows. In that case we should unify the interface. Also, the pressure to make the wm do more is also good for interface problems that can be profitably generalized. In those cases, the wm either has or should get the tools to deal with it. But browsers windows have enough distinctive management needs (as Martin listed in part, and I have added a few above) that in my opinion it would take an extraordinary amount of development for the wm (and again, each wm) to implement the tools for all such needs. The application is just much nearer to the necessary processes, and the applications own way of handling those things. Firefox alone would be a lot of work, but if you wanted to implement it for other browsers, let alone other apps with unique display requirements, you'd either have to give your window manager "inside information" for every app.. So, yes, give the work over to the wm wherever possible, but when a high degree of "inside" knowledge is required to achieve the best effect, it's probably better handled within the application. In this case, I like the idea of being able to put a new window "below" the current one, but full-fledged session and bookmark management, page-load notifications and many of the other things Martin listed are, it seems, best left within the application. But in each case it's a judgment call. my 2p Scot -- To unsubscribe, send mail to [email protected].
