[scribus-dev] Scribus 1.4

[Louis Desjardins]

2008/5/18 "Christoph Schäfer" <christoph-schaefer at gmx.de>:

> Hi gang,


Hi Christoph,

>
> 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. You may ask why, and here are my answers:
>


The reality is clear: we have less developers than we had and thus the
development has slowed down. Some important portions of the code are now
orphans and the project is suffering from this. It is now time to take the
time to look around and try to understand what does that mean for the
project, what can we do with less people — at least for the moment — and how
can we make things go forward, nonetheless.

This was a the heart of the discussion in Wrocław.

To me, Scribus needs no more bells and whistles features or half implemented
or badly implemented features and we need to concentrate on very FEW things,
which are CRITICAL. Text handling being at the foremost level of priority
because it is at the center of the task of DTP and currently, Scribus is
badly broken at that end.

On a personnal basis I do believe that if we are to implement new things
such as the Render Frame, I question the fact that this feature is
implemeted in such an early stage: il works, but clumsily and it is hardly
usable — how come we're using TeX and PDFLatex and still come up with pixels
instead of vectors is beyond me. What was so urgent that we had to add this
to Scribus the way it is? At a certain point, if we are to go further —
which I deeply hope — decisions like this one cannot be made only by coders.
We could have the team look at it and get the feature through some sort of a
test round and then we put it in the hands of the users. We know for a fact
that once something is in, it's hard to pull it out.

I also question Lens effects and all those sorts of tiny extras that could
be great if the program could at least handle stylesheets properly and make
a proper use of the hyphenation languages and settings, for instance — but
cannot make us forget that the vital functions are not at 100%. Who then
cares for a Lens effect if we cannot even import properly and further easily
edit styled or enriched text from OO.o? And we need to be able to handle the
thin space properly, at least for French typography. These are showstoppers
that need to be addressed. This is a priority.

Some GUI issues have to be fixed too in a more urgent manner than others.
One of which being how we show the various linespace options (people don't
have the opportunity to complain: they simply have no clue the options
exist). We also have too many mouse clicks when dealing with frames (edit
content and move around).

And we need a Mac version that is as reliable as the ones of the other
platform.

In short, in some critical areas we have to little to offer, and in some
less important areas, we have close to too many!

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


We are making promises?

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


I am on the opposite side on that one and I trust we can release 1.4 without
this code. Unless a developer can come to us saying he can code this in a
short time, I disagree to call this a priority. More, I think this is
related-to but out-of-the-primarily-scope of Scribus. Scribus outputs its
pages in PDF. Let there be a distinct project on Imposition, PDF-based. Not
having Imposition as part of the Scribus code is not a showstopper in my
view. There are things much more important than this one. This has been
discussed at length on the mailing list. Plus, there are workarounds and
good explanations on how to deal with this particular issue in the wiki. One
bad idea would certainly be to block the 1.4 release because of this.

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


Wishlist. Nothing to be a showstopper here. A bit of math can solve just
about any issue related to this lacking feature. No matter how often it is
requested, it can't be turned into a priority. Of course, if it can be added
down the road, I am fine with this.

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


Annoying but not fundamental. I find more fundamental to have identical
settings available in the PP — such as letterspacing and wordspacing "à la
avox" — and in the StyleManager. Currently, these are not harmonised. This
needs care and this is what I call a priority.

>
> 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 am fine with this if avox says he can fix it at no big cost in time.

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

Also, this gives me the occasion to raise a question about "requested many
times"... This seems to motivate many of the things in your list but do we
really have an idea of just how many people are asking this? And even if
they were hundreds or thousands, I still think Scribus can live a
development cycle without this.

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


Tables are not used much in DTP and since there are ways to get around this,
I don't think this is a priority either. But I am fine with preparing ground
for further enhancements, of course. At the same time, if it was me, I would
never have put that feature into Scribus in the state it was (and still is).
We would have had far less comments from users trying to get something out
of this half-baked feature if it was simply not there. I would even vote for
pulling this out from 1.4, and reintroduce it into 1.6 when we will be able
to import tables from OO.o just the way ID does it for Word files (now, this
rocks).

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


100% agree. This is THE showstopper. Now, this needs the most attention.
This is really about usability. Without this working properly — like it does
now — Scribus can simply not be used in a production environment. Period.

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


Not a priority. This is aimed at very specialised tasks and people. It could
wait a cycle or two without much effect.

>
> 10) Likewise, the other GSoC 2008 projects, if succesful, should be
> incorporated in 1.4.


Sure. If possible. Not a priority either.

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


Considering the fact that Quark and ID users have sometimes (most of the
time) to struggle with the concept of master pages (they get confused on
what is part of it and what's not once the page is created and the master
page applied) — considering also that if a feature like this one is not
clear even after 20 years of "development", there must be a problem at the
root that even the biggest players in the industry failed to address — I
trust this to be a lower priority as well. And when we are to address this
issue, we need to put more thinking into its solution. Simply copying what
others do is not the way to go, imnsho. It's not that difficult to
understand how Scribus handles master pages at present time and the way it
works now is not that insane. Also, the "workaround" in most cases is really
easy to catch and use: simply duplicate pages with empty frames on it when
you need editable frames.

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


Sure. But again, not a high priority. And not a showstopper, certainly.

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


Sure. But same thing. Not a high priority. It's been like that for the last
2 decades with the big players of the industry... We certainly can wait for
a development cycle or two. And there are nice ways of making such lists in
Scribus, all pretty well documented.

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


This is more sensitive, I agree. All modern apps have undo/redo and we
should raise this as a priority. But again, I would make a round of
consultation with the developers to evaluate first what is feasible on a
short term and what needs more codepower. So, raise the priority but not
blocking the process for this one.

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


Sure. But let's see what this means in terms of timeframe for a 1.4 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!


Aren't you a bit overdoing this now? This description of what would have to
be done seems to me far too dramatic. The real work to be done would be less
important than you describe it here, imo.

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


I disagree with such manual becoming "more or less obsolete" within a few
months. But even if it would... You have simply no control over this! Adobe
has shipped major releases of many applications within a year sometimes
while Quark waited for years... And books are written and published all the
time... The bookshelves lifetime of such a book will not exceed a few months
anyway, ask your publisher.

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


First, 1.3.3.x is certainly not a "finished version". Second, people and
distros are already mixed up to a point hard to imagine. Some distros, and
not the smallest, still ship with 1.2 on board. The release of 1.3.3.x as
"stable" got us into trouble with the rest of the world and it's not a bad
idea to think we could try to reconnect with the numbering pattern that
makes the consensus.


> Scribus would then be just another unpredictable Open Source project that
> can't be trusted.


But if we pursue in the direction we're in now, it will surely become
unpredictable... It already is, a bit, isn't it?


> Instead, we should focus on smaller release cycles between development
> releases, so that everything can be tested and documented properly.


Agree. I think we all agree on that.


> 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. Scribus would then become the GIMP of Desktop Publishing (or even
> worse) ;)


I think we can refrain from joking about the GIMP, can we? I do believe that
from the part of a team member from a LGM participating team, this kind of
joke is not only irrelevant, it's out of line. Even if the discussion is to
remain private or semi-private. To me, it's also a matter of spirit. Let's
concentrate on Scribus. — Thanks.

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


Let's not assume that "act like professionnals with respect to releases"
means "wait 'til the application has everything you can dream of"... because
then we're in for a long wait. I would prefer that we agree on going down
the list and making vital things work the way they should before thinking of
putting in any further goodies, even if some goodies take only a few hours
to code.

Let's put it this way: if we would care as much for text handling as we do
for PDF output issues, I think we could be close to release a solid 1.4.


> Getting everything right is more important than just releasing something
> for the sake of a release.


This is precisely what this is all about here. It came to nobody's mind that
we'd need to release "for the sake of a release". What we came about was to
determine what is this "everything" you talk about that we need prior to a
release. My list is shorter than yours.

After all, we don't have any customers who have "software insurance"
> contracts with us,


Who does? I know no company offering this.

and thus, we are under no obligation to ship half-baked products like Vista.


We should concentrate on Scribus and forget to mention those other products.
We do have many half-baked features in Scribus now and this needs attention.


> We have a growing user base, and it's entitled to dependability.


Precisely.

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.


This roadmap is huge and I question the timeframe in which we're going to
reach those goals. The seek for perfection is noble but we have to deal with
reality. We should make smaller steps and see the progression, than try to
make huge steps towards a goal we simply can't reach with the current
"codepower" we have!

Cheers!

Louis

>
>
> All the best
>
> Christoph
> --
> Psssst! Schon vom neuen GMX MultiMessenger gehört?
> Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scribus.net/pipermail/scribus-dev/attachments/20080527/a29afd4e/attachment-0001.htm