Re: [NEWS] Sawfish has tabbing support (finally

[Teika Kazura <teika lavabit com>]

Hi. This is a reply to Chris' previous message. 

On more plans for 1.5.0:
Chris (and all), please separate the thread for distinct issues, or
it'll mix up the discussion, making harder to track. (If everyone
reads all messages, it's ok, but once or more they skip, it's a
mess. Please think of readers.) For private correspondence, it's silly
to send 5 messages in parallel, but this is an ML, so it's better to
make the title and its content match. What Chris said is important,
and deserves a thread. 

Christopher Roy Bratusek wrote:
> A Doc would be really great. Both a really good dev- and userdoc. and a
> tutorial for librep beginners. This is a good idea I can tell, since I
> only learned python/gtk by the tutorial - that has been all. So a that
> high-quality tutorial for librep is a must-have.

This is absolutely true, but what I emphasized in the last post is the
*doc for tab*. It's impossible to offer all docs for 1.5.0, but we
should do tab docs. I referred to dev & user issue, too, but again you
misunderstood what I pointed out. (I think it's important, so could
you read my last message again?) 

> About incompatible changes: Currently there's only one (sawmill-defautls
> -> sawfish-defaults)....
> And sawfish 1.5.0 _is_ for incompatible
> changes, before 3.0 this is the last chance to do so. 

I meant that adopting tab in hurry will surely result in incompatible
changes *after 1.5.0*, in 1.6 or later. 

> A rewrite of tabs sounds good, but: Nathan Froyd made several changes to
> the tab-system and it's his improved version that got in, so perhaps a
> rewrite is not necessary?

I meant: the criterion is not that it's bug-free or not, but the codes
to be released is good enough to allow future extensions. People
shall extend it definitely. Rewritement is to reduce incompatible
changes which can be avoided.

> Either way, who is willing to do [rewritement]? 
It sounds to me that you fool yourself with such logic into ignoring
the issue. It should be decided if it is necessary or not. (I'm not
sure for the last point, so I merely satisfied myself by quoting GSR.)
If no one does, then the tab gets postponed to become part of the
sawfish. It is already available on the web anyway.

If recoding is necessary but no one does, I have to do it to avoid
cluttered things creap into sawfish. But I'm a slow coder, please be
generous to wait for me...

I should put it explicitly: we have to set proper goals for the tab,	
in doc & quality. If they are not met, then tab should be removed
from the release to keep the sawfish's quality.

> we could do a cat README.IMPORTANT at the end of
> configure, or place a good visible (differently colored) message that
> users should read that file. ... All we got to do
> is to make sure users actually know about that changes.

Coloring is good. Output of the configure is a good place, because
that's package maintainers watch. Then they'll take care for what's
related to their distros.

> And sawfish 1.5.0 _is_ for incompatible
> changes, before 3.0 this is the last chance to do so. 

It's better to avoid incompatible changes, but we don't have to
assume that 1.5.0 is the last.

Regards,
Teika kazura