OpenGL is great in creating UI (specially in games) and it is highly portable. Is it unusual that an ordinary (not graphically intensive) application uses OpenGL for its UI? And if not, why? Is it about performance or ease of use?
For example, an Apple developer can use ready to use buttons and sliders, etc provided by Apple; he can also create the UI using OpenGL. The second method makes the code more flexible and portable. Why people don't do this?
Does using OpenGL makes sense if portability is our goal?
There's a lot more to UI than graphics.
As one example fonts. Rendering Chinese, Japanese, Korean, Arabic, Thai in the right directions with the write strokes etc it a TON of work. There are whole teams dedicated to that topic at Microsoft, Google, Apple, Adobe and other companies. If you go straight to GL you're going to have to solve that problem yourself.
Another example, native controls. iOS users expect certain controls to work a certain way. Android users expect something different. For a game that's usually not a problem, games usually have a very unique UI. Apps on the other hand are generally expected to stick to the conventions of their target platform. Generally users get upset when the controls don't match their native platform. Using GL for your UI means you won't get the native controls.
Similarly text editing is a very platform specific feature. Is it drag to select, right click to select, hold to select? What keys go which way, how do they work? Is it Ctrl-V or ⌘-V. All of that is platform dependent as well. You can use the native text editing controls and have the problem solved or you can use GL and have to reproduce not only all the code to edit text but try to make it work the right way on each platform in each configuration. Does your GL text editor handle Japanese keyboards? German Keyboards? Does it handle Input Method Editors for CJK and others?
So, it's more a matter of the right tool for the right job. There are whole UI platforms written on top of GL. Before Metal OSX was probably one of them (or still is?) But if you skip that and build your UI directly on GL you'll end up having to implement all those in-between pieces.
Certainly GL might be the right way to go for certain non-game apps. Paper comes to mind as an app that could be 98% GL and therefore gain portablility. On the other hand Evernote is probably on the far other side. It needs to handle every language, different fonts, input for users with disabilities, etc. All of that is built into the OS, not GL.
Yes, what you suggest is possible. Just have a look at Blender. Blender implements its own UI using OpenGL, for the exact portability reasons you gave.
However there's a lot more to user interfaces than just getting things drawn to the screen. Event management, input handling, interoperability with other applications. All that depends on functions that are not covered by OpenGL.
But there are cross platform application framework libraries, like Qt. And the whole drawing stuff makes only a small portion of what those frameworks do.
One problem you run into when using OpenGL for drawing the GUI though is, that there's a huge variation on the OpenGL profiles supported by the systems out there. It can vary from a mere OpenGL-1.1 software fallback on a old Windows XP machine, over OpenGL-1.4 on Windows Vista machine with only the default drivers installed by the Windows setup, up to OpenGL-4.5 on the same machine once that user installs the proper drivers. And the way you use OpenGL-4.5 is largely incompatible to OpenGL-1.4.
For a UI toolkit written with a OpenGL backend this means that you must implement at least three codepaths: A OpenGL-1.1 variant that uses the fixed function pipeline and client side vertex arrays. A OpenGL-3 compatibility profile. And a OpenGL-4 core profile.
This much more work than just using the OS specific methods, which you have to use anyway to create the window and get user input with.
I'm not very familiar with Linux, but have some experience with C and C++. I would like to get in touch with some Visual FX and/or UI development (either C or C++). I was wondering if there is a possibility to access the GUI elements of the Desktop on Ubuntu's Unity UI.
What I especially would like to do, is to render animations on the desktop or windows or all over the screen. (particle effects when clicking with the mouse or so).
Can anyone point me in the right direction? (Libraries, Documents, ...)
I think Desktop Effects have to be designed specific for the corresponding Window Manager.
I think unity uses (some sort of) compiz, so you should look into compiz plugin development.
A lot of "i thinks" so i am not really sure if that'll help you, but good luck.
You want to learn a lot more about GTK. There are lot of documentation on line (and some books also). You might code in C++ using GtkMM (but you could consider Qt also). GTK itself is coded in C, with well designed coding style and convention. Looking inside its source code is worthwhile.
I am trying to create a simple popup box that appears when my C++ program starts that will allow the user to enter the width, height, and length of a cube that will then be displayed in a separate window. I have been searching for a very long time, and I have yet to find a solution that will allow me to do this. Can this be done using C++, OpenGL, and GLUT? Or do I need another library to allow me to do this.
Thank you.
Jordan
Edit: I am programming a cross-platform program and cannot use Win32 to accomplish this, nor any other Window-specific function.
What are you are looking for is a graphical user interface.
There are many libraries available that interface with various input methods (for keyboard and mouse) and provide graphical output. Each one has it's own model.
There are various models, but the most common one is hierarchical.
If you are looking for a learning experience, I suggest you do some Googling on how to make your own GUI.
If you are simply looking for a convenient library that does the hard-yards for you, I strongly recommended AntTweakBar:
AntTweakBar is a small and easy-to-use C/C++ library that allows programmers to quickly add a light and intuitive graphical user interface into graphic applications based on OpenGL, DirectX 9, DirectX 10 or DirectX 11 to interactively tweak parameters on-screen....AntTweakBar works with GNU/Linux, Windows and OSX
It was designed not as a monolithic batteries-included do-all library (such as Qt, another alternative), but as a simple and lightweight tweaking interface (hence the name).
There are several examples available and it's API is quite simple, so it should be reasonably easy to pick up.
There's also GWEN. It is not a well known library, but I find it extremely versatile and easy to use.
Facts- Coded in C++- Fully Namespaced- All standard window controls- Behaves like you'd expect- Lightweight (No XML readers, no font loaders/renderers, no texture loaders - your engine should be doing all this stuff!)- Easy to integrate (comes with renderers for Windows GDI, Allegro, OpenGL, DirectX and SFML)- Totally portable & cross platform- Doesn't need RTTI- Released under a "do whatever you want" MIT license.
Opinionated note: I prefer GLFW over GLUT. It provides a nicer model, and is still in active development (unlike GLUT which has not been updated in a significantly long time). At least use freeGLUT
You need to use another external gui library to do it. If you're doing it for windows, MFC is a good option. Or check library OpenGL User Interface Library.It's cross platform.
Here some libraries
Maybe this link helps you
Your statement saying that you wish to have a popup box implies your wish to use the underlying windowing system, regardless of the OS.
If you want to be cross-platform, there are quite a few libraries you can use that either emulate or actually use the underlying windowing system, such as wxWidgets.
If using such a library is not an option, you can always use the OpenGL window to draw text and emulate your popup yourself, but that's a bit more work, imo.
I'm interested to know if gtkmm w/ ATK (or whatever) works with MSAA like Qt does. We're looking right now at switching toolkit from WX and it turns out that our testing software relies on MSAA to do it's thing (something I wish I'd known 3 years ago when we picked WX to begin with). Of all the GUI toolkits, I prefer GTKmm mainly due to it's use of signals and slots but in a way much more expressive and generic than Qt's....and without the need for the extra build step that requires the Qt VS plugin. The designer is much better too.
So I'd like to use GTKmm but the only discussions and google stuff I can find on the topic are 3+ years old. They lead me to believe the answer is no, it doesn't support it and if it does it's really shoddy. But a lot can change in 3 years.
So, anyone that uses GTK or GTKmm on win32 know if it supports the windows accessibility framework?
I can’t say for sure but I would lean toward very little to no support. I use the Jaws screen reader SOFTWARE SINCE I’m blind. It uses MSAA quite heavily and GTK applications such as Pidgin are almost completely inaccessible. While I can read some of the text on a screen figuring out weather I’m in an edit field or weather a button is selected is impossible. If my screen reader can’t deal with GTK applications I assume your testing software will have major issues as well.
I don't know if this is still being tracked but I will second this assessment as another windows screen reader user. gnuCash was the app I tried and it was pretty rough going. Worked like a dream in Gnome with Orca though. Apparently, it's like this, if you want windows accessibility, use QT and WxWidgets. If you want Linux, use gtk+. QT is going to be accessible in Linux apparently though this is yet to be (not till gnome 3, I think). Pity you had to abandon WxWidgets. I personally like their widgets since it has those sizers which take much of the guess work out of placement of controls. Important when you can't see and you want to build a gui. Looks like about the only cross-platform accessibility solutions right now are Xul and SWT (Java, you know). Sad thing about WxWidgets is that this sort of thing was reported to them two years ago but nothing seems to have been done about it.
http://trac.wxwidgets.org/ticket/9785
I would be delighted to know that I am wrong about this. I doubt it, though.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I'm spending these holidays learning to write Qt applications. I was reading about Qt Designer just a few hours ago, which made me wonder : what do people writing real world applications in Qt use to design their GUIs? In fact, how do people design GUIs in general?
I, for one, found that writing the code by hand was conceptually simpler than using Qt Designer, although for complex GUIs Designer might make sense. Large GUIs might be possible using Designer, but with time they might become very difficult to manage as complexity increases (this is just my opinion). I also downloaded the AmaroK source code to take a peek at what those guys were doing, and found many calls to addWidget() and friends, but none of those XML files created by Designer (aside: AmaroK has to be my favorite application ever on any platform).
What, then, is the "right" way to create a GUI? Designer or code? Let us, for this discussion, consider the following types of GUIs :
Simple dialogs that just need to take input, show some result and exit. Let's assume an application that takes a YouTube URL and downloads the video to the user's hard disk. The sort of applications a newbie is likely to start out with.
Intermediate level GUIs like, say, a sticky notes editor with a few toolbar/menu items. Let's take xPad for example (http://getxpad.com/). I'd say most applications falling in the category of "utilities".
Very complex GUIs, like AmaroK or OpenOffice. You know 'em when you see 'em because they make your eyes bleed.
Our experience with Designer started in Qt3.
Qt3
At that point, Designer was useful mainly to generate code that you would then compile into your application. We started using for that purpose but with all generated code, once you edit it, you can no longer go back and regenerate it without losing your edits. We ended up just taking the generated code and doing everything by hand henceforth.
Qt4
Qt4 has improved on Designer significantly. No longer does it only generate code, but you can dynamically load in your Designer files (in xml) and dynamically connect them to the running objects in your program -- no generated code however, you do have to name the items in Designer and stick with the names to not break your code.
My assessment is that it's nowhere near as useful as Interface Builder on Mac OS X, but at this point, I could see using the Designer files directly in a program.
We haven't moved back to Designer since Qt3, but still use it to prototype, and debug layouts.
For your problems:
You could probably get away with using the standard dialogs that Qt offers.
QInputDialog or if you subclass QDialog, make sure to use QButtonDialogBox
to make sure your buttons have the proper platform-layout.
You could probably do something more limited like xPad with limited Designer functionality.
I wouldn't think you could write something like OpenOffice solely with Designer but maybe that's not the point.
I'd use Designer as another tool, just like your text editor. Once you find the limitations, try a different tool for that new problem. I totally agree with Steve S that one advantage of Designer is that someone else who's not a programmer can do the layout.
In my experience with Qt Designer and other toolkits/UI-tools:
UI tools speed up the work.
UI tools make it easier to tweak the layout later.
UI tools make it easier/possible for non-programmers to work on the UI design.
Complexity can often be dealt with in a UI tool by breaking the design into multiple UI files. Include small logical groups of components in each file and treat each group as a single widget that is used to build the complete UI. Qt Designer's concept of promoted widgets can help with this.
I haven't found that the scale of the project makes any difference. Your experience may vary.
The files created with UI tools (I guess you could write them by hand if you really wanted to) can often be dynamically loaded at run-time (Qt and GTK+ both provide this feature). This means that you can make layout changes and test them without recompiling.
Ultimately, I think both raw code and UI tools can be effective. It probably depends a lot on the environment, the toolkit/UI-tool, and of course personal preference. I like UI tools because they get me up and running fast and allow easy changes later.
The organisation I work for has ported its GUI application to Qt several years ago.
I think there are several aspects that are worth mentioning:
Working with Qt Designer, at least at that point, was not a realistic option: there were too many features that couldn't be done with Qt Designer;
Conventions and structure that had to be preserved prevented the use of Qt Designer;
Once you've started without Designer, it is probably difficult to return to it;
the most important aspect, though, was that the programmers were very much used to programming using vi or emacs, rather than using a GUI IDE.
My own experience, which goes back approx. 4 years, using Qt3.3, is that dynamic behavior in dialogs was not possible to realise in Designer.
Just to say I've written and maintained complex GUIs in Qt without using Qt Designer -- not because I don't like Qt Designer, but because I never got around to working that way.
It's partly a matter of style and where you're coming from: when I started on Qt, I'd had horrible experiences of Dreamweaver and Frontpage and other visual HTML tools,and far preferred writing code with HomeSite and resorting to Photoshop for tricky layout problems.
There's a danger with visual code IDEs that you try to keep within the visual tools, but end up having to tweak code as well -- in ways that aren't well understood.
Learning iPhone development, for example, I've found it frustrating to hit 'magic' visual stuff ('drag from the empty circle in the Connections inspector to the object in the Interface Builder window...') that would be simpler (for me) to understand in plain old code.
Good luck with Qt -- it's a great toolkit, however you use it, and Qt Creator looks like being a great IDE.
I'd add that one of the reasons for using graphical designer was the lack of layout managers in Win32, for instance. Only absolute positioning was possible, and doing that by hand would have just sucked.
Since I switched from Delphi to Java for GUI apps (back in 2002), I've never used designers any more. I like layout managers much more. And yeah, you get boilerplate code, but moving objects on a UI designer may take as much time as changing the boilerplate. Plus, I would be stuck with a slow IDE; that's for the Java/C# case, OK, while for Qt (especially Qt4) it doesn't apply. For Qt3, I wonder why one should edit the generated code - wasn't it possible to add code in other files? For which reason?
About the discussed cases:
1) Hand Coded GUI is likely faster to write, at least if you know your libraries. If you're a newbie and you don't know them, you may save time and learn less with a designer, since you don't need to learn the APIs you use. But "learn less" is the key factor, so in both cases I'd say Hand Coded GUI.
2) Menu bars are quite annoying to write code for. Also, think to details like accelerators and so on. Still, it depends on what you're used to. After some time, it may be faster to type that boilerplate than to point-and-click into designer to fix all those properties, but just if you can really type like into a typewriter (like those admins for which typing Unix commands is faster than using any GUI).
3) I'd extend the answer for case #2 to this one. Note that, for Win32 platforms, it may be possible that using designers which generate Win32 resources might be faster to load (no idea about that).
However, I'd like to mention a potential problem with using Qt Designer there. Real world case: it took some seconds (say 10) to load a complex Java dialog (the Preferences dialog box for a programmer's text editor) with a lot of options. The correct fix would have been to load each of the tabs only when the programmer wanted to see them (I realized that after), by adding a separate method to each preference set to build its GUI.
If you design all the tabs and the tab switcher together with a designer, can you do that as easily? I guess there might be a similar example where a hand coded GUI gives you more flexibility, and in such a big app, you're likely to need that, even if just for optimization purposes.
One of the main benefits of using designer to create GUIs is that other programmers can change or maintain forms and widgets easily without the need to delve in to a complex code.
Its strange that you're saying the writing code is simpler than manipulating objects in a graphical environment. It's a no-brainer.
The designer is there to make your life easier and in the long term it makes your code more maintainable. It's easier looking in the designer to see what the your UI looks like then reading the code and trying to imagine what it might look like.
With current Qt you can do almost everything from within the designer and the very few things you can't do, you can fix with very few lines of code in the constructor.
Take for instance the simplest example - adding a signal-slot connection. Using the designer it's as simple as a double click. Without the designer you need to go lookup the correct signature of the signal, edit the .h file and then edit write your code in the .cpp file. The designer allows you to be above these details and focus on what really matters - the functionality of your application.
I like to first turn to the designer to develop GUI widgets. As mentioned in the other posts, its faster. You also get immediate feedback to see if it "looks right" and isn't confusing to the user. The designer is a major reason I choose Qt over other toolkits.
I mostly use the designer to make the one-off dialogs.
Having said that, I do the main window and any complex widgets by hand.
I think this is the way Trolltech intended. QFormLayout is a class they provide to easily programatically create an input dialog.
By the way, the designer in Qt 4 is not an IDE like the one they had in Qt 3. It's just an editor for editing .ui files. I like it that way. The new cross platform IDE is going to be called Qt Creator.
It's an old post but I would advise you to look at Clementine - a music player which (I think) derives from Amarok. They use Qt4 and from what I can see there is a ui folder in the src folder of the project. In the ui folder as one might expect they have all sorts of .ui files. If you compile and start Clementine you will see that the GUI is fairly complex and quite nice.
For me, it depends how much logic is encapsulated in the widget/GUI. If it's just about simple forms, I prefer to use QtDesigner.
If it contains complex checks or interaction, I tend to program it.
We're using the Qt Designer if anyone needs to create a Gui.
The thing is to create just little Widgets for certain tasks (like you would do in a class-design) and then get them together into a "parent-gui".
This way your widgets are highly reusable and could be used for Guis in a modular way. You just have to specify which signals each Widget is sending and which slots they provide.
We additionally are creating .ui-Files which than could be generated during build-process. Until now there was no need to edit those files by hand.
Build different parts of your UI
in different .ui files using QtDesigner,
then bring them together (and add complications) in code.
There are things you can't do in Qt Designer, you can only do in code,
so Qt Designer is just one (great) part of the tool chain.