Translating Qt applications - qt

I need to have my application translated into many different languages, I have the translators and know that I can use Qt Linguist. However as far as I can tell I have to package up Linguist myself and ship it out to the translators.
Is there a web-based solution or do other package Qt Linguist with the ts files?

I think you have to package it up yourself. However, while browsing qt-apps.org the other day I did come across Qt Linguist Download which seems to be a packaged version of Linguist designed to address exactly this need. I have not actually used this myself - our translation is done in-house so we have not had this particular issue.

Related

Qt: how to make help system?

I need to provide some help system for my application. The app mostly works on the computers without any Qt installed. I would like to have some way (tool etc) to create the professionally looking help system. I mean I need to provide the regular help system like most applications have. It should look like regular CHM file (with index, search etc.).
I tried to use QtAssistance class, created .adb file but if I run assistance utility, it doesn't know -profile key so I even cannot check if I did this file properly.
I'm a little bit confused because I could see QtAssistant and QHelp classes and I don't know which one is more suitable for my purpose.
Thanks a lot
If you do not care for using Microsofts chm-files, then go ahead and use the QtHelp API - if you are using Qt versions 4.4 or newer. The QAssistant API has been superseded by QtHelp starting with version 4.4, so don't start with old or deprecated interfaces. The QAssistant help files will still be readable from a QtHelp based implementation.
If you do need to read chm files, then a chmlib-based approach with a customized QWebBrowser would be suitable, but I don't think that's what you are looking for.

Where can Qt Creator plugins in binary form be found?

Where can I find plugins for Qt Creator available in binary form?
Because of the diversity of platforms that Qt supports you may be hard pressed to find many plugins in binary form. The Qt developer network does maintain a list of QtCreator plugins here. Some of these may be available in binary formats but since they are plugins for software designed to compile software, it shouldn't be a big problem if you have to build them yourself :)

Gtk+ vs Qt language bindings

Put shortly: For those familiar with language bindings in Qt and Gtk+. E.g. python and ruby. Are there any quality or capability difference?
More background: I know C++ and Qt very well. Minimal experience with Gtk+. I know C++ is not ideal for language bindings due to the lack of a well defined ABI (application binary interface). I also read that Gtk+ was designed to be bound to other languages. So I wonder how this manifets itself in practice. Are the Gtk+ bindings better maintained or work better in some way than their Qt counterparts?
I am presently quite interested in the Go language, and they have started developing Gtk+ bindings. However C++ bindings is far away. It makes me wonder whether learning Gtk+ is worth it.
I've used GTK and Qt in C++ and also PyGTK and PyQt in Python quite extensively.
Qt beats GTK hands down - its a much more flexible, modern and clean API. GTK is also lacking some features that are important to me. From a framework point of view, I'd recommend Qt.
As for langauge bindings (I can only speak about Python, since I've never used the Ruby equivalents), I think PyGTK (using Glade and a wrapper like Padraig Bradys libglade) make GUI programming insanely easy and fun. However, if you can GPL your software (or pay the license fee), then PyQt is also a good option, and while not quite as friendly as PyGTK + Glade (in that with GTK you can define your UI in Glade as a separate XML file, so you can tweak the UI without touching code; in Qt if you want to use QtDesigner, you have to generate code using uic, if I remember correctly) the API itself is really really nice to use and mirrors the Qt frameworks clean design very closely.
Over all, I'd probably recommend using PyQt over PyGTK, but I may be biased since I much prefer Qt over GTK nowadays, though you could try both out and see which you prefer - they are both almost trivial to get working.
If you are looking for a great book on PyQt, I'd recomment Rapid GUI Programming qith Python and Qt.
To summarize: IMHO Qt beats GTK in both quality and capability. Both PyGTK and PyQt are of excellent quality and capability mirrors the underlying framework, though PyGTK can load Glade xml files.
I think that GTK bindings are older than Qt ones (and so a bit more mature) but they are both usable and your previous knowledge of Qt should be the main factor in your choice.
I developed small GUIs using both Qt and GTK with their python bindings and found the two equivalent. Some regrets though on the PyQt bindings with Qt container (QVector, ...) that are not translated into regular python data structure and thus add a bit of complexity to the code. I didn't recall the same issues using PyGTK.
I have worked with both PyQt and PyGTK and I would say they're both regularly mantained and synched with their parent frameworks. However, and this is completely subjective, I found more rewarding working with PyGTK than with PyQt, even if I hadn't previously written any code using GTK. If you know well Qt, go with Qt though.
I have been trying a few combinations around Qt : RubyQt, JRuby + Jambi, PyQt. The first one quickly ends up in various segmentation-faults. My Qt skills may be the problem but all in all the seg faults are not quite readable. The forum for RubyQt is nearly dead so don't expect to find much information there.
So I moved to JRuby + Jambi. This worked until well, I reached some missing functions here and there. Plus I had to implement a proper signal/connect for JRuby. So, more or less a hack. Not convincing.
Finally I moved to Python (wich I don't like very much). But woooh, what a difference. Bindings are up to date, I have still to ecnounter a segmetatio fault, error messages are most of the time very explanatory. So as far as I'm concerned Python+Qt is a clear winner.
Please note that I was trying these combinations in order to find a proper language/qt binding so that I can create a production ready with my commutation hours (roughly 2 hours a day). So my tolerance to small-but-annoying problems such as segmentation faults is 0. I also have to develop on Windows and Linux. So Windows installation is necessary (and once again, Python is a clear winner here).
there are C++ gtk+ bindings. Google for gtkmm.

What is currently the best build system [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
A few years ago I looked into using some build system that isnt Make, and tools like CMake and SCons seemed pretty primitive. I'd like to find out if the situation has improved. So, under the following criteria, what is currently the best build tool:
platform agnostic: should work on windows, linux, mac
language agnostic: should have built-in support for common things like building C/C++ and other static langs. I guess it doesn't need to support the full autotools suite.
extensible: I need to be able to write rules to generate files, like from restructuredText, latex, custom formats, etc. I dont really care what language I have to write the rules in, but I would prefer a real language rather than a DSL.
I would prefer to avoid writing any XML by hand, which I think for example ant requires.
Freely available (preferably open source)
The term "best" is slightly subjective, but I think answers can be rated objectively by the criteria above.
I'd definitively put my vote up for premake. Although it is not as powerful as it's older brothers, it's main advantage is absurd simplicity and ease of use. Makes writing multi-compiler, multi-platform code a breeze, and natively generates Visual Studio solutions, XCode projects, Makefiles, and others, without any additional work needed.
So, judging purely by the criteria set forth in the question, the build system that seems like the best fit is probably waf - pure Python, provides support for C++ and other languages, general, powerful, not a DSL.
However, from my personal experience, I prefer CMake for C++ projects. (I tried CMake, SCons, and waf, and liked them in roughly that order). CMake is a general solution, but it has built-in support for C++ that makes it nicer than a more generic solution when you're actually doing C++.
CMake's build model for C++ is more declarative and less imperative, and thus, to me, easier to use. The CMake language syntax isn't great, but a declarative build with odd syntax beats an imperative build in Python. Of the three, CMake also seems to have the best support for "advanced" things like precompiled headers. Setting up precompiled headers reduced my rebuild time by about 70%.
Other pluses for CMake include decent documentation and a sizable community. Many open source libraries have CMake build files either in-tree or provided by the CMake community. There are major projects that already use CMake (OGRE comes to mind), and other major projects, like Boost and LLVM, are in the process of moving to CMake.
Part of the issue I found when experimenting with build systems is that I was trying to build a NPAPI plugin on OS X, and it turns out that very few build systems are set up to give XCode the exact combination of flags required to do so. CMake, recognizing that XCode is a complex and moving target, provides a hook for manually setting commands in generated XCode projects (and Visual Studio, I think). This is Very Smart as far as I'm concerned.
Whether you're building a library or an application may also determine which build system is best. Boost still uses a jam-based system, in part because it provides the most comprehensive support for managing build types that are more complex than "Debug" and "Release." Most boost libraries have five or six different versions, especially on Windows, anticipating people needing compatible libraries that link against different versions of the CRT.
I didn't have any problems with CMake on Windows, but of course your mileage may vary. There's a decent GUI for setting up build dependencies, though it's clunky to use for rebuilds. Luckily there's also a command-line client. What I've settled on so far is to have a thin wrapper Makefile that invokes CMake from an objdir; CMake then generates Makefiles in the objdir, and the original Makefile uses them to do the build. This ensures that people don't accidentally invoke CMake from the source directory and clutter up their repository. Combined with MinGW, this "CMake sandwich" provides a remarkably consistent cross-platform build experience!
Of course that depends on what your priorities are. If you are looking primarily for ease of use, there are at least two new build systems that hook into the filesystem to automatically track dependencies in a language agnostic fashion.
One is tup:
http://gittup.org/tup/
and the other is fabricate:
http://code.google.com/p/fabricate/
The one that seems to be the best performing, portable, and mature (and the one I have actually used) is tup. The guy who wrote it even maintains a toy linux distro where everything is a git submodule, and everything (including the kernel) is build with tup. From what I've read about the kernel's build system, this is quite an accomplishment.
Also, Tup cleans up old targets and other cruft, and can automatically maintain your .gitignore files. The result is that it becomes trivial to experiment with the layout and names of your targets, and you can confidently jump between git revisions without rebuilding everything. It's written in C.
If you know haskell and are looking for something for very advanced use cases, check out shake:
http://community.haskell.org/~ndm/shake/
Update: I haven't tried it, but this new "buildsome" tool also hooks into the filesystem, and was inspired by tup, so is relevant:
https://github.com/ElastiLotem/buildsome
CMake
CMake is an extensible, open-source
system that manages the build process
in an operating system and in a
compiler-independent manner.
Gradle seems to match all the criteria mentioned above.
It's a build system which took the best of Maven and Ant combined. To me, that's the best.
The Selenium project is moving over to Rake, not because its the best but because it handles multiple languages slightly better than all the other build tools and is cross platform (developed in Ruby).
All build tools have their issues and people learn to live with them. Something that runs on the JVM tends to be really good for building apps so Ant, Maven (i know its hideous), Ivy, Rake
Final Builder is well known in Windows world
smooth build matches most of your requirements.
platform agnostic: yes, it's written in java
language agnostic: it doesn't support c/c++t yet, only java but it is extensible via plugins written in java so adding more compilers support is not a problem
extensible: yes, you can implement smooth function via java plugin, you can also create smooth function via defining it as expression built of other smooth functions.
I would prefer to avoid writing any XML: you won't see a single line of it in smooth build
Freely available: yes, Apache 2 license
disclosure: I'm the author of smooth build.

Using KDE4 localization mechanisms in pure QT4 application

I'm writing an application that is currently a pure QT4 app. It is designed to run cleanly on both Linux and Windows.
However I plan to integrate it a bit into KDE in future and here come the problems with localization/translations.
QT4 uses its own tr()/tr().arg().arg() mechanism and .ts/.qm files.
KDE4 uses gettext and i18n/i18np mechanism and .po files.
How, easily, can I use KDE4's mechanism in my QT4 application without having to closely integrate it with KDE now (apparently making it non-runnable on Windows)?
Is it at all possible?
Thanks!
Starting version 4.5, Qt will support both .po and .xliff;
http://doc.trolltech.com/4.5/qt4-5-intro.html#qt-linguist-improvements
I think you will need to just pick one and go with it, if it is a cross platform app, I'd go with QT's method. The reason why is that KDE wraps it's internationalized string with i18*() macros and QT uses tr() macros, since a macro can't produce another macro, there is no way unless you have #ifdef's all over your code, or a massive string table...both of which suck.

Resources