Many of you may already have dealt with property editors. These are generic widgets that display properties of some object, and allow to edit them. I’ll also have to do one of these property editors for Kolf as an addition to the already available graphical interface, which can only be used to edit geometrical properties, not behavioral ones.
Of course, I want to reuse existing code to get Kolf ready soon, so I had a look around for other property editors. Below is a selection from what I found. The first one is the widget property editor of Qt Designer, the second one is used in Step (a physics simulator from kdeedu) to display and edit the physical properties of some body, and the third one is from Rocs (a graph-editing application which Tomaz Canabrava is working on).
As you can see, each of those editors looks (and probably also behaves) differently. This indicates that there is no library-based generic property editor. This is the first RFC: Am I wrong? Is there a generic property editor widget somewhere in Qt or kdelibs? And before I forget it, here’s the second RFC: Are there any other property editors which I’ve forgotten, and which might be worth to look at?
Now that the option of using a library-based property editor is out, it seems like I have to create one. And this means that more investigation about the pros and cons of the existing property editors is needed.
Let’s begin with the last picture. It is actually a detail from a screenshot that Tomaz published in a blog entry yesterday. In the same post, he indicated that this interface is “less than ok, it’s really ugly.” It’s easy to see that Rocs’s property editor is the odd one out in the above gallery. While the other dialogs use a single list/tree view to display all properties, the Rocs dialog uses widgets arranged in something that looks similar to a QFormLayout (though it also has a list view for something called “dynamic properties”).
Let’s move on: Step’s dialog is plain and simple. After my fancy, the structure is not totally clear because it contains too less lines. Step’s dialog also has something which only a physical simulation program needs: units. (Not visible in the screenshot: The unit disappears while editing the value.) In these two regards, the Designer dialog is the complete opposite: It uses colors and lines very extensively, can group properties (although only by class, not by type), can also add dynamic properties (the green plus button at the top), has sorting and filtering, and uses a tree model for complex properties. Qt shows off what can be done with its generic frameworks.
From these three samples, the Designer dialog is closest to what I want to have. I’m not sure whether the coloring is compatible with our HIG, and I don’t know whether it is possible to easily add support for own data types (which Kolf uses plenty of, because Qt’s geometry data structures cannot be applied to a 3D space). I haven’t had time yet to read into the code for these property editors.
Last but not least, the third RFC: Is anyone here interested to collaborate with me on a generic property editor dialog for KDE applications? I have the following requirements:
- It has to read and write QObject’s meta properties, which requires it to cope with QVariant values and such correctly.
- I need to be able to add support for new data types inside an application that uses this dialog, preferably in a very straight-forward manner.
- Optionally, I would like to be able to group properties by type (e.g. “shape”, “position”, and “behavior” for Kolf objects).
Of course, this list can be extended to meet your requirements if you want to use this property dialog in one of your applications. If you’re interested, please get in touch with me. You should be able to find my mail address easily (e.g. in the license headers or in the about box of kdiamond, palapeli or kolf-ng).
