Linux GUI Programming with no extra framework
 

Hi there,

I've been writing Windows software for many years, starting with Windows 3.1 when Windows wasn't an OS on its own, but merely a GUI for DOS.

In all these years, it has always been my paradigm not to use any third-party libraries or frameworks, but instead use the Windows API directly. I found that this was the easiest and quickest approach (and my programs tended to be lightweight and fast) because most frameworks used with Windows are bulky, hard to handle and poorly documented. So whatever you do, sooner or later you end up doing try & error. The Windows API, however, is fairly straightforward and well-documented.

Now I intend to follow this paradigm on Linux. That is, I want to write GUI applications that do not use Qt, GTK or some framework like that, but use the X Server's or the window manager's API directly.

I know that there is at least one application that uses this approach: The Xfe file manager. But what are the keywords I'd have to use to find tutorials or documentation on that programming approach? Where would I start?

[X] Doc CPU

Keywords are X window programming or X window system programming. There were several books on the subject - I think I saw "Definitive Guides to the X Window System" aka "Xlib Programming Manual for Version 11, Rel. 5, Vol. 1", but I don't know if this book is any good.

I'm not sure if programming without underlying framework is a good idea, though - it locks you in one API or OS, but that's your decision.

Hi there,

thank you, that gives me something to pursue.

That's the idea. I want to have the abstraction layer inside my application where I have full control over it, not in a separate framework that I can only treat as a black box - despite many of them being open-source, but the sheer complexity makes it practically impossible to dig into their details.

[X] Doc CPU

Using Xlibs directly is going to cause you untold misery -it takes about 20 lines of code to draw a single pixel. Xfe uses the fltk libs (which are a real pain since they break the API with each release), so it is not what you think either.

Well, you do sound like experienced/mature developer, but just in case:
Before making custom abstraction layer, consider development costs(time/people) of developing, maintaining, and bug-fixing custom framework (that is supposed to work on several platforms/compilers). Depending on size of the project, your resources, going for custom solution might or might not be worth it. If you rely on a "black box", it doesn't necessarily mean that it is "bad" and "black box" should be replaced with your own software. Black boxes have their own advantages and making alternative to existing code might cause you to "reinvent the wheel" and face problems that were already fixed by developers of the "black box".

Just my 2 cents.

FWIW, wxWidgets: http://wxwidgets.org/ are written in C++, so a lot of abstraction layers exist, and there is a variant (used to be called wxX11: http://sourceforge.net/projects/wxwindows/files/wxX11/ ) which works directly with X, without the otherwise present under Linux gtk+.

I think it will be harder to integrate a pure Xlib app in common used window managers, see for example a GTK app running in KDE, even if some work has been done to uniformize things, it still doesn't look like the KDE QT's apps

There are some docs here:
http://www.sbin.org/doc/Xlib/

You should seriously look into GTK+ or QT.

I use GTK+ for my hobby programs. I have found GTK+ to be well-documented and stable.

I too once programmed Win32. Win32 was low-level and arcane, but at least the Win32 API was stable across many different versions of Windows. I avoided Microsoft's frameworks (MFC and .NET) because Microsoft kept coming out with "better" ones every few years. I also wanted a C-language API, not C++.

GTK+ doesn't suffer from the "framework of the year" problem. It's relatively stable (although there will soon be a major migration from GTK+2 to GTK+3). I don't recommend programming X directly - it's ancient and your apps will look like xpdf. You will want to use a modern widget library.
Ed

I agree with EdGr, though it does depend to some extent on what you are aiming to achieve. If you are writing only a GUI I can see the benefit in going as generic as possible to reduce the workload, but if you are talking about a GUI on top of other code, then it may be quicker just to write the GUI elements for different structures (gtk, qt etc). It may sound longer, but the more mature development environments will make it ultimately faster.

I'm not sure the comparison between abstraction layers in Windows and Linux/X holds up very well. At its lowest level, X gets you almost nothing, especially nothing upon which to build a GUI. There is a very good reason why GUI toolkits, window managers and desktops exist. The only thing that would make me consider abandoning them would be for something like a closed-box application that must run on a resource-constrained embedded system, and does not need to conform to any existing standards or interact with other GUI elements. Or if you are convinced that you can create something that somehow revolutionizes the way GUIs are crafted, and if such is the case, I offer my sincerest wishes for your success.

--- rod.

Hi there,

it looks like you're the one in this thread who gets closest to what I mean - I nodded to every half-sentence of yours that I quoted above. With only one exception: I don't find it arcane, not at all. Once I understood the window principle and the message-based flow of control, it was pretty intuitive to me.

... which is not bad per se. On windows, for example, I still prefer the clear, almost austere look of Windows 2000 and older, and therefore disable the fancy Luna style on XP or Aero on Win7, which both piss me off.

I really thought that, like the Win32 GUI, either X or the window manager had basic building blocks integrated (like standard windows or form controls) that I could just instantiate with a few lines of code - so that they look genuine to the desktop environment the program is run on, whichever it may be. Like in Windows, where a program automatically inherits the visual appearance of the theme.
Summing up what you all told me, that seems not to be the case. :-(

Okay, maybe I really dig into GTK+ ...

Thank you all for your comments.
[X] Doc CPU

Hi there,

that leads us to another question I haven't even asked: For a different project, I want to have a lightweight Linux with no X on a small embedded board (300MHz CPU, 128MB RAM, boot from CF, power consumption <10W). That system has a plain VGA integrated, but I want to stop Linux from using the VGA adapter. Instead, I want to log in exclusively over a serial console, or later using ssh over the network.
Then the custom application that runs on this biscuit should have full control over the VGA adapter (register and memory access), since I already have a very efficient VGA library of my own which is written in pure assembler, highly optimized, and runs extremely fast even on low-end systems. I used that for a few embedded DOS applications.

However, which knobs must I turn to stop Linux from allocating the VGA and using it to establish a console session on it?

Maybe I can. :-)
But it's not gonna be finished this year. :-D

[X] Doc CPU

The Win32 principles are clear, but the details are not. For example, do I want the lParam or wParam? HIWORD or LOWORD? What does RegisterClass really do? I found the only way to keep these straight was to copy working code.

X and its widget set (Xaw) look like they're straight out of the 1980s - not acceptable today. Win32 at least looks like Windows 95 (which we both find to be the peak of the Windows GUI evolution). :) GTK+ looks modern, but not slick-to-the-point-of-impairing-usability like Aero.

I think you'll like GTK+.

GTK+ is easy to learn since you already know Win32. You'll find that GTK+ is cleaner and the layout containers are a sorely-missing feature on Win32 (no more clipped text in dialog boxes). Good luck!
Ed

Then better Qt. There is/was a thread in gtk+ list - gtk+-3.X.Y is significantly (IIRC 2 .. 3 times in some cases) than gtk+-2.X.Y while the latest of gtk+-2.X.Y is IIRC 2 times slower than Qt.

If you use C++, then using Qt 4 will be much better idea. Tutorials/documentation are available at doc.qt.nokia.com

You could check svgalib for info - it MIGHT point you for the right direction.

(IMO) This is actually a bad thing. At this point new GPU would cost you less that development of assembly library (amount of time spend writing code (in hours)* average programmer's salary).
YOu might want to check raspberry PI - once they finally release the damn thing to the market. PI has OpenGL ES 2.0, and as far as I know, "throwing hardware at the problem" frequently beats "assembly-optimized libraries". If you want to display something on a VGA display remotely you could use SDL - it should be able to use "framebuffer" device for display surface.

That's what documentation is for. msdn.microsoft.com. If you want API that can be intuitively understood, then I think that's not gonna happen in next 50 years - windows has burden of backward compatibility, so unless there will be a major paradigm-shifting technological breakthrough, it is unlikely that WinAPI/WinGDI layer will change much..