Adding UI elements to a form is not propagated to the code
-
The link above talks about setting up a new designer file and consuming it in a new application, so it seems.
My application already has a .ui file and it is already included in the <form name>.h
I presume that this follows "direct approach".
So my assumption is that changes in <formname>.ui should reflect in ui_<formname>.h at some point. What has to be done for the changes to .ui to propagate to the .h?@In-Fo Usually changes are propagated instantly. It is my experience though, that (especially on macOS, less often on Windows) with larger codebase to work with whatever background process responsible runs there providing the service seems to be laggy. My simple solution - build the form again enforcing rebuilding of ui_(...).h file.
I never considered it a problem serious enough to search for any kind of solution. -
I think I get it.
There are 2x ui_.h files under my project.
The new one is being generated as ui_newform.h
The old one included in the project is ui_newForm.h
Needless to say that the class name is actually newForm.
This is why the changes I am trying to introduce are not visible in the project.
It is a bug somewhere that butchers the class name. -
Yes, turns out that Makefile and compile_commands.json had a mix and match of newForm with newform. It does not matter under Windows but under Linux this leads to a ton of frustration. Qt Creator and qmake developers should be more careful by being mindful of case sensitivity of UNIX flavors vs Windows.
-
Whatever you found I think your conclusions are in error. Windows run on case sensitive system for about 20 years now (starting with XP, when NTFS 5.1 became a standard).
I run through all my projects using UI on both Windows and macOS (where I have case sensitive FS as well), in every single case header file filename conforms to the ui filename following the patternui_[caseSensitiveClassName].h.
I have no idea why this doesn't seem the case with your project but if it is Qt then it is limited to your particular configuration. -
@artwaw said in Adding UI elements to a form is not propagated to the code:
Whatever you found I think your conclusions are in error.
They are not. You are confusing case-sensitive-friendly filesystems with case sensitivity of file operations.
In Windows, go to an empty directory or create a new one.
Then issue the following commands:echo 1 > ui_newForm.h
echo 2 > ui_newform.hWhat does ui_newForm.h now contain, 1 or 2? It contains 2 because for Windows, both files are one and the same, and you still have only 1 file: ui_newForm.h, whereas ui_newform.h is nowhere to be found.
Now, try the same commands in Linux. You will end up with 2x different files with different contents.
-
@artwaw said in Adding UI elements to a form is not propagated to the code:
Whatever you found I think your conclusions are in error.
They are not. You are confusing case-sensitive-friendly filesystems with case sensitivity of file operations.
In Windows, go to an empty directory or create a new one.
Then issue the following commands:echo 1 > ui_newForm.h
echo 2 > ui_newform.hWhat does ui_newForm.h now contain, 1 or 2? It contains 2 because for Windows, both files are one and the same, and you still have only 1 file: ui_newForm.h, whereas ui_newform.h is nowhere to be found.
Now, try the same commands in Linux. You will end up with 2x different files with different contents.
-
Yes, turns out that Makefile and compile_commands.json had a mix and match of newForm with newform. It does not matter under Windows but under Linux this leads to a ton of frustration. Qt Creator and qmake developers should be more careful by being mindful of case sensitivity of UNIX flavors vs Windows.
@In-Fo said in Adding UI elements to a form is not propagated to the code:
Qt Creator and qmake developers should be more careful by being mindful of case sensitivity of UNIX flavors vs Windows.
No, you should simply care on windows for such stuff too. QtCreator even warns about such wrong includes.
-
@Christian-Ehrlicher said in Adding UI elements to a form is not propagated to the code:
QtCreator even warns about such wrong includes.
It has certainly neglected to warn me. What is the mechanism that it should warn through?
-
@Christian-Ehrlicher said in Adding UI elements to a form is not propagated to the code:
QtCreator even warns about such wrong includes.
It has certainly neglected to warn me. What is the mechanism that it should warn through?
@In-Fo The clang code model will underline the include statement
-
After almost two cruelling months of using QtCreator / QtDesigner I feel an urge to contribute to this "holy war".
I will admit UP FRONT - I do not RTFM BEFORE i code - besides most of the doc are cookie cutters / repetitive and GENERALLY lack good examples - especially for QtDesigner. ( YES i picked Qt for GUI application. )So here is my "contribution" -
implement "connect" in QtDesigner and then find it in YOUR code!
Implement "SLOT" and associated "SIGNAL" then muddle thru the code...
Don't "connect" SLOT and SIGNAL belong to the SAME family to accomplish the task ?
But it is not only "connectivity" which is a big stumbling block in learning to use Qt, it is the lack of comprehensive explanation on how things interact. My favourite .pro "file" etc. ( I have brought this subject on before - so I won't repeat it here.)Cheers END OF RANT
-
After almost two cruelling months of using QtCreator / QtDesigner I feel an urge to contribute to this "holy war".
I will admit UP FRONT - I do not RTFM BEFORE i code - besides most of the doc are cookie cutters / repetitive and GENERALLY lack good examples - especially for QtDesigner. ( YES i picked Qt for GUI application. )So here is my "contribution" -
implement "connect" in QtDesigner and then find it in YOUR code!
Implement "SLOT" and associated "SIGNAL" then muddle thru the code...
Don't "connect" SLOT and SIGNAL belong to the SAME family to accomplish the task ?
But it is not only "connectivity" which is a big stumbling block in learning to use Qt, it is the lack of comprehensive explanation on how things interact. My favourite .pro "file" etc. ( I have brought this subject on before - so I won't repeat it here.)Cheers END OF RANT
Out of curiosity, did you have a fairly good understanding and experience in C++ before picking Qt?
-
@In-Fo The clang code model will underline the include statement
@Christian-Ehrlicher
Which include statement? Do you seriously expect all developers scan 100% of our projects for something underlined, after running into a problem like above?
Bottom line is that if an IDE auto-generates (itself) or outsources auto-generation of some internal files to another tool (that is a part of vendor's toolchain) then both have to be mindful of the platforms that they claim to multiplatform on.Qt claims to be multiplatform but it is not mindful of the case sensitivity of files that it auto-generates behind the scenes. How do you envision developers in a teem cooperating from Windows and Linux machines, when the same project that they work on has incompatible auto-generated files, like in my case?
If a form class is camel-cased, tools on either platform must obey camel-casing and auto-generate files consistently. Is this too much to ask for?
-
It's your task to use the correct camel casing for all files. If you add a wrong include statement it's your fault. I don't see where the tools can help you here. It's as simple as using a wrong camel cased class name like Qdialog instead QDialog.
I still don't have a valid case where you hit a problem though... -
Only if I create those files myself. If Qt Creator auto-generates them based on the class name of the file that I create, it is not my responsibility.
Auto-generated files have to be named correctly by the tool that auto-generates them. It should not be the responsibility of the tool's user to double-check that it does its job properly.
When the tool auto-generates files with the correct name sometimes, or only on some OS's but not on others, it is not fulfilling its stated purpose.I'll repeat: the file's name changed along the lifetime of the project from the one that matched the underlying class's name to the one that no longer matches it. None of the developers has visibility into the name that the tool uses behind the scenes to auto-generate that file. It is probably not productive to blame me for that. The tool has to work consistently across all platforms that Qt Creator claims to support.
-
Only if I create those files myself. If Qt Creator auto-generates them based on the class name of the file that I create, it is not my responsibility.
Auto-generated files have to be named correctly by the tool that auto-generates them. It should not be the responsibility of the tool's user to double-check that it does its job properly.
When the tool auto-generates files with the correct name sometimes, or only on some OS's but not on others, it is not fulfilling its stated purpose.I'll repeat: the file's name changed along the lifetime of the project from the one that matched the underlying class's name to the one that no longer matches it. None of the developers has visibility into the name that the tool uses behind the scenes to auto-generate that file. It is probably not productive to blame me for that. The tool has to work consistently across all platforms that Qt Creator claims to support.
@In-Fo said in Adding UI elements to a form is not propagated to the code:
Only if I create those files myself. If Qt Creator auto-generates them based on the class name of the file that I create, it is not my responsibility.
The class name has nothing to do with the generated file, which is also in the docs mind you. The
.uiform file's nameuicuses exactly as a name to generate the header file. That is:myFormName.ui >> ui_myFormName.hThe include:
#include "ui_myformname.h"works on windows (but not on linux), just because windows is case-aware, but case-insensitive. It is not the fault of the toolchain for a decision made by the os vendor a long, long time ago, be it that good or bad. If you have had the file generated once and only then changed to camel-case name the OS, the toolchain or anything that uses the OS's API can't distinguish, so
uicoverwrites the file with the old name ... solution is to simply remove the old file and re-generate it, that's your job though, no automation can do anything 'bout it. -
Out of curiosity, did you have a fairly good understanding and experience in C++ before picking Qt?
@kshegunov said in Adding UI elements to a form is not propagated to the code:
Out of curiosity, did you have a fairly good understanding and experience in C++ before picking Qt?
Wrote my first program in 1973 - in assembly.
Wrote couple of C programs in 1987 - before Windows .
Was Q&A analyst for Visual Basic software ...
NO, I do not have a foggiest idea about programming... -
@Christian-Ehrlicher
Which include statement? Do you seriously expect all developers scan 100% of our projects for something underlined, after running into a problem like above?
Bottom line is that if an IDE auto-generates (itself) or outsources auto-generation of some internal files to another tool (that is a part of vendor's toolchain) then both have to be mindful of the platforms that they claim to multiplatform on.Qt claims to be multiplatform but it is not mindful of the case sensitivity of files that it auto-generates behind the scenes. How do you envision developers in a teem cooperating from Windows and Linux machines, when the same project that they work on has incompatible auto-generated files, like in my case?
If a form class is camel-cased, tools on either platform must obey camel-casing and auto-generate files consistently. Is this too much to ask for?
@In-Fo said in Adding UI elements to a form is not propagated to the code:
Qt claims to be multiplatform but it is not mindful of the case sensitivity of files that it auto-generates behind the scenes.
If a form class is camel-cased, tools on either platform must obey camel-casing and auto-generate files consistently. Is this too much to ask for?
When the tool auto-generates files with the correct name sometimes, or only on some OS's but not on others, it is not fulfilling its stated purpose.
I'll repeat: the file's name changed along the lifetime of the project from the one that matched the underlying class's name to the one that no longer matches it.
Are you able to reproduce the "file's name changed along the lifetime of the project"? So far as I am aware, the only time Qt Creator auto-generates a filename is when you add a new class via the wizard, and at that point it makes the case of the filename all lower case, at least under Linux presumably so case is consistent. If you then, for example, change the spelling of the class name without doing it via Creator's Rename they may get out-of-sync.
-
@kshegunov said in Adding UI elements to a form is not propagated to the code:
Out of curiosity, did you have a fairly good understanding and experience in C++ before picking Qt?
Wrote my first program in 1973 - in assembly.
Wrote couple of C programs in 1987 - before Windows .
Was Q&A analyst for Visual Basic software ...
NO, I do not have a foggiest idea about programming...@AnneRanch said in Adding UI elements to a form is not propagated to the code:
@kshegunov said in Adding UI elements to a form is not propagated to the code:
Out of curiosity, did you have a fairly good understanding and experience in C++ before picking Qt?
Wrote my first program in 1973 - in assembly.
Wrote couple of C programs in 1987 - before Windows .
Was Q&A analyst for Visual Basic software ...
NO, I do not have a foggiest idea about programming...None of which is actually an answer to my question. But doesn't matter, there's no need for the snide remarks, I did only ask out of curiosity.
@JonB said in Adding UI elements to a form is not propagated to the code:
Are you able to reproduce the "file's name changed along the lifetime of the project"? So far as I am aware, the only time Qt Creator auto-generates a filename is when you add a new class via the wizard, and at that point it makes the case of the filename all lower case, at least under Linux presumably so case is consistent.
This is for sources/headers/form files/resources etc. In any case there's the option to correct the file name before creating the file. Here it's about the
ui_<formname>.hwhich is generated by theuic.
