An article about the Visual Component Framework was posted on DevChannel (here and here) a few weeks ago that developers on Slashdot might be interested in. It introduces the Visual Component Framework, a relatively new (project has been in progress for around 3 years) C++ application framework. Built to target Win32 systems first, it is now in the process of being ported to linux (using GTK) and OS X (using Carbon).
Well, the author got Qt’s licensing pretty much wrong.
* Qt is triple-licensed, not double, he forgot the QPL
* You can get a GPL/QPL Qt for win32 (which is probably in better shape than VCF/gtk check out kde-cygwin’s qt3-win32 (and no, that’s not the one that requires x11)
* The look of Qt on OSX is based on a OSX api, which is the exact same one carbon uses to draw the widgets, so it can expect to have some similar issues, since that API has not been updated to latest OSX look (if I misunderstood this, correct me)
* If VCF’s “native look” is a Y, then Qt deserves at least partial credit, since on X11 both are just as “native”.
You seem to get it wrong, some people don’t want to write GPL software, and the Qt licence for that costs arround $3000+ for one developer.
“* The look of Qt on OSX is based on a OSX api, which is the exact same one carbon uses to draw the widgets, so it can expect to have some similar issues, since that API has not been updated to latest OSX look (if I misunderstood this, correct me)”
Dead wrong. Carbon remains the main API for OS X to this day, though Cocoa is still making rapid progress. Cocoa itself is largely a wrapper around Carbon and even lower level calls, not a low-level system itself.
The reason Qt looks out of place on OS X is that, while it is automatically updated to the new widgets, the system does not automatically reconfigure itself to new metrics. Hence it will use the new buttons etc, but if the size of things has changed, the interface will not reflect this unless TrollTech releases an update.
For some quick links for downloading it, should people be interested:
Source tgz:
http://prdownloads.sourceforge.net/vcf/vcf-0-6-3.tar.gz?download
Win32 Full Installer:
http://prdownloads.sourceforge.net/vcf/VCFFullInstaller.0.6.3.exe?d…
Note this installs source and binaries, with the binaries compiled with VC6sp5. It also integrates docs with MSDN if you have the MSDN Viewer installed that is compatible with VC6.
Win32 compiler support is VC6 and VC7. VC7.1 is in cvs but not yet fully tested, so there’s no release for it yet. To grab it anonymously from cvs see:
http://sourceforge.net/cvs/?group_id=6796
Feel free to join up on IRC at irc.freenode.net #vcf. I’m usually online anytime after 7PM EST.
Questions regarding this can be addressed either to our forums at http://vcf.sf.net/forums/
or email me at:
ddiego at users dot sourceforge dot net
Cheers
and then found…
Why not just help out an existing framework? Why write yet another framework/toolkit?
There are a variety of reasons, such as:
*
One of the big ones is the dynamic nature of the VCF due to the use of advanced RTTI features. For a number of frameworks this would be difficult to fit in with out serious changes to the framework in question.
*
Another reason is simply the way the VCF is designed, for example the use of a Component base class for many of the UI controls, and the presence of Property and Component editors to support RAD design time editing. Supporting these requires certain features that could be difficult to add in to an existing framework (this was partially the case with wxWindows).
*
Other issues are the usage of modern C++, such as templates, STL, namespaces, and exceptions. These require a reasonably up to date C++ compiler (such as GCC, MS VC6 or VC7, Borland C++, etc), and some of the existing toolkits place a high priority on supporting older, non-standard C++ compilers, which greatly reduces what features of the C++ langauge are available to them.
So it looks like Visual Component is using a more modern design than vxWindows. vxWindows also is a bit MFC’ish. It does the job, but might turn some people off. Hopefully Visual Component can become fully cross-platform at some time.
We’re working on it. If you or anyone you know of has experience with either GTK and/or Carbon on OSX we’d love to have the extra help!
Just as an FYI, after looking at both Cocoa and Carbon I decided to use Carbon, because it doesn’t require a compiler to support Objective C, which many compilers do not. A pity, cause the Cocoa API’s and VCF peer API’s are almost a 1 to 1 match.
Not everybody uses C++. The problem with most cross-platform GUI libraries is that you need C++ or a translation/binding. QT, XPCOM (Mozilla), wxWindows, FTL…
I would like to see some automated way to generate an interface to the library for Delphi/Kylix, Python, plain C (which allows a bridge for most other languages) etc.
or OpenOffice.org? …
I’m sure GTK+ has something like this, but for Qt, see libsmoke. In general, there is Boost.Python (excellent, I’ve used it in a project myself) and Swig.
Sorry mate, this is OO programming; you can’t have Component OO programming in C. You should have upgraded to the OO world 14 years ago. I don’t think anyone is crazy enough to create a GUI toolkit in a procedural language that is cross platform.
>Sorry mate, this is OO programming; you can’t have Component OO programming in C.
That is strange, I’m very much able to do component and OO programming in C. GTK+ does it very nicely, so does lots of other software. You need to realize that C++ is not the definite solution to do OO, and that many developers wants/are better of with C.
If I wanted to create something like this I’d do it with GTK+ and *only* GTK+, rather than trying to abstract the underlying widget toolkit.
Most attempts at doing this that I’ve tried have not worked terribly well – a widget toolkit is not an easy abstraction to make because they vary so wildly in design, capabilities and look’n’feel.
If the developer of this framework doesn’t like GTKmm for whatever reason – and it seems the VCF is certainly more comprehensive – then I think it makes sense to build it but only have one backend which is portable to various platforms. Otherwise apps written with the VCF will have the same issues w.r.t portability that wxWindows apps do – they feel out of place everywhere and have slightly fragile feeling UIs.
Obviously it would be easier to use the same backend, but gtk+ has always been known to have issues on Windows and who knows about the gtk+ on mac. He would also lose quite a bit of control too. Only time will tell.
Mike,
IMHO, GTK apps look great on linux, or other systems which use X as their primary window server. However, again IMHO, they look horrible, and utterly alien on systems like Win32 or Mac OSX. One of the points of the VCF is to have a toolkit that full cooperates with the underlying OS/windowing system, as well as behave well with the dominant toolkit(s)/API’s used on that system. This is certainly the case for Win32, where you can use VCF on it’s own, or you can integrate it into existing MFC (or other Win32 based toolkits). Likewise, the choice of GTK is meant to make VCF based applications look and feel like a “normal” linux app, as well as offer the ability to integrate with other apps. The choice for not using gtkmm was simply to minimize depencies. However, it should be noted that the backend is done by implementing a set of peer interfaces. These could be implemented just as easily using Qt, KDE, or even Motif, should someone step up and volunteer their services to do so.
wxWindows apps do – they feel out of place everywhere and have slightly fragile feeling UI
Not really sure what you mean there. Any wxWindows app has look and operated fine to me. The ones that don’t work well probably suffer because they were written poorly, not because of any short coming of wxWindows.
If you *do* have specific issues, then by all means list them out, and I’ll make sure that if they’re not addressed already, that get listed as tasks to implement in the future.
Sorry mate, this is OO programming; you can’t have Component OO programming in C.
Python, Delphi/Kylix and the rest of languages that I would like to see supported are OO programming. You haven’t understood what I said. And you get completely wrong the component requirements for multilanguage.
The problem is that C++ objects are not easily callable from other languages. There seems to be better perspectives with gcc 3 that’s said to be standardizing ABI. But even then, you need to write a lot of wrapper code or have a tool to do it.
Either you write a low-level plain C API and another C++ API to wrap the former, or you write the basic API in C++ and wrap it with a flattened C API that is easily callable from other languages (any but C++). This flattened API and the bindings in other language could be automatically generated to always be in sync.
You should have upgraded to the OO world 14 years ago. I don’t think anyone is crazy enough to create a GUI toolkit in a procedural language that is cross platform.
You can create the toolkit with whatever you like more, but if you want to be linked from programs written in different languages, then it’s a good idea to offer a convenient interface. That means binary compatibility which is a little more complex than object interfaces (exceptions, etc.) but it’s the biggest part.
Thank you for the links. Swig seems nice.