I've been poking around in the Qt 4.4 printing code trying to get a better understanding on how it all hangs together, with on eye on how to extend it in KDE 4.1 to meet our requirements. What follows is more a late-night brain dump of a couple of ideas to remind me later what I'm thinking, or to enable others to do it if I don't. I'll flesh it out later in the wiki.
We lost a number of popular user features in the switch from KDEPrint to Qt Printing, such as 2-up, banners, scheduled printng, etc (just open the KDE3 print dialog and compare the available options to the KDE4/Qt4 version to see). While Qt 4.4 has an API to add extra tabs to QPrintDialog to provide the GUI for restoring these features (*nix only), many features will depend on setting advanced CUPS options (2-up, scheduled printing, etc), and I had been wondering how to get QPrinter to do that when there is no documented API to do so.
However, if I'm reading the code right, the Qt CUPS/PDF QPrintEngine sub-class extends the base QPrintEngine::PrintEnginePropertyKey enum to include PPK_CupsOptions, a list of the Cups Options for the PPD Properties set in the Print Dialog. These options then get passed to CUPS at print time. We may be able to use the QPrintEngine API to add any extra CUPS options we want after the Print Dialog closes, but I need to test to confirm. I can definitely use this in the FilePrinter utility to read the PPD Properties so they actually get respected, a major failing in FilePrinter at the moment.
If this does work, it also provides a way that we could re-introduce our own KPrintDialog again if we need to, while still using QPrinter to talk to CUPS (although the cross-platform issue would then then crop up again if we didn't inherit from QAbstractPrintDialog?).
Talking of FilePrinter, while I plan to re-implement it in 4.1 as part of kdelibs to talk directly to CUPS and thus solve many of its shortcomings, a more elegant method might be to do so as a QPrintEngine. QPrinter embeds a QPrintEngine which abstracts and implements the actual painting/printing routines for the current platform, so there's engines for Mac, Win, CUPS/PDF, and lpr/PS. It also allows you to implement your own print engines, so in theory that's a way to support say RLPR or LPRng if there were demand. It wouldn't take much re-working to fit FilePrinter to this model, no painting code would actually be needed, just a new Print Engine Property for PPK_PrintSourceFile, and some code to pass the file to CUPS or lp/lpr. Now, if only the Trolls could implement this themselves, they could use their existing internal CUPS/lpr classes or code, provide a more seamless API, and save me the effort :-)
I'd like to make FilePrinter cross platform, but while I believe Mac would be easy, the only solution I know so far for Windows would be forcing the users to install Ghostscript and using that to convert the PDF or PS files to the Windows printing format. Lower priority for now.
So, once I have a more permanent roof over my head and get my printer back, I'm going to make a start on porting as many of the old KPrintDialog features over to QPrinter/QPrintDialog as possible. With regard to KDEPrint itself and the Admin features, I see no point in trying to get a version done for 4.0. Instead we should move straight on to stripping down and re-factoring KDEPrint into a more targetted set of admin tools. The famous kprinter command line utility and kdeprintfax would get separated off to be based on QPrinter/QPrintDialog. The remaining backend code would get cleaned up, namespaced, and concentrated on supporting CUPS and lpr admin, with the KCM, Add Printer Wizard, and Job Viewer being the main targets.
Yawn! To bed...
I've posted before about plans to open source the original SimCity game. Well, that day has come with the code finally being released. See the release announcement and source repository for details. I'd love to see a client for it in kdegames or kdeedu one day :-)
Hey, so I'm a little late on both wishes, but I've been mostly offline since early December, between being homeless and then on holiday. I'm homeless because my contract finished with no sign of being renewed, so I moved out of my apartment, only for work to renew me for a further 2 months at 3pm on my supposed last day. The holiday was a quick swing through some towns and cities of southern France and Spain (Lyon, Avignon, Carcassonne, Barcelona, Granada, and Seville), I can highly recommend Granada in particular as a great place to visit.
I wasn't entirely disconnected while on holiday, as I had my little Asus Eee with me, and it was a God-send for booking hotels and checking train timetables and downloading photos from my camera. The portability of this thing combined with ubiquitous wireless is a game changer. I'd love to be running a KDE4 desktop on it, but with only 480 lines of screen resolution the new panel is currently too large to make that immediately practical (I have tried hacking the rc to shrink it enough with no joy, anyone know if it can be made to auto-hide?). That said, maybe I need to make the leap to a panel-less desktop? Time to experiment!
So on to planning for 4.1, and I'm a little uncertain about what to focus on. A given is further work on KCalendarSystem to add a bunch more calendar systems, and some kind of work on printing in particular around the FilePrinter utility. But do I try make the current KDEPrint admin features work OK with 4.0 and Qt 4.3 (is anyone actually working on it?), do I just skip to a 4.1 version based around QPrinter 4.4, or do I move on entirely to other projects that interest me more? There's certainly enough other possibilities, such as work on Marble to add CIA Fact Book integration, or my long promised genealogy program, but at least it appears someone else has taken on the challenge of a new scanning app. Time is something I no longer have in abundance, so I need to choose carefully.
I'm sure we've all been reading a few blogs and articles around the place about the release of KDE 4.0. You can quickly spot which camp a post falls into: there are those who got the message about this being .0 release and they are almost all positive and looking forward to 4.1, and there are those who didn't and so end up wrongly measuring it against 3.5. Then there is the third sort, the willfully ignorant, those sites with well known anti-KDE viewpoints who just enjoy the opportunity for another KDE-bashng session. I don't even bother following the links to those ones. Overall, I'd say 80% of what I've read falls in the first camp, which is gratifying.
I'm not too bothered by most of the negative stuff, KDE 4.0 stands as a great achievement independent of what some random people on the net might think, except for two areas. The first are those reputable news sites who post 'Articles' that criticise aspects of KDE4 based on ill-informed assumptions and erroneously drawn conclusions. They fail to exercise some journalistic discipline by contacting the publicity team, the developers involved, or even reading the Planet, to get the proper story. Essentially these are blogs masquerading as journalistic articles, and the laziness and the lack of editorial rigour irks me no end. The second are the anti-KDE trolls who are happy to write KDE4 off based entirely on a couple of screenshots. What's particularly galling is the way they descend on the positive articles and post their ignorant hate-filled rants in some sad attempt to override the positive impact of the original post. Why??? Why waste your time so???
I will mention two posts in particular, The first was a blog that acknowledged what a great job the publicity guys did on the release announcement (sorry, I've lost the link), in particular the way it explained the significance of the new features for our users instead of just regurgitating a list of buzzwords and version numbers. The second is an article over at Lifehacker, a site dedicated to 'Getting Things Done', which is sure to put a smile on aseigo's face. The author, Kevin Purdy, goes beyond the superficial 'oooh pretty' review and instead demonstrates the power and flexibility of Plasma with a taskbar-less desktop.
Three things piqued my interest today (well, two actually, but things always go better in three's so I chucked another one in).
1) After a few pokes with the blog-stick, Asus have now released more source code for the eee. Is this all of it? Can't say, but I don't see an option for the atheros wireless driver. Maybe in the kernel download? Anyway, Cliff Biffle and many others are slowing sorting all the quirks and working out how to get a real distro installed natively.
2) SCO's attempts to dodge the bullet in the Utah courts by filing for bankruptcy protection in Delaware appears to have failed miserably.
3) Finally, at the risk of feeding some of the more wild-eyed conspiracy theorists out there, I see Google have announced a High School version of the Summer of Code, and the list of 10 participating projects makes for 'interesting' reading:
I say 'interesting', as you would think that Google would want to choose from a wide variety of problem areas to appeal to the widest audiance, but in there I see essentially 6 CMS type projects, including Silverlight which I'd never even heard of. 'Interesting' too is the inclusion of Mono, possibly the most controversial FOSS project I know of, one which I would have thought Google wouldn't be so keen on being involved with. Finally, there's the obvious absence of our beloved KDE. Were we invited but were too busy washing our hair, or were we jilted at the prom? I'd love to know the reasoning behind the choices made.
One of the major features we lost in replacing KPrinter with QPrinter for 4.0 was direct postscript file printing. Whereas most applications paint the required pages onto a QPainter to be rendered into postscript, KPrinter also allowed an application to directly pass through a pre-rendered postscript file and have it submitted to the underlying print system instead. (Note, this is not the kprinter command line tool I'm talking about here).
While only one core application was affected by this, it was a very important one: Okular. Within Okular, the PDF, DJVU, and PS formats implemented high-quality print-outs by converting the document into postscript. Printing the screen pixmaps using QPainter was not an acceptable alternative, so I had to write a tool to take Okulars generated postscript files, and the settings from the print dialog, and pass them through to the print system.
The easiest way to do this was to simply execute lpr or lp with all the options settings and filename passed through. The advantage here is that it's virtually the same code for LPR, LP and CUPS based systems, and there's no added compile time dependencies. The down side is to get all the extra options supported by CUPS and not by LPR/LP (the systems, not the executables), you need to have the CUPS versions of lpr/lp installed (the executables, not the systems). Fortunately, this should be so in most modern Linux installs. The hard part is figuring out what version is actually installed and when not to pass the extra options, and I'm not sure if that side of things is quite right yet.
I've now committed my code in Okular, and I'm looking to get some testing done to make sure it's working on platforms I don't have access to. If you compile and run svn on BSD, Mac, or Windows, or you don't have the CUPS versions of lpr or lp installed, I'd be grateful if you could spare 10 minutes to test the following:
Please run from the command line so you can see any debug output, and send any problems you find my way. All the other formats supported by Okular support full native cross-platform printing using Qt, or don't have printing implemented yet.
Hint for the day: If you bookmark random pages in the main Okular interface, you can print them by choosing Selection in the print dialog.
Today my birthday AND Christmas came early with not one but two new toys arriving in the mailbox, which has left me a very happy little geek boy.
The first is a new lens for my Pentax K10D DSLR, a Tamron 18-250 super zoom to use as a walk-around / travel lens. I've been putting up with the kit 17-55mm lens for too long and finally had to splash out to extend my range. With the 1.5 times multiplier effect, that's equivalent to 27-375mm, so no excuses now for not getting those close-up details I like.
The second is that eigth wonder of the technology age, the ASUS Eee. For those who haven't heard of it before, it's a sub-notebook with a 7 inch
screen, 900Mhz Celeron CPU, 4Gb flash drive in place of the usual hard drive, 512Mb RAM,
wireless, and no CD drive. It weighs less than 1kg, and only costs
£220. You can see what it looks like in my gallery. Actually, "sub" doesn't do this little beauty justice, try sub-ultra-nano-micro-pico-femto-notebook for size. I knew it was small, but I was still shocked when I opened the box to see just how tiny it is. It was a real geek-magnet at work when it arrived, even the hardware guys who are currently trialling all the cool new tablets.
Some random notes:
I'll play with the default Xandros install for a few days, but as soon as I can I'll be wiping it to install another distro and see just how well KDE4 copes with such a low screen resolution screen. I'll also then be able to crack the case and upgrade to 2Gb RAM.
Now, I'm suddenly tempted to get a 3G Bluetooth phone and a data plan so I have internet anywhere I go.
There's a buzz doing the rounds that Maxis are releasing the original SimCity under the GPL to allow it to be used by the OLPC with the new name of Micropolis. There not a lot to see in the OLPC git repositories yet (SimCity, Micropolis), but the original author of the *nix tcl/tk version is currently working on the port to OLPC's python/gtk+ platform. There's a way to go bringing it up-to-date, but if he succeeds in his plans for breaking it into modules, I'm sure a KDE client will follow in due course
Last time I promised a couple of posts on my contributions to KDE4, so lets start with the uncontroversial one, Calendar Systems and Date Widgets. No whizzy Zack/Aaron magic here, nothing to set the pulses racing, but I think an example of the thousands of small improvements that have gone on under the hood of KDE4. My interest largely came from writing kalends and fighting with the artificial restrictions and inflexibilty imposed by QDate3 and KCalendarSystem3.
KCalendarSystem now sports extended date ranges (e.g. Gregorian from 4713BC to 9999AD), an improved the API, better error checking, numerous bugfixes, and internally uses Julian Day numbers in calculations instead of converting everything to and from Gregorian dates. There's also a lot more documentation and unit tests. KDatePicker and the other date widgets also have an improved API, better error checking, and you can now display multiple date widgets each with a different Calendar System. aacid did all the KDatePicker/KDateTable GUI cleanup, my work was largely internal.
And because nothing happened unless you have screenies, witness the new low and high Gregorian dates in a KDatePicker:
Note that unlike KDE3 the out-of-range dates are not shown and cannot be clicked on or selected. If you're wondering why those particular dates, QDate doesn't support anything lower (see below), and date parsing routines may only support a 4 digit year. KDE 4.1 should see an extended upper limit. There's a few non-fatal bugs left when navigating to the low date thanks to 1/1/4713BC not being valid that I will fix in 4.0.1.
The Gregorian Calendar is fully converted and validated against a new test suite, however I ran out of time to complete the Jalali, Hijri, and Hebrew calendars before the libs freeze, so the old calculation code remains just wrapped with the new API. The Jalali calendar was complete and passing all unit tests, but I've since been reading some very contradictory info on the web as to the correct method to calculate it. If there's an expert out there who can clarify a few issues I'd be grateful if you dropped me a line. Hebrew and Hijri are not yet passing their test suites and need more work before 4.1.
For 4.1 I hope to add support for the Pure Gregorian, Pure Julian, Ethiopean, and Saka (Indian civil) calendars. If you use a calendar system that is the official calendar system of a country or actively used in daily life, AND you can point me to reliable unencumbered calculation routines to convert to and from Julian Day numbers, then drop me a line and I'll look to include them either in kdelibs or extragear. There's also a lot of apps that have their own date widgets, or special tweaks added on top (like typing in "tomorrow"), that I want to rationalise and try include in the kdelibs. I'd also like to work with the kdepim guys to figure out a way to propery define the display of weekends and holidays for different locales in the widgets.
While doing the Gregorian calendar, which thinly wraps QDate, I discovered that QDate doesn't quite measure up to TT's usual high coding standards. Try addDays() for example:
QDate QDate::addDays(int ndays) const
d.jd = jd + ndays;
Now jd is a uint, so what happens if you create a QDate with jd = 1, then add -5 days? Whoops! Logged, and protected against in KCalendarSystem.
The biggest problem with QDate, at least from the viewpoint of scientific apps like KStars, is the restricted date range supported. In Qt3, this was only from 1752AD up to 8000AD which the Trolls promised to fix it in Qt4. However they made an unfortunate error in only using a uint to store the Julian Day number (jd), and defined jd 0 as an invalid date. This meant that the possible date range became 2 Jan 4713BC (1 Jan being jd 0) to approx 11,734,883 AD (assuming 32bit word), instead of the possible 5,000,000 BC to 5,000,000 AD if they had used an int instead and accepted zero and negatives as valid day numbers. Worse, they broke their own rule of always using d-> to hide private variables, so this problem can't be fixed in the Qt4 series as it would break BC.
Or can it? I had an evil genius moment. What if you stop thinking of that uint as being the Julian Day number, and instead made it the "QT Day Number" (qd) with 0 still invalid but 1 being say 1 Jan 5,000,000 BC? Then define 2 private methods jd() and setJd(int) that apply the offset required to convert jd<->qd, and modify the code to refer to those methods instead of directly accessing the uint. Suddenly, you have support for a scientifically interesting date range without having to change any of the validated calculation algorithms. Now, this works in theory, but the QDate implementation is rather crufty and I can't tell if something else would end up breaking BC. Anyway, I've passed the idea on and maybe something will come of it.
Well, after making a headline appearance in the Digest and trampling my way over 48 different apps in 2 weeks of QPrinter porting madness, I guess its time to introduce myself to the Planet. So here's the 2 minute potted history…
I’m from New Zealand (yeah, just don’t mention the Rugby World Cup, eh?), mainly from the capitol Wellington, but living and working in London at the moment. Hands up all the other Kiwi’s out there?
I started playing with computers in the very early 80’s, found the 'net in the late 80’s, and was a die-hard Amiga fanboy during the 90’s, before finally succumbing to the all-conquering PC in 2000. Having seen the pain of Win98 close-up in a professional capacity, Linux seemed a saner way to go :-) I was initially swayed to use Gnome due to the licensing FUD wars, but soon switched to KDE when I realised that where Gnome was a disparate collection of apps united only by a common gui toolkit, KDE was the real integrated, cohesive deal. I’ve been hanging around the edges of the community ever since. You may even know me from the dot as that guy calling himself Odysseus.
I’ve tried a couple of one-man code projects, such as Kartographer (an educational atlas), and Kalends (a universal calendar calculator), none of them getting very far because I suck at C++. Living in London gave me the opportunity to attend the Glasgow Akademy this year, where exposure to the force-of-nature that is takat got me motivated enough to get an svn account. As it turns out, I’ve yet to do any of the stuff I planned for Marble, but have instead been messing around in kdelibs doing an API overhaul of KCalendarSystem and the date widgets, and lately getting caught up in the KPrinter -> QPrinter porting. I’ll post more on those later. While I have the horrible feeling KDEPrint will be sucking up a lot of my time in the near future, I’d also like to look at a libkscan/kooka replacement, and one day I’ll finally start coding my design for a KDE genealogy program.
In my 15+ years professional life I’ve worked everything from help desk to lan admin to code monkey to tech lead, but these days I’m a freelancer designing and building financial systems on mainframes in a 4GL database system called ObjectStar (which has nothing to do with Objects as we know them, blame marketing). ObjectStar's a very niche product, so the down side is jobs are scarse, but the up side is that there’s not many people wanting to do it anymore, so once you establish a reputation you can travel the world making a tidy living in the process. I’ve so far worked in NZ, 3 cities in Australia, and now the UK, mostly for banks, utilities, and government departments, including at stint in IBM's body shop. Very boring stuff, so coming home to hack on KDE makes a nice change.
Outside messing with computers I do a lot of travelling (40 countries in 10 years and counting…), ride my bike (slowly), snap photo’s (badly), trace my family history, spoil my nephews (even if from afar), and take the occasional uni course towards some kind of qualifications in Archaeology and GIS.
Ding! Times up!