Thoughts about tab grouping in Rekonq
I was reflecting upon the options I have as to in what manner exactly will I implement tab grouping into Rekonq. I have come up with three possibilities –
- Use the Kate / Konqueror model for sessions. The sessions will be collections of tabs, and will load into separate windows. One must explicitly save a session for the tabs to be remembered for next time. The tabs in the sessions do not have correspondence to the actual tab instances. There will be some added eyecandy to modify the sessions, by providing a panorama view to drag / drop tabs between sessions, or remove tabs, without actually loading the session. I do not feel this is of much use. Here are a few reasons why –
- Being allowed to drag-drop or delete tabs from sessions is very useless without actually opening it.
- The big reason is, the purpose of tab grouping isn’t actually served in this model. Even if I am able to store or load sessions, what do I achieve? The main reason for tab grouping is that a user keeps clicking and surfing at will, opening more and more tabs till he can’t manage them. This is where a web browser differs from a text editor. Changes in it happen dynamically, and the need for grouping is dynamic and instantaneous. The moment I feel that I am having too many tabs, I should be able to move a few of them to another tab group, clearing up the clutter. A user may have his tabs organized under work, play, school, but when one starts browsing, our surfing patterns hardly follows that organization. We click on links here and there, and may soon land up in an article on the lastest android app in market while in the school session. Now, i have no way to clear the clutter of so many tabs. Most I can do is, save the session, close it, then drag its tabs one by one into another session. Seems astoundingly foolish right? I have come to the conclusion that web browsers, being totally different from text editors or other static applications, require dynamic sessions, that is, sessions that are changed on-the-fly and have a direct way to clear the tab clutter.
- The above point brings me to my next option, a similar implementation, but dynamic. Here all sessions will be loaded when the app is loaded. Thus, the sessions stop behaving as sessions, and are better suited to be called tab groups. These tab groups are one per window. We offer the same glossy panorama view to change the tab groups, but here, each tab in the tab group is directly associated with a WebTab instance. That is, since all changes in tabs are immediately stored to the individual tab groups, so each tab in the tab group actually reflects a current tab. Thus, I can now drag/drop tabs between sessions to reduce the clutter, beautifully managing them. Also I do not need to worry about explicitly storing my changes everytime I add a new tab so that I can see it next time I open rekonq.
- The third option is amost like the second one, but allows for multiple tab groups per window. This would make the eye-candly look all the more catchy I suppose, but would cause the session management code to become unnecessarily complex. Also, I need to keep track of detached tabs which will not be visible in the KTabWidget. Every addition of a tab into a window would require a process of selecting an appropriate group first. Not to mention, this would cause huge changes in the codebase.
As has been apparent in my judgement of the three options, I prefer the second one more currently. I will still think on it for some days. In the meanwhile please do put in your valuable suggestions.
Walk With Wyuka 
I think a good compromise between the two models would be to allow loading and storing of “tab groups”, but at the same time, allowing dragging and dropping of tabs only between “tab groups” which have been currently loaded.
Yes i think is very important to drag and drop tabs between sessions because if u look at a browsing day (at least mine) a daily workflow contains reading mixed news or searching for something and after 30min. u end up having many tabs with mixed subjects in your session so is really important to allow this feature but if i have stored 10 sessions x20tabs each and i dont have the option to pick which sessions ill startup with the browser then ill end up starting up my browser with 200tabs!
Prior art:
I would take a look at Opera’s tab stacking and especially KDevelop’s not-sure-what-they-call-it, which are two of the more compelling solutions I’ve come across. KDevelop may nominally be something like a text editor, but in practice the fact that definitions, declarations, and uses are linked together, allowing you to jump from one to the other, which frequently open in new tabs, means you encounter very analogous “I suddenly have all this crap open, what the heck do I do with it” issues to a web browser, so the use case is similar.
(Neither of these really “solves” the problem for me, but they’re well-designed and compelling attempts and not useless. Maybe the problem isn’t truly “solvable”, either.)
Maybe i’m a bit offtopic but… in kde different windows can be grouped in tabs (with tabs showing in title bar). Why don’t use this feature in rekonq? In this way we will have a chrome-style tabbing and automatically also one process per tab because every tab is actually a new instance of rekonq.
From the three options you mention I would also take 2 or 3, as they are very similar what I thought of, when I proposed integrating tab-groups with sessions, on the mailing-list. Though the main objective is lost here, which is the sessions itself. I don’t see why. What I think of is one simple button in the panorama-view to stop a tab-group like you can do with activities. So there would be no manual saving at all, but just a “freeze this tab-group until I need it the next time”
But anyhow, thanks a lot for your effort 🙂
I also prefer 2. Furthermore I want to be able to drag a tab outside the current window and then a new window is created with that tab in it. I then want to be able to move tabs from one window to the other and thus be able to move my tabs in different groups.
Hi Tirtha,
and sorry for the late 😉
I like really much this schema. I prefer the second solution, too.
Going commenting second blog entry…