FrontPage/Kexi Forms

KFormDesigner FAQ

Table of Contents      Why don't we use Qt Designer? Why inventing the wheel a second time?      Have you planned to integrate it into Kommander / KDevelop ?      I like KFormDesigner - nice Qt Designer fork after all..      But I couldn't say bad word about Qt Designer - it works for me

Why don't we use Qt Designer? Why inventing the wheel a second time?

As a short answer, I would say because Qt Designer is not good enough, at least at code level. Ever tried to read (and understand) its code?

First, KFormDesigner is the form plugin in Kexi, and we couldn't wait for Qt4 Designer to be released (not before 2005). And who knows when KDE 4.0 will be out?

We also wanted to make something not only for developers, but also for users who don't know anything about Qt. So we could have started a QT Designer fork, but imho this software really has a bad design and lot of hardcoded stuff. And there are some mistakes that could have been avoided easily (cannot move widgets inside layout, very limited factories...)

So we decided to start our own form designer, which would have a better design, with the fewer widget specific code in core and also new features missing in Qt Designer.

It will be a second form designer for KDE, which will also integrate into KDevelop and stay compatible with Qt Designer. Imho, it is not a bad thing for the user, as the competition will improve both apps, and give users the choice.

Have you planned to integrate it into Kommander / KDevelop ?

Yes. I've sent a mail to Kommander-devel mailing list. They're very interested in using KFormDesigner, they had already thought about it. But they have a lot of work right now with kde3.3, so they won't use KFD until KDE4.0. (see there http://momo.creolmail.org/pipermail/kommander-devel/2004-July/thread.html)

KDevelop can't wait for Qt4 too. That's why they have their own Qt Designer fork (kdevdesigner) which integrates with KDevelop and that's why they are very interested in KFormDesigner progress. KFormDesigner integration with KDevelop will happen very soon (it's just the matter of implementing KInterfaceDesigner::Designer interface).

So KFormDesigner will soon be used in Kexi, KDevelop and Kommander, as a standard in KDE.

I like KFormDesigner - nice Qt Designer fork after all..

One correction: KFD is not a fork of Qt Designer. KFD is an fully original work with no code taken from Qt Designer. Thus, among other reasons, it was possible to release it under GNU Library General Public License (read: LGPL, not GPL). LGPL is a standard license for KDE components.

But I couldn't say bad word about Qt Designer - it works for me

You are most probably experienced user if not a developer, do you? I am developer and Qt Designer is great tool for me. KFormDesigner is also for "typical" user. Here are just examples of why you as non-developer can be confused with QtDesigner (used as a component for creating simple forms):

• Class names: "Q" prefix is not necessary unless you know you're developing with Qt Framework

• Redundancy in widgets set: eg. QPushButton and KPushButton: why should you care about what to pick? KDE user will, undoubtely, pick a KPushButton, savvy KDE developer probably too

• Menu/actions system: KDE has KXMLGUI framework, KActions, Human Interface Guidelines. Icons are most often provided by factories instead of embedding images inside .ui files.

• Adding a code: KJSEmbed and Python are coming into standard KDE toolset. QtDesigner prefers C++ way of doing things ad presenting (and even QSA's Java Script is only for extending apps functionality).