71–80 of 92 posts
One of the things "missing" from Go is the ability to do a GUI. Some work is being done to build out a QT library, but it seems like the progress on atom-shell and node-webkit may almost make Qt overly cumbersome to work with. Other than native controls and the potential DOM lag of a webkit interface, is there any particular reason why someone programming in Go, Python, Ruby, etc. would want to engage Qt; assuming a…
Earlier quoted context omitted.
I haven't investigated Qt's mobile offerings or "Qt Quick", but I am fairly certain that on X11-based systems the basic core desktop SDK is as native as any other UI toolkit (e.g. GTK), and on Windows it uses the same core libraries that MSVC-written programs use, so it's as close to "native" as it gets there, too. Is that incorrect?
That is incorrect unless things have changed in the last few years. Qt does not use native controls. Everything (list boxes, tables, buttons, etc.) is drawn and implemented by the Qt library. wxWidgets takes the opposite approach and uses native controls. I imagine they support a lot fewer platforms as a result. It's much easier to port when all you have to do is abstract the native drawing and input routines.
Earlier quoted context omitted.
plenty of opensource-but-with-enterprise-offerings do the exact same thing, with high levels of success (although I can't think of any examples of this off the top of my head)
Various *nix flavors, MySQL, Asterisk...
Open source, community edition:
Hosted version with customization via themes and plugins:
I wish they could just spin off a QT3-era widget library for cross platform desktop only stuff. All the new QtQuick declarative and mobile stuff just confuses me and gets in the way. Believe it or not, Qt used to be a small and lightweight library.
I wish they could just spin off a QT3-era widget library for cross platform desktop only stuff. All the new QtQuick declarative and mobile stuff just confuses me and gets in the way. Believe it or not, Qt used to be a small and lightweight library.
That being said, if a Qt 3-type spin-off were desired and had enough support, I do not see the current developers of Qt (both Digia and outside of Digia) as spending a lot of time on it, since most of the focus is specifically on the features you would want to avoid.
My suggestion would be that if you want a widgets-only version of Qt, you could gather a group to create an LGPL spin-off of Qt 4 or Qt 5 using the specific modules you want as a starting base. (I may be wrong, but I think Qt3 still has messy licensing from the Trolltech days).
I wish they could just spin off a QT3-era widget library for cross platform desktop only stuff. All the new QtQuick declarative and mobile stuff just confuses me and gets in the way. Believe it or not, Qt used to be a small and lightweight library.
QWidgets are still there.You don't have to use QtQuick.
If you don't need QtQuick or QtWebKit, you can actually drop quite a few of the packages.
One of the things "missing" from Go is the ability to do a GUI. Some work is being done to build out a QT library, but it seems like the progress on atom-shell and node-webkit may almost make Qt overly cumbersome to work with. Other than native controls and the potential DOM lag of a webkit interface, is there any particular reason why someone programming in Go, Python, Ruby, etc. would want to engage Qt; assuming a…
You say "other than", but native controls are a big deal. As an OS X user, I for one would strongly avoid using an application that uses (often generally poor, almost always slightly off with keyboard shortcuts and such) HTML replacements for native UI. (For the record, I don't use Atom, but in that case the horrid performance is more important.) Actually, Qt suffers from this as well compared to native Cocoa, becaus…
Earlier quoted context omitted.
You say "other than", but native controls are a big deal. As an OS X user, I for one would strongly avoid using an application that uses (often generally poor, almost always slightly off with keyboard shortcuts and such) HTML replacements for native UI. (For the record, I don't use Atom, but in that case the horrid performance is more important.) Actually, Qt suffers from this as well compared to native Cocoa, becaus…
When I hear "GUI" and "native", wxWidgets immediately pops up in my head, which is a decent framework and wraps native controls. I wish it had more publicity.
- It uses macros instead of C++ templates in order to support ancient compilers.
- To handle events, you're supposed to make an enum for your controls and go through these EVENT_TABLE macros - it works, but generally it's a mess compared to nicer frameworks like Qt.
- Threading support is really lame, e.g. this quirk of AddPendingEvent: http://docs.wxwidgets.org/trunk/classwx_evt_handler.html#a07...
- Then and probably still today, OS X Retina support was completely broken. Not a great turnaround time - it was already a year after the release of Retina laptops.