When *.ui files are saved, they generate an *.h file which defines and implements a translation method "retranslateui()" which uses a QApplication::translate call where the context for the translation equals the UI class name.
I need to be able to override that and put in my own custom context name.
The reason if you must know is that we have a non-QT legacy translation tables, with 14 languages. I built a tool that translates those strings into a *.TS file. The problem is, there IS NO CONTEXT, it's just a flat list of strings, so my tool forces one context for my entire application. The automatic generation of translate method calls where the context = the UI class name fails my ui translation.
I found that the UIC command line utility, creating this *.h file from the *.ui file has a parameter to define a different translation method. I can use this to route to my own translation method that'll add on the single context. My problem is that I can't find out how to change the UIC call from qmake to include this parameter with a custom value.
You can modify QMAKE_UIC property in your .pro file
QMAKE_UIC += -params to add
Related
I've created a small application. The GUI is ugly, I've done it quickly. I've created a ui.qml file with Qt Design Studio.
My question is : is it simple to use my ui.qml file instead of my ui file ? I mean, do I have to change all my code when I call ui->ComponentName ?
I tried to understand how ui.qml files works, but it seems it's a completely different way to use component in C++ files than ui files..
Depending on the build system you are using, files ending with .ui are used by autouic to generate C++ code that you can call to create your user interface, usually from the constructor of your class that will be the parent for those components.
This is done by calling setupUi on the member variable 'ui', which is the same class name as the parent class, just under the Ui namespace.
QML code is interpreted, however, and can be read by QQmlApplicationEngine. You can expose properties with setContextProperty, taking a QString and a QObject*, as explained further here: https://doc.qt.io/qt-6/qtqml-cppintegration-exposecppattributes.html#exposing-methods-including-qt-slots
I have a class with following constructor: MyClass(QFile& file);. I want to unit-test it with Qt Test framework. How do I specify content of the file from a unit-test (without actually creating a real file)?
Qt lupdate and QTranslator group source strings into exclusive contexts. This means that a translation defined in one context will not be accessible within a different context.
The default context inside C++ is the name of a class that has overridden QObject::tr(). The default context inside declarative QML is the current filename without extension. To override the translation context, one would use qApp->translate( "context", "source" ) or qsTranslate( "context", "source" ) in C++ or QML.
I want to be able to use a single common translation context across a large project and I am finding that specifying the translation context with every single translation function is very tedious. Is there any existing or future Qt translation framework extensions that would simplify this task? I am looking for something that would be as simple as tr( "source" ) and qsTr( "source" ), but use a system-wide or project-wide default context. Any ideas?
You could use the Q_DECLARE_TR_FUNCTIONS() macro applied to a class definition that acts solely as a context:
class CONTEXT_CLASS {
Q_DECLARE_TR_FUNCTIONS(CONTEXT_CLASS)
};
where CONTEXT_CLASS could be as short as you'd like, let's say X (hoping that doesn't conflict with anything else in your code). That would make your tr() statements
X::tr("source");
Don't try to #define something to shorten X::tr, as that won't get picked up by the translation tool.
There's something easier than that. Use qtTrId/qsTrId (Qt/QML) instead of tr/qsTr and add the -idbased parameter to your lrelease calls. ID based translation has no context at all.
when I compile some .py codefiles with no class definitions into dlls , the compiled dll is created with a "DRLCachedCode" class inside. Why is that?
When you compile IronPython code it doesn't get compiled to normal .NET code where you'd have a class at the IL level for each class you have at the source level. Instead it gets compiled into the same form that we compile to internally using the DLR.
For user code this is just a bunch of executable methods. There's one method for each module, function definition, and class definition. When the module code runs it executes against a dictionary. Depending on what you do in the module the .NET method may publish into the dictionary a:
PythonType for new-style classes
An OldClass for old-style classes
A PythonFunction object for function
definitions
Any values that you assign to (e.g.
Foo=42)
Any side effects of doing exec w/o providing a dictionary (e.g. exec "x=42")
etc...
The final piece of the puzzle is where is this dictionary stored and how do you get at it? The dictionary is stored in a PythonModule object and we create it when the user imports the pre-compiled module and then we execute the module against it. Therefore this code is only available via Python's import statement (or the extension method on ScriptEngine "ImportModule" which is exposed via IronPython.Hosting.Python class).
So all of the layout of the code is considered an internal implementation detail which we reserve the right to change at any point in time.
Finally the name DLRCachedCode comes because the DLR (outer layer) saves this code for us. Multiple languages can actually be saved into a single DLL if someone really wanted to.
This link answers the question: http://www.ironpython.info/index.php/Using_Compiled_Python_Classes_from_.NET/CSharp_IP_2.6 how to access an IronPython class from C#.
Manual compilation: \IronPython 2.7\Tools\Scripts>ipy pyc.py /out:MyClass /target:dll MyClass.py did not work. Only when I used SharpDevelop with IronPython it worked as in the post.
In my flex app there are a few custom components. I want to create instance of these components at runtime and assign them properties by reading in a config file.
I know how to read xml and instantiate components, however my question is about being able
to get the type of the component from the xml attribute and then creating an instance of that type.
My xml looks like this:
You can instantiate an arbitrary named type through ActionScript's "reflection API":
var clazz:Class = Class(getDefinitionByName("class.from.your.xml.file.Name"));
var component:Object = new clazz();
http://livedocs.adobe.com/flex/3/langref/flash/utils/package.html#getDefinitionByName()
If you get an error about the type not existing, this is because it isn't linked from elsewhere in your application and the compiler only adds classes that are referenced. You can work around this using the following compiler arg:
includes class [...]
Links one or more classes to the resulting application SWF file, whether or not those classes are required at compile time.
http://livedocs.adobe.com/flex/3/html/compilers_14.html#157203