|
Hehe try to build one better than Qt and that's cross platform and runs on hardware devices like phones, cars, etc then you'll know how to create one  . Don't take it the wrong way or anything. But wasting time writing your own gui is just a waste of time. *shrugs*
|
|
|
|
|
You're right! What a complete idiot I was! I see the light now. Thanks so much for providing such well a thought out and enlightened response! I really do see now that Qt is better than everything else out there! Woot! I can't wait to write a Qt app to run on my linux powered toaster - awesome.
|
|
|
|
|
While I respect your zeal (kind of), I must respectfully disagree. Qt is a bad application framework for the following reasons:
1. It is not exception-safe[^] which was acceptable in 1991, but not in 2011.
2. Qt uses non-standard C++ extensions via a separate tool (moc) without any valid reason. There are many standard-compliant implementations of signals and slots that are superior to the Qt's, such as Boost.Signals[^]
3. GUIs developed with Qt look fine on Linux/KDE, substandard on Windows and on Mac - well try convincing a Mac fan to use a Qt application if you can 
4. Qt duplicates many features of the C++ Standard Library without any real need.
5. Qt design is typical for the 1990s style of OOP design. Modern C++ looks very different than Qt - it avoids raw pointers, uses RAII, STL and exceptions. Qt looks like a half-baked Java.
In conclusion, I strongly advise against using Qt. If you don't like C++, just switch to Java or C# instead. Qt is not C++.
|
|
|
|
|
Who cares about exceptions? Qt uses return error codes. Exceptions just bloat code.
Qt's signals/slots predate all of those. If Qt uses Boost, it would require depending on Boost release cycles and Boost doesn't isn't even binary compatible nor source compatible. Have you ever used Qt's meta object system to even complain about it?
I've used Qt on Mac and Windows and I can't tell a damn difference between the two. Well a few little problems on Mac but nothing the average user will care about. You forgot recently that Qt actually uses the platforms native api to render it. On Mac Qt uses the native widgets. On Windows they use the uxtheme api.
Qt was done in 1991 and the C++ was standardised in 1998. also Qt still tends to support a lot more systems that don't have proper STL support or even lacks some of it which Qt requires which requires Qt to use it's own containers, which are also very compatible with STL. Also if you haven't noticed, there are syntax style issues that don't match Qt's style convention, STL didn't provide a hash until C++0x which still isn't widely supported by compilers. Have you ever seen how bloody painful STL is to work with? I rather use Qt's containers which give me extra functionality that STL's containers don't provide.
How is it 1990's style of OOP? Please xplain this to me? What you rather it be empty and featureless like all the other gui toolkits like Gtkmm, wxWidgets (even wxWidgets has it's own C++ containers, but I don't hear anyone bitching about that?). I guess you prefer everything done in a sh*tty MFC/wxWidgets clone with macro hell, ugly hungarian notation, featureless, only works on one OS, support that sucks, hard to use and keep building on?
Yeah I guess Windows users love to complain about anything and everything. I guess that's what you are saying basically right? You prefer requiring billions of dependencies on other libraries and half broken apis with multiple different style conventions just because you think it will be bad.
If Qt is so bad, then why is it the most toolkit used in C++ for Scientific applications, in Hollywood movies, in car embedded devices, cell phones and I can continue to go on and on.
So please enlighten me troll how is Qt not C++. I guess it's in Javascript or COBOL right?
|
|
|
|
|
xComaWhitex wrote: please enlighten me troll
I'll continue this discussion when you grow up and learn your manners. In the meantime, I have reported your post as offensive. Thank you.
|
|
|
|
|
|
Was that really necessary? You could see from his previous messages that Nemanja is a respected member of this community.
|
|
|
|
|
xComaWhitex wrote: So please enlighten me troll
That's just not called for. Just because somebody chooses to have a different opinion to you does not entitle you to be offensive to them. That is the height of bad manners, and is not going to win you any arguments because you have deigned to start name calling.
|
|
|
|
|
Well it's hard to tell serious people from those that just troll. If he disagree that his opinion. Just wasting time using something else. xD
|
|
|
|
|
xComaWhitex wrote: Who cares about exceptions? Qt uses return error codes. Exceptions just bloat code.
I personally dislike exceptions and only use them when the error is critical. The biggest reason I don't like them is a failure in a function does not have to be a fatal/critical error. There are many cases in my programs that failure return code can be dealt with through the software and in these cases exceptions do not seem to add anything but to make the code less clear by nesting levels of try{} catch() blocks and rethrowing. Not to say that I am thrilled about return codes either but I do use both in an application.
John
|
|
|
|
|
John M. Drescher wrote: I personally dislike exceptions
Which is fine. It is also fine that a library/framework does not use exceptions for error reporting and relies on error codes (although it may lead to problematic practices such as "two-step initialization"). What is *not* fine is that a library/framework does not offer basic exception-safety guarantee[^]. If either your code, or code from some other library you may be using (including the C++ Standard Library) in your code throws an exception, you may leak memory or other resources because Qt is broken.
|
|
|
|
|
Also I forgot to tell you Qt has it's smart pointers that are based on Boost's/STL.
Also Qt doesn't really require smart pointers due to the fact it manages it's own memory using Parent/Children relationships. So when the parent is deleted, all the children are deleted also. I haven't had a memory leak in a long time.
Qt's MetaObject functional gives me more access than STL's sh*tty implementation of RAII does. If IIRC it doesn't even allow me to do introspection, creation of class instances from QMetaObject, etc.
Nothing stops you from using STL in Qt or even exceptions, it's all your choice to.
|
|
|
|
|
Please, understand that this is not a "longest piss context", neither a "my dick is longer then yours" show casting.
It is a matter of fact that many framework (I can cite Qt, WxWidget, MFC ...) had been developed BEFORE certain aspect of C++ that are required in those framework where standardized.
And it is also a matter of fact that 10 years after that standardization almost nothing has been done to re-conduct those framework towards the standard C++.
That said, it is also true there are not so many alternatives: C++ standard based frameworks like VCF or Algierlib exist. How attractive can be they widget library respect to Qt or other is another problem, that has no relation with standardization.
So -at least- we had better to avoid mixing everything up.
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
I have been developing desktop applications in winforms, explored WPF and find it to be great but requires a learning curve.
Recently, developing cross platform application using JUCE framework in C++. Finding it to be great as it is open source.
Praveen Raghuvanshi
Software Developer
|
|
|
|
|
Rags1512 wrote: JUCE framework in C++.
Interesting - didn't know about it. As far as I can see, it looks like something a Java coder would come up with 
|
|
|
|
|
I am a VC++ developer and love desktop application programming. 
I believe in LOVE AT FIRST SIGHT...
Bcoz I have loved my Mother...
even since I opened my eyes...(ICAN)
|
|
|
|
|
Trust me it's even better if you ditch the MFC and use WTL instead. 
Anna ![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
Tech Blog | Visual Lint
"Why would anyone prefer to wield a weapon that takes both hands at once, when they could use a lighter (and obviously superior) weapon that allows you to wield multiple ones at a time, and thus supports multi-paradigm carnage?"
|
|
|
|
|
I had used it in my project but don't know love MFC more than WTL. No doubt working on WTL is nice but there are some limitation i found when implement ListControl in WTL (May be lack of knowledge in WTL)than i switch to MFC.
I believe in LOVE AT FIRST SIGHT...
Bcoz I have loved my Mother...
even since I opened my eyes...(ICAN)
|
|
|
|
|
A lot of it is familiarity. Whilst there's no doubt that some parts of MFC have functionality missing from WTL (the command UI update mechanism and Doc/View are two obvious examples) the common controls aren't among them.
I'm fluent in both frameworks, but I've not had to write a line of MFC in 4 years.
Anna
Tech Blog | Visual Lint
"Why would anyone prefer to wield a weapon that takes both hands at once, when they could use a lighter (and obviously superior) weapon that allows you to wield multiple ones at a time, and thus supports multi-paradigm carnage?"
|
|
|
|
|
For one, WTL is not supported by Visual Studio.
MFC ClassWizard (revamped) is back in VS 2010, and there is obvious reason for it.
|
|
|
|
|
I haven't used the ClassWizard since 1998 (VC4.1) or so - I just found it too restrictive and found it easier to write the code myself instead. Hence I didn't find its omission from VS2002-VS2008 a problem at all.
However, if that's the sort of thing that floats your boat there is a WTL ClassWizard right here on CodeProject - but as I don't find I need ClassWizard I've never used it.
Anna
Tech Blog | Visual Lint
"Why would anyone prefer to wield a weapon that takes both hands at once, when they could use a lighter (and obviously superior) weapon that allows you to wield multiple ones at a time, and thus supports multi-paradigm carnage?"
|
|
|
|
|
Code but how much? There are complicated notification messages (WM_NOTIFY) that can automatically be written straightaway from Resource editor.
As I already mentioned CW is one of the features that MFC has, and not the feature to market MFC.
May be you can point out few features, that aren't available in MFC, but in WTL.
|
|
|
|
|
I prefer to have more control over the code than ClassWizard offers. That's my choice, but I certainly don't condemn yours! As I said, there is a ClassWizard for WTL available for those who are more comfortable with that style of development.
Doc/View and CN_UPDATE_COMMAND_UI are two features in MFC that are notably missing out of the box in WTL; both can be annoying but neither are showstoppers (we actually use a WTL Doc/View port in one of our projects), but it's not in the distribution. By contrast things like ribbon controls and Task Dialogs are included.
On the flipside, it's far easier to extend dialogs and control classes in WTL using mix-ins than in the CObject based single-inheritance model MFC forces you into. For example, adding the same context help fucntionality to a CPropertyPage and a CDialog is very difficult without duplicating the code, and a mix-in class like WTL::CSortListViewImplT just isn't possible in MFC without using window hooks.
Ultimately MFC is a much more heavyweight framework with longer history and therefore backward compatibility induced baggage (remember the CPropertySheetEx fudge?) than WTL, which is rather more lightweight in nature.
If MFC works fine for you, that's perfectly fine; I can only speak for myself - and I have run up against inviolable assumptions in its design which make it unsuitable for the sort of projects I work on at the moment.
Hence, I'm rather enjoying using a more modern lightweight alternative, but I'm not suggesting everyone has to, by any means - use what works for you.
Anna
Tech Blog | Visual Lint
"Why would anyone prefer to wield a weapon that takes both hands at once, when they could use a lighter (and obviously superior) weapon that allows you to wield multiple ones at a time, and thus supports multi-paradigm carnage?"
|
|
|
|
|
Anna-Jayne Metcalfe wrote: I prefer to have more control over the code than ClassWizard offers. That's my choice, but I certainly don't condemn yours! As I said, there is a ClassWizard for WTL available for those who are more comfortable with that style of development.
How many times you need to have more-control? You would love to copy-paste the same code, rather than just let the development environment do it for you? And you don't lose any flexibility either, it is not like ATL/COM complex macros you cannot control - the entire generated code is there for you. Any MFC programmer, after gaining confidence over more-control part (after learning) would prefer automatic code generation; and would have the ability to change the code.
Anna-Jayne Metcalfe wrote: Doc/View and CN_UPDATE_COMMAND_UI are two features in MFC that are notably missing out of the box in WTL; both can be annoying but neither are showstoppers (we actually use a WTL Doc/View port in one of our projects), but it's not in the distribution. By contrast things like ribbon controls and Task Dialogs are included
I don't count is as feature in even in MFC.
Anna-Jayne Metcalfe wrote: On the flipside, it's far easier to extend dialogs and control classes in WTL using mix-ins than in the CObject based single-inheritance model MFC forces you into. For example, adding the same context help fucntionality to a CPropertyPage and a CDialog is very difficult without duplicating the code, and a mix-in class like WTL::CSortListViewImplT just isn't possible in MFC without using window hooks.
MFC doesn't support MI for a reason. Have all classes which are NOT derived from CObject, except one, and you can achieve MI. Why would you need two CObject class participating in MI?
I did not understand about the help-functionality you mentioned!
With CSortListViewImplT, I think you meant a list-control's sorting. You can use virtual-list control! You always don't need callback mechanism for sorting. For less number of items in list-control, you just delete-all and then insert again! What Windows Hooks has to do with it??
Anna-Jayne Metcalfe wrote: Ultimately MFC is a much more heavyweight framework with longer history and therefore backward compatibility induced baggage (remember the CPropertySheetEx fudge?) than WTL, which is rather more lightweight in nature.
Heavyweight. Compared to what? A template-based code that goes into multiple executables? I have developed hundreds of MFC apps, and that needed only one MFC DLL. You know what I am referring here.
MFC is very thin layer over Win32 APIs. Most of the functions are inlined (logically), and they simply call Windows functions (like SendMessage). Yes they are mixed with ASSERT macros, but that's just a defensive approach.
|
|
|
|
|
Ajay Vijayvargiya wrote: Heavyweight. Compared to what? A template-based code that goes into multiple executables?
Pretty much all WTL code gets optimized away by the compiler. Scott Meyers did an interesting experiment with several GUI libraries/frameworks and found WTL to have the least overhead compared to pure C Win32. Can't find the link, sorry - it was a disussion on comp.lang.c++.moderated.
But my biggest peeve with MFC is not the runtime overhead, but the fact that it is an application framework - it works fine as long as your application fits the MFC model, but once your requirements don't fit the model you need to constantly fight MFC, and I find it very frustrating. To be fair, I have the same problem with any other framework I have worked with. ATL/WTL, on another hand, is a library. You can use as much of it as you want and it does not impose any design on you. It does HWND to object mapping fine (much better than MFC), it has a decent message cracking mechanism, enables automatic cleanup of handles for controls, there is a nice optional layout manager[^] - that's almost all I need from a GUI library. Serialization, networking and other MFC provided goodies are orthogonal to GUI programming and have no place in a GUI library, IMHO.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
