In Qt, it is possible to specify an Info.plist file to use when building on Mac, as follows:
QMAKE_INFO_PLIST = MyInfo.plist
This replaces the Qt auto-generated Info.plist file with another one.
Rather than replace Qt's auto generated one entirely, is it possible to add individual entries?
I don't think it will make little practical difference but I'd like to be able to do it because I feel it would be "tidier" to just add the additional items I want rather than brutally replace the whole file.
Unfortunately this is impossible. But Qt makes your life easier with some variables that you can use in plist file. From Qt documentation:
In the .plist file, you can define some variables, e.g., #EXECUTABLE#,
which qmake will replace with the actual executable name. Other
variables include #ICON#, #TYPEINFO#, #LIBRARY#, and #SHORT_VERSION#.
Find a file named 'Info.list.app'. This is the template of Info.list. You can use it as a start point and append you own entries. It is typically location like Qt5.7.0/Src/qtbase/mkspecs/macx-ios-clang/Info.plist.app in your QT root dir.
See Qt documentation for more detail.
Related
I've written an Extension that, among many other things, renames files based on the Types they contain.
This works fine for files in the directory-tree under the csproj-file -- I find the ProjectItem entry for the file and change its name.
For 'linked'-files (those not in the directory-tree) I can rename the file (via File.Move()) but haven't found a way to programatically modify the csproj-file (after the rename the csproj-file has to be modified manually).
If this is something that can be done I'd appreciate a pointer to the docs showing how to implement the functionality.
The easiest solution for me was to modify the csproj-file.
Open, read whole file, close.
Verify that file I want to rename (e.g. xxx.cs) only occurs in 1 directory
(if it occurs in multiple directories the change has to be done manually.)
Make change
Open, write whole file, close
For an SDK project the change is applied immediately.
For a non-SDK project the change is applied after responding to the prompt that the csproj-file has been modified.
I just wondered if there was a way to forward-declare a class in a Qt UI file. The issue that I have is that I use (the same version of) a same widget in two different projects : a project that uses the widget and an independant project that allows me to do testing with this widget while I'm working on its features.
Now, what happens is that when uic generates the ui_widget.h file, it adds this in it:
#include "widgets/custom_line_edit.h"
That's the include path for one of my promoted widgets. The thing is that the path to this file is not the same on the "real" project, as it should be
#include "modules/this_module/widgets/custom_line_edit.h"
I don't really know what to do not to have to edit my UI file each time to match my "current" project's file organization.
I've found this which was quite satisfying:
It is sometimes necessary to forward declare classes, particularly if code is being written in .ui.h files within Qt Designer. Each forward declaration is listed as it should appear in the generated C++ code.
<forwards>
<forward>class QStringList;</forward>
</forwards>```
But unfortunately this documentation is quite old (Qt 3.3) and the syntax seems not to work anymore - I get an Error 1.
What are my options here?
The issue isn't one of forward declarations. I've never seen that "forward" mechanism in a UI file, but even it still works somehow, all that it does is put "class QStringList;" (or whatever) in the include file that uic generates. If you look at those include files, they will have "new SomeWidget ()" statements, and you can't create an object without its full declaration, so a forward declaration for something the UI file creates isn't helpful.
The UI definition needs the include file where the widget is defined for exactly that reason. It has to include the class definition in the file generated from uic, and the relationship between where the files reside is going to have to be consistent.
What I would do to solve this is put the widget(s) in a library, and then reference the library from my main application and my test application. Then the uic generation happens within the library, not the applications, and within the library, the relative locations of the files will remain constant. The applications don't need access to the .ui file nor the generated include file, so how the application source files are laid out in folders won't matter.
I don't see any other way to do this.
i have this tree structure:
repository/modules/module1
repository/modules/module2
repository/modules/module..
repository/apps/application1
repository/apps/application2
repository/apps/application..
where the applications are using some modules.
now, I'd like to put some resources inside a module (like a very colorfull icons inside a widget used by several applications) but.. something gets wrong.
inside the module CMakeLists.txt if I use only:
set(${MODULE_NAME}_RCS
colors.qrc
)
...
qt4_add_resources (${MODULE_NAME}_RHEADERS ${${MODULE_NAME}_RCS})
no qrc_colors.cxx are created anywhere. so I've tried to add:
ADD_EXECUTABLE (${MODULE_NAME}
${${MODULE_NAME}_RHEADERS}
)
but.. I get this weird error:
CMake Error at repo/modules/ColorModule/CMakeLists.txt:51 (ADD_EXECUTABLE):
add_executable cannot create target "ColorModule" because another
target with the same name already exists. The existing target is a static
library created in source directory
"repo/modules/ColorModule". See documentation for
policy CMP0002 for more details.
(I've changed the path of the error of course)
so.. don't know what to think because i'm new both to cmake and qt..
what can i try?
EDIT:
if I add the ${MODULE_NAME}_RHEADERS and ${MODULE_NAME}_RCS in the add_library command the qrc_colors.cxx is created BUT it is in repository/modules/module1/built and not copied in the application built directory...
There is at least two errors in your code.
1) It is usually not necessary to use ${MODULE_NAME} everywhere like that, just "MODULE_NAME". You can see that the difference is the raw string vs. variable. It is usually recommended to avoid double variable value dereference if possible.
2) More importantly, you seem to be setting ${MODULE_NAME} in more than one executable place, which is "ColorModule" according to the error output. You should have individual executable names for different binaries.
Also, the resource file focus is a bit of red herring in here. There are several other issues with your project.
You can cmake files as CmakeLists.txt instead of CMakeLists.txt which inherently causes issues on case sensitive systes as my Linux box.
You use Findfoo.cmake, and find_package(foo) for that matter, rather than the usual FindFoo.cmake convention alongside find_package(Foo).
Your FindFoo.cmake is quite odd, and you should probably be rewritten.
Most importantly, you should use config files rather than find modules.
Documentation and examples can be found at these places:
http://www.cmake.org/Wiki/CMake/Tutorials#CMake_Packages
https://projects.kde.org/projects/kde/kdeexamples/repository/revisions/master/show/buildsystem
When you would like use a find module, you need to have that at hand already. That will tell you what to look for, where things are, or if they are not anywhere where necessary. It is not something that you should write. You should just reuse existing ones for those projects that are not using cmake, and hence the find modules are added separately.
It is a bit like putting the treasure map just next to the treasure. Do you understand the irony? :) Once you find the map, you would automatically have the treasure as well. i.e. you would not look for it anymore.
Here's my problem: We've got .ts files for nine different languages for our product. We've added about 100 new strings that need to be translated, but some are for our next release, and some are for the release after that. We've run into problems with translators missing strings or translating strings ahead of time. We want to be able to send them smaller .ts file containing only the strings we want translated now, and then merge that .ts file into the larger .ts file containing the rest of the translation.
Our translators are required to use QT Linguist (previously we let them edit the raw XML with less than stellar results).
One solution would be to use contexts, but our dev team is not very keen on that idea. Another would be to merge the .ts files by hand, but that seems like a recipe for cut & paste errors.
Is there a method with lupdate & the project file to add or merge secondary .ts files? I've read through the forums in QT-land w/o finding the answer, but the switches in lupdate allude to being able to point to other translation files. Specifically the -pro switch which says:
-pro <filename>
Name of a .pro file. Useful for files with .pro file syntax but
different file suffix. Projects are recursed into and merged.
Example1: we have a German .ts file, we want to add 20 strings from a separate German translation file such that the primary translation file contains all the strings including the 20 new ones.
Example2: we have a German .ts file, we want to add 20 strings from a separate German translation file such that the secondary translation file will be merged with the primary during lupdate so that the resultant .qm file contains all the strings including the 20 new ones.
Has anyone done either of these (and either would work) and can you give me some insight?
The answer doesn't use lupdate, it lies in another utility called lconvert. It's quite easy to create a secondary file that only contains the strings you're interested in (and delete those same strings from the primary file), then run:
lconvert -i primary.ts secondary.ts -o complete.ts
This will take all the strings from the two input files and put them together into the output file. Using this method I was able to create a zero difference file (other than time stamp) of the original file that I'd split the two primary & secondary files from.
This question didn't get a lot of attention, but maybe someone will have this same problem and this will help.
thanks for this tip. It seems to work properly for my case :
I tried to extract updated and new strings from my project, which is currently under translation in an older version/release that I do not already have translated strings.
The problem was to send the new/updated strings only to translators.
I passed older strings in status resolved, adding new string using Lupdate, make a research using OxygenXML Editor with an XPath "/TS/context/message[not(translation/#type)]" to delete older strings, and clean it from useless blanks and carriage returns.
I tried a merge using lconvert with your solution, in order to merge translated strings : older and newer. It pass correctly lrelease and are displayed properly.
When working with cmake, is it better to work with one large CMakeLists.txt in the root of the project, or as seems to be seen in some places, having one in each subdirectory too?
I would assume something along the lines of for large projects, having one in each directory is better.
If so, where should the threshold be?
I would certainly go for using multiple CMakeListst.txt files.
As a rule of thumb I think you should go for one CMakeLists.txt (and thus subdirectory) per target. So, each library or executable has its own CMakeLists.txt.
You can then create one "master" CMakeLists.txt that includes all the others using the add_subdirectory call. If you take care that you order these statements correctly, you can easily reference previously defined targets in the other CMakeLists.txt file.