Back again...

Well, it's been a while since I blogged properly, but life has been incredibly busy and complicated these last few months.  On the personal side, I've restarted uni doing some archaeology courses, had my parents visiting from NZ for 6 weeks, worked some silly hours, done some travelling around Europe and the UK, and utterly failed to find somewhere permanent to live.  On the hacking side, I've had 2 laptops die on me, my web host lock me out, a dead slow net connection, and just a general lack of time to do the stuff I want.

However, there's finally some light at the end of the tunnel time wise, I've fixed my website, and I've splashed out to buy myself a new laptop.  My 5-year old Dell had reached the stage where anything slightly taxing like surfing the net or reading e-mails would send the fan into overdrive, compiling a 1-line change to kdelibs would take 5 hours, one of the memory modules died completely, and the case cracks were threatening to separate the screen from the body.  It's taken a while to find a replacement that met my requirements during which I made do first with an eee 701, then when it died with an eee 901, but finally after evaluating the new Sony Vaio Z, I settled on the brand-new Aluminium Macbook.

I've had the Mac for a few weeks now, and while it is a beautiful piece of kit, there are some annoying features.

* Aluminium body feels wonderfully solid and unlikely to break
* Backlit keyboard
* Huge touchpad
* Mag power cord
* Faaaasssttttt :-)

* No manual CD eject button
* No Insert/Delete/Page Up/Page Down/Print Screen/Hash keys, and a tiny enter key
* The screen is way too glossy and has narrow viewing angles
* USB ports too close together
* Lack of expansion slots

Right now, I've just finished upgrading to a 500Gb HDD on which I am installing the ultimate Hackintosh system, triple-booting OS X, Windows XP, and OpenSuse 11.1 beta 5.  I plan to compile KDE trunk in all three installs as I get time, so if there's something you want tested cross-platform I may be able to oblige.

I've a backlog of subjects I want to blog about, so I'll be boring you on a regular basis over the next few days :-)

Live from Linux Live Expo

Hello from the Linux Live Expo at Olympia in London, where Team KDE is currently locked in a death-match stuggle with the Gnome  guys for the attention of the few passers-by.  I'd guess the current ratio of Booth-Blokes to punters is about 5 to 1, so any poor soul who so much as glances in our direction is quickly lept upon and dragged to their inevitable fate: having to endur a five-minute demo of Fluffy Bunnies, KDE-on-Mac, and Marble world domination :-)  Trauma counselling is offered afterwards by the Heaven Sent massage angels across the aisle...

Team KDE at Linux Live ExpoTeam KDE at Linux Live Expo

Quick update and apologies

I must apologise to anyone expecting an e-mail reply from me (sorry Danny!) or code commits to hit trunk.  It's been a hectic 2-3 weeks, between work going nuts, hunting for somewhere new to live, my net connection packing it in, and my openSuse install getting almost totally hosed.  With this weekend being the May Day long weekend, and fingers crossed moving into a new place to live, I hope to find the time to re-install and get everything sorted, then hopefully I can address the backlog of e-mail and finally commit those printing changes.

Easter progress on printng

Well it's Easter, and rather than being somewhere warm or interesting (or both), I'm stuck here in cold and wet London. This is partly due to my own lack of organisation, but also due to some dodgy fraudster types who managed to clone my debit card and withdraw large sums of my cash from an ATM in Tunisia (I haven't even been there!). Ironic really, given the number of banking security projects I've worked on :-) Well the cash has been refunded, I've been waiting two weeks for the replacement card to arrive, and without easy access to cash I'm reluctant to board a plane or train to anywhere, let alone even being able to book anything online. The one consolation is that I've actually been able to watch it snow in London, a rare occurrence.

So what's a geek to do on a miserable long weekend when he's trapped at home? No surprises really :-) I've been busy lately with The Real World with concerts and gigs and parties and work and starting on one of my irregular get-fit-quick kicks and so haven't had much time to spare for the promised work on KDE printing. So this weekend I've mostly devoted myself to sorting it out. It helps too that my landlady is away for the weekend and so hasn't been gently chiding me that a "young" man such as myself really should be outside enjoying myself more instead of being chained to this laptop :-)

I've been slowly reviewing the Qt4.4 printing system over the last few weeks to see what new stuff has made it, what hasn't, and what we still need / can provide in KDE4.1. Below I've detailed a list of what was missing in Qt4.3, where it's at in Qt4.4, and made some decisions on what we can do in KDE4.1, what we need to request for Qt4.5, and what I don't have a clue on. My initial aim is to work on the application side of things (i.e. the print dialog), before moving on to the printer management side.

So here's the first results of my efforts extending QPrintDialog:

Qt 4.4 - Print Dialog - Cups Pages options: KDE specific CUPS Page Options added to QPrintDialogQt 4.4 - Print Dialog - Cups Pages options: KDE specific CUPS Page Options added to QPrintDialog

Yes, that's full support for n-up printing, page borders, banner pages, and page mirroring using CUPS on *nix. The tab is an entirely self-contained private widget added to the QPrintDialog by the KdePrint::createPrintDIalog() method, and not part of the public API. There's quite a bit of polishing to do (pretty icons, layout, etc), but it all works. Suggestions welcome of course :-)

There's two problems here, the first being that Qt doesn't initialise the list of CUPS Options until after the QPrintDialog signals Accepted(), so I can't make the tab dynamically update the settings itself. Instead, the app programmer needs to make a call to KdePrint::setupPrinter() after the QPrintDialog exec() returns, which while not the most elegant of solutions is not too onerous seeing as they already have to call KdePrint::createPrintDialog() to start with.

The second and major problem that is I can't tell at runtime when Qt is using CUPS for printing and when it has had to fall back to LPR. Obviously, we don't want to be showing these CUPS Options if they won't work, but the new Qt QPrinterInfo class unfortunately doesn't tell us if a printer uses CUPS or LPR. We aso need to know the CUPS version so we can add/remove version-dependent features. I also need to know this in FilePrinter. It's the one thing I can see that we _must_ have in Qt4.4, so I'll try requesting Trolltech add it before the RC comes out (not much time left, so fingers crossed).

Next step is to add another tab for the Job Scheduling and user added CUPS Options, then I'll move onto FilePrinter, and look at KStandardActions for Print to E-mail and Print to Fax, before returning to the Printer Management side of things. I see riddell has proposed an alternative python based system, I'll try do a feature compare on them to see if it's a direction worth going.

For those interested, the magic code to add extra CUPS options to QPrinter is as follows, and can be used by any app to set anything they like after calling exec() on the QPrintDialog:

void setCupsOption( QPrinter *printer, const QString option, const QString value )
    QStringList cupsOptions = printer->printEngine()->property(QPrintEngine::PrintEnginePropertyKey(0xfe00)).toStringList();
    if ( cupsOptions.contains( option ) ) {
        cupsOptions.replace( cupsOptions.indexOf( option ) + 1, value );
    } else {
        cupsOptions.append( option );
        cupsOptions.append( value );
    printer->printEngine()->setProperty(QPrintEngine::PrintEnginePropertyKey(0xfe00), QVariant(cupsOptions));

KDEPrint3 vs Qt4.3 vs Qt4.4

 * = available in Qt4.4
 x = not available in Qt4.4, not to be added in KDE4.1
 + = not available in Qt4.4, support to be added in KDE4.1
 ? for unknown or incomplete support

Usability and General improvements:

 * Drag QPrintDialog into the 21st century :-)
 * Applications able to add custom tabs to dialog
 * Selection of Print to File through Printer combo instead of knowing to type .ps/.pdf
 ? Use KFileDialog when selecting destination for Print To File
 ? Printer / Print System Infomation
 x Printer PPD options dialog improved
 x Special / Virtual Printers in Printer selction combo (i.e. fax/e-mail)
 x Persistance of settings

Advanced page range selection:

 x Non-continuous page ranges
 x Current Page
 x Page set All/Odd/Even Pages
 x QList pageList() method

Advanced page manipulation

 * Duplex Long-edge / Short-edge
 * Custom margins
 + N-Up Printing
 + Banner Printing
 x Reverse Landscape / Reverse Portrait
 x Pamphlet printing
 x Poster printing

Advanced Options:

 * API Read access to Cups options selected in dialog preferences
 */+ API/GUI write access to add extra Cups options
 + Job scheduling
 x Apply filters to output file
 x File printing


N-up / Banner / Job scheduling : I'm adding these to KDE4.1 as *nix / CUPS only options.

Use KFileDialog : ThomasZ mentioned this is now possible, need to check with him how.

Advanced Print Range Selection and Reverse Landscape/Portrait: I could add these in KDE4.1 for CUPS only, but the UI and API would just be too awkward, and it's far better to work at having them natively supported cross-platform in Qt 4.5.

Persistance Of Settings : Apps can still manually persist most settings, but KDEPrint made it far less work. Open question, perhaps a couple of KdePrint methods to save/restore all settings.

Printer / Print System Info : Cool new API for this, but could expose more info, primarily we need to know if using CUPS or LPR, and what version of CUPS.

PPD Options Dialog : Works OK, but is not obvious to newbie how you can actually change the settings, and doesn't size properly. One for Qt4.5.

Apply Filters (which gave us pamplet/poster printing): Personally I think pamphlet and poster printing should be supported inside CUPS, but there are other possible uses for filters so the whole issue is an open one. I do see the kprinter utility being resurrected in kdebase or extragear as say KPrintShop using the old KDEPrint engines and dialog as a *nix only solution. Sure, it becomes a 2 step process of Print to PDF then run KPrintShop, but it's better than nothing.

File Printing: I'll be working on improving the interim *nix-only code I wrote for Okular, but it's another open question. I'll be adding support for all options chosen in the dialog, and proper CUPS support, and looking at moving to kdelibs. I really don't see a cross-platform solution any time soon (yes we could use gv, but really...). [Note to self, follow up Alex's suggestion to see how Scribus copes with cross-platform PDF printing]

Add Special / Virtual Printers : I personally see Export to Fax and Export to E-Mail better implemented as KStandardActions selected from the File menu due to being more user discoverable, but that does require every app to decide if they want to add them or not, whereas having it in the print dialog is universal. The actions could launch a reduced functionality QPrintDialog and use the setOutputProgam() method to set the destination program, but I don't think Qt provides the flexability to do this properly (can't block/hide all invalid options, only works for PS output, etc). Instead, in the background a PDF or PS file would be printed and then the file sent to the required program (i.e. as KPrintPreview does). The drawback here is the user will not be able to choose valid options like page ranges, but a simple private dialog could provide this.

P.S. Why does TinyMCE keep stripping the whitespace from my pre marked code and throwing away the code tag??? Apologies if the layout goes nuts again.

Qt 4.4 Print Dialog - Follow Up

Just a quick follow-up to some of the comments in my last blog:

* No, this is not my work, it's all the trolls, so i can't take credit or change anything in it

* Remember, this is still pre-beta code I'm running, so not everything may have been finished or polished yet, such as pretty icons showing what the options do.

* There's a new Print Preview framework, including widgets and dialogs that haven't had time to play with yet.

* The reason there's is so much 'wasted' space in the Copies tab I showed is due to the dialog resizing to fit the KWrite added tabs, as proof here's the 'pure' Qt dialog without any KDE added tabs:

Qt 4.4 - Print Dialog - PureQt 4.4 - Print Dialog - Pure

There were a couple of good points that I'll try pass on:

* Yes, more pretty icons would be good

* Showing the printer status with an icon next to the name in the combo box, or text directly below the combo box would be useful

Speaking of the combo box, I forgot to show another KDE3 inspired improvement with choosing Print to File:

Qt 4.4 - Print Dialog - FileQt 4.4 - Print Dialog - File

I hope we eventually get an API to add our own options in there (Print to Fax, etc).

Next time, I hope to have a proof-of-concept of adding Cups n-up printing.

A quick look at the new Qt 4.4 Print Dialog

I've finally set up a VirtualBox session for KDE 4.1 development with Qt 4.4 installed, so I've been able to have a quick play with the new QPrintDialog, and it's a huge improvement. Hopefully I'm not stealing anyones thunder here, but I thought we should have a quick peek.

First up, a reminder how the old KDE 3 print dialog and current Qt 4.3 dialogs look like :

KDE 3 Print DialogKDE 3 Print Dialog

Qt 4.3 Print DialogQt 4.3 Print Dialog

Now lets see what the default Qt 4.4 dialog looks like:

Qt 4.4 Print Dialog - DefaultQt 4.4 Print Dialog - Default

A lot cleaner and simpler, and obviously picking up the collapsable options button from KDE3. So lets look at the two options tabs the come with Qt 4.4 (so far at any rate).

Qt 4.4 Print Dialog - Copies TabQt 4.4 Print Dialog - Copies Tab

Qt 4.4 Print Dialog - Options TabQt 4.4 Print Dialog - Options Tab

Well, not much there, just the stuff you'll most frequently change (note the new duplex options). The other tabs you see are the KWrite added options, just as in KDE3. You can click on the Properties button to get the more advanced options that are less frequently changed, i.e. the stuff the app developer should normally take care of setting for you:

Qt 4.4 Print Dialog - Page TabQt 4.4 Print Dialog - Page Tab

Qt 4.4 Print Dialog - Advanced TabQt 4.4 Print Dialog - Advanced Tab

So a vast improvement there over the old Qt 4.3 version and catching up to KDE3. I'm not sure if we'll be getting any more options added for 4.4 (Cups n-up, non-continuous page ranges, etc), but it looks like a better base for the trolls to build on in the future, and for us to add features to in the meantime.

I do have a few problems. I still don't like the Advanced options implementation which appears unchanged from Qt 4.3, which I think suffers from a lack of visible clues about how to actually change the settings, but I don't know if that's the final version or not. I also think it is a shame that there doesn't appear to be a way of us adding tabs into the Properties section instead of the Options section. There's also a couple of thngs I'd like to see exposed in the API to make it easier to extend the dialog, but that's probably something for feedback direct to the trolls.

More musings on printing in 4.1

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...

SimCity source code released

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 :-)

Happy New Year & Happy New KDE!

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.

Some random points

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:

  • Apache
  • Drupal
  • Gnome
  • Joomla
  • MoinMoin
  • Mono
  • Moodle
  • Plone
  • Python
  • SilverStripe

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.

Syndicate content