On win32 the QT 4.4.3 designer is giving me the option to save forms in the new format.
If I convert some forms to qt4, would this be a good thing(tm)?
No, if it were that easy I would do that myself :-)
You need to convert also the code and add custom slots and connections.
Well yes, that would be the point of the exercise.
I converted a form to check if I can find a minimal process. How about this 6-line patch for example? Seems easy and is working for me (super minimal testing done: just added a couple of activities).
Obviously, there could be other forms that don't quite match this process, which is why I'm asking for your input. If not, I could actually come up with a script for people to use if they want to work on an old 3.3 form to convert it as necessary. Or I could convert everything myself. Would you be OK with a qt Designer 4 requirement?
(This is on win32)
run:
uic3 -convert addactivityform_template.ui > addactivityform4.ui
Apply patch (rev261 is 5.10.3):
Index: addactivityform.cpp
===================================================================
--- addactivityform.cpp (revision 261)
+++ addactivityform.cpp (working copy)
@@ -58,6 +58,7 @@
AddActivityForm::AddActivityForm()
{
+ setupUi(this);
/*setWindowFlags(windowFlags() | Qt::WindowMinMaxButtonsHint);
QDesktopWidget* desktop=QApplication::desktop();
int xx=desktop->width()/2 - frameGeometry().width()/2;
Index: addactivityform.h
===================================================================
--- addactivityform.h (revision 261)
+++ addactivityform.h (working copy)
@@ -18,7 +18,7 @@
#ifndef ADDACTIVITYFORM_H
#define ADDACTIVITYFORM_H
-#include "addactivityform_template.h"
+#include "ui_addactivityform4.h"
#include "timetable_defs.h"
#include "timetable.h"
@@ -36,7 +36,7 @@
#include <q3textedit.h>
-class AddActivityForm : public AddActivityForm_template {
+class AddActivityForm : public QDialog, private Ui::AddActivityForm_template {
Q_OBJECT
public:
Index: interface.pro
===================================================================
--- interface.pro (revision 261)
+++ interface.pro (working copy)
@@ -734,6 +734,7 @@
../../translations/fet_fa.ts \
../../translations/fet_untranslated.ts
FORMS+= fetmainform_template.ui \
+ addactivityform4.ui \
helpaboutform_template.ui \
teachersstatisticsform_template.ui \
subjectsstatisticsform_template.ui \
@@ -751,7 +752,6 @@
helptipsform_template.ui \
helpinstructionsform_template.ui \
activitiesform_template.ui \
- addactivityform_template.ui \
modifyactivityform_template.ui \
\
subactivitiesform_template.ui \
Delete
addactivityform_template.ui
Indeed, Corfiot, you are right, converting is easier than I thought. I see that the conversion keeps the custom connections - I thought this was not possible. But it would be also elegant to get rid of Qt 3 classes (like Q3GroupBox). Also, I fear the custom connections might be lost in some cases, I am not sure. I'll read about that in Qt documentation.
Link:
http://doc.trolltech.com/4.4/porting4-designer.html
Quote:
Converting Qt 3 .ui files to Qt 4 has some limitations. The most noticeable limitation is the fact that since uic no longer generates a QObject, it's not possible to define custom signals or slots for the form. Instead, the programmer must define these signals and slots in the main container and connect them to the widgets in the form after calling setupUi(). For example:
This is what I fear. Maybe your conversion is not perfect and connections may be lost.
yes, if you just save it as v4 from the designer. But read what the docs say right after:
A quick and dirty way to port forms containing custom signals and slots is to generate the code using uic3, rather than uic. Since uic3 does generate a QWidget, it will populate it with custom signals, slots and connections specified in the .ui file. However, uic3 can only generate code from Qt 3 .ui files, which implies that the .ui files never get translated and need to be edited using Qt Designer 3.
I'm using uic3. but I can edit the form in qtdesigner4, too. Yep, it's in v4 format.
Concerning the slots, I used the multiple inheritance method so the events work ok because all the event code is untouched and I reused your cpp of the implementation of the slots.
I tried the direct method first but that displayed a blank form, which is what happens when signals dont work. So now the dialog is working ok as far as I can tell.
--G
Quoteyes, if you just save it as v4 from the designer. But read what the docs say right after:
A quick and dirty way to port forms containing custom signals and slots is to generate the code using uic3, rather than uic. Since uic3 does generate a QWidget, it will populate it with custom signals, slots and connections specified in the .ui file. However, uic3 can only generate code from Qt 3 .ui files, which implies that the .ui files never get translated and need to be edited using Qt Designer 3.
I'm using uic3. but I can edit the form in qtdesigner4, too. Yep, it's in v4 format.
I am using this trick for current FET. That is why you need Qt 3 Designer to open them.
Quote
Concerning the slots, I used the multiple inheritance method so the events work ok because all the event code is untouched and I reused your cpp of the implementation of the slots.
I tried the direct method first but that displayed a blank form, which is what happens when signals dont work. So now the dialog is working ok as far as I can tell.
--G
The dialog is blank because you didn't call "setupUi(this)".
You don't need qt3 designer to open the one I converted. It's qt4 designer compatible.
Also, the form had its components, just not the data in the lists (the constructor and generally the implementation was not hooked up). But that is irrelevant, it's working for me with the patch I mentioned. As I said, I added activities with my build.
I meant that using the trick Qt describes keeps the form in Qt 3. If you update it to Qt 4, then they say that you need to rewrite all custom slots and connections. That's the official explanation, although it seems that this step is not necessarily needed. But I am afraid there might be some problems.
No it doesn't. It keeps the Qt3 classes but the form is turned into QT4. I did the "uic3 -convert". I then applied the patch, qmake, make and it all works. I can edit the form in qt designer 4.
In ui_addactivityform4.h, which is automatically created by uic, I see the SLOTS being connected:
QObject::connect(forceAdjacentCheckBox, SIGNAL(toggled(bool)), AddActivityForm_template, SLOT(activityChanged()));
QObject::connect(nStudentsSpinBox, SIGNAL(valueChanged(int)), AddActivityForm_template, SLOT(activityChanged()));
QObject::connect(active8CheckBox, SIGNAL(toggled(bool)), AddActivityForm_template, SLOT(activityChanged()));
QObject::connect(active7CheckBox, SIGNAL(toggled(bool)), AddActivityForm_template, SLOT(activityChanged()));
QObject::connect(active6CheckBox, SIGNAL(toggled(bool)), AddActivityForm_template, SLOT(activityChanged()));
QObject::connect(active5CheckBox, SIGNAL(toggled(bool)), AddActivityForm_template, SLOT(activityChanged()));
QObject::connect(active4CheckBox, SIGNAL(toggled(bool)), AddActivityForm_template, SLOT(activityChanged()));
QObject::connect(active3CheckBox, SIGNAL(toggled(bool)), AddActivityForm_template, SLOT(activityChanged()));
I suspect their tool is more up-to-date than the actual instructions.
I worry about problems, too but because it's the GUI, it's easier to fix since problems are usually easy to see. I am thinking of converting some more forms to test more.
Any suggestions as to which to do first?
Yes, you are right, but still I am afraid. Because some problems might arise and users might find a useless menu.
The correct way would be to take all custom slots and connections and add them in the C++ code (for example in addactivityform.cpp). This is why I consider this very complicated, as there are about 300 files to modify. I'll think about it, anyway. I am not afraid of work, but I am afraid that I might do some hidden bugs and people would have big problems and very few people actually report bugs, most will abandon FET.
I do not have any of order of preference.
Why would you want to do that? The whole point of using the designer is to get away from adding the code manually. Slots and signals in our case are a almost completely a GUI-side issue anyway (buttons and so on), so I don't see any benefit in having signal/slot code separate from the forms themselves. Why not have them automatically generated?
Naturally, if you are using slots and signals between actual internal objects to share data/state, we should keep those away from the forms.
I was thinking to convert all the forms this way so we can get rid of the qt designer 3.3 requirement. Then we can decide if we want to actually replace the qt3 components on the forms on a form by form basis, as needed. I just want to be able to work on forms in win32.
I want the simplest way. But adding custom connections into a Qt 4 form is officially (described in Qt 4 help) impossible, the correct way is to add custom slots and connections in the code. That is what they say. You found a working solution, but I think it is not a perfect way and editing some forms might loose connections, which is disatruous.
I'll think about converting in the perfect way. I'll try to think about it.
More details: open a converted file with Qt 4 Designer. See connections. If you click or double click on a custom slot, the Designer writes there "<slot>", so it does not recognize the slot. The correct way is to write in the C++ code, like I wrote previously.
I'll think about converting the correct way, but I am not sure I'll be able to do it soon.
Ah thanks, I see now. If you don't touch the events they are fine though. You can add and edit components as normal. You can also edit the XML of the ui file manually if you really get stuck :-p
I think I can do this conversion and we can decide on doing it 100% properly on a per form basis. I think we need to do this conversion so the UI can be more easily worked on.
If I do this first step for all forms, will you consider merging it into main? After testing of course.
In the meantime I'll investigate how hard it is to put the CONNECT statements into the CPP. I suspect it's a cut and paste deal.
--G
OK, so you really want this conversion done :-)
I have to tell you that I am a bit afraid to let others do this job, because of possible bugs. I will think about it and maybe I'll do that myself in the near future. Maybe you'll offer to test all the functions of the new version.
I prefer to do that myself, to avoid any possible problems (like the problem you didn't notice, with the custom slots).
Yes, it is a problem of cut+paste, but there are 300 files to modify :-)
I'll start now to look over the code.
Well I don't NEED this as a user. I want to improve my Qt skills and help you out. Not to make you do more work. I just find it interesting :-)
OK, I see, but it is a very high responsibility and I have to supervise :-)
It is a bit of work, maybe a few days, but more people asked me about Qt 3 for Windows (not free), and also I know that someday Qt 3 might disappear from the usual tools, so this is a must-do, indeed.
Maybe you'll want to check my changes, it is similar to changing the code. Do you know the tool kdiff3? Also, running and checking all the buttons (which I hate :-) ).
There is also another aspect: I'll keep Qt 3 classes (like Q3ListBox and Q3Table and Q3GroupBox). This is not very nice, but too many changes are needed to correct that. And I see that Qt Designer 4 has these classes available.
If you want to supervise I can send you patches and you can use any tool you wish to compare. I know kdiff, it's like any diff tool, I sent you a patch using the svn version of diff already :-p
I can commit to converting all forms (the first step).
I cannot fully commit to doing the "proper" conversion yet, I need to research this more. I'll tell you about this later.
I cannot fully commit to pressing ALL the buttons but I can use my builds for my department schedule for october, beginning next week or so. So I will do everything in my dev builds. This should cover at least the basic forms (activities,rooms,most time/space constraints). I can also fiddle a bit with each form I convert to see if the buttons work etc.
So, think on it and tell me what you want done or not.
I found one important thing: in tmp/addactivityform_template.h, there are all 41 needed connections, written exactly as they should be added in the C++ form addactivityform.cpp. So, indeed a matter of copy/paste. I just need to remove the custom connections in the Designer 4 code.
I intend to keep the same name for the forms, so addactivityform_template.ui for designer 4 form. I am not sure, should I rename it addactivityform.ui?
QuoteIf you want to supervise I can send you patches and you can use any tool you wish to compare. I know kdiff, it's like any diff tool, I sent you a patch using the svn version of diff already :-p
I can commit to converting all forms (the first step).
I cannot fully commit to doing the "proper" conversion yet, I need to research this more. I'll tell you about this later.
I cannot fully commit to pressing ALL the buttons but I can use my builds for my department schedule for october, beginning next week or so. So I will do everything in my dev builds. This should cover at least the basic forms (activities,rooms,most time/space constraints). I can also fiddle a bit with each form I convert to see if the buttons work etc.
So, think on it and tell me what you want done or not.
Yes, but comparing the code is easy, while comparing the designer files by content is difficult. There might be hidden errors.
Let me see a bit how the conversion works. I'll let you know. It may be only a matter of 2 days, I am not sure.
Thinking about it, it is maybe better to use shorter names for the forms, like addactivityform.ui. This way, we know that it is a Qt 4 form.
Let me try a bit and I'll let you know. If I can check your changes one by one, I'll think about letting you do some changes. But as I told you, to compare the old ui file with the new one is very difficult with a text comparing tool.
I am sorry if I were too negative to you, Corfiot :-(
I attach the first converted files (you need to rename t.tar.gz, the forum makes them t_tar.gz, incorrectly, then unpack). I'll think about making the whole process. But I am very afraid of introducing new bugs. Everything must be tested. And the current period is very important, because now the schools are making their timetables.
You're not negative. You are cautious and it is good. I have always been the person who is the bravest with changes in all dev teams I have worked in. I get away with it because any bugs I cause, I fix :-p. It scares the hell out of everyone else, though.
There is no point comparing the old .ui files to the new ones as they are totally different. We just have to trust uic3 to do the conversion properly. And test.
As for the names, YES!, make them shorter like I did for the addactivityform. So we get three files with the same name and 3 extensions (.h .cpp .ui). We should update the .pro as well. I attach your files with the names changed and the new .pro so you can check. This builds and the forms seem to work. I see you cleaned up some text, too :-D
Finally, making changes does not mean we have to merge them into the main dev code right away. I would suggest we wait until the critical period has passed, if you are worried about bugs. Besides, there are SO MANY forms it will take us time. I am keeping track of the code changes on a repository so we can do it gradually and in parallel with other things.
I am not going to be working full time on this like I am now, especially after the semester starts. So we should lay back and take it easy. I know you prefer working on the algorithm :) Get some sponsored work done and let me worry about this grunt work, after we agree on the method and test one or two forms to be sure.
Maybe we should test an add, a delete and a modify, too.
I want to keep old name, activitiesform_template.ui, because the name of the class is ActivitiesForm_template.
I have a good news: after a few hours of hard work, I am maybe done with about 1/4 or 1/5 of the work. I think that in at most 2 days I will be ready. I'll give you exact advice on how to test me. There will be source code testing and practical testing.
um ok, so what do i do? Nothing?
:-) No, I won't let you do nothing. I'll put you to do many tests. And testing means verifying slots and connections from old code to new code, and playing with the interface (each function must be tested).
You'll browse the sources, don't worry :-)
I did the change. Everything must be tested. See global announcement for details: --missing link--