Hi, [email protected] (2009-03-07 at 1321.07 +0900): > Hi all. It's time to review tab development environment. Let me propose some. > > 1. SVN branch. > As pointed out repeatedly, tab development involves many parts of > sawfish. In order to speed up the development, a branch for > tab in the SVN repo is appropriate. Thus developers can make bold > acts, without affecting the trunk.
I disagree about full branch needed for tabs. See below. :] [...] > 3. GSR > GSR, you're writing codes of tab, right? (Maybe rewriting from > scratch?) Just a confirmation, but it's better to recognize the > situation, especially for collaboration. And if necessary, please take > the leadership. I have been collecting notes about what tabs need and have some ideas of how could they be implemented. I guess I will have to jump into the fire and (re)code them, or at least try and see if the ideas are wrong. Help would be welcome, of course. I will post the notes soon. The basic is that while current code works in some cases, it has bugs and makes other things hard at best. But it has some nice things like being mostly stand alone, and if we do not try to go beyond just a "binder window", it can be a base or inspiration. The changes I see do not seem radical, just push some tasks to themes, different structure for handling the grouping (probably taken from current groups), split the tab zones into multiple real parts and maybe require some extra hooks in core. No need of branches for devel, and nobody that works without tabs should notice anything beyond a new file when done. Going for a tiling wm would be a different issue. GSR
