[RFC x 3] On property editors

August 26, 2009

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).


16 Responses to “[RFC x 3] On property editors”

  1. The Qt one is available as a QtSolution here: http://doc.trolltech.com/solutions/4/qtpropertybrowser/index.html

    From what I could find out it wasn’t meant to support additional property types though it wouldn’t be too hard to implement.

  2. Herbert Graeber Says:

    As far ask i know, the Qt-Designer property widget – or at least a variant of it – is available from the QT website as part of Qt solutions. It is under LGPL like Qt itself:


  3. Adam Pigg Says:

    There is another property widget library you could look at. KoProperty2 in koffice/kexi/KoProperty2. You can see it in action if you run kexi from trunk, or look at some of the screenshots on my website (http://www.piggz.co.uk/kexi). I use it in the Kexi report component, but it is also used in other parts. Dont worry too much about the fact it resides in the kexi sub dir, because i beleive the intention is to move it outside of koffice (maybe kdesupport) as it is completely generic.

  4. Heller Says:

    “a generic property editor dialog for KDE applications”

    –>I’m not qualified to do this kind of “low level” developement but indeed, KDE needs something like that !

  5. atomopawn Says:

    Funny, but I actually like the third one best. The other two are so cluttered it’s hard to find what you want. Also, because all the properties are displayed in exactly the same way, it’s harder to remember where any but the first and last properties are. In the third one, because some elements are displayed as checkboxes and others are displayed as text fields, and still others are displayed in a list, there are some nice visual cues that help you remember where each property is and find it more quickly.

    The one drawback to the third dialog is that you probably have to right click on the properties list to add each property that you want to change from its default value (I’m guessing, since I’ve never used Rocs).

    I also agree that the grouping functionality of the first dialog is nice. Perhaps something like the first dialog, but in a tabbed widget that provided another level of organization would be nice.

  6. Parker Says:

    The requirement to read QObject properties seems like an artificial one. I’m assuming you want to use some kind of model/view system, in which case you could have a generic PropertyModel which is inherited by ObjectPropertyModel and, say, IniPropertyModel or HtmlElementPropertyModel. If your goal is a reusable widget, it should probably be as backend agnostic as possible.

  7. Andre Says:

    Yes, there are more. On qt-apps.org, you can find Yape, QPropertyEditor and Value Browser.

    My needs were fulfilled quite nicely with Yape (and some lightweight additions to it), as the objects I was interested in were already QObjects anyway. Still, I would be interested in collaborating on something better as long as it does not become too tied in with KDE.

    Parker’s remark above is an interesting one. It would be nice if different back-end models could be plugged in. Of course there would be a QObject backend model, but other models could be defined too.

  8. Christoph Says:

    The one from Qt is pretty generic, you can even make it to display the options in widgets, instead of in a treeview. I’d say use this, and consider contacting Nokia to help making it part of Qt officially. If more people use this class and give feedback to Nokia, the better the API will be. Unfortunately, you missed the 4.6 deadline, it was just feature frozen.

  9. John Layt Says:

    It would be nice if Qt provided one as a core widget, as it would be very useful in my work on the Qt print dialog for editing the Cups options. The current implementation is just plain ugly and near unusable.

  10. Gaël Says:

    Hi, I am interested in such a tool for my own generic graph editor, kgrapheditor. I started a very specific one but using an already made widget would be better. I think I’ll have a look to what other commenters signaled, but if you develop a new one, I could use it and help to debug it, even if I have no time to directly help you in the development.

  11. My needs are fullfilled with my dialog ( the third one ), but it has lots of drawnbacks like the inability to work with generic code ( besides the listview with the dinamic properties for node and edge ). you asked in my blog if I could help you developing one, well, yes. we can both use the code in our apps if it gets generic enougth. but reading the comments I just realized about the kexi one.
    I will try it and see if it can be used for my needs, you can do the same and if it is ok, we can help it on the missing parts.

  12. purple-bobby Says:

    A property editor is (like) a declarative language editor.

    Many property editor panels give you too many options to choose, without any easy discovery about what each choice means to this attribute. I often find myself overwhelmed with similar sounding attributes, unable to find the exact combination of attributes and values to make happen what I want to happen.

    Take the GIMP, a brush might have colour, width, density, shape and a whole lot of other attributes nobody cares about.

    Useful things:
    A preview of what the current choices are going to do.
    A ‘scrapbook’ of previous choice sets.
    A template / library of useful choice sets.
    A way to hide or group to minimize the complexity of a lot of attributes.

    • Stefan Majewsky Says:

      Wow! That’s four feature requests in one. Before I go through them, I make sure you understand what properties are meant to be edited here. Take for example a black hole object: It has an entry point, which sucks balls in. The balls will then disappear temporarily and reappear at some exit point. This object has some geometrical properties (position of entry point and position of exit point, direction of ball after exit) and a behavioral property (time between entry and exit). Another example: A simple rectangular block only has geometrical properties (position and size).

      1. A “preview” is, by its nature, only possible for geometrical properties quite hard to do. Changes in the property editor are directly transferred to the editor view. Perhaps one might show arrows or such to indicate which part of the geometrical representation of the object is affected by changes to the selected property. I’ll put this on my list, but that’s something that won’t happen before KDE 4.5. (Please poke me if I forget about this, or file a bug report.)
      2. By “scrapbook”, you probably mean what Qt calls “undo stack”. Something like this is already implemented in Kolf (see my blogpost “Kolf: Work on multiple fronts” from May), and (from a technical point of view) not the task of the property editor. In Kolf, the objects create snapshots of themselves when properties change.
      3. I do not see how one can define “useful choice sets” generically. A library of user-defined presets is perfectly possible, but also out of the scope for KDE 4.4 (we need to focus on getting the basic features ready, to get it done in time).
      4. Minimizing the complexity is a very important goal for a property editor. As you see from my above examples, Kolf objects usually have very few properties. Also, the complexity of the initial presentation can be reduced by using a tree structure (see how Qt Designer handles sizes and geometries, for instance).

      • purple-bobby Says:

        I feel a bit guilty for not reading up on what Kolf was, I’d assumed it was a Golf game/diary for KDE, oops!

        1 Preview, I guess ‘preview’ was too strong, I was thinking of one of those awful panels littering MS applications which show what and how changing a value would change the system with a simplified diagram. I agree it works better of the graphical stuff and less so on more abstract stuff.
        2 Scrapbook, less of an undo stack, more of a palette of a handful of distinct user selections. In a painting application, when you select a colour, you find your last dozen picked colour ready available or you can mix a new one.
        3 Presets would probably combine with the ‘scrapbook’ function, above. It is like giving the user a range of default values, it allows the user to adjust without having to find out all the affects of all the attributes.
        4 Initial presentation simplicity, (this probably does not apply to Kolf) trees are like grouping, but users can get lost in deep trees. Perhaps folding or (browser) tabs to give course grain scrolling (ironically YaST has moved away from tabbed browsing to one scrollable list). Perhaps a system like Dasher, but applied to your application’s vocabulary / syntax and perhaps extending the character set with icons or ideograms.

        I’m also aware of the growing number of touch screen devices, that lack the finesse of a mouse, but gain the flick gesture. Also joy pad input.

        A general purpose property editor (library) might have an underpinning declarative language, but this can be compiled into a number of interfaces (of increasing sophistication). At the low end you have the HTML form controls: check-box, radio buttons, text input, pull-down menu selection, and action buttons, but needs a rough value input (knob/dial/slider) and precise value input (key pad pop up). There is a problem of killing the fun element which makes less easy to use.

        Sorry long post

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s