AW: [Kde-print-devel] Status of KDEprint in 4.0, and offer of help

John Layt johnlayt at yahoo.com.au
Thu Sep 6 20:46:51 BST 2007


In some quiet moments at work today I was mulling over the situation and 
bashed out a few thoughts on KDEPrint vs QPrinter, then I come home to a 
thread looking in that direction too...

[What follows is random, uninformed speculation from someone floundering in 
the deep end. For all I know, I could be sprouting total rubarb, so don't 
quote me!]

The big question is, will KDEPrint be in an acceptable state, not just for 
users in 4.0, but architecturally for the entire KDE4 life of 3-5 years?  

I'm not sure we have the ability to answer that question, let alone fix the 
issues, in the 4-6 weeks before the proposed SDK release shuts kdelibs down.  
This is the "drop dead" date as we would be advertising to developers that 
the SDK release is the set of libs they can rely on having when we ship and 
any serious messing with KDEPrint after this date would damage their faith in 
the stability of the platform.

Alex appears to be the best placed to make a call on this, and I'd be happy to 
trust his judgement on it.

Personally, while I suspect most of the user visible stuff could be knocked 
into a tolerable state for 4.0, maybe with some featres disabled, the 
underlying architectural issues need some serious thinking, and we just don't 
have the knowledge or time necessary to make it for 4.0.  Whatever ships 
inside kdelibs for 4.0 is what we're stuck with, and while KDEPrint is 
brilliant software, we'd be doing ourselves a disservice if we didn't review 
the situation.  We don't want another arts :-)

So, we may have to take a pragmatic approach for 4.0 that doesn't lock us in 
for the rest of KDE4, with a proper solution to be introduced with 4.1.

Can we do something like moving KDEprint outside kdelibs for 4.0 so it's no 
longer under the API/BC guarantee?  Assuming we get it in a functional state, 
it can then be packaged separately and apps can depend on it separately 
without any code changes.  If we can't get it functional, then moving to 
QPrinter becomes the only option.  Or would BC issues force us to QPrinter 
anyway?

*** This would be a VERY drastic step and the option of last resort. ***  
There’s a lot of steps to go through before we would even consider doing 
this.

Switching to QPrinter for 4.0 does have some attractions:
1) Users would get a working, non-broken, if slightly limited printing
   experience
2) Would work on all platforms out-of-box
3) Some apps are already using it anyway, even if just as a makeshift measure
4) Would give us time to resolve architectural issues properly
5) If adopted as a long-term solution, moves maintenance headache upstream

Of course there are serious disadvantages too:
1) Every single app would have to make the change, and fully test it with
   their usage
2) Apps would lose their advanced printing options
3) Users would lose functionality from their print dialog
4) We would lose our printer management tools
5) We would lose our queue management tools
6) We would lose support for some *NIX backends (?)

Mitigating factors:
3) Expectations can be managed, provided we deliver in 4.1, we're doing it
   with other features already
4) Most distros have their own, those that don't probably won't ship
   4.0 as default, or can package the manager separately
5) Most 4.0 users will be home desktops with the printer on the same desk,
   fallback to manual mode :-)  Other moniitoring options may exist, or
   package the manager separately
6) Most people use CUPS now (what about the BSD's?)

The most serious impact is on the applications themselves.  While losing some 
printing functionality from Kate may not seem too much of an issue, how would 
this affect the likes of Digikam, Umbrello, or KOffice with their more 
advanced requirements, especially this late in the cycle?  We would have to 
poll the major apps before considering such a move.  We could end up pushing 
a lot of extra unwelcome work their way and depriving their users of valued 
features.

Well, like I said, random thoughts, strong arguments either way really...

Cheers!

John.

--

Send instant messages to your online friends http://au.messenger.yahoo.com 





More information about the kde-core-devel mailing list