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