First steps with Grantlee and KDE PIM GSoC

Well, coding officially starts on May 24, now is time supposed to read documentation, know your mentor(s) and discuss the project ideas, needs, requirements, difficulties, etc. but as many other GSoCers I couldn’t resist to code something.

My goal for the last week was to write a very simple Qt application showing the power of Grantlee. The idea was to simulate that I am reading a message in Kmail and I want to change the theme again and again.

You can take a look at the code in the soc-pim branch or:

svn co svn://anonsvn.kde.org/home/kde/branches/work/soc-pim/kdepim/examples/mail_grantlee/

Of course, you need to install Grantlee, before compiling the example:

git clone git://gitorious.org/grantlee/grantlee.git
cd grantlee
git checkout -b 0.1 origin/0.1
mkdir build && cd build
cmake ..
make && make install

Here some Kmail themes. I’m not an artist, so don’t expect too much, but I know some CSS and started creating the themes just for the example.

KDE theme for Kmail
KDE theme for Kmail
openSUSE theme for Kmail
openSUSE theme for Kmail
Nokia theme for Kmail
Nokia theme for Kmail
Konsole theme for Kmail
Konsole theme for Kmail

Don’t worry. Surely in the future there will be themes for everyone.

BTW, before continue, what is Grantlee?.
I talked about it in my GSoC proposal and Stephen has written a lot in his blog, but in case you haven’t read, here we go:

Grantlee is a Qt string template engine based on the Django template system. Django is a powerful Python framework that makes it easier to create web apps.

In general, what Grantlee does is that it allows an application separate logic from presentation. There are many benefits of doing this: Flexibility, clean code style (readability), consistency and beauty.

Developers concentrate on the technical aspects of the application (logic, performance,…) and artists work on the templates (HTML, CSS) and they both don’t need to touch each other’s code.

This separation allows the application to be built and tested independent of the visual presentation.

So, What would be the role of Grantlee in KDEPIM?

Let us see what is the job for the moment.
The MessageViewer is the library responsible for the header styling in some KDE PIM applications. If you browse the headerStyle class code, will see that there is HTML stuff everywhere. That makes hard, for both developer and artist, to change the way information is displayed.

That problem should be solved by integrating Grantlee with the MessageViewer and my task for now is to extract the presentation stuff, set up the Grantlee code and load the templates.

Of course the job is not only to load templates, I have in my mind all what can we achieve with this integration and believe me there is a lot to do. Grantlee has many cool features for theming, the API documentation is good and I will continue studying the capabilities during this community bounding period.

Well, it is very difficult to blog about all the Grantlee features in a post, but in case you are interested, you can have a quick overview of it here:

Grantlee for application developers.
Grantlee for theme artists.

Of course, I will be posting my grantlee adventures with KDEPIM week by week.

For example, this week I found a useful feature:
The ‘safe filter’. Imagine a mail message come with HTML content or special characters. We should render that message correctly in the template otherwise the content will look horrible.

The safe filter autoescapes a variable in case it has already been escaped. Just do:

{{ message|safe }}

That means, if a message comes with "Kmail & CO" ,that content will be rendered :

“Kmail & Co”

Filters affect the way variables are shown in a template. Grantlee comes with some default filters similar to Django like:

{{ variable|upper }} or {{ variable|cut:”something ” }} to cut a string from the variable. There are more filters and you can also create your own ones.

For the developer side, the fun thing is that you don’t need to rebuild your application if there is a change in the template.

For artists, the template syntax is really clear, very human readable.

I already started hacking a little on the headerStyle, but still I have nothing concrete so far to show you in a real world application. This is just the beginning. Althought, the MessageViewer code is huge, Thomas has given me good entry points to understand how it works.

The end result will be a MessageViewer without any presentation code and connected to a theme location.

The current default header styles are these:
Brief, Plain, Fancy, Enterprise and Mobile.

Please, if you are a KDE PIM user and want a change or feature on those styles, just tell me what to take into consideration before creating them. One feature we will provide is a user option to decide which header fields are displayed.

The second part of the GSoC project consists of GHNS integration in PIM applications that will use Grantlee, that way users can create and share their art-work. In the next weeks, we will be defining a standard package structure for those themes.

I consider theming an important part of the PIM module. On one side, users usually like to have their collection of beautiful themes, and on the other hand, it is also important for companies or educational institutions to show/export/print their identity (colors, logos, slogans).

In general, I’m happy understanding better and better how the project has to be carried on and my continuous Qt/KDE learning. If you have some feedback to provide, it will be well received.

I find the KDE community very friendly, that makes development, communication and the GSoC experience more enjoyable.

Hopefully, my mentors have passed the first week evaluation. I am really glad they are doing a great job and I am willing to help them with everything I can during the project.

Just kidding, they completely rock, their support and answers have helped me lot.

News about this integration coming soon.

Upgrade to Django 1.1

Developing or considering Django to create your cool 2.0 web applications/sites?

Please, try the new version of Django (1.1) which comes with interesting new features.

If you already have Django installed, you must remove the old version directory before upgrading. The path to the directory depends of your system, but it is usually located at:

/usr/local/lib/python$version/dist-packages/
/usr/local/lib/python$version/site-packages/
or
/usr/lib/python$version/dist-packages/
/usr/lib/python$version/site-packages/

One of the new features I recently tried is the possibility to create admin actions that allow for bulk updates to many objects at once.

Example:

Imagine you have a field called status which is a boolean field and you want to change the status of many elements at the same time. It’s annoying to select an object one by one to change the status. Here come “admin actions”, they are really useful.

In this short example, I want to make some objects published/unpublished. I will define two methods in my admin.py to achieve this.

def published(modeladmin, request, queryset):
    queryset.update(status=1)
published.short_description = 'Published stores'

def unpublished(modeladmin, request, queryset):
    queryset.update(status=0)
unpublished.short_description = 'Unpublished stores'

As you can see, in this case, the actions take an argument: queryset, which contains the action to perform and the fields that will be affected.

Then, you add these actions to your model admin:

class StoreAdmin(admin.ModelAdmin):
  ...
  actions = [published,unpublished]

And your admin interface will look like this:

Django admin actions
Django admin actions

Now you can select Published/Unpublished and press “Go” to test the actions.

I selected some elements to make them unpublished and in a second I got the following:

After performing admin actions in Django
After performing admin actions in Django

Simple right?. KISS is always important. But, there are some things to consider before finishing:

Those actions(published, unpublished) are placed outside the class ModelAdmin. (StoreAdmin in this example). But, we also can define these actions as methods of the ModelAdmin.

The advantage is that defining actions as methods gives the action a more direct access to the ModelAdmin (Performance) and the possibility to call any of the methods provided by the admin.

So, I am going to define the actions as methods of StoreAdmin and rename modeladmin parameter to self.

And finally I put the strings ‘published’,’unpublished’ in actions to tell the ModelAdmin to see those actions as methods instead of direct references to functions:

class StoreAdmin(admin.ModelAdmin):
  ...
  actions = ['published','unpublished']

  def published(self, request, queryset):
    queryset.update(status=1)
  published.short_description = 'Published stores'

  def unpublished(self, request, queryset):
    queryset.update(status=0)
  unpublished.short_description = 'Unpublished stores'

And that’s it. If you want to know more about admin actions or implement advanced action techniques, take a look at the excellent Django documentation.

Another feature I tried in Django 1.1 was the option: list_editable which allow edit and save multiple rows at once from the change list page. This option has the same format that list_display, but you have two restrictions:

  • Any field in list_editable must be in list_display.
  • The same field can’t be listed in both list_editable and list_display_links
  • class StoreAdmin(admin.ModelAdmin):
      ...
      list_display = ('customer', 'state','city','phone','status')
      list_editable = ['phone']
    

    A screenshot of the list_editable option for the field phone of my Store model.

    Django - list_editable option
    Django - list_editable option

    Well, I’ll continue exploring the new features in Django 1.1. If you have something to share, don’ t hesitate to post a comment or blog about that.

    Blogging once again

    Wow.  Almost 4 months since my last post, sometimes it’s too hard to update my blog. However, I continue exploring and learning new technologies about my passion: Open Source/Free Software.

    Here are some things that happened in the last months:

    I started learning Python and Django and I have to admit that since the first moment I tried them that I like it very much. On the other hand, I got tired about how slow rails is and the error messages whenever you upgrade some gems and plugins. Conclusion: I switched to Python-Django for web development. Now I am re-writing an application, written in Rails, with Django.

    My boss acquired a dedicated server hosting to run a lot of web services for his company use and proposed me to manage it. Now I am maintaining the server and it was fun to learn SSH and Fedora commands (I use Debian). SSH takes part of my everyday freelance work.

    Last week, I finished the development of an e-commerce site for an American company called Misti International Inc. I used the Magento e-commerce platform to develop it. Which at the beginning seems beautiful with a lot of cool features, but you need some patience to understand it deeply, because has a complex structure with too many folder and files and it is kind of difficult to customize it. But, I worked hard on this site and my client is really happy about it. I strongly recommend to learn PHP5 and take a look at the Zend Framework to learn more about the Magento code.

    I installed KDE 4.2 in my Debian machine. (Here is a quick tutorial ). The only thing I want to say is: THANKS to all the KDE team for give us this great technology that is so well created and designed. But I will talk about KDE in other posts, because I am really interested in developing for KDE.

    Google Summer of Code 2009 was announced and I am going to apply this year again.  I already got in contact with a mentor to work in his proposal and received good feedback about it.