Hi Lorenzo,
I'm personally only interested in no app UI rewrite and
maximum portability, so I'm sticking with the CUI look.
Me too.
My apps have to run "exactly" in the same way under *nix, Win and OS X
( even using same number of rows and cols ), so for me
gtwvt=gtxwc=gttrm.
CUI ( sadly not much appreciated today ) has the plus to work
everywhere.
Using gttrm/gtxwc I have users that enters orders with IPAQ, eeepc,
notebooks and every possible desktop with many *nix and many Win*s
versions.
And when you need nice UI for BI, video, CRM and so on html, ajax and
web standards are much easier than gdi, gtk and so on.
So I don't see much room today for desktop apps with mixed CUI/GUI or
even with a full GUI.
Understand me I would pay for a lib that would not require a full
rewrite of a CUI app, but if much of the code have to be rewritten
many other things comes in ( dbf -> sql, developers availability,
costs ) so at last it's easier to hire some Java developers and
rewrite everything from scratch ( if you have customers that will pay
it ).
My thoughts _exactly_.
For this I think that MT is necessary asap.
MT is almost useless used directly in business apps but it's necessary
to create RPC apps that responds to an off-process GUI frontend.
Yes, MT is very important. This seems like the highest priority.
I'd also find localization and unicode support very important,
since my apps have to work in multiple countries, with different
codepages. It's also needed to exchange data with external
subsystems of all kinds.
As for Unicode (if anyone else is interested) it would be nice
to identify the bigger steps ahead to implement it in Harbour.
The goal here is to be able to compile a regular .prg file
that may also contain UTF8 encoded chars, into a fully unicode
application. At the end, the application should only deal
with codepages where any input/output subsystems are not
Unicode ready and we need to convert to/from non-Unicode to
Unicode using a specified codepage. Other than that the app
should simply work with all unicode chars and present them
properly on screen for example.
We'll probably need to introduce Unicode versions of pcodes,
so that uni/non-uni Harbour .obj can be mixed, and we may need to
duplicate each API calls to accept both kinds of string input.
This looks very ugly and difficult to maintain, so I wonder if
there is any other solution. Another one, which I'd personally
favor, is to upgrade to Unicode in one step and require to
recompile all Harbour objs in order to make them work with
Unicode Harbour. Here one remaining question is how to stay
compatible with C code expecting a legacy (non-Unicode)
Harbour/Clipper API. This one could be solved using a compatibility
layer between non-Uni and native Harbour Unicode API. So that
apps can keep using old ones and may choose to switch to native
Unicode if they wish. Maybe the two methods below can be combined
for best results.
As for the compiler, it needs a switch to get the codepage
non-Unicode sources, and it needs to recognize UTF-8 source too.
We'll need a Set() to specify codepages for Clipper functions,
like MemoRead().
We'll also need to find the appropriate Unicode APIs for
different platforms. Here there will be a problem supporting
Win95/98/ME in clean way. We'll need to identify those
platforms where unicode is not available, and either drop
or handle these gracefully.
Last but not least we'll need to settle on which Unicode
encoding standards to use. For internal usage I'd personally
stick with UTF16, like most OSes and languages do internally
(not Linux though, unfortunately so this won't be an easy
decision), it's also easy to work with, but I'm fully
convincible on UTF8 either :) For source code representation
I'd stick with UTF8. [ Some speed penalty is to be expected
when the Harbour internal and platform unicode encoding is
different. ]
All the above is just speculation, food for thought...
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
