Are there any out there that are easy to get ahold of? Preferably free, as I don't have any money to spend right now.
What I'm trying to Accomplish
Basically, I'm writing a multi-platform application in native C/C++, and now that I have Linux installed, I feel as though I'm truly ready to make the "multi-platform" development go. Before anyone says "use SDL" or "Qt", note that I'm doing this for an application which I plan to go commercial with (Qt costs money for commercial applications). While SDL is good, I'm also looking to learn about window managers in general. I feel as though the best way to learn how to communicate directly with the operating system is to write the application yourself.
So, are there any resources out there?
First of all X-Windows has nothing to do with Linux.
X-Windows is both a graphical protocol and a GUI system built up around it. X runs on most OSes including Windows and Mac. The most typical scenario is for an X application to run on a multiuser computer running a UNIX-like OS (for instance Linux) and for the users to interact with it using an X-server which runs on either an X-terminal or a desktop OS. The X-Server is a standard piece of the X-System. If you install an X-Server on Windows then you will be able to interact with graphical applications running on one or more other computers.
It sounds like you want to focus on building the X applications, not the device drivers or the server or any other part of the X-system. Linux is as good a choice as any, but the books and documents that you need were likely written using Solaris or BSD UNIX. But it's the same API.
Since X has been widespread since at least the early 90's, look for books in secondhand shops and university jumble sales. Advertise on Craigslist for X related books.
The lowest level API for X is called Xlib. Toolkits like GTK and QT are layered on top of this so studying their code is a good way to learn how to do things. But there is also something called the X-Toolkit that runs over Xlib and used to be the foundation layer for GUI toolkits like Motif and others. If I were you I would start with X-Toolkit, to get familiar with all the component parts of X and how they interact. For instance, it will take you a while to get used to the fact that a window manager which manages the windows on an X-Server display, doesn't run on the X-server but runs on a remote system. Or that you can have apps running on Linux and OS/X and Solaris all displaying their windows on the X-server on a single Windows box.
Google X Toolkit intrinsics to get all kinds of info including free reference manuals.
As you read more about it you will come across a lot of other unique terms that you can google to get additional info and a broader perspective. Don't spend too much time with old toolkits like Athena Widgets or Motif.
Since there were more people programming X in the early days of the Internet than today, the USENET FAQs are still a good source of introductory tips, e.g. http://www.faqs.org/faqs/Xt-FAQ/
You can write your app as a server in C. Call it Engine. No need to think about the User Interface. After that you can create interface in Qt. The communication protocol will be public (or private) and your Qt application will be open-source. Later if you like you can create many more interface to your application. Such as web interface, Gnome interface, C#.NET interface etc.
Related
From my understanding, Qt and GTK on the Windows and OS X side are just wrappers around the native GUI libraries, like for OS X it wraps around Cocoa, and for Windows around Win32. However, my question is, how do they integrate with Linux? Do the Desktop Environment developers have to implement special libraries for either Qt or GTK or how does it work? I have looked around but I can't really find the answer.
A few further notes.
Neither GTK+ nor Qt use the native widgets of Windows and OS X. They approximate the look and feel using native APIs, but internally everything is all done custom.
GTK+ and Qt are responsible for, and define, the themes available to programs on Linux. Desktop environments typically provide a way to change the theme globally for all applications, but how this is done is defined by GTK+ and Qt. For example, GTK+ 3 typically uses ~/.config/gtk-3.0/settings.ini to store this information (and there is a programmatic API to this file).
Qt has a bridge for GTK+ 2 themes via QGtkStyle, and the KDE developers maintain versions of their Oxygen theme for GTK+ 2 and GTK+ 3. (The previous sentence may change in the future, especially now that GTK+ 2 is long dead.)
Update 1: Unix systems only provide a way to reserve a rectangular region of the screen to do what you want with it, including drawing (as in plotting a bitmap image) to it. Drawing (as in drawing shapes) is done by hand. GTK+ uses a library called cairo to do its drawing; I believe Qt wrote their own (QPainter?). Both Windows and OS X provide drawing APIs (Windows has several; OS X has Core Graphics). (X11 does have drawing primitives, but I assume they are not expressive enough to be used for modern 2D graphics; I wouldn't know...)
The same applies to font rendering, though modern Unix systems tend to base their font rendering on some generally accepted base libraries (freetype, fontconfig, fribidi, harfbuzz). GTK+ uses Pango to do text layout (actually arranging blocks of text into lines and paragraphs) and drawing (Pango integrates with cairo); I believe Qt also uses its own (this time I'm not sure).
I wrote about what X11 does do some time ago.
On Linux (desktops and laptops) the graphical screen is generally displayed (at least that was the case in beginning of 2015) by the X11 server. Your GUI app is communicating with that server thru sockets, often locally on a Unix socket like /tmp/.X11-unix/X0. The X11 server is generally Xorg.
For some embedded devices like Android mobile phones or some gadgets (GPS in cars, automotive or medical device industry) it is different (DirectFB, framebuffer devices -which is used by the X11 server on your desktop, ...)
Some distributions are switching to Wayland (or perhaps to Mir). Since I don't know these much, I cannot explain the gory details. AFAIU, there is still some server involved (which, like Xorg, is the only user-land software component talking to your graphics card) and some protocol, and major toolkits like Qt & GTK are been adapted to them (so if you code for Qt or for GTK, you don't care about those details, but you should upgrade your toolkit).
The graphical toolkits (Qt, Gtk) are interacting with the X11 server (or the Wayland one) thru some specific protocol(s), e.g. X Window System protocols for X11. For historical reasons, these protocols are quite complex, and practically require to follow some conventions like EWMH.
See also this answer to a related question. I explain there that X11 is not used today as it was in the previous century; in particular the server-side drawing abilities of X11 (e.g. Xlib's XDrawLine or XDrawText) are rarely used today, because the toolkit is drawing a pixmap image client side and sending it to the server.
Notice that you might consider giving not a GUI interface, but a Web interface, to your application (e.g. using libraries like libonion, Wt, ....); then your application becomes a specialized Web server, and the user would go thru his browser (in his desktop/laptop/tablet/phone) to interact with your app.
Practically speaking, user interfaces are so complex that you really should use some toolkit for them (Qt if coding in C++). Coding from scratch (even above Xlib or XCB for X11) would requires years of work.
There exist several other widget toolkits above X11, e.g. FOX toolkit, FLTK (but most of them have much less features than Qt or GTK).
There's no clear answer. There's no native GUI on Linux, as there is on Windows and OSX. X11, which is windowing system used on Linux (this applies to Wayland and Mir too), is very basic and low level and is responsible mainly for handling input devices and allocating windows to applications. It does not provide any GUI components such as buttons or text fields. In that sense, both Qt and GTK+ can be seen as "native" Linux GUI libraries. To make matters worse, desktop environment plays a part too. On Gnome, GTK+ can be seen as more "native", whereas on KDE QT is more "native".
I need to develop an application that can be run on both Windows and Mac OS X, is a application "monitor" that needs to display data in real time, connection over ethernet. I'm interested in the performance and graphics. I know very well the c++. can you help me in choosing a development tool?thank you
JUCE is not just about for Music industry. Its for all. I have used it in Music softwares, Image processing and only GUI applications too.
Its a well built library which supports all platform.
you need not to create different project files for the application. JUCE creates it for you.
And its pure C++.
I would say your two choices are Juce or Qt. Juce is geared toward audio and graphics, letting you get your hands on creating fast and powerful DSP algorithms. Although Juce's largest following is with developers making music software, it's fully capable of making general purpose applications with the same ease as Qt. Qt does have advantages resulting from it's greater adoption; you will find plenty of tutorials, books and courses on Qt but hardly much on Juce at the moment.
Hopefully that will change soon as Juce was bought out by ROLI and will likely have more resources soon.
Both Windows (Win32 API) and OS X (Cocoa) have their own APIs to handle windows, events and other OS stuff. I have never really got a clear answer as to what Linux’s equivalent is?
I have heard some people say GTK+, but GTK+ being cross platform. How can it be native?
In Linux the graphical user interface is not a part of the operating system. The graphical user interface found on most Linux desktops is provided by software called the X Window System, which defines a device independent way of dealing with screens, keyboards and pointer devices.
X Window defines a network protocol for communication, and any program that knows how to "speak" this protocol can use it. There is a C library called Xlib that makes it easier to use this protocol, so Xlib is kind of the native GUI API. Xlib is not the only way to access an X Window server; there is also XCB.
Toolkit libraries such as GTK+ (used by GNOME) and Qt (used by KDE), built on top of Xlib, are used because they are easier to program with. For example they give you a consistent look and feel across applications, make it easier to use drag-and-drop, provide components standard to a modern desktop environment, and so on.
How X draws on the screen internally depends on the implementation. X.org has a device independent part and a device dependent part. The former manages screen resources such as windows, while the latter communicates with the graphics card driver, usually a kernel module. The communication may happen over direct memory access or through system calls to the kernel. The driver translates the commands into a form that the hardware on the card understands.
As of 2013, a new window system called Wayland is starting to become usable, and many distributions have said they will at some point migrate to it, though there is still no clear schedule. This system is based on OpenGL/ES API, which means that in the future OpenGL will be the "native GUI API" in Linux. Work is being done to port GTK+ and QT to Wayland, so that current popular applications and desktop systems would need minimal changes. The applications that cannot be ported will be supported through an X11 server, much like OS X supports X11 apps through Xquartz. The GTK+ port is expected to be finished within a year, while Qt 5 already has complete Wayland support.
To further complicate matters, Ubuntu has announced they are developing a new system called Mir because of problems they perceive with Wayland. This window system is also based on the OpenGL/ES API.
Linux is a kernel, not a full operating system. There are different windowing systems and gui's that run on top of Linux to provide windowing. Typically X11 is the windowing system used by Linux distros.
Wayland is also worth mentioning as it is mostly referred as a "future X11 killer".
Also note that Android and some other mobile operating systems don't include X11 although they have a Linux kernel, so in that sense X11 is not native to all Linux systems.
Being cross-platform has nothing to do with being native. Cocoa has also been ported to other platforms via GNUStep but it is still native to OS X / macOS.
Strictly speaking, the API of Linux consists of its system calls. These are all of the kernel functions that can be called by a user-mode (non-kernel) program. This is a very low-level interface that allows programs to do things like open and read files. See http://en.wikipedia.org/wiki/System_call for a general introduction.
A real Linux system will also have an entire "stack" of other software running on it, in order to provide a graphical user interface and other features. Each element of this stack will offer its own API.
To aid in what has already been mentioned there is a very good overview of the Linux graphics stack at this blog: http://blog.mecheye.net/2012/06/the-linux-graphics-stack/
This explains X11/Wayland etc and how it all fits together. In addition to what has already been mentioned I think it's worth adding a bit about the following API's you can use for graphics in Linux:
Mesa - "Mesa is many things, but one of the major things it provides that it is most famous for is its OpenGL implementation. It is an open-source implementation of the OpenGL API."
Cairo - "cairo is a drawing library used either by applications like Firefox directly, or through libraries like GTK+, to draw vector shapes."
DRM (Direct Rendering Manager) - I understand this the least but its basically the kernel drivers that let you write graphics directly to framebuffer without going through X
I suppose the question is more like "What is linux's native GUI API".
In most cases X (aka X11) will be used for that: http://en.wikipedia.org/wiki/X_Window_System.
You can find the API documentation here
XWindows is probably the closest to what could be called 'native' :)
The linux kernel graphical operations are in /include/linux/fb.h as struct fb_ops. Eventually this is what add-ons like X11, Wayland, or DRM appear to reference. As these operations are only for video cards, not vector or raster hardcopy or tty oriented terminal devices, their usefulness as a GUI is limited; it's just not entirely true you need those add-ons to get graphical output if you don't mind using some assembler to bypass syscall as necessary.
Wayland
As you might hear, wayland is the featured choice of many distros these days, because of its protocol is simpler than the X.
Toolkits of wayland
Toolkits or gui libraries that wayland suggests are:
QT 5
GTK+
LSD
Clutter
EFL
The closest thing to Win32 in linux would be the libc, as you mention not only the UI but events and "other os stuff"
GUI is a high level abstraction of capability, so almost everything from XOrg server to OpenGL is ported cross-platform, including for Windows platform. But if by GUI API you mean *nix graphics API then you might be wandering around "Direct Rendering Infrastructure".
I want to create a C++ UI framework (something like QT or like ubuntu unity Desktop)
How is programmed , is it using OpenGL or lets take plasma ui of QT (how is this programmed )?
Direct answers , reference links anything will be helpful.
Some interesting opengl based UI I founf on the web
LiquidEngine
http://www.youtube.com/watch?v=k0saaAIjIEY
Libnui
en.wikipedia.org/wiki/Libnui
Some UI frameworks render everything themselves, and work based on some kind of clipping-window-within-the-host-systems-screen. Non-display aspects (such as input event handling) have to be translated to/from the host systems underlying APIs.
Some UI frameworks translate as much as possible to some underlying framework.
wxWidgets can do both. You can choose a native version (e.g. wxMSW if you're on Windows) and most wxWidgets controls will be implemented using native Windows controls. Equally, you can choose the wxUniversal version, where all controls are implemented by the wxWidgets library itself.
The trouble is that typical GUI frameworks are huge. If you want a more manageable example to imitate, you might look at FLTK. I haven't got around to studying it myself, but it has a reputation for being consise.
There are also some GUI toolkits that are specifically aimed at games programming, such as Crazy Eddies GUI. My guess - these are probably as idependent of the underlying API as possible, so that particular applications can implement the mapping to whichever underlying API they happen to target (OpenGL, DirectX, SDL, whatever) and can be the boss of the GUI rather than visa versa.
http://www.wxwidgets.org/
http://www.fltk.org/
http://www.cegui.org.uk/wiki/index.php/Main_Page
"no really, don't write your own wm or toolkit"
The #Xorg-devel guys on irc.freenode.org
doing one anyway means that you have to test against a wide range of more or less buggy WMs and X implementations, and that you have to frequently update to be compatible with the latest Xorg server and X protocol features (like Xinput 2.1)
understandably, the Xorg people are tired to support old, unmaintained toolkits and applications. They already have enough bugs.
The GUI frameworks are very dependant on a windows system, which dictates what is allowed and how windows are created and rendered. For example, pass a specific option to create a borderless or full-screen window.
Since you mentioned opengl and ubuntu, I guess you want to start on a linux platform. You should study xlib, for which you can find reference here.
Since the qt library is open source, you can download it and peek into it's sources.
A UI library isn't developed from scratch. It relies on the OS' windowing system, which relies on the driver from your graphics adapter, which relies on the OS kernel, which relies on... and so on.
To develop any software "from scratch", you can start by writing your own BIOS. Once you're done with that, move on to writing an OS, and then you should be just about ready to write the software you wanted. Good luck.
And this is assuming you're willing to cheat, of course, and use a compiler you didn't write from scratch.
Before you do that, it's worth that you spend one week on thinking:
1, Do you really know how to do it? I doubt that.
2, Do you really need to do it? I doubt that too.
I'm a long time Windows developer, and it looks like I'm going to be involved in porting a Windows app to the Mac.
We've decided to use Flex/Air for the gui for both sides, which looks really slick BTW.
My Windows application has a C++ DLL that controls network adapters (wired and wireless). This is written using the standard library and Boost, so most of it should work cross platform.
On the Mac, what IDE/complier do most folks use if they want to write C++? Also, can someone provide a pointer to whatever APIs the Mac has that can control WiFi adapters (associate, scan, disconnect, etc)?
Xcode is the IDE for Mac OS X, you can download the latest version by joining the Apple Developer Connection with a free Online membership.
I don't believe there are any supported APIs for controlling wireless networking adaptors. The closest thing would be the System Configuration framework, but I don't know if it will let you do everything you want.
Also, I would strongly recommend against trying to use Flex/Air for your application's user experience. It may look slick to you on Windows as a Windows developer, but when it comes to providing a full Macintosh user experience such technologies aren't always a great choice.
For one example, I think Air applications don't support the full range of Mac OS X text editing keystrokes. While not all Mac users will use all keystrokes, for those people used to them trying to type in a text field that doesn't handle (say) control-A and control-E to go to the beginning and end of field is like swimming through syrup.
For a new application that needs to be cross-platform, I'd strongly consider building the core logic in C++ while using Cocoa on the Mac and WPF on Windows to get the best user experience on each platform. Both Mac OS X and Windows have modern native user experience technologies that their respective users are getting used to, and also have good ways for C++ code to interoperate with these technologies.
The de-facto OS X IDE and compiler is Xcode. It comes with every Mac, you just install it from the OS X install CD.
Apple's developer site is the place to get more information on OS X APIs
Xcode and a custom GCC I believe...
xcode is the hotness, as people have already pointed out.
Having maintained a windows/mac codebase in the past, take a look at MVC.
So long as you keep the background logic distinct from the UI and from the platform-specific stuff (like file handling, networks, drawing to the screen, etc). That way, when you want to go to Linux in the future, you just have to write those platform specific components.
As for mac networking, are you on the level of connecting and so forth? Why not just let the OS handle that, and then you just see what connections are available? Why bother with whether or not the connection is wired or wireless? Because the OS has a lot of those tools already built in and users are used to making sure that the connection is there to do work, it seems odd to have an extra program to want to manipulate the network.
Xcode is used a lot, as far as I know the combination editor (e.g. Textmate), command line gcc is in fairly heavy use too. (that's what I do on OS X)
For all API needs head to Apple's developer site e.g. the networking API's