Good evening, my name is Eric Janses 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. 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

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

So for example, the table view can easily display a list of 1 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 SQLAlchemy, which is an object relational mapper in Python, which is actually very powerful and has good support for inheritance.

Next to SQLAlchemy, 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 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 and I change something, then on the other guys' desktop, 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 path 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 LX0 object model and also contains the definition of

how your model should be visualized. And then the application admin file, which says how your application should look like. So the first thing you have to do is to create your LX0 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 LX0 class, and it just tells LX0 that the movie object should be mapped to the database. So in your database you will have a table called movie, which for every field in this

class a column. So you can define all standard SQLAlchemy fields, like Unicode fields, date fields. You can also define relations between various objects. But this is actually plain SQLAlchemy LX0.

Then when you define your model, you can use as well some specific Camelot field types. Camelot field types actually extend the SQLAlchemy 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-based class which assess 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 side panel of the application.

And this is done in the application admin file. So there is simply at here the movies section, then we will have a new section in our side 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 side 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 movies section and we get the 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 widgets, the rich text widgets. We also have one-to-many widgets and many-to-one widgets for relations.

What else do 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 a form actions attribute of the admin class.

So here we have the burn to disk function. 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 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 tabs and horizontal boxes and vertical boxes and you can also very easily subclass the form classes and define your own layouts for the forms.

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 to 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 attributes. 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 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 PyQT 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've 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 GPL. Other questions? Yeah, please. Excuse me.

Well, when I started this project, I developed actually a couple of prototypes. One was with TCLTK, one was with GTK and one was with QT and after evaluating these prototypes I found actually the QT one, the most convenient to develop 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 class. If you specify it as an inner class, it's picked up automatically. Otherwise you have to register it, which is more or less like is done in the new Django interface.

Okay, thank you.