In my Qt applications I widely use reports printing. All of them were written with Qt < 5. Now I want to rewrite it with Qt5 but suddenly I come across the unexpected difficulty. I use HTML templates with placeholders and QWebView to print the document. But in Qt5 QWebView has buggy printing (see QTBUG-35222, QTBUG-43145, QTBUG-36308 etc.) So QWebView is out. Next candidate is QWebEngine but it does not work with Windows. (Or works partially with x86-64 and VS2013 but I need it to work with MInGW). So using QWebEngine is currently impossible.
QTextEdit supports only limited subset of HTML and it does not support external css etc.
So now I look for some way to load and print HTML documents in Qt. Any advice will be much appreciated.
Related
I am new to Qt in general, and I have been playing with it to get to learn about it since I have to develop a very specific text editor.
I want to know if anyone could help me understand which one is better (or the most indicated) for the development of a rich text editor. I have worked before with C and C++ but Qt Widgets seems like a very step hill for the time being and I am completely new to javascript in general.
Some of the settings that I would need to implement on the text editor for better context are:
Look for the user to be always connected to internet.
Transfer and receive data from another program.
Grant read only to the opened files and then permission to write on them when a button is clicked.
Has to work on linux and windows.
Needs to look great.
My context:
So far I have done a few little applications and even a little rich text editor on Qt Widgets, but since I was having problems with the GUI implementation that I wanted, I started looking for a way to solve it and found that Qt Quick might be the solution.
I have been trying Qt Quick, and for now on looks great, but I do not know if it has the capabilities to do what I have explained before. Or if it is better to use one or another.
I decided to create a new post since the one that I found looking for something similar is from 2014.
Also, the text editor for now only needs to work on desktop, but in a future might be on other devices and embedded systems.
I am an iOS / Cocoa developer looking to port one of my apps to PC platform. I don't care to code multiplatform and maintain one app. I will continue using cocoa and cocoa touch for iOS Mac Development.
I have chosen to use QT 5 for PC, I am not sure if its wise choice but its easy and I can understand c++. If its not please point me to the correct direction.
My App is not hugely complicated, but needs some special customization e.g. ListView that looks like an iOS Table View, uses custom rounded windows with twitter bootstrap style search box and I want to monitor some global OS events like keystrokes, and what other applications the user is currently working with. I also use SQLite and AES encryption.
My questions is regarding UI customization.
Should I start studying and use QML for that? I am not sure what exactly it is, seems extremely simple CSS like, but I have the feeling is more designed for embedded devices and have limitations...
Do I have access to the entire power of QT if I use QML ?
What other options I have to customise widgets instead using QML (e.g. in objective C we use subclassing and drawing whatever we want or handling events...)
I am inexperienced in windows platform. Should I use VisualStudio C++ instead of QT5? With the changes in ownership I feel somehow insecure.
Yes you should. QML is declarative language which allows javascript to be executed within it. And you can do almost anything UI related with QML. If you don't have some particular UI element you can draw it in plain C++(Qt) and use it in the QML. So QML is the best choice for Qt development at the moment. It is not like CSS though, it is much more powerful.
Yes you have all the power Qt has and additional power which declarative language may offer - simplification of UI development process as well as modern decomposition of UI&logic.
You have this option in plain C++ Qt, you may subclass widget, redraw them, change behavior etc. This approach is inferior to the QML one.
This point doesn't make sense. Some people count Visual C++ like separate language which is wrong. You may count Visual C++ as C++ + some minor extensions MS compiler has. But it is as ridiculous to refer as GCC C++. So basically you can use Visual Studio with Qt almost without a pain if you use Qt integration add-in which is freely available. Or you can choose Qt creator, which some people count as superior to MSVS. It is up to you what to choose, but I believe for the novice it is much simpler to use Qt creator with Qt. But note you will need to have some compiler because Qt creator is just an IDE it should use some 3rd party compiler(either MS or GNU one)
You can use QML Desktop Components to build easily your application:
https://web.archive.org/web/20121203050945/http://blog.qt.digia.com/blog/2012/06/06/desktop-components-for-qt-5/
http://qt-project.org/wiki/Qt_Quick_Components
Anyway I recommend you use Qt Widgets and Qt Style Sheets to costume your widgets:
http://qt-project.org/doc/qt-4.8/stylesheet-reference.html
I'm currently trying to get Qt working with my existing program.
I'm using SFML for creating my OpenGL rendering context and creating the window. The things I tried out so far however always create a separate window by Qt instead of just rendering into the existing context.
Is there any way I can force Qt to render to an already existing OpenGL context?
I've not looked into the specifics, but this has been done for openage.
I think looking at the documentation for QQuickRenderControl might be a good place to start.
Qt wants full control over the windows and the event loop, so this will not work (unless you put a lot of effort into it). Your best bet is using a QGLWidget and emulate the event management of SFML with that, so that your application effectively runs on Qt. It is very well possible to render Qt widgets into a OpenGL window (Qt has a OpenGL widget backend) but this must be still managed by Qt itself.
I've been trying to get custom font rendering working in a Symbian Qt app (4.6) for some time. For most fonts and most glyphs, it all works just fine using a method similar to this.
However, for the majority of fonts many glyphs are rendered incorrectly - essentially, the wrong glyph is rendered. I've tried a Symbian C++ app using the same loading method, and that does render correctly. So, this does seem like a Qt bug, and in fact all the gory details are here.
Can anyone suggest a workaround to get full TTF font rendering working on Symbian^3 devices in Qt 4.6?
Although I have no experience with Symbian Qt Apps, I was working last year for several months in a dual environment Qt application (Win32 & Mac OS X) which has to do mainly with font rendering.
QFont rendering -in Win32/Mac OS X- in general runs smoothly, but if you have advanced font rendering requirements you may encounter several and severe problems:
a) It's not possible to find if a specific unicode character is really present in a specific font (i.e. it's not possible to totally disable the character-substitution mechanism - you can only provide substitution hints)
b) If you try to load some specific (bad?) TTF/OTF fonts for exclusive use of your application (i.e. to load not-installed fonts to use them in you application) the application crashes and the crash is inside the Qt Libraries code (it's trying to double-free some buffers).
This is a very rare bug to encounter: It was happened to me for just 5-10 fonts out of 90.000 fonts I tested, but it's still annoying if the main task of your application has to do with font-rendering.
My workaround was to use the FreeType2 (open source) library:
-> It never crashes (it just returns an error on bad fonts)
-> It's about 4-5 times faster than QFont rendering
FreeType2 is not a direct replacement for QFont and it for sure requires to spend some extra time to understand some basic (low-level) concepts before using it, but if you really need a fast and reliable library to render any TTF/OTF (+other) font into a gray or bw image, I highly recommend it as the ultimate choice.
The ultimate answer is that this is a QT bug, but happily it is fixed in QT 4.7.2. Now, just have to wait until the Ovi Store accepts Nokia QT 4.7.2 apps....
After 4 years of absence I'm finally coming back to Qt development again. I'm quite impressed by the development it has gone through, but also a bit confused by Qt Quick, which got just introduced in Qt 4.7
For me it seems like something to build a quick, appealing GUI with some logic in Java Script. However, if I'm going to build a C++ application, is Qt Quick also the modern way of building a GUI for that or should I follow the classic path by using the .ui files?
Qt Quick should fill a much needed gap but whether that means it will become the way to build applications will largely be determined on the type of applications you intend to build.
Qt has provided .ui files for a long time. These files are easy to work with when you need to create applications based on standard widgets. Designer makes it easy to layout the widgets and do other basic operations.
Qt 4.2 introduce style sheets (qss) that made it possible to style existing widgets. These styles are convenient ways of styling the standard widgets to get away from the standard widgets' look-and-feel, while retaining basic functionality.
But sometimes you need to create custom widgets, widgets that don't exist. Before Qt quick, the only way to do this was to write native code (be it C++ or, with language bindings, Python or Ruby). With Qt Quick it's now quite possible to write widgets and full blown UIs that would otherwise be somewhat painful to write in code. Because Qt quick's focus is on the UI, it's becomes a better development language for that goal. The Qt Quick paradigm also transcends the idea of strict standard widgets, adding support for transitions and boundary-less widgets.
The answer really depends on the type of application you're planning to build and I consider the description provided on the page you linked to very accurate:
"Qt Quick helps programmers and designers collaborate to build the fluid user interfaces that are becoming common in portable consumer devices, such as mobile phones, media players, set-top boxes and netbooks."
At the moment, Qt Quick is certainly not the most obvious choice if you're planning on building a classical desktop application, an area of development which the Qt library traditionally excels at, and in this case you're probably better off using what you call "the classic .ui approach"; at the same time, I think that's the exact reason why Qt Quick was introduced: to add a new tool to facilitate the development (or rapid prototyping) of applications not focused on the desktop.