My main experience is with C && C++, so I'd prefer to remain with them. I don't want to use anything like QT, GTK, or wxWidgets or any tool kits. I'd like to learn native programming and this sort of defeats the purpose. With that in mind I'd also like to avoid Java.
I understand gnome and xfce and KDE and such are all Desktop Environments for Linux, and the base installed typically is X (Xorg). When coding for Linux, do you code for X, or for the desktop environment? Is there a standard Linux header for this (like win32 has windows.h) for Linux? or is it different coding methods for every desktop environment?
any help is greatly appreciated.
X is a hideous layer to program for and, despite your intent to avoid Java, QT or any of the excellent UI abstraction layers, you'll be doing yourself a disservice by coding to that level. I've done it (a long time ago when Motif was in its infancy on the platform we were using) and I would not do it again if there was an easier way.
Your use of the phrase "native programming" confuses me a little. If you want to learn native programming, it's to the APIs that you choose to call. Using similar reasoning, you shouldn't be coding in C either, instead opting for assembler (or direct machine code) since C provides an abstraction to the hardware.
If you want to learn X programming, that's fine. You'll end up with a lot more control over your interface but almost everyone else will be out-performing you in terms of delivery of software. Myself, I'd prefer to code to a higher-level API that I can use on many platforms - it gives me both faster delivery times and more market potential.
You don't build a house out of atoms, you build it out of bricks. My suggestion is to use the tools, that's what they're there for.
I don't want to use anything like QT, GTK, or wxWidgets or any tool kits. I'd like to learn native programming and this sort of defeats the purpose.
No you don't. Back in an early version of X11, like R1 or R2, I coded a complete "Hello, world" program in Xlib alone.
Roughly 700 lines of C.
You don't want to go there.
I guess you could write C code directly against Xlib, but you'd end up recreating all the functionality that GTK+ or QT provide that X doesn't alone.
Unix (and by extension, Linux) doesn't actually define anything to do with GUIs. X, which is commonly used, doesn't define anything to do with widgets or styles or anything of that nature - it's concerned mostly with drawing primitives and event handling. Essentially, if you wanted to write in pure X, you'd be defining the shape and behaviour of every element on screen. If you were crazy enough to abandon X, you'd be working at the graphics framebuffer level...
You're better off using some toolkit - if you're looking for light-weight, why not try FLTK?
GTK, QT and wx are toolkits that build on X to provide a friendlier API.
If you don't use an existing toolkit you'll need to write things at a very low level - directly handling mouse and keyboard events. If you want a button or a textbox you'll have to write it yourself using the low level xlib primitives.
Before trying this you're probably better off picking the toolkit of your preferred desktop environment and starting with that.
There is simply no such thing as "native" in this case. Windows and OS X just have an official option, while X does not.
The "native" interface for Linux & most other Unix-like OSs is Xlib, the lowest-level C API for X11.
GTK, Qt & others are all (so far as I know) implemented in terms of Xlib at their core. As others have said, Xlib gives you maximal control but you'll have to work for it (and others may run circles around you in terms of delivering a product).
As a point of reference, I personally implemented a fairly feature-rich & modern (i.e. flowable) cross-platform (Win32 + X11) GUI library in C++. Total count is about 29 KLOC of C++, of which about 2500 lines each was required for the X11 & Win32 shimming. The rest is for platform-neutral Widget implementations. Unless you're prepared to make a commitment like that, I strongly recommend going with one of the higher level libraries (Qt would probably be my choice, though I can't stand the preprocessor approach).
BTW, a big plus for Xlib is its raw portability--any Unix box with a screen will have it, and it can be made to work on Windows & OS X as well.
I feel it necessary to counterpoint the unanimity of the other answers here. X11 is indeed low level. But to "truly" understand what's going on, you should have some familiarity with how X11 works. Since all the toolkits work on top of X, you're using it whether you like it or not. There is nice tutorial online somewhere that I'm too lazy to search for. It guides you through building a simple Hello World. To do it, you'll have to learn how to create a window, request events, map the window, and process events in a loop. You could even go so far as to order some used books on Amazon. The O'Reilly vols 1 and 2 (for now get the cheapest editions, but nothing earlier than X11R4) are essential for reference and to get the full story of how the pieces work together. For learning, however, the best book is X Window Applications Programming by Eric Johnson and Kevin Reichard.
At some point along this journey, as everyone else says, you will find you've had enough. Two pages of code just to select a visual, and then you still have to populate a colormap before you can paint your custom bitmap. And then two days of rewriting and debugging to realize that it all does work; you just forgot to XFlush()!
The struggle is important, because you'll appreciate the toolkits more once you find the one you like.
I would suggest lesstif/motif as well. It also builds on top of X and the learning curve is, in my opinion, isn't as steep as GTK or Qt. The UI's you build with it aren't going to be as sophisticated as ones you could build with GTK or Qt though. More information can be found here.
As others have mentioned you probably don't want to X it's a pain.
Why not choose one among, say, Qt, wxWidgets and GTK and learn its internals, rather than its API? I do not mean just for the sake of it, but with the aim of contributing to the parts you find most appealing. In this way you'd fulfill your goal and get to do something useful, for you and also for others. I think this would be more rewarding than assigning yourself the rather artificial task of building an application with what amount to the wrong tools.
oh yeah, there is such "native" things:
FBUI, svgalib, directfb, exa(kdrive), SDL, Allegro..+Wayland, although not mainstream.
http://home.comcast.net/~fbui/
http://www.svgalib.org/
http://directfb.org/
http://xorg.freedesktop.org/wiki/ExaStatus
+
http://wayland.freedesktop.org/
Related
I've had much experience writing in Java, python, C#, and C, mostly for hobby. In all of the applications I've coded that involve displays (simulations, graphers, etc.), I've always just used the stock "Canvas" class of whatever framework I'm using (Swing Canvas, .NET Canvas, pygame once for python).
The downside of this is that all of these have slightly different paradigms in drawing.
I'm starting a project in C++ and was wondering what the best solution is for cross-platform drawing. OpenGL is obviously very low level, but some sort of library on top of OpenGL would be good. I've heard of/read about things like Cairo, SDL, etc., but don't yet know what to go with. I'm already using wxWidgets for interface, but would prefer to use something more standard instead of just a wxWidgets canvas. Obviously, the ability to draw lines and shapes is important, not just display pictures or whatnot.
Thanks for any direction!
I would consider using Qt, and notably its Graphics View framework. (Qt works on Linux, Windows, MacOSX).
SDL is SimpleMedia Direct Layer, which is basically a common interface to interface with the framebuffer and audio devices. If you wanted to create windows and such, it doesn't have general purpose constructs that work cross-platform.
Cairo is for drawing graphics, but still operates at a level that's lower than what WxWidgets provides.
C++ doesn't provide anything standard, so either you go with some platform specific, or you use a cross platform library like Qt (already mentioned by Basile) or stick with wxWidgets. Both are popular and widely used, though Qt is probably much more well-known and used (though that is just opinion). I've used Qt for work and it is very much cross platform and pretty easy to use (but very extensive, so prepare to read a lot of documentation). Luckily it also has a lot of documentation and many examples available.
Plus, both wxWidgets and Qt have bindings in many languages, so you could take the knowledge with either and use it with many other languages.
Open Frameworks is very easy to use and comes with a lot of examples...
it's platform independent and somehow reminds me of processing
I am producing a piece numerical software in C++ and want to add a GUI (mainly for Windows). I know how to produce GUIs using comfortable editors in modern languages like Java or .NET. Now my question is what is the easiest and most comfortable way to add a GUI frontend for my program. In the choice of the tools am completely free (open source and portability would be nice), but please also keep in mind how much boilerplate code and interfaces that have to be maintained are required if the GUI is implemented in another language (Like C#).
Please don't suggest switching the whole project from C++! And note that the program does not require not much interaction between the C++ code and the GUI.
The statements about ISO C++ in this answer's comments are poorly edited. None of the solutions presented here would impose on the computational code a requirement of changing to a different dialect of C++. The GUI code itself might be another story.
The answers about using Windows Forms with managed C++ are probably the most practical. A lot of the UI-related code would be in a dialect (extension) of C++ where the .NET-garbage-collected pointers would be living alongside the traditional ISO C++ pointers. I haven't used this method but from what I read it might be better than what I have used.
MFC might be more practical if you don't want to invest in .NET knowledge for this task. It uses standard C++ constructs to wrap the Windows API. The Windows API uses a particular calling convention which C++ doesn't normally use, and it takes an extension to C++ to work with that, but this is no different than having a C++ program that calls some functions that are extern "C". Visual Studio has a GUI layout tool that is really good at layout of dialogs and at interfacing the dialog widgets to variables that reflect the state of the widgets. I've used this. If you can boil your GUI down to a dialog box then this would be a great option, otherwise you'd be using one of MFC's layout-managed windows.
Obviously the above options do not handle other platforms you might have in mind.
There are also various toolkits that were born on other platforms and have been decently ported to Windows. GTK, QT, FLTK, and WxWindows come to mind. I haven't used any of the dialog-layout/application designer tools that work with those, and I haven't used QT at all. When I last reviewed QT it had a special preprocessing pass for the GUI code. Other than that these portable tool kits are pure ISO C++ as far as I know.
As a really-out-there option one could program to the X Window System protocol using "libx". As far as I know this would involve no non-ISO C++ code.
Qt is a decent choice. It's stable, has a wonderful C++ interface (as opposed to MFC) and has a convenient designer tool.
The overhead of learning it from scratch might however be more that what you're willing to invest. It does have a certain learning curve.
wxWidgets would a good choice for a cross platform GUI for C++
As much as I love C++, it's difficult to build a GUI with. I'd build a quick C# WinForms application which would let you use things like Visual Studio's visual designers (Drag and drop buttons and such), and call your C++ application using P/Invoke.
C++ will often produce smoother and nicer GUIs, but it takes a bit more work out of the box.
If it's going to be just a simple GUI consisting mostly of standard controls I would do it with MFC. It may be outdated and was never really good, but it's still useful to get a native Windows GUI up and running quickly.
I have to chuckle at all the ways to skin this cat. Life is good. My response is a product I manage. XVT can do it for you. The easiest way is let us do it for you or give you a template to get there. It's just a matter of if you have more money than time. Then I'd look at us. It would be the fastest and least amount of effort on your part.
MFC Dialog Based application could answer the needs.
Depending on what you need, there's a nice imgui made by Mikko floating around that you can simply plug-in and use fairly quickly. It's done in opengl though so it won't be your standard windows-gui but it's really small and really easy to work with. You can download r'lyeh's version from here: http://code.google.com/p/colony9/source/browse/include/goo/imgui.h.
That's the easiest and most comfortable way I know, it is dependent on SDL though.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Gui toolkits, which should I use?
I've got a fair bit of C/C++ experience - mostly for writing console application for Windows/Linux, and also a fair bit of C# experience - generally for writing WinForms applications etc.
I'm extremely impressed with with ease at which I can create a window in .net, for example something as simple as
Form form = new Form();
form.ShowDialog();
is enough to get a blank form up on the screen. In fact,
new Form().ShowDialog();
is technically enough as long as we don't mind losing reference to the form after it's closed.
I've tried writing some windows-based GUI stuff in C++ using windows.h, but not only does the learning curve seem a little steep but also the syntax is extremely verbose. Creating a simple window like the above mentioned single line .net implementation can easily exceed 2 dozen lines using windows.h.
But not only that, if I were to port the application over to Linux/Max (something which I can pretty much never do with .net, with the exception of hacks like mono etc), then I would need to rewrite 95% of the GUI code.
I'm assuming this is where frameworks come in, for example QT etc... (I don't really know much about gui frameworks, I'm afraid).
What GUI frameworks do you recommend? which are the most powerful and which are the easiest to use?
How do you generally tackle the task of coding your GUI in C/C++?
The closer to the metal (so to speak) that you are programming, the more difficult things get. WinForms (provided by the .NET Framework) is a pretty outstanding abstraction over the Win32 API, considering the complexity you've already seen that it involves for the even the simplest of tasks, like getting a window to appear on the screen. All of that is still happening in the background, of course (registering a window class, creating the window, etc.), you just don't have to write the code yourself.
It's interesting that you write off Mono as a "hack", but would consider a library like Qt. I'm really not sure on what basis you make the distinction. The Mono library is widely regarded as excellent when it comes to WinForms support. The biggest detractors are the same as Microsoft's own CLR implementation, namely that it doesn't produce truly native code, which is more irrelevant to performance in the majority of situations than one might think. Beyond that, some complain that Mono applications don't conform fully to the platform's UI guidelines (that is, they don't look and behave exactly like a native application would), but I have a similar complaint about applications written using Qt.
It seems like literally everyone recommends using Qt if you want to do GUI work in C++. As I mentioned above, it happens not to be my favorite library because I'm a stickler for using fully native controls and widgets provided by the platform you're currently running on. I understand that Qt has gotten a little better at this recently, but I still don't think it's up to my standards. If you're more flexible than I am (and I'll warn you that the average Mac user is not any more flexible than I am), and true platform independence is a big concern to you, it's probably the one you should opt for. Many people praise it for its design elegance and convenience, although I seriously doubt that even it offers the same simplicity as the .NET Framework's implementation.
If sheer simplicity and terseness of code is as important as the beginning of your question makes it sound, I highly recommend sticking with C# and WinForms. Things get harder as you start to remove layers of abstraction, and if you don't need the extra levels of control that doing so affords you, there's hardly any justification for making more work for yourself. Mono's Forms implementation is a perfectly viable solution for cross-platform applications, assuming your needs are relatively modest.
Beyond that, if you want to create a truly cross-platform application in C++ the right way, I recommend that you strictly separate your data layer code from your UI layer, and then write the UI using the tools provided by each platform you want to support. In Windows, your options are relatively open: .NET WinForms is a solid choice, native Win32 is a somewhat painful though merited option, and a handful of other libraries like MFC and WxWidgets can help to ease the pain of fully native programming (though not nearly as well as WinForms does). On the Mac, the only real option is Xcode, Interface Builder, and Objective-C, targeting the Cocoa framework. Linux/Unix-based systems are hardly my forte, but I'm given to understand that Qt is about as native a library as you can get. This sounds like more work than I think it is—a well-designed library should handle 80% of the work, leaving only around 20% that you have to do in implementing the UI. Beyond using truly native controls and widgets, I think the other big advantage afforded by this approach is flexibility. Notice how Microsoft Word looks very different (despite some superficial similarities) on Windows than it does on the Mac. And iTunes has become almost a paragon of excellent UI design on the Mac platform, but sticks out like a sore thumb on Windows. On the other hand, if you rolled out something like Windows Media Player on the Mac (and yes, it's been tried by Microsoft themselves, though without much success), Mac users will dismiss it as a complete abomination and probably be somewhat offended that you even tried. Not so good for the truly cross-platform-minded developer. All of that to say, if your app is anything but the simplest of utilities, you'll probably find that an entirely different interface is justified (and even expected) on each platform that you want to support.
No matter how great Qt may be, you're not going to get that with it.
Qt, hands down.
it's the most complete, most mature, fastest framework available. and on top of it, it's seriously multiplaftorm and your choice of commercially friendly open source or paid support.
I wrote a small program with Boost in c++. It works fine and so I want to give it a graphical interface so that it is easier to use.
In order to do so, I am looking for small cross-platform framework which provides native look and feel. Windows and Linux support would be enough, currently i do not need os x...
I used wxWidgets for some other project, but it was a pain to set everything up and ship this big library with the software.
But I was really amazed by the use of real native controls.
In order to keep the program small I also tried fltk, but it has an awful look.
I just need an simple framework without network support or other gimmicks.
So my question: Is there any framework out there which fits all the requirements? Or if not, which frameworks fits at least some of these needs?
Thanks in advance!
When it has the word "framework" in its name it's almost never small.
Anyway, graphical frameworks/libraries tend to be big, cause they need to handle a lot of stuff.
Qt is probably the best straightforward library for cross-platform GUI, but it definitely doesn't constitute a "small framework". On the other hand, on Linux systems, Qt will be most likely already installed. Plus it definitely pays for its size.
wxwidgets is fairly small as far as gui toolkits go.
And it's cross platform
http://www.wxwidgets.org/
You have mentioned it, but as far as cross platform toolkits go it's one of the smallest I've seen.
The only other suggestion I have is that you could wrap your code up into a C library and link that into another language. e.g. Use .NET on windows and mono for linux or even a java based app (although they don't always look very native to the platform). Then use your library from there.
Ultimate++ might contain what you need. (Although they make it sound in the FAQ as if their library is really big, it doesn't seem that bad to me.)
don't forget to check juce as well
Qt works amazingly, but is not very small. I've found there is a genuine lack of "small" cross-platform GUIs. You either might try to just abstract your GUI with #ifdefs all over the place, or use Qt/wx.
If you want it to be small, just write the GUI twice -- once in MFC and then in X. Your GUI sounds simple enough. Build up your own small abstraction that is just what you need.
There is a long list of both active and dead cross-platform C++ UI libraries here: https://philippegroarke.com/posts/2018/c++_ui_solutions/
Some of them are small and have a native look.
Like others mentioned you cannot mix the "cross platform" and small in size in the same sentence.
More work, smaller in size:
One solution I can suggest is to use native python binding for the UI portion. Since you are already using boost, it should be fairly trivial to have Boost.Python communicate between C++ space and python space. You already have python on Linux and its a 20-40MB package on Windows (can't remember how big the latest release is). But here you will have to use win32 binding on windows and gtk/qt bindings on linux, so more work. Nah, too much work to maintain, scratch this.
Moderate work, smaller in size but with non-native controls:
You can try to get clutter or freeglut to get your UI work done but I personally haven't used them so I don't know if they provide full native looks for your apps. But they are small in size compared to wx or qt.
Less work, bigger in size:
Use WxWidgets if you are already comfortable with it, otherwise I recommend Qt.
You can also have a look at some of the other offerings: http://en.wikipedia.org/wiki/List_of_widget_toolkits
Clutter: http://www.clutter-project.org/about
FreeGLUT: http://freeglut.sourceforge.net
ever heard of QT ???
http://qt.nokia.com/products/
i think it should fits all your your needs
Let's say the factors for valuing a choice are the library of widgets available, the slope of the learning curve, and the degree of portability (platforms it works on). As far a language binding goes, I'm using C++.
Thanks!
Pure X is quite hardcore these days, and not very portable. Basically, there are three major toolkits:
GTK+ (and C++ wrapper GTKmm)
Qt
wxWidgets
which are pretty comparable, so which to choose is a matter of taste. All three run on major three operating systems, although GTK+ on Mac and Windows is little bit awkward.
Qt is very good. It has quite large library (not UI only). Runs on a lot of platforms.
My personal favorite: Qt. It's cross-platform, it's very intuitive, it's extensively documented, there's bindings for many languages (the original is C++), and it's actually fun to develop with it.
Unless you're planning to write your own UI toolkit, there's really no point in using X directly anymore. Too hard, too much work.
On Linux, you have the two main choices - GTK and Qt. Both work fine. Qt works better as a native C++ toolkit than GTK itself, although GTKmm is a decent C++ wrapper for it. GTK tends to be usable from more languages than Qt, but that doesn't matter if you're using C++ anyway.
Both are cross-platform, but GTK feels somewhat alien on other operating systems, particularly on Mac OS X. Qt feels completely native on Windows, and fairly close on Mac OS X. It also provides a lot of other cross-platform functionality beyond the UI, such as threading, filesystem access, networking, and so on. Qt certainly seems to win on the portability front, at least.
Generally, go with something that's popular - there's more chance of finding good examples, pre-made applications you can dissect, libraries you can use, or even just finding help here.
As you requested a widget library for C++, then I would suggest QT, which was created for that programming language; GTK is good too, but it was created for C (as many of the libraries created for the GNU project which privileges C against C++).
Nobody uses X directly while creating an application; the only people who work directly with X is who is creating a new widget library, as already reported from other people here.
GTK+ it is: runs on most Linux distros and Windows too.
Of course there are also Qt and WxWidgets which are cross-platform.
In my opinion, the best C++ GUI toolkit is Qt http://qt.nokia.com
It's cross-plateform (windows, mac os x, linux), efficient and has quite a few nice extensions (Qwt, Qwt3d, QGLViewer, ...)
On the other hand, if you want to learn about GUI programming, I would learn quite a few systems, including GTK, Tk, Motif.
I suggest getting a generic book on GUIs. I have used Borland's, Windows, wxWidgets, QT, and PEG windowing frameworks. In summary, there is no standard, but GUI systems are Event Driven. Study up on Event Driven programming and that should give you an excellent foundation.
I think you can start with wxWidgets.
If you are most familiar with an interested in C, GTK+ is a good place to start. If C++, QT is probably a better choice. Your desktop of choice is also a factor. Gnome uses GTK+, KDE uses QT.
Raw X programming is much to low-level to start with. Very few programs are written directly against the X API directly. There have always been toolkits layered over it. Some of the older toolkits are Motif (Lesstif) and Athena. Don't try to start with those though, they are very old now.
I think there is another issue that you did not mention: where do you want to go with it?
do you want to "just learn it" or do you have a specific application in mind?
if you have an application, perhaps you also need to consider:
what OS you plan to run it on
how is the community supporting it: active? is it difficult to get help?
what performance do you need/expect?
how long do you plan to support it? (you might decide to run^H^H^Hmove away from C++ in a few years, and if so, would it make sense to use a different language - ie Java?)