I'm thinking of a library that would render all custom controls to a bitmap, so the final "gui image" could be applied to a windows form, osx window, or OpenGL texture, etc. Does this exist? I know the other libraries like QT are intermediates that finally use the OS specific control code. I want something that is completely independent of the OS code, and is just layering the custom control graphics onto a final image in memory. I'm thinking this would be the ultimate X-platform GUI library for C++. Thoughts?
PS: I know questions asking for opinions are not really kosher but I googled hard and couldn't find anything. I need some input here.
Thanks!
EDIT: Ok, to clarify that I meant GUI library, I meant the library is given mouse/keyboard events then handles the logic of the typical GUI chain, then it's final render target is a bitmap in memory that I can do stuff with after. It would be GUI library, not just a canvas.
Related
When I browsed the source code of Qt I didn't find how it actually draws a GUI component, but I know it uses OpenGL.
I want to know how does a GUI library like Qt draw its GUI components (ex : QPushButton ,QWidget)?
Can any one help me with a basic idea ?
In Qt-project site :
Qt is painting QtWidgets using QPainter, which uses (usually) the raster engine to draw the content. It is not using native OS calls, apart from few exceptions (file dialog, for example, which can be drawn either natively or using QtWidgets).
QtQuick is painted using scenegraph, so OpenGL. Also, no native OS calls here.
I think you either misunderstood (there are several meanings of the word “native” in computing) the stackoverflow post, or your information source is wrong.
OK, then to be clear: by “native” I’ve meant using native OS controlls, like wxWidgets library does: asking the OS to draw native scroll bar, or combo box, etc. Qt does not do this. It paints all the widgets itself, and only tries to mimick the looks of the OS it is running on.
But obviously, some kind of native OS calling is happening deep inside, in order to actually draw some pixels on the screen, and open native window container. But that is usually not important at all to high level UI developers.
You have a clear choice whether the widget should be drawn by the CPU or the GPU: widgets can use different painting methods (native, raster, OpenGL, for more see here! [qt-project.org]), and the user has choice which one should be utilised. Most people do not use that, though, because the default settings work well.
Thanks.
I have been using a few cross-platform GUI libraries (such as FLTK, wxWidgets, GTK++), however I feel like none fulfil my needs as I would like to create something that looks the same regardless of the platform (I understand that there will be people against building GUI's that don't have a native look on the platforms but that's not the issue here).
To build my controls, I usually rely on basic shapes provided by the library and make my way up binding & coding everything together...
So I decided to give it a try and do some opengl for 2D GUI programming (as it would still be cross-platform. With that in mind, I couldn't help to notice that the applications that I have written using wxWidgets & FLTK usually have a average RAM consume of 1/2MB, whereas a very basic openGL window with a simple background ranges from 6 to 9 MB.
This brings me to the actual question for this thread,
I thought that all the rendering of the screen was made using either opengl/direct (under the covers).
Could someone please explain or link me some sort of article that could give me some insight of how these things actually work?
Thanks for reading!
These multiplatform toolkits usually support quite a lot of backends which does the drawing. Even though some of the toolkits support OpenGL as their backend, the default is usually the "native" backend.
Take a look eg. at Qt. On Windows it uses GDI for drawing for its native backend. On linux it uses XRender I think. Same on Symbian and Mac. Qt also has its own software rasterizer. And of course there is an OpenGL backend.
So why the application using some of these GUI toolkits can take less memory than a simple OpenGL application? If the toolkit use the "native" backend, everything is already loaded in memory, because it is very likely that all visible GUI uses the same drawing API. The native APIs can also use only one buffer representing a whole screen in which all applications can draw.
However when using OpenGL you have your own buffer which represents the application window. Not to mention that an OpenGL application usually has several framebuffers, like z-buffer, stencil buffer, back buffer, which are not essential for 2D drawing, but they take some space (even though its probably the space in graphics card memory). Finally, when using OpenGL, it is possible that the necessary libraries are not yet loaded.
Your question is exceedingly vague, but it seems like you're asking about why your GL app takes up more memory than a basic GUI window.
It's because it's an OpenGL application. This means it has to store all of the machinery needed to make OpenGL work. It means it needs a hefty-sized framebuffer: back buffer, z-buffer, etc. It needs a lot of boilerplate to function.
Really, I wouldn't worry about it. It's something every application does.
I guess this question has been ask before, but I have not found sufficient answer to even start poking around. Most answer refers to catching WM_PAINT method directly and do custom rendering, or use a onwer draw object. However, I did not see a centralized place that has the info. to start researching. Hence, the question.
My goal is to create a very simple GUI program with custom look into it. I prefer the way winamp does their custom look that is customizable through "skins". However, I am not interested in using some cross-platform library like GTK+, QT or wxWidget.
I have some experience in system programming, but not much for GUI. I spent most of my time developing console applications, and I just started doing some QT development. If you can point me in the right direction, I'd be very appreciated.
PS: I am interested in both windows and linux environment.
Everybody,
Sorry for the late reply. I had a chance to have a quick talk with the original developer for winamp, and this is the quick answers I have:
Using skins: Artists create skins, developer will render the skins
To the OS (Windows), winamp is just one pretty box, nothing else. There is a container windows, and that's about it
All controls (button, label, list, etc) are implemented by winamp team themselves. All messages and stuffs are passed as relative position to the container window. WinAmp and the GUI engine has to decide if a button is clicked or if the label next to it is the target, etc.
Rendering artists skins created in XML
I do not have the details on if they use any libraries to do all that, but I am suspecting they do hook a window call directly, and do custom rendering themselves.
GUI skin usually using plug-in mechanism
I guess this is exactly what you are looking for:
https://www.linux.com/learn/tutorials/428800:weekend-project-creating-qt-interfaces-with-gimp?utm_medium=twitter&utm_source=twitterfeed
I also interested in creating custom look of window and widgets.
Speaking about widgets it's not hard, just need to create subclass (if you are using C++) or some widget and implement some methods like draw, handle etc. But this solution is good only if you use some high-level library like GTK, QT, etc. If you want to implement all controls by your own, you may get any graphics library, which can create window and do any graphics inside. For example, SDL2 + Cairo. SDL2 for creating window, Cairo for vector rendering controls/widgets. Both of this libraries are for win and linux. Another option is take opengl/vulkan + some lib for rendering window. It could be SDL2, SFML, GLFW.
If you really interested how it works on low level, then search Windows API for Windows and XLib or XCB for Linux/X.Org.
Speaking about window, I still investigate it. However I have one thought: you may create an empty window and then draw whatever you want. Then you need to add handlers for resizing window on the borders. But I am not sure if it's good solution, and if it won't freezes.
I'm making a game with OpenGL render api. Now I need in level editor. It should consist of lots of widgets parents/children etc, so it's hard to write need widgets by hands.
Any ideas about good gui-system which can be easilly connected with opengl? The most important part is gui editing. I really need some editing-tool for it.
Thanks
You should have a look to http://qt.nokia.com/ .
It is very easy to inject the OpenGL rendering into Qt widgets.
To easily edit your GUI, you can use Qt Creator ( http://qt.nokia.com/products/developer-tools ).
You have several options (and this has been answered before, but probably not exactly like this):
SDL: very good abstraction layer for audio, graphics and anything related. It will force you to write your widget stuff by hand.
Qt: has an OpenGL module that makes it easy to set up an OpenGL context. It will make widgets and everything very easy.
wxWidgets: same as Qt, but has slightly worse documentation and tools (if I might be so blunt)
I'd go with number two: it has a beautiful Designer tool to create Widgets with all the fancyness you'll need. OpenGL is also built right in.
If you're running Windows (can't confirm Mono will do it), another option would be to use C# and WinForms to make your life significantly easier.
Check out CEGUI:
http://www.cegui.org.uk/wiki/index.php/Main_Page
It defines its GUIs in XML and has editors for it.
I have an application that I want add some cool animations to show state changes. However, wxwidgets would be difficult because I'd have to program these animations in straight gdi. What's the best way to add these effect windows? Should I open a flash window and run a flash sequence or is maybe some other technology? Does .net have something I could code into a dll and run from my wxwidgets binary? I need something that is super easy to draw and set up the animation.
It's hard to say what the best approach would be to achieve "cool effects", but in most cases you would want a double-buffered drawing surface. That's what I've used in similar-sounding situations.
In wxWidgets, you would want wxBufferedDC.
You could prepare animation as a bunch of images (wxImage loaded from PNG, GIF, JPG or whatever files), and then use a timer and paint them on a control. Maybe it sounds like too much, you I believe you could do it in 50-70 lines of code.
Perhaps you just could make a single widget that has a custom paint-event that hand-draws the various widgets inside it? Then you could draw them at the appropriate locations/sizes without having to involve wxwidgets at all, it would just be a bunch of line-draw/rectangle-draw/text-draw commands to update the display for each frame of animation.