But the fundamental problem with both is that
we're again introducing a way to make the GTs
behave differently. So it kind of ruins the concept.
+1
For me the first question is: what do we expect from GTs?
For me GTs are like RDDs, a compatibility layer with "old" code.
I would add only few things like close and palette ( not available at
DOS times ) that can be used in all or many GTs.
All the rest should go in contrib libs like wvt, wvg.
WVG, as WVT is core :)
The next question is: what is the next step?
For me the only thing that worth the work is "merging" CT win
management with tbrowse, get system, teditor, add the controls we
miss, put everything in a "blueprint" and see if we can map this tree
to sth like wxWidgets that is already multiplatform.
But we need a good plan BEFORE starting to add features here and
there.
For example Teo has a project on SF called wxHarbour.
If we careful plan the goals and share the work between the very few C
developers and the few prg developers we could probably achieve
something useful in not much time.
As a first step I would personally add (~move from CT)
window support to core. I'm for example relying on
a custom written windowing system, so I cannot use the
CT one as is. Admittedly this is a rare thing, but
having windowing capabilities in core GT would be good
for everyone I guess.
This way CT windowing could become just a thin(nish)
compatibility layer above the core implementation.
Having window support in core could create the bed
for natively windowing GTs (like GTWVW). From this
point on, the actual presentation could be changed to
more and more graphical.
But, for me it's still very difficult to believe
in _any_ portable GUIs.. It's enough to look at
Firefox, all the work they've done, and it's still
(3.0) just a mockup on OS X for example. Maybe using
QT, but QT is commercial. Not to mention the huge
work this needs for any final apps to migrate.
BTW, there is GUI in XBase++ too, but it looks very
very "alien" even in Windows... for sure it doesn't
look professional.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
