I'm developing an application that makes use of Qt and OpenGL, using Qt Creator and QGLWidget subclassing.
My application has a user base that has a higher than average proportion of older hardware, which is why I need it to run on machines with graphics cards supporting OpenGL 2.1 only - or, in other words, I cannot rely on anything newer than 2.1 being present.
I am worried about unknowingly using OpenGL functionality that was introduced after 2.1. Is there any way I can configure OpenGL to "only" support 2.1, so that I would get a runtime error if I do something I shouldn't be doing? Or, failing that, what is the best practice to ensure compatibility?
The only thing you need to worry about is not creating a OpenGL-3 core profile context, and only to use functions found in the OpenGL-2.1 specification.
Since creating a OpenGL-3 core context requires you to jump some hoops, you're not running into problems there. The system may give you something newer than OpenGL-2.1 but as long as you don't use any functionality not found in the 2.1 specification document you're fine. You'll have to use the extension mechanism, to actually get the functionality on Windows; OpenGL-2.1 is technically a list of extensions made official functionality, so carefully read the Appendix of the specification, where the functionality that formerly were extensions are explicitly mentioned.
Related
I’m working now on some project built on Qt 5.2.1. The project makes some basic rendering (using QPixmap, GraphicsScene, etc). The goal is to switch this mechanism to OpenGL as quickly as possible. In addition we plan to move the whole project to Qt 5.10.
Is there some benefit first moving to Qt 5.10 and only then switch to OpenGL over first switching to OpenGL and afterwards move to Qt 5.10?
Is there possibility of some unexpected difficulties if we first switch to OpenGL (on Qt 5.2.1) and only then upgrading to Qt 5.10 (some features got deprecated or some new nice-to-use features appear)?
My experience with OpenGL on Qt is it being full of both old and new bugs, poor integration capabilities, poor platform support (Intel=NOPE) and no error handling of Qt-internals (e.g. context creation). At least of you use the built-in OpenGL-widgets.
That said there is much development going on right now of the Qt-OpenGL support, judging from which Qt-version certain OpenGL related features I have found in he manual. If you must use Qt-OpenGL, I would assume you get most features and few(er) bugs jumping onto latest and greatest.
I've read some things about .NET Standard and .NET Core, and generally they seem to say something like "This is the new way to do things, and here are the advantages and disadvantages."
What I haven't seen is a good, clear explanation of what was wrong with the status quo, such as .NET Standard and .NET Core were even necessarily. To really judge what I should use these for, it would be helpful to know why they exist at all.
Can someone give a clear (and not necessarily concise!) explanation of (a) what problem .NET Standard and .NET Core are intended to solve, and (b) how they solve it?
.NET Standard is a set of library contracts. Each version includes all the contracts of the previous version - so everything in netstandard1.4 is in netstandard1.5 for example.
.NET Core is an implementation of .NET Standard (and some extra functionality) which runs on Windows, Linux and OSX.
Biggest problems they solve:
Not having a Microsoft-provided/supported toolchain and runtime on Linux/MacOSX. Saying that you could only run .NET-based server code on Windows or Mono was simply untenable.
The Portable Class Library mess with hundreds of different profiles giving partially-overlapping API surfaces to target.
PCLs in particular were very hard to work with for class library authors such as myself. The mess came about because there were multiple efforts to bring a .NET runtime to different devices without enough coordination to provide a coherent API surface to target.
Now multiple vendors can target particular versions of .NET Standard, and anything targeted to that version or higher should work. For example, my Noda Time library targets netstandard1.3. Suppose a new mobile phone vendor comes out with a completely new implementation of .NET, with a completely new kind of application - but says they support netstandard2.0. That's fine - a user of that new platform will still be able to install the Noda Time NuGet package and (implementation bugs aside, of course) they'll be able to use it. I don't need to know that the platform even exists.
What is the difference between Qt versions with dynamic and desktop OpenGL? http://tver-soft.org/qt64
It is likley that this refers to the configure option that was set when they compiled Qt.
This option is explained in detail here: https://blog.qt.io/blog/2014/11/27/qt-weekly-21-dynamic-opengl-implementation-loading-in-qt-5-4/
To summarise, Qt can be compiled to use ether the desktop OpenGL (a direct interface to the graphics driver provided OpenGL version) or to use Angle (a version of OpenGL that uses directX to provide hardware GL support).
Using 'desktop' gives you the latest (and deprecated) OpenGL features where available, but some drivers do not work properly.
Qt now relies on OpenGL to do important 2D rendering and can be badly affected by faulty drivers. For this reason you have the safer option of Angle, safer but limited to OpenGL ES 2.0 functionality.
Dinamic is a new option that will select between them automatically at runtime on the user's machine. It does however mean that you will need to use the Qt OpenGL API (rather than e.g. GLEW) to access OpenGL.
If you are not going to use OpenGL directly in your code then you should chose dynamic.
You should also consider compiling the code for yourself, as you are trusting your and your user's security to tver-soft.org. Even without malicious intent these files may be a security risk.
I believe Qt uses GDI(+) and you start with a QObject. Does it call ActiveX components, COM etc?
For example, putting WebKit in a form is there anything happening there that uses the Windows bits and pieces for painting?
I'm just a beginner trying to work out how much of WINAPI, COM, and ActiveX is used/wrapped by Qt.
In general Qt only implements a feature if there is a sensible(/compatible) metaphor for that feature on all* supported platforms. It makes use of a lot of different Microsoft and non-Microsoft components on Windows, not just the one's you have mentioned.
I've not found a document which summarises what you're asking before because it's not something I've ever needed or found useful as the document would be immense. The way I tend to work with Qt is read the excellent documentation and believe it until I find something which does what I didn't expect it to. Then delve into what it does under the bonnet(/hood) for that specific platform. Remember, the source code is freely available.
* Note: there are some features which are platform specific in the framework but these are usually clearly identified as such.
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.