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.
Related
I am currently considering writing a small game. It is essentially a map where you can zoom out and in, and in certain places click on info boxes where, at some point, I hope to integrate minigames. Granted, game might be overstating it. Think of it as an interactive map. The theme is how mathematics can be applied in peoples every day life to raise awareness on the usefullness of mathematics.
The question is how I as fast as possible can make a reasonable prototype. If I recieve enough positive response on this I might try to code "the real thing" and use the prototype to obtain funding.
However, I am at a crossroad. I want something to work rather fast and have some C++ experience coding optimization problems, mainly in c-style. I am not convienced, though, that coding it in C++ is the fast way to obtain a prototype. Though I have some experience coding in C++, but have no experience in coding any sort of GUI.
As I see it there is a number of possibilites:
C++, possibly using some library, such as boost or ???.
Start out purely webbased, using e.g. HTML 5 and java.
Python
C#/.NET
Others, such as?
I have to admit I have little experience with anything besides C++ and the STL.
So my question to this wonderful forum is basically, is there a language that provides a significant advantage? Also, any additional insight or comments is more than welcome!
Python is a simpler language than C++, and for prototyping it will help you focus on the task at hand. You can use Pygame, a game library built on the excellent cross-platform SDL library. It provides 2D graphics, input, and audio mixing features. SDL is mainly a C library (and thus compatible with C++), and there are a number of very useful libraries that integrate with it:
SDL_image for loading images in various formats
SDL_ttf for rendering text using TrueType fonts
SDL_mixer for audio mixing
SDL_net for networking
SDL_gfx for graphics drawing primitives
So if you prototype in Python using Pygame, there is a reasonable chance you’ll be able to port what you make over to C++ with minimal hassle, if and when you choose to do so.
Possible options:
Go with what you know the best. Anything else will require a learning curve, which may be weeks to months long. If you're willing to take that road in order to make your prototype, then there are some really great tools available.
BlitzBasic is a good way to go, and is basically designed to be for games
I've done little games in Java using Slick2D - but you'll need good grounding in object-oriented coding to work effectively in Java. If you've got that from C++, then you can see a tech demo I built in Slick2D called Pedestrians. It's open source, and has demo videos here.
You might also ask your question on https://gamedev.stackexchange.com/ - a Q/A site dedicated to game programming
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++.
We are currently designing a business application that has two primary requirements for it's UI:
1) run on the Desktop (WPF) for enterprise users to provide a rich user interface, interoperate with other applications, access the filesystem, work offline, work with special local hardware, etc.
2) run on ASP.NET/Ajax to provide several components of this application to customers (internet). Unfortunately Silverlight is not (yet) an option.
Even though we don't have to make the full application available on the web, some of these components are fairly complex and we would like to share as much UI code as possible with the WPF implementation.
What options do we have to reach this goal? Is there a pattern that works well with both technologies?
Update:
Thanks for the answers even though they don't include the one I was looking for! :)
I don't think UI generators are a good option. Like Eduardo pointed out you will probably end up with problems in both worlds. I will check out Sculpture though.
I've been thinking along these lines for a while now, and I've yet to come up with a great answer. That being said, here are some of my thoughts:
If you used some variation of the various MVP/MVC/MVVM UI methodologies and you were very disciplined in this approach (i.e. not mixing presentation stuff with behavior stuff), you'd probably be farther down the road.
You might consider investigating the various DSL toolkits that have cropped up, the idea being to create a simple "language" to describe your UI at a high level and generate a representation of that UI in WPF/ASPX.
Also, I ran across this recently. I have no idea how good it is. I'm planning to take a closer look when I get the chance.
Good luck!
The unfortunate truth is that Asp.net/ajax (the web in general for that matter) and WPF (and heck, let's throw WinForms in there for good measure) have very different User Interface models and what works well for one is not necessarily going to work well for another. That's not to say that you can't share logic between applications written for either technology, but, I'll make a stretch here, your UI logic is not going to be in that category.
I've been using a variation of MVVM for WPF and ASP.Net MVC most recently and I'd say they are very good fits for the technology at hand. However, while they are very similar, they have their differences and I'm not sure you could write an abstraction layer (in any decent amount of time) that could take advantage of the great features in both technologies.
Ultimately, I'd say that your best bet is to follow some SOA patterns and extract as much of your business and data access logic into common libraries as possible. Then, write separate user interfaces in WPF and Asp.net to take advantage of those common libraries. This is the approach that my company is taking at the moment, and it's working like a charm.
It may seem daunting to write your UI logic twice (once for asp.net and once for wpf), but I think it's worth it so that your code can fit the patterns and practices that best fit those technologies.
As an aside, even though Silverlight is not an option, have you considered XBAP?
If a former job we did something similar. As Daniel Pratt says, we describe our interfaces in XML and then a render will create the form, report or whatever we decided to create.
We have to provide a Javascript function to do some UI validations in the HTML render, and a call to a java function in the Swing render.
Beware that you may end with imperfect apps in both worlds.
I was using a CASE called MAGIC for a system I'm developing, I've never used this kind of tool before and at first sight I liked, a month later I had a lot of the application generated, I felt very productive and ... I would say ... satisfied.
In some way a felt uncomfortable, cause, there is no code and everything I was used to, but in the other hand I could speed up my developing. The fact is that eventually I returned to use C# because I find it more flexible to develop, I can make unit testing, use CVS, I have access to more resources and basically I had "all the control". I felt that this tool didn't give me confidence and I thought that later in the project I could not manage it due to its forced established rules of development. And also a lot of things like sending emails, using my own controls, and other things had their complication, it seemed that at some point it was not going to be as easy as initially I thought and as initially the product claims. This reminds me a very nice article called "No Silver Bullet".
This CASE had its advantages but on the other hand it doesn't have resources you can consult and actually the license and certification are very expensive. For me another dissapointing thing is that because of its simplistic approach for development I felt scared on first hand cause of my unexperience on these kind of tools and second cause I thought that if I continued using it maybe it would have turned to be a complex monster that I could not manage later in the project.
I think it's good to use these kind of solutions to speed up things but I wonder, why aren't these programs as popular as VS.Net, J2EE, Ruby, Python, etc. if they claim to enhance productivity better than the tools I've pointed?
We use a CASE tool at my current company for code generation and we are trying to move away from it.
The benefits that it brings - a graphical representation of the code making components 'easier' to pick up for new developers - are outweighed by the disadvantges in my opinion.
Those main disadvantages are:
We cannot do automatic merges, making it close to impossible for parallel development on one component.
Developers get dependant on the tool and 'forget' how to handcode.
Just a couple questions for you:
How much productivity do you gain compared to the control that you use?
How testable and reliant is the code you create?
How well can you implement a new pattern into your design?
I can't imagine that there is a CASE out there that I could write a test first and then use a CASE to generate the code I need. I'd rather stick to resharper which can easily do my mundane tasks and retain full control of my code.
The project I'm on originally went w/ the Oracle Development Suite to put together a web application.
Over time (5+ years), customer requirements became more complex than originally anticipated, and the screens were not easily maintainable. So, the team informally decided to start doing custom (hand coded) screens in web PL/SQL, instead of generating them using the Oracle Development Suite CASE tools (Oracle Designer).
The Oracle Report Builder component of the Development Suite is still being used by the team, as it seems to "get the job done" in a timely fashion. In general, the developers using the Report Builder tool are not very comfortable coding.
In this case, it seems that the productivity aspect of such CASE tools is heavily dependent on customer requirements and developer skill sets/training/background.
Unfortunaly the Magic tool doesn't generates code and also it can't implement a design pattern. I don't have control over the code cause as i stated before it doesn't have code to modify. Te bottom line is that it can speed up productivity in some way but it has the impossibility to user CVS, patterns also and I can't control all the details.
I agree with gary when he says "it seems that the productivity aspect of such CASE tools is heavily dependent on customer requirements and developer skill sets/training/background" but also I can't agree more with Klelky;
Those main disadvantages are:
1. We cannot do automatic merges, making it close to impossible for parallel development on one component.
2.Developers get dependant on the tool and 'forget' how to handcode.
Thanks