[scribus-dev] Scribus 1.4
avox at scribus.info
Sun May 18 18:54:44 CEST 2008
Am 18.05.2008 um 18:12 schrieb Christoph Schäfer:
> Hi gang,
> As you know, I wasn't able to attend the strategy discussion at
> LGM. However, I heard/read rumours that it's been contemplated to
> release 1.3.5 as 1.4. To be honest, I think this would be a really
> bad idea. It might even damage Scribus's reputation.
It was contemplated but decided against (to be rediscussed after
release of 1.3.5).
> You may ask why, and here are my answers:
> 1) It has been promised to users again and again that some or all
> of their major requirements will be available in 1.4, but
> unfortunately, they still aren't. Examples below:
> 2) Feature request #1 is imposition. We had a GSoC project that
> wasn't exactly a success. I don't think 1.4 can be released without
> completion of this code.
Agree (or a replacement)
> 3) The enhancements to the line/stroke code (thickness based on:
> centred, to the outside, to the inside) are also a feature that has
> been requested often. If it can't be done in 1.4, at least the file
> format should be prepared for it, so that it can be added in 1.4.x.
IMHO we should finalize the new fileformat before 1.4
> 4) A rewrite of the Properties Palette has been promised for ages.
> What has happened to the plans? Isn't this just a UI issue that
> doesn't require heaps of new code?
Unfortunately not. The most ugly think about PP is its event handling
which causes some of the speed problems we see.
> 5) Linking/unlinking of text frames is still a curse for many
> users. This has to be fixed before the release of 1.4.
I plan to do that.
> 6) Two features for PDF forms have been requested many times: radio
> buttons and the change of the stacking order of objects after their
> creation (for the use of the Tab keys in a PDF file). IMHO 1.4
> can't be released without offering these important PDF form functions.
Not critical for 1.4 IMHO
> 7) Tables would remain as basic and clumsy as they have been for
> years. Changes had been promised for 1.4. We should at least
> prepare the 1.4 file format for the necessary enhancements, so that
> they can be added in 1.4.x
> 8) The Style Manager is a real pain in its current (unfinished)
> state. It has to be fixed before a "stable" 1.4 is being let loose
> on users ;)
> 9) ScripterNG should definitely become part of 1.4.
> 10) Likewise, the other GSoC 2008 projects, if succesful, should be
> incorporated in 1.4.
If they are stable, sure.
> 11) Editable frames on master pages have been and continue to be
> asked for over and over again. Do we want to tell our users one
> more time: Sorry, you're out of luck again? Jean wanted to tackle
> this in 1.3.6, and I strongly suggest to be patient enought to
> enable this feature.
Hm, that's a complicated one.
> 12) Making Adjust Frame to Image and Adjust Image to Frame coherent
> and easily accessible is probably only a tweak, as the code is
> already there, only the UI needs fixing. Do we want to release 1.4
> without fixing this usability problem? More advanced features (see
> my roadmap draft) can be added later, if the file format can handle
> 13) Bulleted/numbered lists have been asked for very often. We
> should at least prepare the file format for this, so that later
> inclusion becomes possible during a 1.4 development cycle.
> 14) What about the Undo/Redo system? Do we really want to present
> it in its current state in a major version? Given the loads of new
> features, it currently works even worse than in 1.3.3.x! This has
> to be fixed before a major release, IMHO.
Agree, we also discussed a rewrite because of stability issues.
> 14) What about a stable API, file format and related documentation?
> This could help attracting new developers and speed up development
> in the future (hint: GSoC). Shouldn't this be a top priority for a
> major release?
> 15) Another thing we should consider is the manual. If a 1.4
> version is being released soon, the manual we plan to publish will
> be obsolete shortly after its release -- which would be another
> reason for our users to lose faith in the team. I'm currently
> preparing the outline for the next generation of the manual (based
> on 1.3.5svn, but of course open to further enhancements). A new
> version of the manual (based on 1.3.5) will require at least 21 new
> chapters, and 72 chapters will have to be rewritten or modified.
> Moreover, _all_ screenshots will have to be redone!
> We also must not forget that we plan to publish the manual
> commercially. Being one of the main authors, I cannot sign in good
> conscience a contract with a publisher for a 22.214.171.124+ manual,
> while I'm fully aware that it'll become more or less obsolete
> within a few months. I also don't want to be legally liable for
> damages, and I certainly don't want to destroy the trust between
> the Scribus team, the authors and the publisher (and the buyers of
> the manual!). As you can see, there's a bit more at stake here than
> just internal release decisions.
> For the reasons stated above, I raise my voice against declaring
> 1.3.5 the official stable version, even if it turns out to be
> stable enough for everyday use (just being stable is not
> sufficient!). I'd rather prefer a polished 1.4 with a clean API, a
> reliable file format etc. that can be enhanced with backports from
> a 1.5 development series. Our users need reliability, and declaring
> a literally unfinished version stable (with an even number) means
> misleading them. Scribus would then be just another unpredictable
> Open Source project that can't be trusted. Instead, we should focus
> on smaller release cycles between development releases, so that
> everything can be tested and documented properly.
That's one thing we discussed, too.
> We could then release a polished 1.4, ideally with a manual that's
> available for sale one day after the release. While I agree that
> shorter release cycles are necessary, rushing a major relase that's
> not really finished and betrays the expectations of many users
> doesn't sound like a good idea.
True. I'd be perfectly happy with regular development releases. And I
stated long ago that we should fix tables, fileformat and scripter/
API *before* 1.4.
> Scribus would then become the GIMP of Desktop Publishing (or even
> worse) ;)
> During his LGM 2008 talk, Peter mentioned professional users as a
> target group and also the impressing growth of an Open Source
> ecosystem. IMHO, this also means we have to act like professionals
> with respect to releases. Getting everything right is more
> important than just releasing something for the sake of a release.
> After all, we don't have any customers who have "software
> insurance" contracts with us, and thus, we are under no obligation
> to ship half-baked products like Vista. We have a growing user
> base, and it's entitled to dependability.
> I attach an updated version of my "Roadmap" text, including the
> rant. It contains some suggestions that seem to be tweaks, but may
> improve the user experience significantly.
> All the best
> Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten
> Browser-Versionen downloaden: http://www.gmx.net/de/go/
More information about the scribus-dev