 Good evening. My name is Eric Janssus, and I'm very pleased that I can tell you something about the Camelot project. So what is the Camelot project? The Camelot is actually a framework, a Python framework to build rich GUI applications simply by adding some additional information to your object model. It's heavily inspired by the Django admin interface. So what are the main targets of the framework? The first target is to be user and developer friendly. So notice that user friendliness comes before developer friendliness. And with developer friendliness, I mean that the framework provides a set of standard functions which can be easily overwritten or replaced by custom ones if you want to customize the framework to suit your particular needs. And you can do so without actually touching the source code of the framework. User friendliness also means that the application should be responsive. So the application is designed to be responsive even in the presence of large data sets. So for example, the table view can easily display a list of one million objects at the same time without any sloppiness. Another target is that it should handle object inheritance at the GUI level. So for example, if you have an animal object and you have a list of animal objects, you get all the properties of the animals. But if you select one of the animals and it's, for example, a donkey, then you get all the properties of the donkey visualized. Thank you. So Camelot is built with Python. So it relies heavily on Python and the standard Python libraries. A very important part of the framework is SQL Alchemy, which is an object relational mapper in Python, which is actually very powerful and has good support for inheritance. Next to SQL Alchemy, Elixir is used. And Elixir makes it very easy to define your object relational mappings. It makes it as easy as just defining plain old Python objects. For the graphical part, PyQt is used. And then ActiveMQ is used as well. But this is an optional part. This is if you want, if you have multiple clients working together and you want to send updates from one client to the other. So if I am editing the properties of an animal or I change something, then on the other guys, it just stops, it changes as well. This signaling is done through the ActiveMQ messaging server. So I will demonstrate how to start a project in Camelot. So we will build a movie database in 15 minutes. So the first thing you have to do is you download the Camelot framework, including all its dependencies. And you set your Python part correctly, which is very important. Once you've done so, you can use the Camelot admin tool to start a new project. So we just start the video store project. And then the Camelot admin tool will create a couple of files. The main file, which is obviously the file you need to start if you want to launch the application. The settings file, which contains your database configuration and the location of your images and icons. The model file, which contains the LXEAR object model, and also contains the definition of how your model should be visualized. And then the application admin file, which contains, which says how your application should look like. So the first thing you have to do is to create your LXEAR model. This is very easy. It's just like defining a plain old Python object. So here we have a movie class, which extends the entity class. And the entity class is actually a base LXEAR class. And it just tells LXEAR that the movie object should be mapped to the database. So you will have, in your database, you will have a table called movie with all, which for every field in this class, a column. So you can define all standard SQL Alchemy fields, like Unicode fields, Date fields. You can also define relations between various objects. But this is actually plain SQL Alchemy LXEAR. Then when you define your model, you can use as well some specific Camelot field types. Camelot field types actually extend the SQL Alchemy field types to provide some additional functionality. There is, for example, the image field type, which helps you to store location of images in the database. And there is the rich text field type, which stores text as HTML in the database, but visualizes it to the user as a rich text component. So once we've defined our model, we will define how to visualize it. And this is done by adding an admin inner class to your movie class. This admin inner class extends the entity admin class. Entity admin class is a Camelot base class, which says how your entity class should be visualized in the application. So here we say that it should be present in the movies section. And we have here the list display attributes, which specifies which field should be visible if we see a list of movie objects. And then we have the form display attribute, which is a list of fields that should be present on the form. Now before we can start the application, we have to do one more thing, and that is defining the sections in the site panel of the application. And this is done in the application admin file. So there we simply add here the movie section. Then we will have a new section in our site panel. And we have to register the movie admin subclass as being the class that defines how the movie class should be visualized. This registration is actually done automatically if you specify movie admin as an inner class of movie, but the only classes that are registered manually will be present in the site panel. That's why we have to do this. So now we are ready to launch the application. We start main.py and we click the movie section and we get a list of all the movies in the application. Notice that you can filter this list on the genre of the movies. And you can also search this list with the text box on the top. By default the search widget will search through all text fields of your objects. If you click one of the movies, you get the standard form view where we have the image widget, the rich text widget. We also have one to many widgets and many to one widgets for relations. For those that we get for free, in the toolbar you get the functions to do prints of tables and forms. You can export them to a pretty spreadsheet. You can export them to HTML or you can send them by email to your friends. Now I promised that the framework was easy to customize. So first thing you can do is you can add actions to forms. This is very easy to do. You just add some functions to form actions attribute of the admin class. So here we have the burn to disk function. It just takes a single argument, the movie, and it burns it to the disk. So you get a button on the form and when the user presses that button the function gets called. Another way of customizing the form is through the field attributes, attribute of the admin class. This actually specifies for each field a list of attributes that further define how the field should be visualized. So for example for the genre field we can specify some choices that the user should get when he wants to edit this field. We can also further define the layout of the form. This is done by instead of putting in the form display attribute a list of all fields which should be on the form, we can put in there a structure of form classes and form classes actually map to layout managers of QT. So you can actually have steps and horizontal boxes and vertical boxes and you can also very easily subclass the form classes and define your own layouts for the forms. Then the next level of customization is by using delegates. What you might want to do is you might want to further specify how exactly a field should be visualized and this can be done through delegates. Delegates is a QT concept in the QT world. A delegate is the bridge between the model and the view. The delegate says to the view how it should display a field of the model. So typically a delegate class has a method create editor which gets called to create an editor in the view. So in Camelot you can specify which delegate should be used for which field. This is done again with the field attribute. So you tell it there to use a particular delegate for a particular field and you do that by specifying a factory function that creates the delegate. This factory function will then be called by Camelot to create a delegate which in turn will then be used to create the form. So maybe I should go back one slide. So here we have specified that a slider delegate should be used to visualize the rating field and if we look then at the form we see that a slider is used to visualize the rating field. It's very easy to define your own delegates. If you want to define your own editors you can program them in Pi QT and then put your own delegates in there. So for example the ratings it could be stars or something like that. Then the next level of customization is by subclassing the entity admin class. So the entity admin class actually specifies how all forms and tables are presented to the user. It has a couple of methods which create the forms and the table views and the select views and what you can do is you can just simply overwrite those functions and fully customize how your table or your form should look like. Now I have no example of this since I have never done so myself. So this basically concludes the short presentation on the Camelot project. I hope you have enjoyed it and if you have questions please don't hesitate to contact me or ask them right now. Are there any questions? Yes please. What's the license? It's GPO. So other questions? Yeah please. Excuse me. Well when I started this project I developed actually a couple of prototypes. One was with Tickle TK, one was with CTK and one was with QT and after evaluating these prototypes I found actually the QT one the most convenient to develop in and also the best when you want to target multiple platforms. So therefore it was actually developed in QT. Yes please. Yes, yes, yes. Actually now it's specified with an inner clause. If you specify it as an inner clause it's picked up automatically. Otherwise you have to register it which is more or less like it's done in the new Django interface. Okay thank you.