basic x windows applications

I've not programmed in C++ for years but I remember stuff like you were expressly warned not to try to figure out how member names etc. were mangled because it varied between compilers and was subject to change without warning. This meant that C++ was barely interoperable with itself let alone other languages.
I know this isn't a new analogy by any stretch, but C++ seems to dazzle people in the same way as communism did. Both claim to have definitively described the world as it is and explained precisely what should be done next. And both lead to a dreadful mess.
 
Trust me this is very serious business. I know very intelligent persons breaking there head to link non-C code to C-code with #includes.
 
Well for any x-windows application you want to code, you will have the task of choosing a language in which to code. In this sense this seams relevant to me.
 
If you want C++, that's what QT is built on. QT is also on top of libxcb, which is a benefit. Other than that, I think the thread should be split, or a new thread started that's closer to the topic of C++.

C and C++ themselves aren't the toolkits. libxcb and libx11 are libraries based on C for the desktop. Graphical toolkits are of their own libraries, many which have libx11 underneath. libxcb is in C, but it still is a part of QT which is in C++.

When C or C++ are mentioned, they are in relevance to which library or toolkit?
 
Legit question. I used d-lang with gtk-toolkit this worked fine.
I used ruby with qt-toolkit and suddenly out of nowhere it was discontinued.
For instance d-lang has no binding to wxwindows. That's because d-lang does not contain a full C++ compiler.
Qt binding with python works fine.
 
A few years ago, I actually tried to write a GUI program in C#.... and spent WAY too much time just trying to get a handle on how the graphics stack is organized in Windows... even a simple helloworld program required a truckload of setup before writing out the string in the middle of the window. And if graphical elements look out of place, I have to hunt down the API's to adjust just the right values. Not to mention there's different toolkits, best practices, and other details to take care of...
 
astyle said:
A few years ago, I actually tried to write a GUI program in C#.... and spent WAY too much time just trying to get a handle on how the graphics stack is organized in Windows... even a simple helloworld program required a truckload of setup before writing out the string in the middle of the window. And if graphical elements look out of place, I have to hunt down the API's to adjust just the right values. Not to mention there's different toolkits, best practices, and other details to take care of...
Click to expand...
#include <windows.h>
LRESULT CALLBACK WindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam);
int WINAPI wWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PWSTR pCmdLine, int nCmdShow)
{....
When you map this to a virtual machine like mono or java, big problems can indeed be expected...
 
I wrote up what I learned and made a post on my blog:

Decuser's Blog - X Window Dev Environment for Mac

Pretty much everything in the post applies in a FreeBSD environment - the paths are different, pkg instead of port, xorg and not XQuartz. etc - but pretty much the same :)... and it came out of our discussion here, so I thought I'd share.

Here's what the environment (twm) looks like running my compiled from source versions of xeyes (xt based), and basicwin (from the xlib programming manual) on my mac:

01-small.jpeg


oh, and with xclock, htop, and midori thrown in for a good looking snap :).
 
You must log in or register to reply here.
Back
Top