Thiago Macieira wrote:
> Kurt Pfeifle wrote:
>> But how long will TT devote resources into this? They may leave it
>> bit-rotting as soon as it "somehow" works. As they did with the rest
>> of the "print stuff" support in their toolkit since KDE 1.0 was relea-
>> sed...
> 
> You said it yourself: printing isn't sexy. Yes. And people don't print 
> that much anymore.
> 
> It is a low-priority feature compared to other big-shots like Graphics 
> View, Network or XML.
> 
> But it's also a very low-maintenance one.

I beg to differ.

The fact that current KDEPrint survived for 6 years with very little
maintenance does not mean there could have been lots of stuff done
to improve it, to add new features, to make it keep current with
CUPS development, to fix bugs... It just didn't happen, and *that*
is what made you think it is very low maintenance. That, and the
likely fact that you personally don't print stuff more than once or
twice a year.

But you know, there are users, in offices, who use KDE daily, and
print daily dozens of documents, because it is part of their job
to send out letters and permits to customers, insurants, citizens,...

> KDEPrint has gone basically 
> without changes other than bugfixes here and there for 3-4 years.

Yes, and it meant a considerable bit-rotting process too. Unfortu-
nately. And sadly this is not even *recognized* as such by folks
like you. Because you simply don't use it, and you therefor aren't
interested much in it. That's OK, but at least start to trust to
some degree what others who *do* use and need it are saying...

> Why do 
> you suddenly expect there to be a lot of work in the next 2-3 years? 

Because I don't expect it to be nearly as feature complete as current
KDEPrint is/was, and that it takes a time to even get close to that.
Especially given the fact that you yourself now say that printing *still*
willl remain a "low priority" feature as compared to other big shots.

> Past 
> experience shows that it is not the case.
> 
> I give you a couple of reasons why we should go on this track:
> 1) it's the only realistic option. But even with that aside:
> 
> 2) less duplication of efforts. We won't need to keep adding all the 
> latest features in QPrinter and the KDE equivalent, as well as the 
> dialogs. For all platforms.
> 
> 3) Trolltech is a radically different company compared to 10 years ago. 
> The engineering department is much, much larger. And growing at a fast 
> pace.
> 
> 4) There's no reason why community-contributed code as well as feature 
> requests can't be added. Remember that KDE is the most proeminent user of 
> Qt. If Qt's printing system was sub-par so far, maybe it was because KDE 
> wasn't using it? 

It *was* sub-par, and it was the reason for KDE to do their own stuff in
the first place. Which may have re-enforced the suckiness in turn, as you
say...

> (therefore, less exposure; therefore, less feature 
> requests, etc.)

That may be a reason. And hopefully it changes in the future.

(However -- this did *not* work for ten years, for the three major examples
I gave in my post: PostScript level 1 only with all the problems and bug
reports this caused in KDE; TrueType font handling with $ditto; Custom
page sizes for printouts with $ditto... )

> 5) The Printing System is in our roadmap. And when I say that, it means we 
> want to have a good printing system and we will dedicate the resources to 
> doing it.
> (No, I'm not saying TT will dedicate someone to doing every whim the KDE 
> community asks for)

I'm not expecting this.

However, I sincerely hope that TT will do at least a *few* of the
important things that may come up in the future.

In the past, they did *none* and showed only deaf ears (that is meant
regarding the printing stuff only -- I don't know much about else).

> We had the very same discussion two years ago on QtNetwork and KNetwork. I 
> was the one arguing for KNetwork. In the end, two things convinced me for 
> the other side, and that happened after my starting at Trolltech:
> 
> - the incredible mess that supporting a huge amount of platforms is, 
> especially Windows's broken idea of sockets
> - the amount of time required to maintain such an API -- I couldn't do it 
> on my own

(But as it looks like, I *still* will be unable to use any KDE $mail,
$browser, $chat nor $musicplayer (internetradio) application -- with
the first three probably being the most important apps for probably
every KDE power user, because all these will not support SOCKS5 proxy
support, which I *need* (or not be able to access some web pages, one
private mail account or any chat at all). I need to use Firefox, Thun-
derbird and XChat, because with them I can go through a SOCKS5 proxy.
With KDE3 I can't, with KDE4/4.0 I can't either.)


-- 
Kurt Pfeifle
System & Network Printing Consultant ---- Linux/Unix/Windows/Samba/CUPS
Infotec Deutschland GmbH  .....................  Hedelfinger Strasse 58
A RICOH Company  ...........................  D-70327 Stuttgart/Germany