Angel Pais wrote:
A compiler without a GUI Framework leads it to nitche apps: Servers,
console and cgi apps.
You are right Angel.
Harbour must have a multi-platform GUI support as an integral (core)
component to succeed.
IMHO There is some things to consider to achieve that:
1. Basic core GUI classes must be defined as 'Harbour own' classes,
then, do wrappers to connect it to the GUI framework selected to do this
development. Expose to users (Harbour programemrs) the QT, GTK (or
whatever) API should be not a solution.
As I've pointed in other posts, classes defined by Clipper 5.3 could be
a good starting point.
Another big advantage of this approach is that Clipper console
applications could run (with minimal modifications) on NATIVE GUI MODE
for ALL OSs supported by Harbour.
IMHO this point is EXTREMELY IMPORTANT, since it will turn Harbour in
the natural succesor to Clipper for all OSs without a doubt.
2. The GUI framework behind this scheme must be choosen carefully and
afetr a deep evaluation.
IMHO, QT is not a good choice. Compared with (ie) GTK, it is bigger,
slower and more difficult. I don't want to start a flame with this, I
understand that a lot of people think different. My opinions are based
on my own tests only.
3. In the case that it be possible, the extension of these features to
give to current and future Harbour users, some kind of native support to
create web-enabled applications, should be considered.
Desktop applications will not dissapear right now, but its use will
decrease steadily in the next years, reducing the user base of products
like Harbour, a lot.
Regards,
Roberto.
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
