Re: Proposal on tab development.



Hi,
teika lavabit com (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
 


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]