And no, it's not an app for your Gran, and yes, if you want something like MS Publisher, Scribus may not be your best choice (at least with MS Publisher you get the print preview from the file menu, I guess). But if I recall correctly, Scribus was once leaned towards the older versions of QuarkXPress, maybe the menu structure derives from Quark?

ok. I was reading the text. I overlooked the last paragraph with the score.
Anyway, I'm a bit surprised, that the reviewer gave Scribus a fairly good score, but the review doesn't sound like he/she is impressed by the app. I don't see the point in picking the alignment feature as an outstanding nicety (where there are actually far more impressive features) versus "bad usability" as a major drawback.
I can agree on improving the usability (who doesn't...) and standards-compliance (like putting the print preview under the file menu). This just did not make sense for me (and btw., I am a scribus user. I'm using it quite frequently for layout of sales brochures) and in my opinion the weak points of scribus are:
a) zoom and selection tools. If you've more than one page the selection and view sometimes jumps around until you loose orientation on the page
b) the story editor (text input in general)

And Scribus has nearly the same demands on hardware like other comparable layout tools (Quark, etc...). An old PIII is really not enough to do serious work with scribus. But that's not a real minus, cause even scribus can't do magic. If you have to deal with lots of pixels or vector graphics, you need a fast PC and lots of RAM. period.

I'm not sure it's what you'd call "stupid". The reviewer made many valid points, as you yourself point out.

Whether Scribus models itself on MS Publisher or QuarkXPress, it ought to conform to the KDE standard in menus. It should also inherit standard icons. Finally, I'm sure the Scribus developers would agree that it could be more user friendly without making it any less powerful.

One of the mistakes that MS made was that they quit listening to their customers. The reviewer is simply a customer. He is telling you that he does not like the menu structure and find the useability to not quite be there. But all the working code is. I have used scribus and I can understand what the reviewer is saying.

I would be very surprised to NOT see the interface change in a release or two. The author has always shown themselves as being responsive and productive with regards to comments. I would also guess that some folks will soon come up with alternative layouts for scribus.

But he's not a customer, not really. Look at the author info at the end of the article -- he's a student and an open-source enthusiast. Well, so what? If he made his living as a layout designer or editor or, well, anything vaguely print-related, this review would carry some weight.

As it is, he doesn't spend enough time with the core professional features of Scribus that he starts his article with :
* CMYK Colour
* "Press Ready" PDF Creation
* EPS and PDF import/export
* Complete ICC colour management
* Font embedding and sub-setting in both postscript and PDF export

instead we, got
So all I do in Scribus is I select all three text boxes, select the Distribute/align function and the boxes are aligned. Therefore saving me the time and hassle of having to do that myself. It's things like that, that help to make Scribus a good program.

Aligning columns and objects are things that were present in Adobe products when I was using Apple system 8 and Pagemaker back in the nineties. It's not a compelling feature for Scribus at all, and should, at best be glossed over in a sentence like "Scribus has all the features you'd expect from Pagemaker, like...", not given its own paragraph and screenshots.

Did the contact sheets look ok? Did you take any samples to a professional printer? Were there problems with color matching or calibration? This software should have been put into the hands of a professional graphic designer to review, not a self-professed open source enthusiast.

That theme isn't quite so nice, nor is the icon set. I can only assume that, since the reviewer is probably a Gnome person, he hasn't spent much time tweaking the Control Panel to make things look nice.

That said, I understand his frustration with where items are on menus. However, if you have ever used Quark, you will realize that an intuitive user-interface, esp. for first-time users, is by no means a prerequisite for a desktop publishing app. Of course, once you have figured out how to change fonts and such in Quark, it's not so hard, but it is also not obvious or standard.

It would be nice if Scribus could break the mediocre tradition set by Quark in the interface department.

Ugly? Not intuitive? Has a learning curve, which is apparently its Achilles heel? Man, ever since Havoc Pennington and others decided to "ruin" GNOME, there's been this attitude that apps aimed at the Free Desktop had to be as simple as the rock-bottom consumer-level apps out there.

Would it be so horrible if Scribus eventually ended up being suitable for production print work, or does it have to turn into Print Shop? ;-D

You're implying that if Scribus were to make its UI more user friendly, it'd become less functional, or otherwise worse. Is it not just possible that Scribus could do a lot to improve its UI without losing functionality?

Just because a lot of production-level apps like Quark have terrible UIs, and a lot of GNOME apps have reduced functionality and/or configurability, doesn't mean KDE and Scribus have to emulate them.

Desktop publishing isn't something granny sits down at. It's professional people generating stuff, usually on short notice, for printing.

KDevelop has a complicated menu structure, buttons all over, and usually shows this wierd stuff in languages that most don't understand. I don't want to say what I would call someone who complains about it for those reasons. It is a complicated powerful tool. I use tools that require weeks of training to use effectively. And I wouldn't have them any other way because they are very effective for their purpose.

The largest usability issues with an application like Scribus are not being able to do something that desktop publishers need to do every day. That is what would prevent people from using it. The icon themes and menu structures are frankly secondary. I would rather the developers spend the time finishing the necessary feature todos. Make a tool that people can use for their jobs. After that is done, put pretty icons everywhere. Or let someone else do it.

> The largest usability issues with an application like Scribus are not being
> able to do something that desktop publishers need to do every day.

that's not a usability issue, that's a functional requirement. meeting the required func spec is, of course, #1 when creating software, as software that doesn't do anything isn't worth anything. but usability can (and should) be a parallel track while achieving that end.

> After that is done, put pretty icons everywhere. Or let someone else do it.

if only it were a matter of pretty icons =) but i (think i) know what you mean. i completely agree with you that it's probably best left to a team member whose aim is designing for usability. it should, however, be done in parallel with development if at ALL possible and it MUST involve the "feature" developers and bug fixers otherwise it becomes a frustrating and counterproductive affair.

I guess what frustrates me about this stuff is how 'usability' ends up being 'I can't figure out how to use it'. Desktop publishing entails concepts and skills that I don't understand. I could bang out a simple two column with picture and header, or a letterhead. Scribus would be overkill, OO, Kword, or any of dozens of word processors would suit better. If I can't get Scribus to do what I want, maybe it's not what I need. How can I judge?

Someone who works with this stuff, production work, would be a good judge, and be able to offer constructive suggestions as to improvements. It may be that production demands different things than some HIG guideline could even contemplate.

This is why usability is such a minefield. Serious usability work entails studying how people work, and figuring out ways to make it better. You are doing that type of work, and I do appreciate it.

But essentially my point is that usability ultimately means someone can actually use it. I think of the earlier days of CAD, with the two letter commands, no menus, etc. To learn required cheat sheets, etc. Some packages came on the market that were more 'usable', with menus, easy stuff. The problem was these packages became 'unusable' once you had a drawing of even moderate complexity, because they took forever to redraw. To get work done, you needed one of the harder to learn packages, because they could be productive, or 'usable' with the hardware of the day.

Or something I worked with today, a hardware/software package. The software has it's annoying points, requiring changing modes to do most things, etc. Somewhat time consuming and frustrating. Yet, it is ultimately very usable, since once set up, I literally can forget about it. So the designers put the energy and focus on what really matters.

They do, to an extent, but that's not an excuse for unnecessarily bad UI decisions. The review highlighted a few (print preview in an odd menu) and suggested that there were many more problems that could be alleviated without decreasing functionality.

Look at Konqueror's right-mouse button menus in KDE 3.0 and KDE 3.2. You have more or less the same functionality, but now the menus are far cleaner, and far more usable.

What is really ugly is the big font for menus and dialog boxes. Scribus does for some reason not respect the qtconfig setting, and there doesn't seem to be a way to configure it. It therefore looks different from any other Qt application and, of course, all KDE applications. It looks ungainly. Also the window menu icon at the left side of the menu is quite disturbing. I hope that this won't be in the KDE version.

Hm. I just fired up Scribus over here on my Gentoo box, and I'm nost sure I know what you're talking about. Make sure your distribution bothered to set up X DPI settings (not just relying on the desktop at hand to do it), and I have no idea why your copy of Scribus wouldn't vaguely resemble a KDE app. Sure, it's not going to use the KDE icons (so?), but on my system Scribus seems to be using the same fonts and toolkit style as my KDE apps.

Fix your system. Scribus uses the themes from qtconfig. (Yes they can be different (KDE/Qt), eg in the case if you build a new Qt after building KDE, sometimes many apps cant see all the KDE themes, answer is to rebuild kdelibs.. KDE issue AFAIK)

Whoops. Sorry, and thanks to scribusdocs! I glanced through the configuration options and didn't see that (although I admit that it's quite obvious). Anyway, it was not my system that was to be fixed, but rather an old scribus config file. qtconfig has the GUI font set to 10pt (just like KDE) but scribus had still 12pt set. Damn, now my list of complaints is down to one trivial item ... ;-)

typesetting a large (5'x3') conference poster in Scribus 1.1.6 on the dated PIII (450). Sure, it was slow, and story editor sucks (ruins subscript/superscript when you open your text frame). But it helped me to set a fairly complex layout with lots of graphics and two-column textframes in <1 day. And PDF output looks perfect -- just got a proof print on our color laserjet. Next step -- bring it to the professional printer and hear the verdict [rolleye], hope font embedding works.

Keep up a great work -- Scribus is the next best thing to Latex/Lyx combination ;)

As I posted on the slashdot article yesterday, we have professional printers with real DTP hardware, RIPS, printers etc.. that are testing Scribus in a few countries, eg, USA, Canada, France, Germany, India. Scribus produces compliant PDFs and PS3 output, with very exacting colour matching capabilities.

As I am also a user of Scribus, I can say that when I produce my 24-36 page magazine and send to the printer in PDF form, he has no trouble with it. Seems to be perfect, and the result is as good as ID2 for sure. I recently have had letterheads and business cards produced that I did in Scribus. Perfect.

Scribus isnt perfect in all areas, but we are aiming sky high and with more time and more help we can take it there. Remember.. we all have day jobs and families etc, like the rest of the FOSS developers out there. 48 hours in the day would be a big help.

If someone wants to design new icons, mockup new dialogs.. fine.. we would welcome any input and help.

BUT, this is not a consumer word processor, it is a DTP program intended for professional use.

What I like about it is that:

1. It will find and use ALL of my fonts (e.g. different widths and weights of Helvetica). Something that KDE doesn't seem to be able to do.

2. Although the screen image of fonts could use some work (this would slow it down by requiring a FT transform (scale and shift) of each letter), the printed output has the correct spacing. Again, something that KDE doesn't seem to be able to.

A desktop publishing application must be judged first by its output. In that criteria, Scribus is a clear winner. If it takes a few hours to learn how to use it, so what.

I stated what I believe to be the case -- that Scribus needs some _minor_ improvements in its user interface.

What it does not need is for the changes in its user interface to change the paradigm of using it. It should remain a desktop publishing application with its major purpose to combine text and images created by other applications -- it should not become something which is usable as a wordprocessor and it does not need to be as usable as a wordprocessor.

it's unfortunate that it garnered only 2 stars for usability, but it got 4 stars for everything else. awesome.

making Scribus a true KDE app would solve some of the usability issues (e.g. print preview being where the user would expect it), and i hope the developers find success in improving KDE integration. i'd sooner see a full fledged KDE app emerge than a Windows app (looking at their roadmap), but that's my selfish "i don't use windows" side speaking ;-)

Scribus is a very cool app. looks like the biggest thing it needs it some UI refinement. will be nice to see a review where they get four stars for usability too =)

The GUI has improved in various places since 1.1.6 was released. We are working towards a 1.2 stable release in the coming months.

We will NOT totally integrate with KDE as we will limit ourselves to KDE. We want people to be able to run on Gnome, Blackbox etc, as well as future ports to Windows and Mac OSX (why shouldnt the rest of the world have great, free DTP capabilities?).

We are however planning to build in whatever KDE integration we can based on build time includes, so therefore perhaps it will seem a lot more KDE integrated than it is now.

We will probably move Print preview to the file menu in CVS.. the reason is where it is now is that it is a type 1 Scribus plugin and therefore appears in the Extras menu.

Making Scribus a completely KDE application wouldn't limit anything. Gnome and Blackbox users can use a KDE application just as easily as they can use a plain QT application. There is a port of KDE to OS X and a port to Windows too (and free, whereas QT/Win costs money, though it has advantages). KDE offers a lot of great technologies (IOSlaves, XMLGUI, DCOP, etc) that really can't be leveraged unless you go all the way and make Scribus a KDE application. I hope you'll consider it some more.

> We will NOT totally integrate with KDE as we will limit ourselves to KDE. We want people to be able to run on Gnome, Blackbox etc, as well as future ports to Windows and Mac OSX (why shouldnt the rest of the world have great, free DTP capabilities?).

I never really understood why it wasn't built on KDE. In the case of Quanta we felt the choice was obvious. We were using the Kate editor, KHTML and the file dialogs. On top of that we get DCOP, kparts and a very cool API. I have a lot of users who use Quanta on GNOME and Blackbox as well as OS X. (What is cool is that there are teams of people working to bring the KDE repository up on OS X.) Beyond Qt they only have to load kdelibs and our module. It can also run on Windows under Cygwin, but I tend to agree with Trolltech, Windows is not a free platform.

In my experience your reasoning is flawed. I say this from having been the number 10 most active project on sourceforge when there were 5,000 projects to now when we are part of KDE. Let me explain. If someone wants Quanta they load the required library (kdelibs). It doesn't seem to be a problem for them. On Linux it seems to be pretty standardly installed too. People who have a problem with KDE seem to have a problem with Qt and why change toolkits.

A better question is to compare the benefits for you and your users by going with KDE as compared to what you lose by being just Qt. Granted if you want to do the work you can do integration and stand alone but usually it becomes a lot more work.

With KDE you get:
1) Very nice file and service dialogs (like Ktip) that you have to build now.
2) A number of enhancements to the API for more productive development.
3) Kparts to enable easy use of plugins in your application.
4) DCOP to enable interaction and scriptability. (For instance Kommander is being improved right now and can easily add functionality in custom dialogs driven by DCOP and scripting.)
5) Usability enhancements of a complete team of people who focus on this. For what ever small annoyances this may occasionally bring it will bring many times the benefit with feedback and people reviewing and fine tuning your code (when you are in KDE CVS).
6) More developers and support! While Scribus is a great app I noticed that by being in KDE CVS with Quanta that more people were involved with our development both peripherally and by general interest.
7) Translation team, and though we do our docs we get help from the doc team. Being in KDE makes you available in more languages than I can list without lifting a finger or asking for help.
8) Even more promotion and exposure in a great community. KDE is really outstanding because it is a community that bands together to promote their packages. Like Scribus Quanta is a great desktop application and while it was not mentioned in the recent article of killer desktop applications I feel it deserved to be. For me one of the best things about Quanta has been the association with a great community that has been very helpful in our efforts to make an even better tool.

Conversely your presentation of the limitations of KDE integration are a quantum leap. For GNOME and Blackbox, if they are one of the few Linux desktops without KDE installed, they only need to load an extra library. It's worth it. There's a good chance they already do for Quanta anyway. For OS X, somebody else would have already been working on it for you. For windows... the Cygwin team works on KDE apps, but honestly who really cares? I'd rather give people a reason to opt out of monopoly control and reduce the odds of all information being coopted for profit. Without insuring freedom there is no guarantee that free (as in beer) can be sustained. All it takes is a patent or the right application of DRM. Why should we remove the incentive to reduce the leverage of a monopoly whose lust for power is a risk to our freedom to give freebies to those who are funding them?

In our final analysis, even if we didn't use an editor and HTML widget from KDE I still would have wanted to be part of KDE because for all the other reasons it was obviously my best course of action to produce the best possible software. If someone needs to load kdelibs or get a Live CD to run it then so be it. You don't compromise your way to ultimate status. ;-)

I take all your points into consideration but I ask this:
You have said to me the limitations placed on being the KDE release schedule would limit a LOT of our freedoms we enjoy now.

I disagree on the kdelibs thing, there are MANY people that do not want ANYTHING to do with KDE, and will go out of their way to find other apps just because of KDE dependencies (of any sort).

The cygwin idea is NOT acceptable. Its a solution, but the file system performance within that environment is SLOW from what Peter has said. Why shouldnt we be able to offer a native Windows port, like OO.org etc? Eg, in the case of a friend, I recently built a PC.. they got Doze with the PC by default, but ALL the apps they run are FOSS based. They would not have the technical knowledge to install cygwin etc etc.

Even many of the Qt libs are slow or so buggy we have had to work around various issues. One such was the Qt canvas (possibly fixed in qt4) but libart provides a fast and powerful canvas and without it.. we would have had to write our own.

I'm sure that KDE integration and the benefits of KDE libs would be a great thing but the downsides have to be considered too. Its all up for discussion, but up until this point we have not seen enough reasons to start using kdelibs.

Dont get me wrong.. Im a KDE user on all PCs.. I love it for all it provides.

> I disagree on the kdelibs thing, there are MANY people that do not want
> ANYTHING to do with KDE, and will go out of their way to find other apps just
> because of KDE dependencies (of any sort).

These people are fools and probably would not use a qt application anyways. I mean seriously, who would use Qt from supposedly "evil" Trolltech and not the LGPL kdelibs?

I think that not using kdelibs for this reason means succumbing to irrational, stupid prejudice. IMNSHO, people who don't want to use a great application like scribus because it needs kdelibs, don't have to use it.

The people who have an irrational grudge against KDE in many cases also have an irrational grudge against any app that is based on QT. There's no point in basing your development decisions on the opinions of these crazy people. I doubt you would lose any more users by using KDE in addition to QT. Scribus could go into kdenonbeta and not be subject to the KDE release schedule.

I agree that Cygwin isn't the most ideal solution, but if you don't use it you'll have to buy QT/Win, which is probably impossible for an open-source project like Scribus. As I see it, you're going to have to use Cygwin if you want a Windows port. And if you're already using Cygwin, why not bring along KDE too...

There are plenty of Gnome users who dont use or want anything to do with KDE, for one. While many dont use Gnome, it has its place, and just because this is primarily a KDE haven, doesnt mean that the rest of the WMs out there dont deserve a decent DTP app without KDE dependencies.

Well, one of the team members is being asked to do a native Windows port by his employer (a university) and therefore has a copy of Qt/Win (Educational). As for how to publicly release the final version/qt libs.. not sure of that yet.

Anyway, this discussion doesnt change anything for our upcoming 1.2 release. It will be a stable release based on the current releases, without massive changes here and there but with decent bug fixes and functionality enhancements.

We have large under-the-hood changes in line for 1.3, AND we have plans for conditional use of KDE libs, who knows.. maybe more than just that. Decisions will be made later down the track based on what makes sense then.

"There are plenty of Gnome users who dont use or want anything to do with KDE, for one."

Think of users who know nothing or very little of KDE or Gnome - DTP users using Windows or Mac OS?

"Anyway, this discussion doesnt change anything for our upcoming 1.2 release. It will be a stable release based on the current releases, without massive changes here and there but with decent bug fixes and functionality enhancements."

Cool!

"We have large under-the-hood changes in line for 1.3, AND we have plans for conditional use of KDE libs, who knows.. maybe more than just that. Decisions will be made later down the track based on what makes sense then."

"limitations placed on being the KDE release schedule would limit a LOT of our freedoms we enjoy now."

This is the primary reason why Extra Gear (extragear.kde.org) exists afaik: allowing independent but KDE-using project to use the KDE.org infrastructure (centralized CVS, i18n and bug tracker with the respective advantage of more "looking eyes") while not being bound to any release schedule etc. But seeing how other Qt apps with KDE integration avoid it so far I'm not sure how well a Qt-only/KDE-integrated split within Extra Gear would be managed. Possibly it might be a good idea to move KDE integration to Extra Gear and sync the backend development of both trees?

"I disagree on the kdelibs thing, there are MANY people that do not want ANYTHING to do with KDE, and will go out of their way to find other apps just because of KDE dependencies (of any sort)."

Mmmm. If people don't want anything to do with KDE then they won't use a Qt app - Qt is tainted, remember? You can't get into political games like this - look at what is laid before you, and really leverage the potential of your application. Besides, I think this comment is flawed because if you are attracting people to Scribus sane people will not see KDE or Qt or kdelibs - they will see the makings of a very good DTP application. Try not to tie yourself in knots over this issue.

"The cygwin idea is NOT acceptable. Its a solution, but the file system performance within that environment is SLOW from what Peter has said. Why shouldnt we be able to offer a native Windows port, like OO.org etc?"

The OO Windows port is important because of the nature of the application (MS Office competition and migration), but honestly, if you have a good alternative platform and operating system, Windows quickly becomes pointless. A new DTP application on Windows is too much of a niche considering what is already out there commercially. Look at the Gimp. That now runs on Windows, and no one really cares that much. From this perspective, Trolltech's attitude to a GPL'd Windows Qt does make complete sense.

"I'm sure that KDE integration and the benefits of KDE libs would be a great thing but the downsides have to be considered too."

Definitely, but the downsides currently don't make too much sense to be honest. However, can definitely understand you wanting to provide a multi-desktop port wherever you can. It just depends whether it really gets used enough on Windows or Mac OS to justify that attitude and effort.

There are already plenty of Mac people using it under Fink, and would be very happy to use it natively, have a look on the site stats for www.scribus.net for the browser/platform status. 20% of them are IE users, and 35% of them are Windows users. Only 3% of them are Mac users.. but oh well, maybe they just scream loudest. We have professional DTPers on Windows and Mac begging for native versions.

Of course, 51% of them are Linux users.

Go to the end of these posts.. and reply to my as yet unanswered questions regarding what you think would change in Scribus if KDE libs were used.

In the end, its not just my decision, I'm just saying the reasons as discussed in the past by the team.

i look forward to it .. thanks for all the hard work you guys/gals are putting into it; this is a rather important niche to fill. who said complex apps for (relatively) niche markets won't be developed as Free Software? =)

> We will NOT totally integrate with KDE as we will limit ourselves to KDE.

you are currently limited to Qt, if one wants to look at in those terms. the major challenge you would run into with full KDE integration versus pure Qt would be getting it to run acceptably on Windows. blackbox, GNOME, etc are not really issues. yes, there would be the one or two moaners, but i doubt those individuals would represent the core userbase. given a better app, people doing page layout would welcome the improvements (e.g. XMLUI and a nicer file dialog =). i guess you probably know all this, but i like stating the obvious all the same ;-)

it will be interesting to see what the Scribus Windows and MacOS X userbase ends up becoming. if they remain paltry in numbers compared to the Linux/UNIX userbase then the Scribus userbase will be getting short-shrifted by the push to Windows; if they come on strong then it will have been worth it (viva la Free Software). too bad we can't see the future, hm? ;-)

as an aside (which means: this has less to do with Scribus then it should for me to post it here ;), to provide compelling reasons to use our Free Sotware desktops, i can't help but feel that at some point we have to gather our courage up and be willing to tap into the full potential of our Free desktop frameworks to create the best apps possible even if it comes at the expense of certain non-Free platforms. the traditional, incumbent software companies understand this concept well: applications beget users. if using Scribus and the host of other Insanely Great(tm) apps we have floating about meant using a Free Software desktop, more people would do just that. either that or else support our Free Software frameworks on non-Free platforms. either way we all win. but if our best apps remain lowest-common-denominator then not only will people have less motivation to explore Free Software in general, those who are exploring it will enjoy fewer benefits from doing so.

> We are however planning to build in whatever KDE integration we can based on
> build time includes

the more the merrier; i'll be first in line to download it when it's ready to play with.... =)

"making Scribus a true KDE app would solve some of the usability issues (e.g. print preview being where the user would expect it), and i hope the developers find success in improving KDE integration. i'd sooner see a full fledged KDE app emerge than a Windows app (looking at their roadmap), but that's my selfish "i don't use windows" side speaking ;-)"

Well, Scribus is quite an application (wow!) and I wouldn't expect to see KDE integration overnight. They seem to be moving towards it quite steadily though. I like the way they have developed this application up.

This I found interesting:

"Scribus has an unusually small development team and is mostly the work of a German programmer called Franz Schmid."

For an app like this that is absolutely incredible. It seems to show what you can get done with Qt. They're web site is also very nice.

"it's unfortunate that it garnered only 2 stars for usability, but it got 4 stars for everything else. awesome."

Well, I think the author has unfortunately picked up the definition of usability from somewhere else...

"Since you can't just pick it up and go with it, its not something you can give your Gran to play with for instance. Your Gran is not going to want to spend time working out which icon to click on the tool bar to click so she can insert text into a box she's already drawn. At most all she will want to do is double click it, and then be able to type. Any more and she's just not going to understand it and will rapidly give up with it. Which is a real shame."

This is rubbish, and is one of the reasons why I think the 'usability' drive by some people who don't know the meaning of the word has done a great deal of harm. No one can just waltz into a DTP program and start doing things. You have to know about the subject of DTP first, understand what you are doing and read up on tutorials so you know how to get those things done effectively. That is just like anything in life. You absolutely cannot create any application that anyone can walk straight into - that is not bad usability, that is just the reality of the functional requirements of the application. Anyone that does think like this obviously hasn't programmed apps and trained users in the real world; I mention no names.

"Performance wise, I really couldn't ask much more from Scribus. It's stable, I haven't encountered any bugs in it and it flys along. I mean the thing is amazingly fast even on an old Pentium 3 450mhz computer, that is a great achievement for an application so heavily dependent on graphics that it really should be demanding more from your system."

I think that we can safely say that Qt works quite well then :).

"...the user interface turned out to be poor and for there to exist a learning curve."

Wow. A learning curve for a spreadsheet, a financial application or a DTP program. Imagine that?