john.layt.net

I hear that Qt 4.6 goes into feature freeze at the end of this month, so that's like in 1 working days time.  Eeep!  I'd better get those printing changes pushed upstream then.  Is there some official place where such dates are advertised I should have been watching?

I've pushed the latest version of my code to a new Gitorious branch http://qt.gitorious.org/~odysseus/qt/odysseus-clone/commits/advanced-pag..., and I may just have to put in a merge request even though it's not quite done.  First the screenie:

As you can see I now have an editable range field that allows you to enter multiple page ranges, in addition to the Page Set and Current Page stuff I'd previously added.  This will show up for all applications that enable it, or if you are running Cups as your print system, i.e. 99.99% of you out there.  If you don't have Cups, then you get the traditional From/To page range entry.  This is not enabled on Win or Mac as yet, but it should be possible and I've designed it so it can be added without altering the API and so it gracefully degardes to the maximum feature set supported by your platform without the app programmer having to do anything.

Status is that I think this is API complete and stable, the only thing missing is the validation of the Page Range input by the user and some other small clean-ups of the dialog layout (yes, that radio button glitch visible in the screenie is proving a pain to solve).

Like I said, I'll probably put in a merge request for this now and worry about patching the remaining issues later.  I think I should also have the File Printing under Unix feature done in the next day, so that may also make it.  Less likely are the additional Cups features (n-up, banners, job control, etc) depending on how far I get this weekend (but we already add those ourselves), and the rest like saving/restoring settings and virtual printers will have to wait for 4.7 (or the new OpenPrinting dialog, whichever comes first).

So I cloned the Qt master repository on Gitorious as odysseus-clone a few months back, and then cloned odysseus-clone onto my laptop where I've been working away happily.  Now I want to make sure my work is still OK against the latest master before doing a merge request, so I think I need to update my odysseus-clone on gitorious first to the latest master, then do a fetch/rebase to update my local clone, then push my changes up to Gitorious. 

Thing is, I can't for the life of me figure out how to get my odysseus-clone on Gitorious to update to the current master.  Any clues?  Or have I got this all wrong?  1am is not the best time to be trying to figure this out :-)

I know, I know, I'm supposed to be working on the Print Dialog, but I've reached a tricky part and while my brain ticks away on that in the background I thought I would do something a little more fun.  Seeing as I'm the 'official' maintainer for Calendar Systems (i.e. I was the last person to work on them...), and to be part of the cool crowd hacking on Plasma, I thought I'd have a crack at fixing the Plasma Calendar and Clock widgets to allow the users to select which Calendar System to display, just like you can currently choose which timezone to display.  Long story short, here's what I now have:

So that's the four different supported Calendar Systems (Gregorian, Hebrew, Hijri, Jalali) all being displayed at once in separate Calendar widgets.  Hmmm, I wonder if we need a label at the top of the widget to show which Calendar System is being displayed?

And again, but this time in four Digital Clock widgets. The left-click pop-up calendar from each obviously also shows the correct Calendar System.

There's a common configuration widget used in both the Digital Clock and Calendar widgets.  In 'Use Calendar System' you can choose from Local, Gregorian, Hebrew, Hijri, or Jalali, where Local is the default and will use whatever the Locale setting is. The Holidays settings are the same as currently available in 4.3, but obviously you could choose to have different holiday regions on each Calendar or Clock widget.

Right-click on a Digital Clock widget and you can choose a 'Copy To Clipboard' menu option to which I've added the date in other Calendar Systems.

There's still a little polishing to be done, especially on the Digital Clock to sort out some date format localisation issues on the main widget and the copy menu, but look for this to pop-up on ReviewBoard in the next day or so.  I've got some thoughts on other improvements especially for Holidays, and there's a fairly long bug list in bko, but I'll get this sorted first.

Oh, and while I have my official maintainers hat on, could I just remind developers that you can't use most of QDate's methods like formatDate() or addMonths() as these only work on the Gregorian calendar system.  To ensure your KDE app localises the Calendar System displayed and performs the right date maths on it you need to use the methods provided by KCalendarSystem through KGlobal::locale() and KGlobal::locale()->calendar().  QDate is essentially only a storage medium that KCalendarSystem then interprets for you.  OK, the API is not very friendly and definately longer to type, but that's the way it is until either Qt5 or KDE5 comes along with Calendar System support built directly into QDate / KDate (and yes Trolls, that is an offer to help write it the correct way :-)

[Edit: For some reason comments were turned off, back on now if you want to add soemthing :-)]

With Page Set (Odd/Even) and Selected Page done for X11, I thought I'd skip the OSX/Win stuff for now (it was doing my head in) and get the Advanced Page Range completed on X11  So here's my design for supporting user enterable non-continuous or broken page ranges such as "2,5-9,11".

[Just a reminder SimplePageSelection mode is designed to be 100% compatible with the existing API and apps will use these by default without having to be modified, an app has to be modifed to explicitly set AdvancedPageSelection mode to fully activate the new features and use PageList() to obtain the pages to print].

In SimplePageSelection mode, when CUPS is not available the Range edit will not be displayed but the From/To edit will.  The application will generate all pages between From and To and LPR will print all pages sent to it.

In SimplePageSelection mode, when CUPS is available the Range edit will be displayed, but will be validated to only allow strictly ascending non-repeating document page numbers as this is all CUPS supports (we could allow random order as CUPS sorts it first, but that would just mislead the user).  The application will generate all pages between From and To which are set to the lowest and highest page in the Range.  Qt will then adjust the Range to tell CUPS to ensure the correct pages are printed.  (Note that CUPS actually applies the Range on Output Pages, not Document Pages, which is why we need the adjustment, and why applying n-up at the same time produces results other than the user expects).

In AdvancedPageSelection mode the Range edit will be displayed and the user will be allowed to enter the page numbers in random and duplicated order and have those pages printed in exactly that order, e.g. "5,2,9,3-7,11-4".  The application will generate only the required pages in the required order and CUPS will print all pages sent to it.

Note that this means a user can enter a Range of "20-10" and have the pages printed in descending order, but if they also select the Reverse option at the same time the pages will come out in ascending order.  Slightly confusing but the only consistent way of dealing with it.

For Win, the native dialog does support an editiable Range and will be supported later on.

For OSX, the native dialog does not provide an editable Range and so will always default to the standard From/To range regardless of what mode the app sets.

This scheme provides the user with the maximum amount of functionality available at each level, but I am concerned about the inconsistancy between the Simple/CUPS and Advanced modes combination which users will use side-by-side depending on the app. This is because some apps may never be able to set Advanced mode, for example Kate and Konqueror don't really know about pages so may find it very difficult or inefficient to generate pages out of order by themselves.  Users could become confused by this inconsistency between apps without realising why they behave differently, but dropping the Simple/CUPS mode will prevent apps like Kate from printing broken ranges, and restricting the Advanced mode to only ascending pages would remove a useful feature.

So what do people think, which is better, consistency or features?

[Note to self: log and fix bugs in both Kate and Konqi which leave the From/To page range enabled in the print dialog when they in fact always ignore the users input and print the entire document].  

Do people also think it would be useful to continue to display the From/To Page Range entry at the same time as the Range edit entry?  Or would it just clutter things up?

I plan to use a RegEx with QRexExValidator to validate the users input into the Range line edit, but I haven't written a RegEx in years, so thought I'd ask the experts out there to have a look.  The general rules are as follows.

A valid Range is made up of one or more valid Sub-Ranges separated by commas, with no commas allowed at the start or end.

A valid Sub-Range is one of the following (where n is a number from 1 to MAXINT)

• n
• n-n
• n-  [equivalent to n-MAXINT only allowed as final Sub-Range]
• -n  [equivalent to 1-n only allowed as first Sub-Range]

And here's my attempt which I've yet to test to see if it even works:

^(?:(?:\-\d+,)?(?:\d+|\d+\-\d+,)*(?:\d+|\d+\-\d*))|\d*\-\d+$

Suggestions welcome, just remember it needs to be maintainable :-)  Note I'm using \d for digits so we get support for the different number sets we support, but it means I have to do an additional validation step afterwards for n!=0.

Hey all you GSOC bloggers, I'm really enjoying all your blogs about the really cool stuff you're doing, it's real exciting to see what you're up to, and I'm more than just a little bit jealous.  But could an old memory-challenged fogey ask one small favour?  Could you just include the title of your GSOC project and the application at the top of your posts, with so many of you about it's a bit of a struggle to remember who's working on what, and it's not always immediately clear from the post contents.

Congrats to all of you for passing the mid-point review, and be sure to stick around afterwards, it's great to see so many new faces making such solid contributions to the community.

So I'm home from a fantastic 8 days at GCDS in Gran Canaria and a cultured but boiling hot weekend in Madrid.  There's so much to say about the experience, and so much to do as a result, but those will be for another blog.  Since getting home it's been going downhill rapidly.   Late flights, work production issues seeing me pulling 13 hour days, then to cap it off I get a call from my agent this morning to say my employer is terminating my contract effective end of this month.  It's not a total surprise given the current climate, but what $@%$£% me off is that my coward of a manager who's away on leave today didn't have the guts to tell me himself yesterday when he had ample opportunity.  Forget it being unprofessional, you just don't treat other people that way.

So I'm back in the job market again and its not a good time to be looking. If you know of anyone looking for an old-school mainframe programmer / designer / tech lead in the London area with experience in the banking, telco, and energy markets, then drop me a line.  Or if you're really really really desperate for a C++ hack (I wouldn't deign to label myself a programmer)...

Then again, this is the same disorganised outfit that rang me at 3pm on 24th December while I was at the pub enjoying my leaving drinks to offer me a contract renewal, so who knows what will happen.

Well, look on the bright side, I'm soon going to have all the time in the world to hack on KDE and Qt printing:-)

Rather than waste time wrestling with Drupal's image support, I've posted some of my GCDS/Akademy photos on Flickr.  There's more from the tourist trip with people messing about on the dunes, but I hit the 100Mb limit.

One photo Ade might like showing just how cool OpenSolaris really is :-)

All going well, my code for adding Current Page and Page Set selection (aka Odd/Even pages) to Qt should now be up on gitorious for all to see and try out.  For those of you not wanting the hassle of compiling, here's a screenie:

The Gitorious branch is at http://qt.gitorious.org/~odysseus/qt/odysseus-clone/commits/current-odd-even.  I still have a few bits of polish to add, like disabling Page Set if Current Page is selected, and the initialisation is something I'm not 100% happy with, but it's mostly there and working.  I've been testing the last couple of days witout a real printer, but it should still be OK. I also haven't tested it compiles under Windows or OSX, so I'd be grateful to someone did :-)

So what does it do?

• If you're on X11 / LPR and running an app that hasn't been modified, then you see nothing new.
• If you're on X11 / CUPS and running an app that hasn't been modified, then you see the Page Set combo and CUPS takes care of the odd/even page selection.
• If you're on X11 with CUPS or LPR and running an app that has been modified, then you see the Current Page (if set by the app) and the Page Set and the app takes care of the odd/even page selection.
• If you are on OSX or Windows then you see nothing new (as yet).  Good news on that front is I have just seen a commit that moves Qt to using the Win2k print dialog instead of the Win98 print dialog, which should make adding these new features way easier. I still need help here though!

So how to modify an app?  Easy.  To enable the Current Page, just call QPrinter::setCurrentPage() with whatever your current page number is before you exec the print dialog.  To enable Page Set fully, just call QPrinter::setPageSelectionMode(QPrinter::AdvancedPageSelection) before you exec the print dialog, then make sure you either use the new QPrinter::pageList() method to get a list of the pages to render (the easy way) or use QPrinter::pageSet() to figure it out yourself (the hard way).

For reference, the newly added QPrinter public api is:

			enum PrintRange { AllPages, Selection, PageRange, CurrentPage }; // Just added CurrentPage
	enum PageSelectionMode { SimplePageSelection, AdvancedPageSelection };
	enum PageSet { PageSetAllPages, PageSetOddPages, PageSetEvenPages };
	void setPageSet(PageSet);
	PageSet pageSet() const;
	void setCurrentPage(int);
	int currentPage() const;
	void setPageSelectionMode(PageSelectionMode);
	PageSelectionMode pageSelectionMode() const;
	QList<int> pageList() const;
	

 

So, have a look, have a play, and let me know when you find my bugs :-)

[EDIT: Just a reminder this is a change to Qt so depends on the Trolls accepting it, but I'm hoping it makes it into Qt4.6 which will be out before KDE 4.4 so that's the up side]

I use Alt-F2 to launch apps all the time, so imagine my surprise when today when I suddenly got the following dialog the first time I launch a program:

What is this, KDE Vista???

[Edit: Fixed the missing image]

This blog started at the last Akademy in Mechelen as some thoughts on the location aware desktop, what apps would benefit, and how we should be looking to use GeoClue to achieve this rather than rolling our own. But as I've written it I've been thinking about other concepts people have been discussing to the point that it has morphed into a disconnected ramble about the Reactive Desktop. It may not make a lot of sense, but one year later it's about time I posted it :-)

Just a quick note first about Geolocation services. At the moment Plasma has it's own Geolocation implementation. All credit to the guys who have been working on it, it filled a need and it is a fun itch to scratch and it is designed with a future switch in mind, but to me they do need to move to using GeoClue as a backend and to co-ordinate with Marble to move a Geolocation API lower in the stack (kdesupport?) where all apps can access it at all times, not just when using Plasma. A common low level Geolocation API with pluggable backends in the style of Solid and Phonon would become another Pillar Of KDE.

Right, onto the fuzzy blue-sky thinking.

A lot of the ideas I see floating around about the Location Aware Desktop are just at an application level, where an individual application responds to a change of location in an independent and un-coordinated manner, or actively queries the geolocation service when it needs to know the exact current location. These are ideas ranging from the panel clock automatically updating your timezone based on your location changing to konqi telling search engines where you are when searching for a restaurant, etc.

But at a higher level than that is the possibility of your entire desktop automatically adapting to your location when it changes. Imagine being at work with your laptop using your Plasma ‘Work’ Activity, you have open a bunch of work documents and apps, you’re connected to your work chat room, and Kontact is using your work groupware for e-mail and calender. You get to the end of the day, suspend your laptop and go home. On restarting your laptop at home, KDE detects that you’ve changed location to Home, so switches to your Plasma 'Home' Activity/Containment/Whatever with the NSFW wallpaper, saves your Work Session of open docs and apps for later, restores your last Home session with your Kate 'Hacking' session of several kdelibs source files you were working on, Konquorer tabs session with those dot and slashdot articles you were reading, starts Amarok playing with your chill-out playlist, logs you into #kde-devel, connects to MSN, and switches Kontact to your personal e-mail and calendar settings. When you go back to Work everything automatically switches back again.

While you could achieve that by the user going through every single app and individually configuring it to respond as required, that's just too much work. Why shouldn't we provide the user with a single place to configure this? To do that, I think you would need a broader, fuzzier concept of a 'Named Location' then an 'Exact Location' georeference at this moment in time. While you could then define Work as being within 1km of your office georef, Starbucks as being their ESSID, and Home as being anywhere else, you would then also have a way of manually switching locations when you have no Geolocation service available to automatically trigger the change or if you want to be in a different 'location' than where you are now (e.g. work from home).

And this is where my thinking gets a lot fuzzier as to how this would work in practice.

If you think about that a little more, we're no longer talking about being location aware, we're talking about application and desktop session or state management, with pre-defined application and desktop states being switched in response to an outside event. A Reactive Desktop and Applications.

OK, so we already have a lot of that with D-Bus and Solid events triggering application or desktop changes, but much of that is down to the app programmer to join up or the advanced user to script using D-Bus calls. Shouldn't we be letting our users decide what Events or combinations of Events trigger what Actions or state and session changes? If you look at PowerDevil, you have a great example of this sort of model. Shouldn't we have a more general model available where all apps and the desktop advertise a subset of the D-Bus Events they emit and what D-Bus or Session Management Actions they can have triggered, and then give our users a GUI to link these together? The switching to a Named Location state would then just be a special case of this. For example, if There's a cool app over in OSX that does something like this called Marco Polo, have a look it's quite cool.

There's a lot of stuff that would need to hapen first to lay the foundations here. Sorting out Geolocations services is a biggie, but other parts don't necessarily depend on that. Session management would obviously need to be greatly enhanced to enable you to save, edit and restore named desktop sessions, but also to have smart session switching, i.e. if an app is already running don’t close it and open it just change its state or config and geometry if possible. What else can people think of?

Some of the work needed as I see it:

• Fix Geoclue to be fully Gnome independent (Inge has a patch?)
• Add a Qt-only abstraction layer for Geolocation services (including Geoclue as one backend) to kdesupport
• Add a KDE wrapper for the Qt abstraction layer (if needed) into kdelibs
• Add a Named Location service to kdelibs or kdebase
• Add improvements to desktop session management in kdebase
• Add a KCM for Named Locations
• Add support to apps and desktop
• Apps to advertise their Events and Actions
• GUI to allow users to link Events and Actions

Obviously this isn’t all thought through yet, there’s a lot that would need to be sorted out with the architecture and interactions of the components, and many things I’ve probably misunderstood completely about the KDE / D-Bus architecture that may make some things impossible to do, but I thought I’d float the idea out there and see if we can get some discussion going.