Status of KDEprint in 4.0, and offer of help

[Cristian Tibirna]

On 4 September 2007 17:07, John Layt wrote:
> Hi Cristian and the KDEprint team,

Hello

My answer comes very late because of work-related travel. I'm still on 6h 
jetlag so please forgive any English, orthograph or logic errors in what 
follows.

> There has been some recent discussion on the core-devel list expressing
> concern about the state of KDEprint in KDE4.0, you can read the threads at
> http://lists.kde.org/?t=118859658700001&r=1&w=2 and
> http://lists.kde.org/?t=118873017700002&r=1&w=2.  A couple of people,
> myself included, have stuck up our hands as willing to help out on the
> boring bits if needed to get things cleaned up in time for 4.0.

Thanks for digging this up for me. I don't think I would have missed it, but I 
still have 446 messages to pass through before coming up to date with the 
mailing lists I care about.

> Before we step on any toes, however, I thought it best to check with you on
> the status of things: how you see the state of KDEprint in 4.0, what you
> think needs to happen between now and 4.0, and if our help would be useful.

Please forget the "step on tows" part. It is very obvious I am an unworthy 
maintainer. This is mostly because I only can afford 2h/week of full work on 
KDE and the KDEPrint team is formed of exactly one main programmer right now 
(me). 

We hoped to get two students attracted with GSoC and got finally one, 
admittedly a very passionate and daring one, but obviously he is caught in 
his studies.

So, we need _all_ ressources we can get.

> The problems identified in the threads seem to fall into 3 categories:
> 1) General fit and polish of the KDE4 port
> 2) UNIX domain socket support
> 3) Incomplete CUPS support

Yeah, I have a TODO plan that I never managed to format for printing.kde.org. 
This plan is somehow like it follows:

1) Port to Qt4/KDE4
	1.a) insure compilation and write some functional tests
	1.b) investigate (!) "is a" QPrinter instead of "has a" QPrinter (that was 
used in KDE3).
	1.c) polish and eventually rewrite dialogs based on usability studies (was 
topic of a GSoC project but was abandoned)
	1.d) use KNotification for job life signaling
2) Port to latest CUPS
	2.a) use unix sockets for local cups server connection
	2.b) support all new CUPS features (password protection of jobs on advanced 
printers etc. etc.
	2.c) implement CUPS-side job preview if at all possible. If not, emulate as 
done in one highly polished , CUPS-loving/owning commercial platform.
	2.d) drop support for all printing platforms but CUPS (and eventually lpr but 
even that...) and cleanup after the dropping.
3) Port to PDF printing flux
4) Fix bugs (there are very many)

1.b), 2.c) and 3) are research (!) topics. They alone represent about 70% of 
the work to be done. But even without them, the rest is a huge bit to 
swallow.

It is simply too much for one person, even at 50h/week. As I said, I can't 
afford more than two, which are most often spent in e-mail answering, bug 
triaging and code reading.

> The last two probably require a level of expertise in KDEprint we can't
> offer (and are of debatable necessity for 4.0), but the first one is
> something we can help with, and is needed to be working.

No matter what you feel like doing, just do it. Nobody has the right to 
protest. Always remember, "he wo does the work, decides", one of the KDE 
cornerstones.

> Primarily, we need to be sure that people can perform their basic printing
> requirements in 4.0, i.e. print a document using CUPS.  Getting more
> advanced features to 100% while desirable for 4.0 could be deferred to 4.1
> if needed.

For this, a solution will be to deactivate KDEPrint for now and use QPrinter 
directly. If offers a somehow useable UI and even PDF printing. This is 
urgent and should be reachable with a simple/small wrapper in a matter of 
days. Then the hard work to KDEPrint 4.0 should stard ASAP and as intensely 
as possible. A team of 3 to 5 good programmers with at least 20h/week each 
would be required for about 3 months (but probably more like 6).

> Aaron has suggested we set up a page in the TechBase wiki to help
> co-ordinate efforts (probably under
> http://techbase.kde.org/Projects/KDEPrint).  The sorts of things we could
> do there are:
> 1) Matrix of KDEprint features to be tested under 4.0
> 2) Special hardware/software scenarios to be tested for 4.0
> 3) Links to bugs that must be fixed for 4.0
> 4) List of tasks to defer to 4.1
> 5) Migrate the developer documentation from printing.kde.org
> 6) Matrix of distro's, their cup's version, sockets usage, etc
> 7) etc...

This is a good suggestion. But I'd drop 2. We shouldn't care about hardware 
scenarios but only about user scenarios (document, photo, CD printing, as 
well as bulk printing). We should also drop 3. Most bugs there have to be 
solved.

Don't even try to _think_ of 7. We should choose a latest stable version of 
CUPS as of the day of packaging KDE in the first beta of a series and keep 
tight to it. Distros can play their version games, we have the right to 
request the version we develop for. Anything else will fastly become a 
shrieking whorehouse.

> Do you see this as being useful?  Do you have any existing resources or
> documentation for this that we can leverage off?

printing.kde.org for development starting and for a hint in the platform. For 
anything else I had to rely on the code. Somehow this is difficult because of 
lack of documentation on the private classes, but Michael Goffioul always was 
very helpful.

> P.S. One thing I have noticed in the Public API in KPrinter are methods
> marked as KDE_DEPRICATED or “For internal use only”.  

This is a matter of code cleaning and KDE coding rules have to be obeyed. 
Workhands seeked.

Thanks for your concern and help.

-- 
Cristian Tibirna
KDE developer .. tibirna at kde.org .. http://www.kde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070908/c1ee0654/attachment.sig>