[scribus-dev] Scribus 1.4

[Andreas Vox]

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

> 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 ;)
>
Agree.

> 9) ScripterNG should definitely become part of 1.4.
>
Definitely.

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

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

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

> 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 1.3.3.12+ 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
>
> Christoph
> -- 
> Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten
> Browser-Versionen downloaden: http://www.gmx.net/de/go/ 
> browser<roadmap.odt>