Accessing WebDAV calendar from commandline

March 11, 2011 in open source, programming, projects, python, software

Have you tried to access Zimbra or Google Calendar from command line? I have. And I couldn’t find any normal command line client that would be able to read and write these calendars, display alerts etc. Well there is a googlecl project, but it’s specific for Google Calendar and is not using standard WebDav iCal access methods.

Thus I set out to create console application that would fulfil my needs. What are my requirements?:

  • Read/write access to Google Calendar and Zimbra (at least)
  • Multiple remote calendars
  • Working alerts
  • Nice ncurses UI (but also ability to just display some info and quit)
  • Correct handling of timezones
  • Integration with mail client (open ics files received by email)
  • I guess a lot more :-)

I had a look at existing python modules that work on iCalendar, WebDAV and combination of both. There are quite a few of them, but I just didn’t like their APIs. They were usually complex and required knowledge of iCal specification. So I decided to create simplified module that would be easy to understand (even if not so powerful).

I named the project pywebcal (yes, unimaginative) and it’s now on github. I would LOVE some input. I know it’s far from perfect (or complete), but let’s see. For now it offers read-only support for Zimbra (Google should work too but I haven’t tested in a while).

You can have a look at the example directory that contains one simple example you can run in-place and see if it works :-) I did my best to create proper test cases covering problems with timezones and whatnot, and this helped me quite a lot with recent refactoring. I am now using vobject library as my backend and it is rather nice to use. Plan is to allow access to vobject components so that my simplified API is not preventing some advanced modifications.

Next step is obviously to start working on ncurses application itself. Anyone wants to help?

Python3, PyQt4 and missing QString

October 20, 2010 in howto, open source, programming, pyqt, python, qt

As I was recently adding support for Python 3 to my little trailer downloader application that I mentioned before (PyQTrailer) I encountered a strange problem with PyQt4 that only occurred in Python 3.

Let’s take this simple python example:


$ python
>>> from PyQt4.QtCore import QString
>>>

That same code snippet doesn’t work in python3 interpreter though:


$ python3
>>> from PyQt4.QtCore import QString
Traceback (most recent call last):
File "", line 1, in
ImportError: cannot import name QString
>>>

My first instinct was: Bug! Gentoo PyQt4 ebuild was doing something terrible and somehow made PyQt4 unusable in python3 interpreter. Turns out my gut instinct was wrong (once again :-) ).

PyQt4 since version 4.6 changed API of QString and QVariant for python 3.x. For QString this is due to fact that from Python 3.0, string literals are unicode objects (no need for u’unicode’ magic anymore). This means that you can use ordinary Python strings in place for QString. But I wanted my QString for something like this:


...
downloadClicked = pyqtSignal((QString, ))
...

This snippet creates Qt signals that you can then emit. Question is… How can we update this for Python 3.x? We could probably just replace QString with type(“”), but for a change that wouldn’t work with Python 2.x. So? Python dynamic nature to the rescue!
Edit: simplified QString definition (thanks Arfrever)


try:
from PyQt4.QtCore import QString
except ImportError:
# we are using Python3 so QString is not defined
QString = str

If we put previous code sample to the beginning of our Python file we can use QString in our code and it will keep working both in Python 3.x and Python 2.x. Case closed dear Watson.

Uploading original photos from Digikam to Flickr

August 28, 2010 in en, kde, open source, photography, programming, projects, qt, software

I have been using Digikam for managing my photos for some time. It’s pretty neat software and development is progressing quite fast. You can think of it as Lightroom, just without the neat non-destructive editing. But that is coming too, thanks to Google and another round of Summer of Code participants. But I wouldn’t be writing this blog post if Digikam was flawless would I? :-)

First I’ll describe my work-flow in few short bullet-points :-)

  • Shoot a LOT of photos
  • Delete almost as many photos
  • Geotag, tag/keyword and rate remaining photos
  • If it was party or something similar upload to Facebook right away
  • Pick few photos and improve them a bit with Gimp (nothing fancy, just crop/levels)
  • Upload all photos to Flickr as a backup/sharing place

Digikam enables me to work like this, except the last point. Why? Because apparently Digikam developers don’t think anyone would update their photos to Flickr without first resizing/recompressing them. This  how flickr export dialog looks like this:

See the problem? Even if I don’t chose “Resize photos before uploading” Digikam will still re-compress them which is a Really-Bad-Thing(tm) to do with jpeg files. I had some previous experience with Qt3 and even Qt4. so I though it might be a good idea to look into fixing this small annoyance. I will not bore you with the details how I checked out svn repository with git and rest of the stuff. Here is the result:

If you un-check “Send original file (no resizing)” original settings will appear and you can resize/recompress as much as you want (Blasphemy! Madness!). The patch is not flawless, because it won’t prevent you from trying to upload RAW files to Flickr, but it’s good enough for me :-) It’s not even that big, stats are like this:

 flickrexport/flickrtalker.cpp |   18 ++++++++++++——
 flickrexport/flickrtalker.h   |    2 +-
 flickrexport/flickrwidget.cpp |   34 ++++++++++++++++++++++++++——–
 flickrexport/flickrwidget.h   |    5 +++++
 flickrexport/flickrwindow.cpp |    4 ++++
 flickrexport/flickrwindow.h   |    1 +
 6 files changed, 49 insertions(+), 15 deletions(-)

You can download the patch from my Dropbox for now until the bugreport I created some time ago will get sorted out (don’t hold your breath too much though). The patch applies cleanly across all versions of kipi-plugins I tried (from 0.8.something to 1.4.0). Happy uploading.