I'm developing a cross-platform app w/ wxWidgets and opengl...
I'm not sure what the best way is to have fonts work in the glcanvas. I've tried using FTGL but I think the version included in Fedora 11 must be broken or something since I can't get the example code on the web site to compile. I could try using GLUT or SDL but I'm not sure I want to include those as dependencies...
EDIT: Turns out it's just a different version than the one that is documented on the web site and has a completely different API.
Even if I have a font library though, all the ones I've seen require a path to a font file, and I have no idea how to do that in a cross-platform manner.
All platforms deal with fonts differently. There is no cross platform way to find fonts on a system. Alternatives include...
Package your fonts with your app so you know where they are.
Convert the fonts to a binary blob and embed them in your app.
Test for the OS and set the font path accordingly.
Transliterate this tutorial to C++ and array-embed a gzipped copy of the GNU Unifont. QuesoGLC might also be an option, but watch out for performance gotchas.
Related
I am writing an OpenGL app which runs on windows, OSX and linux.
I have some free-for-commercial-use truetype fonts that I'm packaging with the app, so the user can choose their preferred font for the text part of my renders.
I have some glsl shaders of my own making, so that my rendering does just the right thing. I need to package these with the app, too
I build with cmake and build an installer with cpack. I use the install command to control where the fonts and shaders go, on the target machine.
I have C++ code which, given a path to a font file, will give me just the right font in the rendered image. Similarly, I have OpenGL code which needs to know where the shaders are, at runtime.
On the build machine I've used configure_file to handle OS/user variations. The fonts and shaders are relative to a directory where the code resides, so I can put their location into a header file as a namespace variable, and the shading and font code can always find them.
Now I'm trying to get the installed app to work I've hit a problem: I can put my fonts and shaders anywhere I like on the target machine, at install time, but am struggling to see how the runtime (installed) executable, on the target machine, can be made to understand where that location is.
Compiler flag? Environment variable? Target property? None of them seems to quite fit the bill. Or is that wrong? Any thoughts would be very much appreciated.
You have two possibilities here:
The application is installed to a directory chosen by the user, but you control everything within that directory (what CMake calls the install tree). Because of this, you know where all of the external files are located relatively to the executable, so you can use relative paths for addressing them (as was also suggested in the comments). This approach is very common for OS X and Windows, where each application is typically installed to its own distinct directory. It's a bit less common for Unix-y systems, where stuff is typically just dumped to /usr/bin.
If you are not comfortable with relative paths, you can always package all resources into the executable itself. This is typically done using a resource compiler, but CMake has built-in support for those. This approach is particularly popular with GUI applications that package their fonts and icons into the executable itself. Qt offers a cross-platform resource compiler for this purpose, that is also supported by CMake.
Linux has a really different installation philosophy. Resources are installed in standard locations, which are not at a fixed relative location from the binary itself (windows in somewhat moving in this direction with ProgramData and .AppData)
The Linux approach would be to use fontconfig to locate fonts, and then install your fonts system-wide in /usr/share/fonts/myapp or in the user directory (~/.fonts/myapp or even better the new XDG location)
For shaders it would be similar with /usr/share/myapp system-wide and XDG locations user-side (https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html)
Of course you can force whatever you want in your code, and install in /opt, it will never feel like an integrated linux app from the user POW though
I am trying to configure (and build) QT5 static. I want it to draw to the framebuffer and use webkit. I searched the docs but I didn't find anything on how I can do this without X. Does anyone know a way of doing this ?
Building Qt statically is totally orthogonal to the platform selection. Depending on your target device, you can choose between using Wayland, EGLFS, LinuxFB/DirectFB, etc.
Just be sure when you run configure that the actual plugin you're interested in gets compiled. In other words, check configure's final output (or read the config.summary file generated). If the platform is not there, run configure -v and try to see what's missing (headers, libs, ...).
You can then make any application use a given plugin by simply starting the application and passing the argument -platform eglfs|wayland|... (or by setting the QT_QPA_PLATFORM environment variable; or you can make it the default by mangling with the device mkspecs). More info here.
When it actually comes to static linking: this multi-platform support is implemented via plugins. A statically linked application won't have plugin loading available, so you must actually link the platform plugin into the application itself by adding something like
QTPLUGIN.platforms = eglfs
into your .pro file. More info here.
The best way is to use the "minimal" plugin and blit it into the framebuffer (something similar to the discussion at http://lists.qt-project.org/pipermail/development/2015-April/021160.html). However, ask your Platform vendor - check if "eglfs with fb" is a supported option.
However be aware that things like Cursor, overlays, rotation, vsync handling, GPU acceleration, may not be fully supported in these non-mainstream options on Linux.
I am developing a multiplatform (Windows, Linux and Mac) Qt based Phonon C++ application and am aware that Phonon itself is only API, which relies on a backend to interact with installed codecs.
Logically, I should assume that the end user has no extra codecs installed, only those provided by OS.
So my question would be, is it possible to bundle an OGG (preferably) or AAC decoder with my application so that the backend would recognize it and be able to play audio files? What steps in general should I take and where to look for more information on this?
The application itself is not installable, it runs directly form physical media.
Sound Libraries for C++
As far as getting the right libraries for playing sound, it should just be a matter of finding out what libraries are used by Phonon on your system. I know Phonon is a pretty big project and each OS has a different set of drivers for playing media and using Codec, etc. I would suggest looking at Audacity and VLC and checking Google.
Plugins/Libraries and Qt
As far as getting Phonon to work with Qt, I have experience there...
I haven't done a ton of testing with Phonon on every major OS, but I have on a few different versions of Windows.
The deployment of a Qt Application is very straight forward, even with plugins and libraries like Phonon. But figuring it out the first time was a little painful, just because the jargon is a little weird.
My answer is in the context of a Windows Desktop Application with Dynamic Linking to the Qt Libraries, not static.
Here is the directory structure for windows and a short explanation of how dlls are found.
Deploying a Qt Application
Dynamic-Link Library Search Order in Windows
For Mingw on Windows in the Qt SDK there is a folder for its binaries, and in that folder there are the dlls that your application needs to be able to find at runtime (If you are doing Dynamic Linking). I usually put these DLL's in the same folder as the Application EXE that I build in Qt creator and then keep the "Working Directory" or the directory that the EXE is ran from to be the same directory as well.
For the additional plugins/libraries that are for specific media types, like image formats and for phonon, you need to have a specific structure that your application can find it in.
You can make some very specific ones for your application and add them using the functions related to this call.
QStringList QCoreApplication::libraryPaths()
In general mimic the directory structure that you find in the MingW "plugins" folder for the additional dlls you need.
For example, I wanted to be able to show a system tray icon properly. Apparently you need the correct image format engine plugin to show the icon. (qgif4.dll, qico4.dll, and qjpeg4.dll)
Here is were the plugin was located on my developing machine:
"C:\QtSDK\Desktop\Qt\4.7.3\mingw\plugins\imageformats"
Here is where I place it so that it can be found at runtime:
"C:\path\to\my\EXE\imageformats"
or
".\imageformats" (relative to my working directory of my EXE)
What is one of the more annoying things about discovering this information, is that the plugins don't fail in the same way as the main Qt Libraries, so you don't see it broken until you get to the part of your program that is actually attempting to use them.
Generally, you could supply the VLC Phonon backend for Windows. The default DirectX backend is unfortunately quite limited.
On Linux, you can assume that a suitable Phonon backend comes with the OS's Phonon installation. The two backends currently popular are GStreamer and VLC.
I am making a program in which I will include datasheets of PIC processors. I now want to display these inside the QT program itself as a widget. I wanted to use poppler for this, but I am having a very hard time trying to get hold of these binaries! I can't seem to Cmake the poppler for QT4. Could anyone help me on how to make these libraries on Windows 7.
(I have never compiled/build anything yet on Windows, only Unix, I downloaded the CMAKE program, and tried to use this to generate it with the CMakeLists.txt file, but no luck so far.)
The best solution (because this way I could learn it myself, and never have this problem again) is a 'tutorial' on how to do it myself.
If not then giving me the libraries itself would be very much appreciated!
I'd wanted to point you to SumatraPDF, but it looks like they're not using poppler any more. You could have a look at the mupdf subdirectory though, it has MSVC makefiles for several libraries required for poppler. You might have some luck adapting them for building libpoppler itself.
You could also use Cygwin or MingW to get/build poppler.
You might have to take a look at this: Poppler: Displaying PDF Files with Qt
You can use the KDEWin installer to automatically get all the appropriate binaries for your machine. This is very useful and is the strategy used in many projects (including my CarMusTy, Carnatic Music Typesetting application).
Check out: http://www.winkde.org/pub/kde/ports/win32/installer/
It automatically downloads all the required dependencies when you ask it download the required binaries. And you can get the dlls suited for your particular compiler. (MSVC, MingW supported)
Also you can get the source code for poppler. KDEWin supports versions, so you can get the latest version binaries or any previous version you like.
Check out http://windows.kde.org/ for more details.
All the best
Gopalakrishna Palem
Creator of CFugue and CarMusTy
http://gpalem.web.officelive.com/
I've scanned over the (outdated) article that is the first hit on google about ARM cross-compiling. I've also seen the article about compiling OpenCV to the iPhone and the general cross compiling instructions there. My question is can I call the apparently already configured gcc/g++ in the iPhone developer package (which I already have installed) like in the latter article? A lot of the OpenCV stuff seems superfluous to my needs.
If I can, what would the calls look like? Should I create a Makefile to make things easier?
Also, I need -lncurses library. Can I call them like normal, or do I need to specify it's path because I'm not calling the default gcc/g++?
If you're using the official SDK, compiling C++ for the iPhone is as simple as including cpp files in your project and hitting "build". Of course you can still go in and tweak the compiler switches - well, most of them.
As for ncurses, I'm not sure why you'd want to use that - but the only limitation you should have is that you can't link against dynamic libraries - so you'd have to linked the object code in.
A script that you can use as a basis for crosscompiling your libraries for iOs development.
Unfortunately the [n]curses package is not going to do you any good for the iPhone.
[n]curses is designed to be used with a terminal window. This is just not available for the iPhone you will need to learn how to use Coco to develop a GUI interface.