Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
I'm going to start working on a new project. It's a 3D game using OpenGL for Windows, Linux and Mac OS X. and I'm going to need a library for GUI, windowing and handling input. I ended up with 3 choices Qt, WxWidgets and GTK+. All of them are under LGPL license.
1- Does LGPL allow to use these libraries to make proprietary applications?
2- Which one of these 3 applications is best for me?
Yes, so long as you don't statically link to them (ie: use them as DLLs). Though wxWidgets allows you to statically link without becoming GPL'd.
None of the above. If you are making a 3D game, then none of these is good for your needs. The needs of a GUI for a game are very different from the needs of a GUI for a typical desktop application. In a game, you want you particular GUI elements to be consistent with a particular artistic direction, not be consistent with the desktop environment. Plus, you may want your GUI elements to be more expressive than what these toolkits would normally allow.
It is for reasons like this that CEGUI exists. That is a GUI system designed for the needs of a game.
Also, none of these provide input the way a game generally wants to process it. You typically want something lower level for a game than what these toolkits provide. That's why projects like SDL and SFML exist.
1 - Yes, provided that your project doesn't require alteration of the library itself
2 - I strongly reccommend Qt for new windowed apps, if for no other reason than it has excellent documentation (although there are many other winning points, but it gets subjective quite quickly). GTK and WxWidgets will both make you waste mental energy thinking about things you really shouldn't have to think about. Qt is easier to a) customise, and b) ignore when you don't care about customisation.
Although for 3D stuff you might want to look into full-blown engines like, ooh, Irrlicht or Ogre3D or any of a number of others
WxWidgets uses LGPL which means you can dynamically link to it in your project, without it forcing your project to be GPL or LGPL.
However, I suggest using CEGUI instead of the libraries you suggested, for any game or rendering application
CEGUI uses the MIT license which is less strict than LGPL and also allows you to link to the library dynamically (preferred) or statically, both without forcing you to have a specific license for your own project.
Supports OpenGL 3.2+ Core Profile (OpenGL3 Renderer)
Supports very old OpenGL versions (OpenGL Renderer)
If you want to use Ogre or Irrlicht engine, which can also rely on OpenGL, CEGUI also supports these two renderers via the CEGUIOgreRenderer and CEGUIIrrlichtRenderer
Ssupports Windows, Linux and Mac OS X, just as you want
Because someone asked in the comments: Unicode characters are fully supported so that you can use Hebrew, Arabic, all sort of Asian alphabets, etc, as shown in the current Font Demo - of course you need to install either one of the CEGUI fonts or use another Open Source Font
Was specifically designed for games, simulation and rendering applications
You can skin all elements in the UI (currently only via XML, soon also using an editor)
Provides a powerful editor (CEED) for layout editing with WYSIWYG (!) for free!
Is fully extendable and adaptive via changes in C++ code and/or XML
Powerful Event System
It might take a bit to set CEGUI and its dependencies up and get it to run with your project but it will still pay off on the long run because it has a lot more features than most free solutions for UI. Imagine how annoying it would be if you used an UI library and then found out it does not provide a specific feature you need and that it would be almost impossible to add this - because CEGUI is based on C++ and XML and because of its design, you can always add specific adjustments to CEGUI. So you will most likely not run into limitations even on the long run. Also it already has a lot of features out of the box - more than comparable libraries.
Related
I create applications, that are divorced from any native framework. All rendering happens in OpenGL, with a context provided by GLFW, all in C, with no framework to rely on supplying compatibility. As such, standard screen readers like NVDA have no chance of picking up information ( excluding OCR ) and my applications are an accessibility black hole.
How can I provide an interface for screen readers to cling unto? I presume this is a per OS thing... How would that be possible on Windows, Linux, BSD or even android? In the *NIX world, I presume this would be Desktop environment dependent...
I'm finding a lot of information on this, with a framework as a starting point, but have a hard time finding resources on how to do it from scratch.
I'm fully aware this is far beyond the capability of a sole developer and know, that writing programs by ignoring native interfaces is a common accessibility hole, which you are advised to avoid.
However, I have a tough time finding resources and jump-in points to explore this topic. Can someone point me in the right direction?
TL;DR: How to provide screen-reader compatibility from scratch. Not in detail - but conceptually.
As you have already well identified, your app is an accessibility blackhole because you are using a rendering engine.
It's basicly the same for OpenGL, SDL, or <canvas> on the web, or any library rendering something without specific accessibility support.
WE can talk about several possibilities:
Become an accessibility server. Under windows, it means doing the necessary so that your app provide accessible components on demand from UIA / IAccessible2 interface.
Use a well known GUI toolkits having accessibility support and their provieded accessibility API to make your app.
Directly talk to screen readers via their respective API in order to make them say something and/or show something on a connected braille display.
Do specific screen reader scripting
However, it doesnt stops there. Supporting screen readers isn't sufficient to make your app really accessible. You must also think about many other things.
1. Accessibility server, UIA, IAccessible2
This option is of course the best, because users of assistive technologies in general (not only screen readers) will feel right at home with a perfectly accessible app if you do your job correctly.
However, it's also by far the hardest since you have to reinvent everything. You must decompose your interface into components, tell which category of component each of them are (more commonly called roles), make callback to fetch values and descriptions, etc.
IF you are making web development, compare that with if you had to use ARIA everywhere because there's no defaults, no titles, no paragraphs, no input fields, no buttons, etc.
That's an huge job ! But if you do it really well, your app will be well accessible.
You may get code and ideas on how to do it by looking at open source GUI toolkits or browsers which all do it.
Of course, the API to use are different for each OS. UIA and IAccessible2 are for windows, but MacOS and several linux desktops also have OS-specific accessibility API that are based on the same root principles.
Note about terminology: the accessibility server or provider is your app or the GUI toolkit you are using, while the accessibility client or consumer is the scren reader (or others assistive tools).
2. Use a GUI toolkit with good accessibility support
By chance, you aren't obliged to reinvent the wheel, of course !
Many people did the job of point 1 above and it resulted in libraries commonly called GUI toolkits.
Some of them are known to generally produce well accessible apps, while others are known to produce totally inaccessible apps.
QT, WXWidgets and Java SWT are three of them with quite good accessibility support.
So you can quite a lot simplify the job by simply using one of them and their associated accessibility API. You will be saved from talking more or less directly to the OS with UIA/IAccessible2 and similar API on other platforms.
Be careful though, it isn't as easy as it seems: all components provided by GUI toolkits aren't necessarily all accessible under all platforms.
Some components may be accessible out of the box, some other need configuration and/or a few specific code on your side, and some are unaccessible no matter what.
Some are accessible under windows but not under MacOS or vice-versa.
For example, GTK is the first choice for linux under GNOME for making accessible apps, but GTK under windows give quite poor results. Another example: wxWidgets's DataView control is known to be good under MacOS, but it is emulated under windows and therefore much less accessible.
In case of doubt, the best is to test yourself under all combinations of OS and screen readers you intent to support.
Sadly, for a game, using a GUI toolkit is perhaps not a viable option, even if there exist OpenGL components capable of displaying a 3D scene.
Here come the third possibility.
3. Talk directly to screen readers
Several screen readers provide an API to make them speak, adjust some settings and/or show something on braille display. If you can't, or don't want to use a GUI toolkit, this might be a solution.
Jaws come with an API called FSAPI, NVDA with NVDA controller client. Apple also alow to control several aspects of VoiceOver programatically.
There are still several disadvantages, though:
You are specificly targetting some screen readers. People using another one, or another assistive tool than a screen reader (a screen magnifier for example), are all out of luc. Or you may multiply support for a big forest of different API for different products on different platforms.
All of these screen reader specific API support different things that may not be supported by others. There is no standards at all here.
Thinking about WCAG and how it would be transposed to desktop apps, in fact you are bypassing most best practices, which all recommand first above anything else to use well known standard component, and only customize when really necessary.
So this third possibility should ideally be used if, and only if, using a good GUI toolkit isn't possible, or if the accessibility of the used GUI toolkit isn't sufficient.
I'm the autohr of UniversalSpeech, a small library trying to unify direct talking with several screen readers.
You may have a look at it if you are interested.
4. Screen reader scripting
If your app isn't accessible alone, you may distribute screen reader specific scripts to users.
These scripts can be instructed to fetch information to give to the user, add additional keyboard shortcuts and several other things.
Jaws has its own scripting language, while NVDA scripts are developed with Python. AS far as I know, there's also scripting capabilities with VoiceOver under MacOS.
I gave you this fourth point for your information, but since you are starting from a completely inaccessible app, I wouldn't advise you to go that way.
In order for scripts to be able to do useful things, you must have a working accessible base. A script can help fixing small accessibility issues, but it's nearly impossible to turn a completly inaccessible app into an accessible one just with a script.
Additionally, you must distribute these scripts separately from your app, and users have to install them. It may be a difficulty for some people, depending on your target audience.
Beyond screen reader support
Screen reader support isn't everything.
This is beyond your question, so I won't enter into details, but you shouldn't forget about the following points if you really want to make an accessible app which isn't only accessible but also comfortable to use for a screen reader user.
This isn't at all an exhaustive list of additional things to watch out.
Keyboard navigation: most blind and many visually impaired aren't comfortable with the mouse and/or a touch screen. You must provide a full and consist way of using your app only with a keyboard, or, on mobile, only by standard touch gestures supported by the screen reader. Navigation should be as simple as possible, and should as much as you can conform to user preferences and general OS conventions (i.e. functions of tab, space, enter, etc.). This in turn implies to have a good structure of components.
Gamepad, motion sensors and other inputs: unless it's absolutely mandatory because it's your core concept, don't force the use of them and always allow a keyboard fallback
Visual appearance: as much as you can, you should use the settings/preferences defined at OS level for disposition, colors, contrasts, fonts, text size, dark mode, high contrast mode, etc. rather than using your own
Audio: don't output anything if the user can't reasonably expect any, make sure the volume can be changed at any time very easily, and if possible if it isn't against your core concept, always allow it to be paused, resumed, stopped and muted. Same reflection can apply to other outputs like vibration which you should always be able to disable.
I am an iOS / Cocoa developer looking to port one of my apps to PC platform. I don't care to code multiplatform and maintain one app. I will continue using cocoa and cocoa touch for iOS Mac Development.
I have chosen to use QT 5 for PC, I am not sure if its wise choice but its easy and I can understand c++. If its not please point me to the correct direction.
My App is not hugely complicated, but needs some special customization e.g. ListView that looks like an iOS Table View, uses custom rounded windows with twitter bootstrap style search box and I want to monitor some global OS events like keystrokes, and what other applications the user is currently working with. I also use SQLite and AES encryption.
My questions is regarding UI customization.
Should I start studying and use QML for that? I am not sure what exactly it is, seems extremely simple CSS like, but I have the feeling is more designed for embedded devices and have limitations...
Do I have access to the entire power of QT if I use QML ?
What other options I have to customise widgets instead using QML (e.g. in objective C we use subclassing and drawing whatever we want or handling events...)
I am inexperienced in windows platform. Should I use VisualStudio C++ instead of QT5? With the changes in ownership I feel somehow insecure.
Yes you should. QML is declarative language which allows javascript to be executed within it. And you can do almost anything UI related with QML. If you don't have some particular UI element you can draw it in plain C++(Qt) and use it in the QML. So QML is the best choice for Qt development at the moment. It is not like CSS though, it is much more powerful.
Yes you have all the power Qt has and additional power which declarative language may offer - simplification of UI development process as well as modern decomposition of UI&logic.
You have this option in plain C++ Qt, you may subclass widget, redraw them, change behavior etc. This approach is inferior to the QML one.
This point doesn't make sense. Some people count Visual C++ like separate language which is wrong. You may count Visual C++ as C++ + some minor extensions MS compiler has. But it is as ridiculous to refer as GCC C++. So basically you can use Visual Studio with Qt almost without a pain if you use Qt integration add-in which is freely available. Or you can choose Qt creator, which some people count as superior to MSVS. It is up to you what to choose, but I believe for the novice it is much simpler to use Qt creator with Qt. But note you will need to have some compiler because Qt creator is just an IDE it should use some 3rd party compiler(either MS or GNU one)
You can use QML Desktop Components to build easily your application:
https://web.archive.org/web/20121203050945/http://blog.qt.digia.com/blog/2012/06/06/desktop-components-for-qt-5/
http://qt-project.org/wiki/Qt_Quick_Components
Anyway I recommend you use Qt Widgets and Qt Style Sheets to costume your widgets:
http://qt-project.org/doc/qt-4.8/stylesheet-reference.html
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 6 years ago.
Improve this question
Nokia has just introduced Qt Quick (build UI declaratively like using CSS/HTML) in the recent beta versions of Qt, check this example page, it can build fancy and modern UI, very cool!
On the opposite, the UI developed by 'traditional Qt' seems to be less fancy (I might be wrong, see disclaimer below).
So my question is, would you use 'Traditional Qt' or 'Qt Quick' for a new desktop program? Why?
My initial thoughts:
'Traditional Qt':
Pros:
The overall technologies used be less, thus simpler, if you use PySide, you only code in Python, don't have to mess with the CSS/JS-like things in Qt Quick;
It's maturer.
Cons:
Building fancy UI seems to be more difficult?
'Qt Quick':
Pros and cons: the other way around.
Edit: Qt Quick has a downside, correct me if I'm wrong, you can't design Qt Quick UI in a WYSIWYG way, right?
Disclaimer: I'm new to Qt, PySide and Python, just recently has started evaluating using these tech to build desktop programs.
ave been messing up with qml for my desktop and i personally found this:
its easier to create animations than in traditional qt/c++/pyqt (i loved the animations :)
I haven't looked through all examples but the code size of qml apps looks smaller than equivalent apps in c++
Problems i have found with qml
has poor qml design support- at the moment custom elements dont show up in qml designer.This is a big pain coz ideally i should get a designer to create my ui and i concentrate on the code. Their qml designer still needs some work
You are expected to learn javascript since its the "recommended" way of scripting in qt. Javascript is NOT easy as you may expect eg learning python took me a few hours but javascript looks superficially similar to c but some of its concepts are different. Also i wonder if i can protect intellectual property in an app written i just javascript and qml.(correct me if am wrong)
native widgets are not available in qml eg it just offers rectangles, etc which you combine to form your own widgets.
This has not stopped me from playing with qml and as it matures, i shall adopt a wait and see attitude. Currently am using qml for part of my ui and c++ for the backend.
You made one mistake: Qt Quick is not available only in a beta version of Qt. It has been part of the official Qt release since 4.7 (although each minor version significantly improved the features offered by Qt Quick).
Although the "normal" Qt UI (with QWidgets and layouts and all) is older, this doesn't necessarily mean Qt Quick is immature. It is part of the release, after all.
One thing you fail to point out in your pro's and cons is performance: "normal" Qt UI's are prebuillt (for the most part, basically), and Qt Quick UI's rely on runtime interpretation of QML and CSS/HTML as you say. This will mostly not impact application speed on a desktop system, but if you run into performance bottleneck because you're making the UI too fancy, don't say I didn't warn you. Although such a bottleneck probably means you should've gone OpenGL from the beginning.
Qt Quick provides an easy way of building a cool UI (that's the selling point anyway) and will allow you to use cooler effects in an easier way than the old stuff.
If you are using Python then you probably are not concerned about performance. Traditional Qt allows for fancy looks, too via QSS. What Qt Quick gives is a way to easily build a UI (even without tooling support that is being introduced in 4.8) and use scripting to make it work.
You can make fancy UIs with tradtional Qt, too, mainly via QSS and deriving existing widgets. Most Qt examples don't focus on this but that doesn't mean it can't be done. It also probably gives a better overall performance, especially if coded in C++.
I would use traditional Qt because I'm more familiar with it. But this is subjective anyway, so I think your question will be closed.
I have not so experience on traditional Qt UI systems. But I can give you my experience on QtQuick:
UI using QML is more simple.
QML enables you to better developing using MVC pattern. It makes View separated from Model. You can load different version of the UI in runtime.
QML enables developing advanced UI.
It is very performant now (using QSceneGraph technology). It is implemented on multiple UI threads! I am not sure that you can make more performant UI using C++ anymore!
UI designers can develop UI simpler than HTML+CSS+Javascript!
You can develop your custom UI element by C++ using specific classes.
QML is based on OpenGL and in free version of Qt you need to notice that.
QML has a specific debugger and profiler. Debugging in UI is so easy.
If you want to develop your app using a standard patten like MVC, QML may be more suitable.
You need to be careful about performance notes.
After 4 years of absence I'm finally coming back to Qt development again. I'm quite impressed by the development it has gone through, but also a bit confused by Qt Quick, which got just introduced in Qt 4.7
For me it seems like something to build a quick, appealing GUI with some logic in Java Script. However, if I'm going to build a C++ application, is Qt Quick also the modern way of building a GUI for that or should I follow the classic path by using the .ui files?
Qt Quick should fill a much needed gap but whether that means it will become the way to build applications will largely be determined on the type of applications you intend to build.
Qt has provided .ui files for a long time. These files are easy to work with when you need to create applications based on standard widgets. Designer makes it easy to layout the widgets and do other basic operations.
Qt 4.2 introduce style sheets (qss) that made it possible to style existing widgets. These styles are convenient ways of styling the standard widgets to get away from the standard widgets' look-and-feel, while retaining basic functionality.
But sometimes you need to create custom widgets, widgets that don't exist. Before Qt quick, the only way to do this was to write native code (be it C++ or, with language bindings, Python or Ruby). With Qt Quick it's now quite possible to write widgets and full blown UIs that would otherwise be somewhat painful to write in code. Because Qt quick's focus is on the UI, it's becomes a better development language for that goal. The Qt Quick paradigm also transcends the idea of strict standard widgets, adding support for transitions and boundary-less widgets.
The answer really depends on the type of application you're planning to build and I consider the description provided on the page you linked to very accurate:
"Qt Quick helps programmers and designers collaborate to build the fluid user interfaces that are becoming common in portable consumer devices, such as mobile phones, media players, set-top boxes and netbooks."
At the moment, Qt Quick is certainly not the most obvious choice if you're planning on building a classical desktop application, an area of development which the Qt library traditionally excels at, and in this case you're probably better off using what you call "the classic .ui approach"; at the same time, I think that's the exact reason why Qt Quick was introduced: to add a new tool to facilitate the development (or rapid prototyping) of applications not focused on the desktop.
I'm used to working in a Delphi and C# environment which seem to have a rich set of third party components available. I'm currently wanting to do cross-platform programming in C++ using either qt or wxwidgets. Is there a large market for third party components? I was looking at sourceforge and that doesn't seem to show much that is useful (how the hell do you find out what components or features are in a project without downloading the source?). I'm thinking carousel/coverflow components, rich datagrids (like the sort DevExpress provide). Or is this, write your own territory?
There are a number of good quality third party Qt libraries, though I don't know of a centralized resource for finding them.
A few places to start looking:
http://www.ics.com/products/qt/addons
ICS provides the
QicsTable, a high performance
model-view-delegate table library,
and resells various libraries by
KDAB. (These are all available as a
free download.)
http://www.qtcentre.org/contest-first-edition/finalists
QtCentre has an annual
programming contest which awards
interesting Qt-based tools and
libraries. This year's contest is
still being judged, but the
finalists from last year can be seen
at the above link. Check out the
Custom Widget and Helper Library
categories.
There is a third-party component for Qt - advanced data grid - Qtitan DataGrid.
In it there are almost all necessary possibilities.
Ultra-fast processing of large data sets
Use of QStyle for rendering objects ensures that the grid blends into the UI design of any application
Two modes of vertical scrolling
Customizable colors of rows and columns
Two integrated table views
Column banding and grouping
Automatic width and height adjustment
Fixed columns
Flexible sorting
Column summaries
Integrated high-performance caching mechanism
Advanced paint engine for faster rendering of UI elements
Cross-platform support
API for external editors
Screenshots about this Grid
http://www.devmachines.com/qtitan_screenshots.php
For a crossplatform GUI development, Qt is the tool you should be looking for. I have used both. Here is what I feel about Qt
Building rich GUI is a piece of cake if you use Qt. It has a loads of GUI capabilities, starting with its Graphics View, OpenGL support, stylesheets that supports css. A mature painting system, Richtext formatting, Integration with Webkit, and I am sure I am missing a lot more here...
Qt has its own build system, qmake which creates platform dependent Makefiles, so no Makefile hassles. Moreover you get a single pro-file which is much easier to manage. For wxWidgets, you will need to create different Makefiles for the various compilers you intent to use.
Other advantages of using Qt over wxWidgets are - the Api is very easy to learn with its intuitive api, superb documentation and tons and tons of examples. This helps you get yourself productive pretty soon and thus getting your product early to marker. BTW Qt is a RAD tool. Moreover, there is a huge user base, and there are forums like QtCentre.org to help you with your questions.
If you are planning to buy commercial license, you get support directly from Qt Software (trolltech).
You would obviously be using Qt's Model View pattern, allowing you to separate your business logic from the presentation tier. I would suggest that you write to "support at trolltech dot com" or "sales at trolltech dot com" to get more information. You can explain your requirements and they would be able to explain how Qt fits your needs.
You could also download the opensource version and have look at the demos.
Coverflow: http://labs.trolltech.com/blogs/2007/11/02/pictureflow-on-windows-mobile/ , http://ariya.blogspot.com/2008/03/introducing-photoflow.html
As I said, if its Rich gui you are planning to develop, use Qt.
In addition to the ones by ICS and at QtCentre the Qt-apps website has some open source widgets/components for Qt.
For wxWidgets you have wxCode which has quite a few things although not all the existing third party components (including a few very useful ones) are available from there.
Good quality components for Qt can be found here - http://www.devmachines.com/
At the moment there are Microsoft Ribbon Control for Qt, DataGrid for Qt, Charting for Qt.
All components are commercial and should be used in Qt Commercial or Qt LGPL.