2008/5/18 "Christoph Schäfer" <<a href="mailto:christoph-schaefer@gmx.de" target="_blank">christoph-schaefer@gmx.de</a>>:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi gang, </blockquote><div><br>Hi Christoph, <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
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:<br>
</blockquote>
<div><br><br>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.<br>
<br>This was a the heart of the discussion in Wroc<span class="Curseur">ł</span>aw.<br>
<br>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.<br>
<br>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.<br>
<br>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.<br>
<br>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).<br>
<br>And we need a Mac version that is as reliable as the ones of the other platform.<br>
<br>In short, in some critical areas we have to little to offer, and in some less important areas, we have close to too many!<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
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:</blockquote><div><br>We are making promises?<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
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.</blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
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.</blockquote>
<div><br>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.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
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?</blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
5) Linking/unlinking of text frames is still a curse for many users. This has to be fixed before the release of 1.4.</blockquote><div><br>I am fine with this if avox says he can fix it at no big cost in time.<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
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.</blockquote>
<div><br>Not a priority.<br><br>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.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
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</blockquote>
<div><br>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).<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
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 ;)</blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
9) ScripterNG should definitely become part of 1.4.</blockquote><div><br>Not a priority. This is aimed at very specialised tasks and people. It could wait a cycle or two without much effect.<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
10) Likewise, the other GSoC 2008 projects, if succesful, should be incorporated in 1.4.</blockquote><div><br>Sure. If possible. Not a priority either. <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
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.</blockquote>
<div><br>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.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
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.</blockquote>
<div><br>Sure. But again, not a high priority. And not a showstopper, certainly. <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
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.</blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
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.</blockquote>
<div><br>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.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
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?</blockquote>
<div><br>Sure. But let's see what this means in terms of timeframe for a 1.4 release.<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
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!</blockquote>
<div><br>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.<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
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 <a href="http://1.3.3.12" target="_blank">1.3.3.12</a>+ 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.</blockquote>
<div><br>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.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
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.</blockquote>
<div><br>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.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Scribus would then be just another unpredictable Open Source project that can't be trusted.</blockquote>
<div><br>But if we pursue in the direction we're in now, it will surely become unpredictable... It already is, a bit, isn't it?<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Instead, we should focus on smaller release cycles between development releases, so that everything can be tested and documented properly.</blockquote><div><br>Agree. I think we all agree on that.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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) ;)</blockquote>
<div><br>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.<br>
</div>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
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.</blockquote>
<div><br>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.<br>
<br>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.<br> <br></div>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Getting everything right is more important than just releasing something for the sake of a release.</blockquote>
<div><br>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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
After all, we don't have any customers who have "software insurance" contracts with us,</blockquote><div><br>Who does? I know no company offering this.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
and thus, we are under no obligation to ship half-baked products like Vista.</blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
We have a growing user base, and it's entitled to dependability.</blockquote><div><br>Precisely.<br></div>
<div><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.</blockquote><div><br>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!<br>
<br>Cheers!<br>
<br>Louis<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
All the best<br>
<br>
Christoph<br>
<font color="#888888">--<br>
Psssst! Schon vom neuen GMX MultiMessenger gehört?<br>
Der kann`s mit allen: <a href="http://www.gmx.net/de/go/multimessenger" target="_blank">http://www.gmx.net/de/go/multimessenger</a></font></blockquote></div>