I'm searching for a simple library for creating GUI that can have:
a portable codebase across different compilers and OS
can be easily extended to a new platform if that platform it's not natively supported
are real library and not just a collection of #define, tools and other un-portable and non-standard things.
So far the "best" match is QT that is just the opposite of each one of this 3 points, especially the 3rd one (moc compiler and #defines ... ).
I also do not need data structures and 10000 extra functions, i just need to code a portable GUI, hipotetically i don't even need a signal slot library included because I can handle signals with third part libraries.
If there is no such lib available can you point me to a resource where I can learn about the OS specific basics about Widgets and Windows ?
I never used it, but I would suggest looking into IUP
From what I read this would fit the bill quite well. The project is also quite active. Though it is probably not too pretty.
Related
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 5 years ago.
Improve this question
Since Qt can handle in normal way OpenGL, it is cross-platform, can handle mouse, keyboard, gamepad etc. What are the disadvantages of using Qt with OpenGL instead using OpenGL with extensions?
What are the disadvantages of using Qt with OpenGL instead using OpenGL with extensions?
Your question is malformed. Nothing stops you from using Qt with OpenGL and with OpenGL extensions.
You can use Qt to manage the OpenGL window, while using direct OpenGL commands with extension to render. You are not required to use Qt's OpenGL interface to render in an OpenGL window.
Qt does not provide "additional opengl functionality." It cannot provide "additional opengl functionality." It isn't part of OpenGL, so it can't make OpenGL features magically appear.
There are no OpenGL extensions for mouse, keyboard, gamepad, or any of the other things Qt handles. Qt's windowing functionality and OpenGL extensions are two completely different things. And they are completely orthogonal; nothing stops you from using Qt+OpenGL and OpenGL extensions at the same time.
Well, unless you stop yourself. See, Qt has this OpenGL abstraction layer. This is a set of wrapper classes around OpenGL: QtOpenGLShaderProgram, QtOpenGLVertexArrayObject, and the like. If you use that, you don't directly make OpenGL calls; you make Qt calls that make OpenGL calls for you.
If your question is whether to use Qt+OpenGL directly vs. using Qt's OpenGL abstraction layer, that's a different matter.
The first problem is that Qt's abstraction layer is bound to OpenGL ES 2.0. While it occasionally offers features that ES 2.0 can't do, it is primarily intended as a class-ified implementation of ES 2.0. So by using ES 2.0, you're effectively giving up using lots of desktop OpenGL features.
Not "extensions"; core features.
For example, you cannot use integers for vertex attributes with Qt's abstraction. The QtOpenGLShaderProgram class doesn't allow it. All of its setAttributeBuffer calls assume that you're calling glVertexAttribPointer. It has no mechanism for calling glVertexAttribIPointer. And that has been core desktop OpenGL for nearly a decade.
Note that this is just one feature. Other things Qt doesn't have wrapper class support that are part of core desktop OpenGL (this is not a comprehensive list):
Separate programs
Sampler objects
Separate attribute formats
These are not bleeding-edge hardware features; most of them have been around for half a decade.
QtOpenGLFunctions is similarly limited to OpenGL ES versions. That leaves plenty of non-extension desktop GL stuff on the table that cannot be used through their abstraction.
Also, because Qt's abstraction is around ES 2.0, it doesn't care about core OpenGL contexts. For example, it still has non-buffered vertex attributes (setAttributeArray). That's not legal in core OpenGL, and again hasn't been legal for nearly a decade.
So if you want to actually use core desktop OpenGL functionality, the Qt abstraction layer is out.
Then, there are places where Qt's abstraction just doesn't match how OpenGL works.
For example (and this is a personal pet-peeve of mine), QtOpenGLBufferObject is typed. That is, the binding type is part of the object. This is not how buffer objects work!
OpenGL buffer objects aren't typed. It is perfectly legal to perform an asynchronous glReadPixels into a buffer, then bind the same buffer for use as vertex data. That's not possible with Qt's class abstraction. And it's not like this is something specific to desktop GL; OpenGL ES works the same way.
Similarly, for reasons best known to themselves, they put the vertex attribute specification functions (the equivalent to glVertexAttribPointer) in QtOpenGLShaderProgram. Why are they there? While vertex attributes do have an indirect connection to a program, they're not a direct part of the conceptual program interface. OpenGL doesn't work like that.
So those are the biggest problems with Qt's abstraction layer. If you can live within those restrictions, feel free to use it. For people making desktop OpenGL applications, they may be too restrictive.
You (OP) wrote in a comment to a different answer:
Extensions provide functionality that the core of OpenGL doesn't provide when Qt itself won't be created for providing additional opengl functionality. It was like a addon for users.
I think you completely misunderstood what OpenGL extensions are and how they work. OpenGL extensions allow to add new features to OpenGL (which might actually be included into a later core version) and/or to expose vendor specific functionality like access to special GPU functions present only for a very specific narrow range of GPUs.
Qt on the other hand offers a framework for applications that deals with operating system specifics in a portable way. Qt and OpenGL are completely orthogonal to each other and nothing, that OpenGL extensions do in any way resembles what Qt does. Qt has a OpenGL integration module, that – among other things – will also load OpenGL extensions if you ask it to; but that doesn't make it a "Qt" thing.
I think you are missing the point. OpenGL (including its extensions that provide some perks that the plain OpenGL does not) is "just" a graphics library intended for rendering 2D and 3D. Qt on the other hand is much more. OpenGL in itself doesn't provide anything but rendering. You can't even create a window (as what you are used to in Windows/Linux) with it. In order to add any sort of handling of the user's input you need an extra layer which Qt (and many other similar frameworks) provides - integration into the window manager of the OS, handling of mouse and keyboard events etc. Qt does also support the OpenGL extensions so you don't have to throw these away if you want to use them.
Whether you need Qt for your OpenGL (with or without the extensions your system supports) tasks or not is something you need to decide for yourself. Qt does offer many nice features that will help you make your OpenGL interaction great however it is a huge overhead and depending on your target system you may have to use a smaller framework with a smaller memory (incl. persistent storage for all the library files) footprint and CPU usage. Other popular choices are GLFW, freeglut and SDL/SDL2 all of which provide at least the basics (window creation and mouse/keyboard handling) to get your application up and running.
The QT dev kit comes with some good examples of how to code features via trivial apps, but nothing comes close to showing how to structure a complex program in QT. What, if anything, should be global, etc? Pitfalls in designing your classes that would turn out to need a lot of eventual refactoring?
I'm sure there are plenty of open source KDE apps that would serve nicely, so I guess my question is what't the minimal amount of source code I'd need to download and set up in order to work with, say, Dolphin as a sample app? If the answer is 'all of KDE', then I guess this isn't practical (unless downloading and building all of KDE from source is easy enough to make that practical).
Any suggestions? Personally, I'm looking to build a browser-like app, but much simpler. So for an example to follow, something that handles sockets and multiple tabbed viewports would be nice.
Thanks,
Rob
The main advice regarding Qt itself is I would give is to try to spend as much effort as possible in learning to use Qt's Model View Delegate functionality. It can be a lot of work to wrap your head around, but once you get there, you can do very powerful things with it. Another relatively tricky topic you will want to invest learning resources in is memory management and how Qt facilitates (and doesn't facilitate) it.
One of the most confusing things to me was though that when your model is very complex, you might not want to have your core model class be a Qt model at all. Instead, I nowadays see Qt models as something that primarily provide data to views. If your model is very complex, you might want to use your actual, more complex model as a data source for the Qt model class (an QAbstractItemModel derivative), which in turn attaches to the UI view.
Also, Qt documentation is your friend. Qt is a wide framework and contains LOTS of useful functionality. I love the data structures in their ease of use, for example: QHash, QList, etc.
Project scaffolding features for beginners, for different project types in Qt Creator might indeed be useful. For now, the Qt Examples actually are quite good ones, and contain lots of good practices. You just need to pick and choose what you need.
I have been developing our Qt desktop app family for five years now. Our directory structure is quite unorthodox - the main thing is that we have lib/ under which we have grouped different related functionality in subdirectories. The thinking goes, if something is in lib, it is general-purpose and atomic enough to be used in several of the actual desktop applications in our software family.
Your question seems more general level than Qt. It is difficult to tell if you are looking for a more general level computer science education. Globals in general should be avoided, sure. OTOH, we do have a constants.h and other immutable configuration data that is global-like, since it is needed in many places. This adds state though, so it can have unpredictable consequences if you don't do it carefully.
You could look for directory structures in places like this, though I don't really follow this advice myself. http://hiltmon.com/blog/2013/07/03/a-simple-c-plus-plus-project-structure/
Unless you are planning to contribute directly to KDE, I would advice against learning KDE way of doing things. Not necessarily because they are doing things badly, but because it is a world of its own - the best practice for KDE development might not be the best practice for a stand-alone Qt app. (Disclaimer: I, as a UI developer, don't actually like KDE, so I do not know the project very well - aside from the fact that it indeed seems a bit monolithic to the outsider.)
So I wonder if something like Qupzilla would fit the bill for you? (Found via qt-apps.)
HTH.
I wonder what is the bounds of Qt's perimeter. I know for exemple that it can specify types (such as qint or QString), and I know it cannot get system informations such as CPU Usage or Memory Usage.
My question is about the limits of Qt.
Is it correct that Qt can only interact with what is inside the project but not with what is outside (I mean system-related) ?
You can get information about operating system with QSysInfo class, if you are looking for this. This is one example, I am sure there are other helper classes. I think you should use other libraries for information like CPU usage etc, see here and also this question.
QT is nothing more/nothing less then a GUI C++ cross-platform framework. It's doesn't really have a perimeter, it has certain cross-platform functions implemented (like widgets/frames/controls a lot of other things). And within it's own functionality it provides (As being mentioned above) QSysInfo class, but you are free to add any OS dependent (if you target your application for particular platform) or cross-platform solutions for whatever tasks you need - hardware info/OS monitoring/etc..
I have to port a project from Borland C++ Builder 5.0 under Windows XP to Qt 4.7.1 using g++ under Windows 7/mingw. The libraries and command-line utilities are done, and now I have to tackle the GUI applications, which use Borland VCL.
Can anybody recommend any tools or libraries to make this task easier?
Does anybody have any experience of this?
Edited to add: Well, I took the bull by the horns, and implemented the GUI from scratch. And I have to say, the commentators were right: I can't see any way of using the existing Borland GUI to ease the process.
There are several big differences between VCL and Qt that will make an automatic conversion process quite difficult.
Qt uses signals and slots and inheritance where VCL uses events.
VCL components use absolute coordinates and Qt uses layouts. Of course, you could use absolute coordinates also with Qt, but the GUIs would be quite awful then.
VCL's TListBox and TTreeView classes are quite different from Qt's View and Model classes (although you could use QListWidget and QTreeWidget instead).
I guess it is much faster to design totally new GUIs with Qt than to create even a mediocre VCL-to-Qt converter. And the code will be much easier to maintain. I suggest that you take one VCL form of medium complexity and recreate that with Qt. After that you can make an estimation of the total recreation work. Also you will have a better understanding about the feasibility of a conversion tool, which you most probably would need to make by yourself.
Someone has written a tool to convert dfm's to qt ui files:
http://sourceforge.net/projects/dfm2qt4ui/
Its has a few small bugs but it can save several hours of time porting form designs. In some cases redesigning specific forms is preferable - but in many cases, having labels and roughly equivalent controls positioned for you saves a lot of point-and-click action.
I agree with the current consensus that automatic conversion from VCL to QT is not a good idea because the concept behind both is very different, and you are much better off learning "the QT way" and using that from the start.
However there is one major step that nobody has yet mentioned: refactoring! Before starting, make sure you refactor the original forms to remove as much business logic as possible and leave only what is really GUI code. It depends on how good your architecture already is of course, but the VCL designer tends to encourage putting as much as possible in forms (even going as far as having invisible "data forms" with non-visual components!), so you often find a lot of stuff in the form that shouldn't be there.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am new to programming. I have some Knowledge Of C++ and have learned Python.
Now i want to develop a Qt Gui Application. Which language should i use for Qt development C++ or Python with PyQt. I found Python to be easy language.
There is no definite answer to this question. With that said...
Pros and cons you often hear
Python is easy, C++ is hard (in
comparison to Python)
C++ is fast, Python is slow (so to
speak) performance wise.
In reality...
Both arguments can be true or false, you can make slow C++ program, but you can also make fast Python program, you could also say C++ is not that hard if you know it really good etc.
Qt is written in C++ so the documentation examples are in C++. This is not really a problem since it is easy to port this to Python. Although I've found that for example animations with state machine cause segmentation faults with PyQt and PySide is not all that stable yet.
So which one to pick?
Depends on your skill and assignment. If it is work you are doing go with what you know best and asses how much speed you actually need, not every app has a need for lower level code.
If you know Python, you could start building your prototype in Python, then port to C++ parts that you deemed slow and bind them back to the Python (using SIP for example) or even port the whole application to C++. This approach also makes good exercise.
But even if you wrote your whole app in Python I doubt you and your clients would ever notice the "slowness" or "fastness" if you go with C++. These things usually depend on skill of a programmer.
Conclusion
It's entirely up to you to choose what are you are most comfortable with and to understand what your app really needs, but both languages will do the job in most cases.
My subjective advice would be to go with Python and port to C++ if you really need to. Sole reason for this advice is that you do not need to type as much in Python as you do in C++ but this can also be seen as a silly reason.
I just finished a reasonably large project with PyQT... I think your choice should depend on three factors:
How big is your audience (less
than 100 installations? More?)
How much functionality do you need?
(Databases + graphics + plotting +
signal analysis + network access +
blah blah blah)?
How rapidly do
you need to develop, both now and in
the future?
C++/QT is great for 1) Big audience, 2) Low to medium functionality, and 3) Slow to medium development speed. Of course, you can do anything with C++ given enough time and money.
Python/PyQt is great for 1) Small Audience, 2) Any level (including high) functionality, and 3) Medium to fast development speed.
The benefits of Python/PyQt are that:
you needn't worry too much about datatypes, header files, and numerous other headaches that slow development, and you get to work in a world-class interpreted environment known for its ability to foster fast and robust development.
you can pull in massive 3rd party libraries like matplotlib, scipy, sqlalchemy, and configobj that can make complex tasks stupidly easy.
The downsides of Python/PyQt, IMHO, are that:
it may have slower performance in some applications (who cares? How often does that really matter?)
it may be substantially harder to deploy. Py2exe requires quite a bit of tweaking to get 3rd party libraries to work, and then you still need to build an installer and get that working. Then, every time someone installs your app you might have 10 to 100MB of unnecessary dependencies built into the thing.
Personally, I work in an engineering R&D environment where fast turnaround and extensive data analysis/visualization is key, and deployment is often to only a few dozen (tech-savvy) people. Python/Pyqt is the clear choice. But, if I were to be developing a simple, widely-deployed application like a bittorrent client or something, I'd go C++ all the way.
Other notes:
PySide (a free LGPL alternative to PyQt) is rapidly progressing and seems sure to blow PyQt out of the water; I'm planning to switch within the next few months but as of now some 3rd party libraries still aren't set up for it.
The documentation for Pyside is much better than for PyQt; if you need help on, say, "QListView", just search google for "Pyside QListView".
I'd recommend only using PyQt where you need to. E.g., don't mess with QtSQL (debugging is a nightmare) when you could just use SqlAlchemy, and don't screw with Qt's configuration system when you can use the awesome library ConfigObj.
The clear way to install Python/Pyqt/etc is using the distribution Python(x,y) ... it includes, among other things: Python, PyQt, Qt, Eclipse, PyDev, QtDesigner, Spyder, iPython, and many dozens of useful scientific and computing libraries. Compiling and installing this stuff on your own is not fun.
In addition to the arguments given by rebus, I would add that the development and maintenance time in Python is considered to be about 2-10 times faster than in C++ (in papers by Prechelt and Ousterhout). This is another significant advantage of Python, that you might want to consider.
My main reasons for choosing Python and PyQt4 are:
Readability: I can't think in C++. I truthfully cannot. Python, on the other hand, is pretty close to English, so I find it easier to skim and debug.
Speed: I find that Qt4 works almost identically in both C++ and Python when you're using it for simple applications that do little work on the inside. I coded a book binding application with Python, and since it is basically a frontend to bunch of CLI tools, there is no noticeable performance lag.
Rapid Development: If you can write it in words, you can probably write it in Python. When I had to implement a new feature in my program, I just opened up the source folder (which consists of only a few files. Compare that to C++'s header mayhem), and added it in. Sure I had to tweak it to work faster later on, but my main point is that because the language is readable, it is easy to code in, and hence increases productivity.
But just to weigh both sides equally, here's what I don't like about Python and Qt4:
Example Code: Good luck trying to find some sample PyQt4 applications. The community is pretty small compared to the C++ Qt community, so don't expect tons and tons of examples.
IDE: I code with Gedit, so this was not a big issue for me, but it did take some hacking while I was designing the GUI. You have to trick Qt Designer into promoting your widgets in Python-compatible ways (like proving fake header file names so that the modules import properly), and other things like that. Nothing to serious. My regret was the inability to use Qt Creator IDE. It's basically a GUI designer on steroids, but it looks nice and is like Visual Studio for Qt.
Speed: If your application does some serious heavy lifting, I'd stick with C++. Python is good for algorithmic things, but for raw number-crunching power, C++ is the winner.
Deployment: To compile Python applications into binaries, you need to do some magical stuff with PyInstaller, Py2exe, and Py2App. It's a pretty painful process (for me at least), but it's the price you pay for an interpreted language. C++ just compiles and is ready to go.
I hope this helps in your decision. Good luck!
Learn C++. C++ executes faster than Python, and the fact that Qt is not native to Python will also slow things down slightly. Also, there is at this point far more 3rd party software in C/C++ than in Python. You might not need it now but down the road you might want to link to some of this.
EDIT: Looking a little harder I see that EOL is right, there is a lot of Python support for major libraries, though not for everything as lunayorn points out. Nonetheless in all these cases the Python user is reliant on bindings, which by their nature may lag the library developments and add extra possibility for bugs.
And since I don't yet have the cred to respond to others' posts, let me say here that rebus' claim that it's all programmer relative and C++ or Python can be just as fast is completely (and dangerously, where speed is important!) wrong. Python's ease of use comes at an unavoidable performance cost, see the wikipedia entries on interpreted vs. directly executed languages. I know from direct experience that Matlab, which is interpreted in the way Python is, executes line for line 2 full orders of magnitude more slowly than C++. Python and Matlab are best considered as (and in the case of Matlab at least, originally intended as) interfaces to libraries coded in languages like C or Fortran. For serious, large programs where performance matters use C++.