Description: KFormDesigner is meant to be Qt Designer replacement for KDE. It provides almost all Qt Designer features (except code entering) and uses Qt Designer UI file format. It also has new features, such as editing widget contents inside forms, without dialogs, or dynamic resizing of widgets to fit its contents when you edit it.
Being a KPart, it can be used eg inside Konqueror (or with any app that supports KParts) to view UI files.
One can extend it by writing plugins (called factories) to manage more widgets, and control a lot of things about this widget (editing, menu items, shown properties, etc.).
It is developed inside Kexi Project (http://kde-apps.org/content/show.php?content=12365). So if you have installed Kexi, you already have KFormDesigner. The version inside Kexi is always the more up-to-date.
**** About installation ****** If kformdesigner don't appear in your path after installation, try running './configure --prefix=your_kde_prefix'. To know your kde prefix, run kde_config --prefix.
**** About KDevelop Plugin **** It is not compiled by default. If you want to compile it, 'cd kdevdesigner_plugin' and then 'make', etc. To make it appear in KDevelop, you have to modify your kde file associations after installing. In the 'Embedded' tab, make 'Form Designer KDevelop Plugin' first in the list. It should then appear in KDevelop instead of Qt Designer.
Please let me know if you have made a binary package of KFormDesigner, I'll add a link in this page.Last changelog:
**** v0.3.2 10/28/2004 **************** * Support for sub forms, ie form embedded inside another form. By now, you have to enter .ui file path manually, but a dialog will soon appear (when new property editor will be finished) * New actions: "Select All", "Clear Contents" * Major code cleanup * Other fixes and improvements
**** v0.3.1 08/27/2004 **************** * Added a KDevelop plugin (in kdevdesigner_plugin) * Fixed all actions activation, including undo/redo actions. * Some fixes in Connection Dialog by Jaroslaw Staniek . * New 'Unique Form Mode': only one form is shown at a time * User can save the form when closing it * Undo/Redo menu item now also have command name * Renamed libs and files * Some other fixes
**** v0.3 07/31/2004 **************** * KFormDesigner is now a KPart. This will allow its integration into KDevelop (which is just a matter of days) and Kommander. It also allow KFormDesigner to embed eg in Konqueror to preview UI files. * Added needed icons in tarball * Some little fixes **** v0.2 07/29/2004 **************** * First standalone version
This is throwing some compilation errors using the following compiler:
gcc version 3.4.5 20050809 (prerelease) (Ubuntu 3.4.4-6ubuntu8)
cursor.cpp: In member function 'bool KexiDB::Cursor::getNextRecord()':
cursor.cpp:379: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second:
cursor.cpp:379: note: candidate 1: operator!=(int, int)
/usr/share/qt3/include/qstring.h:322: note: candidate 2: bool operator!=(char, QChar)
cursor.cpp:386: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second:
cursor.cpp:386: note: candidate 1: operator==(int, int)
/usr/share/qt3/include/qstring.h:302: note: candidate 2: bool operator==(char, QChar)
cursor.cpp:404: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second:
cursor.cpp:404: note: candidate 1: operator!=(int, int)
/usr/share/qt3/include/qstring.h:322: note: candidate 2: bool operator!=(char, QChar)
cursor.cpp:409: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second:
cursor.cpp:409: note: candidate 1: operator==(int, int)
/usr/share/qt3/include/qstring.h:302: note: candidate 2: bool operator==(char, QChar)
Qt 4 compatible version will be released as soon as Qt 4.0 is released and kdelibs is ported (at least partially).
I'll begin porting when we decide it's time to port Kexi to QT4.
i like your program, but can you make a feature where you can show the code it would generate? you have Preview Form, can't you make a Preview Source too?
Implementing this feature would not be very difficult, however, I doesn't really see the interest..
And, are you talking of the .ui file source, or of the code generated by uic form the ui file?
Could you please improve the support for external widgets?
Maybe the hand-coded widgets is hard to to, but I don't see why can't I just specify the widget .ui and it will embedded it in the editing document, so it'll be a full WYSIWYG UI editor.
Gustavo
I don't really understand your questions. Are you talking about custom widgets (ie not QT nor KDE widgets)? Or are you talking about subforms, ie embedding a form (so a ui file) inside another form?
Loading widgets as you said by just giving a class name is afaik really hard to do, or even impossible.
Sub forms could be done easily (there are already subforms in Kexi).
I was talking about sub forms as new widgets.
I agree that using a new hand-crafted widget (using direct paint for example) is hard.
But having the possibility to use forms in other .ui file as components for other forms are a great feature!
The version of KFormDesigner in KDE CVS (so inside Kexi) now supports subforms as Kexi do, and so outperforms Qt Designer even more now.
This will be included in the next release I'll make here.
looks great. i think its great to see a new qt-designer! being dependant on commercially developed software always sucks (doesnt matter if its open source or not), and i'd always prefer the community based app. i hope trolltech goes bankrupt some time after qt4.0 and the community takes over ;) . well maybe not, but i seriously think we should get independant of those companies sooner or later, and substituting their software with new community based software is the first step. thank you! ;)
i havent tested kformdesigner yet, but can you tell me whether it makes the uis the kde or the qt way (i dont know whether there is a difference really but there is kde widgets and qt widgets and qt projects and kde projects)? i am working on x-platform qt apps, just wanted to ask if that matters.
dont wanto realise that after couple of weeks of work the app wont compile on windoze anymore...
thanks
Being part of Koffice, and so of the KDE project, KFormDesigner uses by default KDE widgets.
The file format used is compatible with Qt Designer, so it would be easy to add an option to use only Qt widgets. However, that's not one of my priorities. If you wan't do it, you're of course invited to do it.
This application looks really great, but unfortunately I can't install it on my SuSE 9.1 system. I ran "./configure", "make", "su" and "make install" and no error occured. But when I then tried to run "kformdesigner", bash couldn't find this application. So I added "/usr/local/kde/share/apps/kfd_part" and "/usr/local/kde/share/apps/kformdesigner/" to my path. When I now run "kformdesigner", I get:
kformdesigner: WARNING: KXMLGUIClient::setXMLFile: cannot find .rc file kfd_mainwindow.rc
And an error-window pops up, saying:
"Could not find the KFormDesigner part. Please check your installation."
Running "kformdesigner" as root doesn't help either.
Please excuse me if I'm just asking a dump question, but I couldn't find an answer anywhere on the web. Further, I couldn't find any compiled package of kformdesigner for SuSE (I only found some for Mandrake). If somebody has found a SuSE-rpm, please inform me.
Thanks a lot.
The problem seems to be that you didn't installed it in the good directory. You should check where other apps are installed, which imho is not in /usr/local/ (the default), but in /usr/local/kde.
Try running './configure --prefix=/usr/local/kde' and 'make install' again. This should solve your problem.
Thank you for your help. I finally managed the installation by choosing "/opt/kde3" as prefix. So, to all "SuSE 9.1 Personal"-users that may read this post: type "./configure --prefix=/opt/kde3".
To all SuSE users: All version of this distro have /opt/kde3 prefix for KDE3.
To all users: run:
kde-config --prefix
..to see what your prefix really is :)
Butifull work !
But QT4 was means (as one of its goals) to make QTDesigner integratable in KDevelop (for example) and other tools...
Why fork a new one instead of wait for that ?
Because it can use KDE icons and technologies ? Good point, but have you discussed with QT to make it easy to intergrate KDE technology and change icons instead of "re-make the wheel" (better, as I can see) ?
Thank you very much.
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.
errr... don't get me wrong, but i never had any problems to understand the qt designer code (reading itself isn't a big deal since i mastered elementary school :)
could you just give a simple example how to create messy code?
(e.g. click here, group there
I'm not talking about the UI files generated by Qt Designer or the code generated by uic. There's no problem with both.
I'm talking about Qt Designer source code, which is imho a real mess, badly designed and hard to read.
I can add here some examples of whynon-developers can be cofused with QtDesigner (as a component for creating simple forms):
- Class names: "Q" prefix is not necessary unless you know you develoiping with Qt Framework
- Redundancy in widgets set: eg. QPushButton and KPushButton: why anybody should care what to choose? KDE user will, undoubtely, pick a KPushButton, as well as savvy KDE developer
- Menu/actions system: KDE has KXMLGUI framework, KActions, Human Interface guidelines. Icons are most often provided by factories instead of embedding in .ui files.
- Adding a code: KJSEmbed and Python are coming into standard KDE toolset. QtDesigner prefers C++ way of doing things (and even QSA is only for extending apps functionality).
OK.
I then wish you a good time with this project.
Since KFormDesigner is a KDE porject I would prefer it over QtDesigner (more beatifull, and KDE integrated).
Have you planned (ie. call the mainteners/programers) to integrate it / make it integratable into Kommander ?
Would be very good...
I haven't talked yet to Kommander developers, but I may do it soon.
This could be a good idea, but this would require some work, as Kommander is a fork of Qt Designer, that adds scripting possibilities.
But it would be consistent over all KDE.
And KDE then would have *one* library to make/edit dialogs, as it has one editor: KatePart (which is very well too).
OK a fork is good (especially this one) but a lot aren't very good, for me.
Ratings & Comments
29 Comments
This is throwing some compilation errors using the following compiler: gcc version 3.4.5 20050809 (prerelease) (Ubuntu 3.4.4-6ubuntu8) cursor.cpp: In member function 'bool KexiDB::Cursor::getNextRecord()': cursor.cpp:379: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second: cursor.cpp:379: note: candidate 1: operator!=(int, int) /usr/share/qt3/include/qstring.h:322: note: candidate 2: bool operator!=(char, QChar) cursor.cpp:386: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second: cursor.cpp:386: note: candidate 1: operator==(int, int) /usr/share/qt3/include/qstring.h:302: note: candidate 2: bool operator==(char, QChar) cursor.cpp:404: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second: cursor.cpp:404: note: candidate 1: operator!=(int, int) /usr/share/qt3/include/qstring.h:322: note: candidate 2: bool operator!=(char, QChar) cursor.cpp:409: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second: cursor.cpp:409: note: candidate 1: operator==(int, int) /usr/share/qt3/include/qstring.h:302: note: candidate 2: bool operator==(char, QChar)
thanks for this greate application :) Question: also is Qt4 supported, if it's available? (i don't like the Qt4 Designer) :) --- lfreak
Qt 4 compatible version will be released as soon as Qt 4.0 is released and kdelibs is ported (at least partially). I'll begin porting when we decide it's time to port Kexi to QT4.
this is great stuff, keep up the good work! I was getting annoyed with QtDesigner :) cheers PetevdM
i like your program, but can you make a feature where you can show the code it would generate? you have Preview Form, can't you make a Preview Source too?
Implementing this feature would not be very difficult, however, I doesn't really see the interest.. And, are you talking of the .ui file source, or of the code generated by uic form the ui file?
Could you please improve the support for external widgets? Maybe the hand-coded widgets is hard to to, but I don't see why can't I just specify the widget .ui and it will embedded it in the editing document, so it'll be a full WYSIWYG UI editor. Gustavo
I don't really understand your questions. Are you talking about custom widgets (ie not QT nor KDE widgets)? Or are you talking about subforms, ie embedding a form (so a ui file) inside another form? Loading widgets as you said by just giving a class name is afaik really hard to do, or even impossible. Sub forms could be done easily (there are already subforms in Kexi).
I was talking about sub forms as new widgets. I agree that using a new hand-crafted widget (using direct paint for example) is hard. But having the possibility to use forms in other .ui file as components for other forms are a great feature!
The version of KFormDesigner in KDE CVS (so inside Kexi) now supports subforms as Kexi do, and so outperforms Qt Designer even more now. This will be included in the next release I'll make here.
looks great. i think its great to see a new qt-designer! being dependant on commercially developed software always sucks (doesnt matter if its open source or not), and i'd always prefer the community based app. i hope trolltech goes bankrupt some time after qt4.0 and the community takes over ;) . well maybe not, but i seriously think we should get independant of those companies sooner or later, and substituting their software with new community based software is the first step. thank you! ;) i havent tested kformdesigner yet, but can you tell me whether it makes the uis the kde or the qt way (i dont know whether there is a difference really but there is kde widgets and qt widgets and qt projects and kde projects)? i am working on x-platform qt apps, just wanted to ask if that matters. dont wanto realise that after couple of weeks of work the app wont compile on windoze anymore... thanks
Being part of Koffice, and so of the KDE project, KFormDesigner uses by default KDE widgets. The file format used is compatible with Qt Designer, so it would be easy to add an option to use only Qt widgets. However, that's not one of my priorities. If you wan't do it, you're of course invited to do it.
This application looks really great, but unfortunately I can't install it on my SuSE 9.1 system. I ran "./configure", "make", "su" and "make install" and no error occured. But when I then tried to run "kformdesigner", bash couldn't find this application. So I added "/usr/local/kde/share/apps/kfd_part" and "/usr/local/kde/share/apps/kformdesigner/" to my path. When I now run "kformdesigner", I get: kformdesigner: WARNING: KXMLGUIClient::setXMLFile: cannot find .rc file kfd_mainwindow.rc And an error-window pops up, saying: "Could not find the KFormDesigner part. Please check your installation." Running "kformdesigner" as root doesn't help either. Please excuse me if I'm just asking a dump question, but I couldn't find an answer anywhere on the web. Further, I couldn't find any compiled package of kformdesigner for SuSE (I only found some for Mandrake). If somebody has found a SuSE-rpm, please inform me. Thanks a lot.
The problem seems to be that you didn't installed it in the good directory. You should check where other apps are installed, which imho is not in /usr/local/ (the default), but in /usr/local/kde. Try running './configure --prefix=/usr/local/kde' and 'make install' again. This should solve your problem.
Thank you for your help. I finally managed the installation by choosing "/opt/kde3" as prefix. So, to all "SuSE 9.1 Personal"-users that may read this post: type "./configure --prefix=/opt/kde3".
To all SuSE users: All version of this distro have /opt/kde3 prefix for KDE3. To all users: run: kde-config --prefix ..to see what your prefix really is :)
Butifull work ! But QT4 was means (as one of its goals) to make QTDesigner integratable in KDevelop (for example) and other tools... Why fork a new one instead of wait for that ? Because it can use KDE icons and technologies ? Good point, but have you discussed with QT to make it easy to intergrate KDE technology and change icons instead of "re-make the wheel" (better, as I can see) ?
I'd completely agree on that. Why inventing the wheel a second time?
Thank you very much. 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.
errr... don't get me wrong, but i never had any problems to understand the qt designer code (reading itself isn't a big deal since i mastered elementary school :) could you just give a simple example how to create messy code? (e.g. click here, group there
I'm not talking about the UI files generated by Qt Designer or the code generated by uic. There's no problem with both. I'm talking about Qt Designer source code, which is imho a real mess, badly designed and hard to read.
I can add here some examples of whynon-developers can be cofused with QtDesigner (as a component for creating simple forms): - Class names: "Q" prefix is not necessary unless you know you develoiping with Qt Framework - Redundancy in widgets set: eg. QPushButton and KPushButton: why anybody should care what to choose? KDE user will, undoubtely, pick a KPushButton, as well as savvy KDE developer - Menu/actions system: KDE has KXMLGUI framework, KActions, Human Interface guidelines. Icons are most often provided by factories instead of embedding in .ui files. - Adding a code: KJSEmbed and Python are coming into standard KDE toolset. QtDesigner prefers C++ way of doing things (and even QSA is only for extending apps functionality).
OK. I then wish you a good time with this project. Since KFormDesigner is a KDE porject I would prefer it over QtDesigner (more beatifull, and KDE integrated). Have you planned (ie. call the mainteners/programers) to integrate it / make it integratable into Kommander ? Would be very good...
I haven't talked yet to Kommander developers, but I may do it soon. This could be a good idea, but this would require some work, as Kommander is a fork of Qt Designer, that adds scripting possibilities.
But it would be consistent over all KDE. And KDE then would have *one* library to make/edit dialogs, as it has one editor: KatePart (which is very well too). OK a fork is good (especially this one) but a lot aren't very good, for me.