How do I make an extension of qobject cross platform - qt

I'm making a way of getting truly global hotkeys (I.e. emits a signal on certain inputs even when app is out of focus)
This will require different code for win vs osx vs x11. In qt creator how should I go about making this suitable for cross platform development.
Edit: I don't want to know how to do the actual code with x11, windows etc. I just want to know how I would do separate definitions for each platform.

I don't want to know how to do the actual code with x11, windows etc.
I just want to know how I would do separate definitions for each
platform.
It is convenient to do with ifdefs based on pre-defined compiler symbols e.g.:
http://sourceforge.net/p/predef/wiki/OperatingSystems/
#ifdef __linux__ // linux related, GCC has that macros
// your code and/or definitions
#endif
#if defined(__linux__) || defined(macintosh)
// your code and/or definitions
#endif
You may use OR logic there as well, as many things on Mac resemble Linux and vise versa. Mind the compiler, though, if it has that symbol. I would use OR logic with all platform symbols of applicable compilers.

If you're willing to use Qt, it has OS and compiler defines easily available for you:
#include <QtGlobal>
#if defined(Q_OS_LINUX)
// linux-specifc
#elif defined(Q_OS_WIN32) && defined(Q_CC_MSVC)
// win32 and msvc
#endif
Documentation.

Related

Reason to use Qt standard library function wrappers

Is there any reason to use Qt standard function wrappers like qstrncpy instead of strncpy?
I could not find any hint in documentation. And I'm curious if there is any functional difference. It looks like making code dependent on Qt, even in not mandatory places.
I found this: Qt wrapper for C libraries
But it doesn't answer my question.
These methods are part of Qt's efforts for platform-independence. Qt tries to hide platform differences and use the best each platform has to offer, replicating that functionality on platforms where it is not available. Here is what the documentation of qstrncpy has to say:
A safe strncpy() function.
Copies at most len bytes from src (stopping at len or the terminating '\0' whichever comes first) into dst and returns a pointer to dst. Guarantees that dst is '\0'-terminated. If src or dst is nullptr, returns nullptr immediately.
[…]
Note: When compiling with Visual C++ compiler version 14.00 (Visual C++ 2005) or later, internally the function strncpy_s will be used.
So qstrncpy is safer than strncpy.
The Qt wrappers for these functions are safer than the standard ones because they guarantee the destination string will always be null-terminated. strncpy() does not guarantee this.
In C11, strncpy_s() and other _s() suffixed functions were added as safe string functions. However, they are not available in any C++ standard, they are C-only. The Qt wrappers fix this.

Force QWebEngine to use software rendering

I'm using QWebEngine to display some webpages. Unfortunately it uses OpenGL internally - which leads to a crash on some graphics adapters (one can see the driver-DLL as the reason for the crash easily). As a second caveat it is not possible to catch this crash by a try-catch-block.
So my question: how can one force QWebEngine to use software rendering only and to not to use OpenGL?
Thanks!
I assume you're on Windows, and are using the official Qt binaries, and are using Qt 5.5 or newer. These allow to switch between Desktop OpenGL, ANGLE (Direct X) and software rasterization at runime.
It should be therefore enough to set the QT_OPENGL environment variable to either "angle" (to use the DirectX backend) or "desktop". To hardcode this you can set the Qt::AA_UseOpenGLES or Qt::AA_UseSoftwareOpenGL application attributes.
If you use WebEngine through Qt Quick, you can also use the Qt Quick 2D renderer.

Handling Multiple OpenCL Versions and Platforms

Intel recently updated its OpenCL SDK to the 2.0 specification. AMD is still on 1.2, and Nvidia on 1.1. Essentially, this means each GPU platform is now on its own version.
OpenCL does not appear to be designed in the same way OpenGL is in terms of how deprecation works. As far as I know there's no way to request a compatibility version, and Intel even incorporates build errors in its SDK preventing you from calling deprecated functions.
If I want to support every platform using a minimum version (1.1, most likely), what is required of me?
Making only ifdef statements unfortunately doesn't work if you have more than one platform, and they support different OpenCL versions. For instance POCL which installs on the CPU supports 2.0, so you need to have the 2.0 OpenCL headers, but most GPU's and open source drivers, only support OpenCL 1.1 or 1.2.
The best option seems to be to get the OpenCL platform version info, and base what commands are called based on that. Unfortunately it is a char[] so may have to parse it out.
Here is an example of how to get the platform info string.
clGetPlatformInfo(platforms[platform_indexFinger], CL_PLATFORM_VERSION, INFO_LENGTH, &platformInfo, &realSize);
Typically the version info is of the form: "OpenCL 1.2 implementation name"
Here is a little function I made to diagnose the current opencl number
float diagnoseOpenCLnumber(cl_platform_id platform) {
#define VERSION_LENGTH 64
char complete_version[VERSION_LENGTH];
size_t realSize = 0;
clGetPlatformInfo(platform, CL_PLATFORM_VERSION, VERSION_LENGTH,
&complete_version, &realSize);
char version[4];
version[3] = 0;
memcpy(version, &complete_version[7], 3);
// printf("V %s %f\n", version, version_float);
float version_float = atof(version);
return version_float;
}
Can then use it like so, for example with command queue function which were modified for 2.0
float version_float = diagnoseOpenCLnumber(platform_id);
if (version_float >= 2.0) {
command_waiting_line =
clCreateCommandQueueWithProperties(context, device_id, 0, &return_number);
else {
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
command_waiting_line =
clCreateCommandQueue(context, device_id, 0, &return_number);
#pragma GCC diagnostic pop
}
AFAIK deprecated functions do not have to be implemented, hence code should check the OpenCL platform version number and avoid calling deprecated functions on that platform. See this earlier discussion: http://www.khronos.org/message_boards/showthread.php/8514-clCreateImage-2D-3D-vs-the-ICD-loader. At present, calling deprecated OpenCL 1.1 functions on AMD or Intel platforms (OpenCL 1.2) still works, but there are no guarantees that this will remain true in the future or on other platforms. I guess that as soon as supporting those deprecated functions becomes too much hassle for the maintainers of an implementation, they'll be removed.
Admittedly, I'm naughty as I have just ignored the problem and continued to use OpenCL 1.1 functions. However, if you are starting a new project (and have the time) then rather wrap the deprecated functions in some sort of generic function that has paths for each version of OpenCL - faster to do it now than later in my opinion. There is a list of frameworks and libraries at http://www.khronos.org/opencl/resources. Perhaps you will find that one of them solves this problem well enough. If not, and if you have enough time then you could build a framework that hides most of the OpenCL functions from your program. Then, as more functions get deprecated you will hopefully only need to change your framework, but not the programs that use it. At the moment, I don't know of any framework that does this for one in C++.
In the header cl.h you'll find a list of definitions like the following:
...
#define CL_VERSION_1_0 1
#define CL_VERSION_1_1 1
#define CL_VERSION_1_2 1
#define CL_VERSION_2_0 1
...
In my case I had annoying warnings about a deprecated function if I was using OpenCL 2.0 to build. So my quick/dirty solution was to do
#ifdef CL_VERSION_2_0
//call 2.0 Function
#else
//call deprecated Function
#endif
Although this might require several fix in your code it's the way to me if you want to compile based on the opencl library available.
Note that if you are using opencl 1.2 you'll get the definition of all the previous versions (so like in the example above CL_VERSION_1_1 and CL_VERSION_1_0 will be defined as well)
Hope this helps

Network/Host Byte Order Functions for multiple platforms

I am working on a project wehre current ntohl, ntohs, htonl and htons are defined as macros in a standard header file that most files include. This causes problems on platforms where these symbols are already defined, for example, winsock2.h declares functions with the same names mentioned above, and causes compile errors, as these declarations get expanded to my macro definition. On Mac OS, I get thousands of compiler warning, as Mac OS defines these macros for you already.
I want to support Windows, Mac OS and Linux, and use the standard OS functions or macros wherever possible, and if they are not decalred, then use my own definition. What is the best way to do this?
I have tried:
#if defined WIN32
#include <winsock2.h>
#endif
but this causes compile errors as there are lots of function name clashes with my current, large codebase.
This is hardly a mystery:
#ifndef ntohl
#define ntohl(x) ...
#endif
Then you just have to make sure that all language and system #includes occur before your own, which is standard practice anyway.

ANSI C compliant or C++ cross-platform GUI library?

I'm searching for a simple library for creating GUI that can have:
a portable codebase across different compilers and OS
can be easily extended to a new platform if that platform it's not natively supported
are real library and not just a collection of #define, tools and other un-portable and non-standard things.
So far the "best" match is QT that is just the opposite of each one of this 3 points, especially the 3rd one (moc compiler and #defines ... ).
I also do not need data structures and 10000 extra functions, i just need to code a portable GUI, hipotetically i don't even need a signal slot library included because I can handle signals with third part libraries.
If there is no such lib available can you point me to a resource where I can learn about the OS specific basics about Widgets and Windows ?
I never used it, but I would suggest looking into IUP
From what I read this would fit the bill quite well. The project is also quite active. Though it is probably not too pretty.

Resources