Re: [NEWS] Sawfish has tabbing support (finally

Am Samstag, den 07.02.2009, 18:20 +0900 schrieb Teika Kazura:
> 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?) 

Oh my. It seems that we have been in two different worlds yesterday.

doc for tab will be part of the user-doc. At least the user-doc should
be complete for 1.5.0.

> > 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. 

well, 1.6 is not planned and of course tabs are not perfect and finished

> > 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.

I see. And there are currently two things missing in tabs: There are no
hooks (makes it pretty hard for users to change behaviour on the fly)
and there's no support of sloppy focus mode (so hovering a different tab
does not raise it).

> > 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.

I'm not ignoring the issue, but there's atm not much work from the
others. That's why I said, "Who is willing to do that?".

> 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...

Speed does not matter, sawfish 1.5.0 is finished, when it's finished.

> 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.

Of course you're right with docs & quality.

And if tabs really don't pass the qualitychecks, they can still be
postponed to 1.5.1.

> > 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.

... But we need a color that's visible on both light and dark terminals.
Red? Blue?

> > 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.

Of course it's better to avoid them. But I'm sure that the current one
we got will be the only one. I expect 1.5 to be the last series of 1.x
There need to be major changes for a 1.6, and if a compositor is
available, we'll bump to 3.0. That's what Janek proposed.

> Regards,
> Teika kazura

Attachment: signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

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