Is there some basic way to draw something in C++?
I know there are lot of engines, libraries etc. But these libraries have to use some most basic drawing function or whatever it is. I mean normally without any non-standart c++ libraries you are only able to make console applications. But the new libraries that can draw something, or atleast show something different than standard command line, have to use some basic function that allows to make something different without commandline.
I've heard about WIN32 API (I'm not targeting just Windows platform,vbut I'm using windows, still have Ubuntu(Wubi)). I just can't belive that the only way is to use WIN32 API.
So I guess my questions are as follows:
Are all GUI(or non-console) libraries using WIN32 API as basic?
Are linux developers required use some linux API for GUI?
(Sorry for my English, it's not my native language)
The operating system (on a modern computer) is in charge of the screen so you have to use it's functions to draw on the screen.
There are a whole range of libraries from very high level ones, where displaying a video is a single line of code, to low level ones where you can determine the details of every pixel.
As well as drawing on the screen a GUI library, or toolkit, is also responsible for handling keyboard and mouse, for dealing with other windows going over your window and for drawing all the standard controls such as file open boxes etc - that's why it's a bit complex.
See minimal cross-platform gui lib? fro some examples
Related
How can graphics functions be used in Visual Studio 2017 (C++) without using a BGI library? What header file is used? I want to use these functions to do things like drawing a circle.
The header file <windows.h> allows you to use Windows API for many functionalities including but not limited to functions that you will use to do graphics by yourself such as SetPixel and GetPixel and many others you can see the code in this repository which contains C++ implementations for various circle drawing algorthims.
You have quite a few options:
Windows API - Quite difficult to use but runs incredibly fast. This is perhaps the most difficult option due to how complex and no-hand-holding it is.
MFC - Microsoft's tools for C++ graphics. Not too easy to use but certainly easier than WinAPI. A lot of people don't like using this as it's kind of old and there are better stuff out there.
OpenGL/Vulkan/DirextX - These three are very similar technologies. They are based around using your graphics card for drawing, using small programs called 'shaders' which can be edited and compiled on the fly. Most games use one of these, and they run pretty fast. DirectX is Windows only, and Vulkan is pretty low-level. I would recommend OpenGL out of these three.
External library - There are many libraries you can use such as Qt, wxWidgets or SFML. All of these have their own pros and cons, but they all are third party libraries which bridge the gap between commands like 'draw a circle' and the Windows calls that go on under the surface.
Chromium Embedded Framework - CEF allows you to code the guts of your program in C++, then create the GUI using HTML5 and Javascript. Essentially it's a web browser connected to a C++ backend. Looks really nice but some criticise it for its resource usage, which is much larger than the alternatives.
I would recommend staying away from WinAPI and MFC and either use a third-party library (for simple GUIs) or OpenGL (for complex rendering i.e. games). If you're confident in web programming then you can go for CEF.
Im a newbie and want to know if this is possible so that it may help in my project which is only in c++. This is something similar to "uigetfile" in matlab.I use Ubuntu.
Thanks in advance.
You will need to add windowing capability to your program. The standard C++ language has no facilities for dialog boxes.
Windowing is platform specific. You may find windowing frameworks that are cross-platform.
Dialog box creation is either OS dependent or windowing framework dependent.
You didn't specify in your post the OS you are using.
Graphical User Interfaces (GUI or UI) are very complex systems that depends on many layers of hardware and software:
The hardware, especially the graphic card help for drawing and showing the result on screen.
Driver: To access the Graphic card. This is already platform-dependent.
Operating system: Give you facilities to user the graphic card and usually a library for drawing your GUI.
This mean, there is not a standard way to make a GUI, and that C++ stay outside of the mess.
However, some libraries abstract the different systems and provide single API for creating GUI, this obviously relay on the library having implemented the specific platform details, so it will never be 100% cross-platform.
Examples of GUI libraries are:
QT (e.g. used for KDE)
GDK (e.g. used for GNOME / UNITY)
wxWidgets
...
Is there any way to have a simple edit box in plain X11 C or C++ code?
By "plain X11 C or C++ code" I mean creating the control on a XCreateSimpleWindow created window as the CreateWindow("edit"..) equivalent in Win32 API.
If not, what are my options to have a simple edit box with the minimum amount of dependencies (i.e. no Qt please) for a simple edit box input dialog?
Plain X11 doesn't have such functionality - It is a low-level windowing toolkit (opening and maintaining windows, receiving input events, drawing to windows).
In case you are prepared to write such an edit window from the available primitives, you are fine. If not, you need to use some toolkit that does it for you. The simplest and most lightweight one providing such functions would probably be Athena widgets (in case you are not particularily choosy about look and feel).
X11 is a very low level protocol. It provides the ability to create individual windows, draw on them, and receive individual input events, and nothing more. That's it.
The job of providing high level user interface, like edit boxes, is for higher level toolkits, like Qt or Gtk. Those are the most common toolkits. There are a few less-popular ones too.
But the bottom line is that there are no "edit controls" of any kind, that you get with Xlib, the library you're using to talk X11 protocol. If the only dependency you want is Xlib, then it's up to you to actually implement the edit control, using your own code. If you don't want to use any common font handling libraries, like fontconfig and freetype, you will have to write the code to enumerate the X server's built-in fonts, handle keyboard input, and draw your edit control. Just the job of translating the somewhat obscure keyboard encodings used in X11 into something usable, like UTF-8 or unicode, will take a few hundreds of lines of code.
So the answer here is: use Qt or Gtk.
As low level alternative for X widgets you can use Xaw library, or Motif library or Xforms library.
Is it possible to write GUI application without using GUI toolkit ? As the GUI toolkit like GTK+ itself is written in c language, when there were no such toolkits at starting so how could programmers developed GUI apps only using c or c++ without using such toolkits? How can one write Gui application in c or c++ without using any GUI toolkit?
You can program Windows GUI applications using the Win32 API directly, without using any separate toolkit like GTK+. One reference on how to do that is here: http://www.winprog.org/tutorial/start.html
It's not so common these days, and not for the faint of heart.
Doing GUI stuff at the API level in Windows is not difficult, but involves a lot of work.
As a starting point you can check out my old Windows API programming tutorial “Lessons in Windows API Programming (C++)”.
Going that route you would do well to obtain a copy of the 5th edition or earlier (not 6th or later) of Charles Petzold’s “Programming Windows”, which is considered the Bible on the subject.
You start with a frame buffer for the graphics, upon that you write a set of primitive functions to do basic geometry (lines, circles, polygons, bit copies). Then you create an event queue, and a way to populate it with input events (keyboard, mouse, etc.).
You'll also need to create font and text routines.
Those are the basics upon which any GUI are built, as basic guis are little more than boxes that take click events, and eventually keyboard events.
It's a lot of work.
If you want to look at GUI programming at a lower level, consider looking up are it was originally done in the primitve OSes (such as early Windows, early Mac OS, early X Windows).
Mac OS made much of the work explicit. It offered a Window Manager, and other high level controls, but with a bit of study you can see how these were built on top of Quickdraw (MacOS graphics primitive library).
None of this addresses the modern issue of GPU acceleration and the like, that's a completely different layer of complexity to the problem.
As a fan of the cross-platform text editor, Sublime Text 2, I've been doing some research into how it was developed. The developer has noted that it's 99% c++ with some GTK for linux and that it uses a custom UI Toolkit he calls "Sublime GUI". This is a quote from the dev
Sublime Text 2 itself uses a custom UI toolkit. There are a lot of apps where this may not make sense, but it's not such an unreasonable choice for Sublime Text, where I always knew that a lot of the UI controls were going to have to be custom no matter the toolkit (e.g., the text control and tab controls). The UI toolkit sits on top of a cross platform abstraction layer, which is more a union of platform functionality rather than lowest common denominator.
My question is, what are some options for a cross platform abstraction layer? I assume this is at a lower level than GTK, QT, SDL. I'm trying to figure out how one would create a custom UI toolkit that would be cross platform and only have to write code once.
I appreciate the benefits of a UI Toolkit, but if I wanted to get my hands dirty and have support for my application on Windows, Linux, Mac, I am not sure where to start.
I guess the most important question is how to draw and get keyboard and mouse events.
As I see it there are two approaches for drawing:
Create an OpenGL context and draw your widgets with OpenGL. Like glui.
Use the native drawing infrastructure. Like GDI+ on windows, XLib on X11.
Of course you would need to implement certain things for each platform. With OpenGL you need to write the context (WGL, GLX, ..) handling for each platform, whereas with the native drawing infrastructure you need much more work. Since all drawing infrastructures are unique, you probably want to write an abstraction for the drawing and then implement your widgets with your drawing abstraction layer.
As for the event handling, I think you would also need to write your own abstraction because the event handling is unique for each platform.
Lastly, you should also have an abstraction layer for creating the main window in which you draw your widgets and from which you get the events.
When going with OpenGL, you could start with glut, which already handles window creation and event handling.
Bear in mind, I have never implemented anything like this. However, I would probably try the OpenGL approach because I believe it is less work to reach the goal.
There are many GUI toolkits that work across platform (Tk, QT and GTK to name a few)
If you wanted to write your own though, it wouldn't have to be a lower level toolkit than GTK, QT or similar.
You could expose an interface similar to this
void draw_window(mywindow *mw, char *name){
non platform specific code goes here (maybe arg parsing, etc.)
#IFDEF windows
windows specific code goes here
#ENDIF
#IFDEF macosx
mac specific code goes here
#ENDIF
#IFDEF linux
linux specific code goes here
#ENDIF
non platform specific code goes here (tidying up, recording state, etc.)
}
Within each of the platform-specific sections you could dispatch to a gui toolkit for that platform or use whatever interface is available (ie; X11 for Unix).
When you compile the code you specify the target platform, and this determines which IFDEF sections get compiled in.
Of course this is overly simplified, and great care would have to be taken so that the interface you expose isn't too painful to map onto the native equivalents.