| 6.1.1. | Why are you writing another framework ? Aren't there enough out there ? |
|
The Visual Component Framework (VCF) was designed to make application
programming in general, particularly applications with User Interfaces,
much easier than it currently is with typical development tools. In addition
it was created to be cross platform in design, so a program relying only
on features within the VCF should simply recompile on another platform
supported by the VCF. In addition to all of this the VCF was designed to
support design time component editing, something that very few (Qt is the
only exception to this that I know of) toolkits/frameworks support. To
support this you need Reflection capabilities similar to what are found
in Java or Delphi, again very few C++ frameworks support this.
|
| 6.1.2. | Regarding the copyright, is it open-source, gnu license, what are the rules
about that? I just saw the installer telling me you own the copyright, is that so? |
| The VCF license is a BSD license. The only restriction is that
the copyright notice may not be stripped out from the source, and
you need to give credit to the project and or author(s). Beyond
that you are free to use the code however you like, and you are not
required to release changes you make back to
the VCF project (though they are certainly welcome to, and encouraged to
do so). Copyright is owned by the authors of the content. |
| 6.1.3. | How does the VCF compare to other frameworks or toolkits,
such as MFC, Qt, FLTK, FOX, and GTK? |
| |
| 6.1.4. | 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.
|
| 6.1.5. | Can we use the VCF in commercial applications? |
| Yes. There are no restrictions made on how the VCF is
used. It can used in both OSS and commercial/proprietary
projects. In addition, due to the BSD license, you are free
to make any changes to the VCF source code without obligations
to share the changes. While people are encouraged to do so if
possible, there is no requirement that forces this.
|
| 6.1.6. | Is the VCF Documentation available in PDF format? |
| Not currently, though there is an effort to make this
happen. |
| 6.1.7. | Is the VCF Documentation available in HTML for offline viewing? |
| Yes, see the project downloads section and look for the
Documentation area. |
| 6.1.8. | Is the VCF Documentation available as an HTML Help .CHM file? |
| Yes, see the project downloads section and look for the
Documentation area. |
| 6.1.9. | What would be required to port my MFC App to VCF? |
| Short answer. A miracle? Seriously porting an
existing code in one framework to another is not a 5 minute job. It would
partially depend on what features of MFC you make use of and how you built
your app. Many of the function names are different or subtly different.
The basic core concepts are pretty much the same, but the fundamental
design of the two frameworks is quite different.
Long answer.
The (rather glib) answer above assumes the questioner is talking about
a 100% port from one codebase to another. Obviously this is a painful process
no matter what framework we're talking about - even migrating an MFC app
over to the .Net framework is just as painful, possibly worse because there
are many concepts in MFC that have no direct equivalents in .Net.
However, it is possible to do this gradually. Thanks to the modular nature of
the VCF, you can gradually migrate your application over. For example, if
you wanted to just start with your IO code and basic objects, then you could
just use the FoundationKit with your MFC code base. See the
vcf/examples/MFCIntegration1 example for more information about this. Then
you might decide to just migrate your drawing code over to the VCF's way
of painting. Because we use standard Win32 primitives it's relatively easy
to mix and match the two. See the vcf/examples/MFCIntegration2 for more on
this.
|
| 6.1.10. | What platforms and/or compilers does the VCF support? |
| Currently the VCF runs on Win32 (Windows 98, Windows NT 4 sp4 or better, Windows 2000
and Windows XP). A linux port (with the UI/graphics parts based on GTK) is currently
underway and making good progress). Some work has been done on MacOSX, but it is
sporadic at best.
As far as supported compilers, the VCF is known to compile/link with:
|
| 6.1.11. | How are the resources handled between OS's? |
| On Win32 platforms resources are compiled into the executable using the toolchains rc compiler.
For other platforms, the VCF will use whatever native support there is, or come up with an
appropriate scheme. |
| 6.1.12. | If a serious security/memory/whatever issue was found 18 months down
the track how is this handled? In general where do I go if I find bugs, and
if I do, how can I get them resolved? |
| |
| 6.1.13. | How do I know what headers to use in my application? |
|
As a general rule you can do the following:
If you're just using the FoundationKit, then you can
simply include the FoundationKit.h, i.e.
#include "FoundationKit.h"
If you're just using the GraphicsKit, then you can
simply include the GraphicsKit.h, i.e.
#include "GraphicsKit.h"
The GraphicsKit depends on the FoundationKit and will
automatically include the FoundationKit header.
If you're using the ApplicationKit, then you can
simply include the ApplicationKit.h, i.e.
#include "ApplicationKit.h"
The ApplicationKit depends on the GraphicsKit and will
automatically include the GraphicsKit header.
|
| 6.1.14. | Why do I have to set environment variables? |
| The VCF uses three environment variables to identify the following:
Where the vcf/include directory is (as an absolute path), stored as VCF_INCLUDE.
This is the base include directory.
Where the vcf/lib directory is (as an absolute path), stored as VCF_LIB.
This is the base library directory.
GCC 2.95
GCC 3.2
|
| 6.1.15. | Will the VCF really save the world ? |
| No, this is a cruel rumor started by an obviously deranged
individual. Probably someone who spends far, far too much time in
front of a computer...
|
