[scribus-dev] Scribus review in Linux-Magazin

"Christoph Schäfer" christoph-schaefer at gmx.de
Thu Jul 31 17:05:38 CEST 2008

Hi guys,

OK, here's my reply compilation to the previous answers:

> - The Properties Palette isn't dockable (agreed).

Craig Bradney: 
"Not critical, or devastating, and wont be fixed until someone comes up with a model for doing this properly. We have ideas, which are not implementable in 1.3.5 due to other outstanding issues."

As Alex mentioned in his reply, the model is already available (GIMP). Craig, please also note that I've not been talking about 1.3.5 here, as we all know what has to be done before the release of 1.3.5. Nevertheless, thinking ahead and contemplating future priorities doesn't hurt, right?

> - The Properties Palette is too big (I agree. This has become a huge
> problem with Qt4, as it takes about 50% of the screen now. This isn't
> acceptable!).

Craig Bradney:
"As above, and while I think its too big, its about a 6th or less of my screen at home. More styling may need to be applied to the widgets. Petr or someone else needs to work on this."

Louis Desjardins:
"Not a showstopper. Not a big deal."

It's much too big, and the major issue is the wrong design choice for a Qt tool box. Almost 50% of the PP space is occupied by tool box tabs! If there's a dialog that you need, but you have to move it around all the time to just see your layout, that's a major usability issue and a major restriction to productivity!. Throwing the Qt toolbox design overboard (and return to the 1.2 layout) would already be a major advantage.

> - There's no way to tear off PP tabs and leave them open while the rest of
the PP is hidden (Pierre and Franz seem to work on this issue).

Craig Bradney:
"Really unimportant, and see my 1st point."

It's unimportant compared to the challenges we face with 1.3.5, but regarding productivity, it _is_ important. But as already said, Pierre seems to have prepared a solution that can be introduced with 1.3.6.

> - The Zoom tool is too primitive, and it remains active after zooming. It
should be automatically deactivated after a zoom. Here's a new idea derived
from my reading of the article: How about allowing the user to activate the
magnifier and then let him drag a rubber band around the area he wishes to
enlarge on screen?

Craig Bradney:
"Agreed... but nothing new unfortunately. Same in all previous versions."

I disagree with Craig Bradney and myself, because Alex told me the truth: Rubberband selection is already possible :) I'm going to add it to the manual right now. As for switching off the zoom tool once it has been applied, this wouldn't be a big deal, no? It would be a major gain in working speed!

> - Another complaint is still valuable: The choice between scaling and
moving and item is still a game of chance. This has to be improved as soon
as possible. I know from experience that this a real showstopper, because
people are really wasting a lot of time with this unpredictable behaviour.

Craig Bradney:
"I dont see that game of chance whatsoever, in fact I closed the bug relating
to this as I am unable to reproduce this at all, on any platform, on
multiple machines."

Louis Desjardins:
"? ? ? ? I see no showstopper here."

Craig, it has been improved in 1.3.4+, but it still doesn't work correctly in 1.3.5svn.

Louis, if you need between 4 and 15 attempts to rescale an object because the mouse pointer indicates it's in scaling mode, but instead moves the item, you will certainly agree that this a showstopper (ie. wasted time). I can't imagine you would use that kind of software in your company for regular jobs, as time is money.

> - No editable items on master pages. This was one of the major complaints.
> I'm working on a user-side suggestion for the solution of the issue, which,
> I think, will be much better than QXP's and ID's ways.

Louis Desjardins:
"The reporter should read the mailing list more often. We have discussed that
thouroughly, didn't we? and I for one don't think we are really in a
twilight zone with the actual Scribus way. But I agree there will always be
people complaining about things they can't find where they think it should
be. In the meantime, he could have mentionned that a simple duplication of a
page (containing all the empty elements he wants to further edit, needless
to say) can probably solve 90% of all issues related to the so-called "no
editable items on master pages". He could also use the Scrapbook for even
more "workability"... Maybe a bit more experience in DTP could help, here."

I sent an email to the author, because he was wrong on some other accounts, including a remark similar to yours, but more diplomatic ;) I also offered to proofread further Scribus articles for factual correctness.

Finally, @ Henning:

I haven't read the article, but I asked Peter Kreußel for a PDF version, even though "platziert" is so stupid that it hurts my brain ;P


Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

More information about the scribus-dev mailing list