Hi Lorenzo,
Yes, I'm ready to actively participate but this will be a team work.
I think we should start from the "prg level" and think about it as the
"abstract level".
I think the opposite way :) BTW what I had in mind is
"multi-window GT", you seem to talking about something different.
We already have 5.3 classes like tbrowse, button, get, menu so we
don't start from scratch.
We have only to add what is missed for a more complete GUI like
twindow ( or tform ), tcombo, teditor, ttoolbar, tfolder and so on.
This is different from what I had in mind. These things are
controls. TWindow is related, since it can be an OOP wrapper
(and extender) for window handling, but even this is one level
above hb_w*() functionality.
To me these all seem like part of a different move (than
multi-window GT), and what you say would be something like
"Harbour UI abstraction library". And if you mean a CUI
implementation, it is doable (even independently from
multi-window). A very good implementation of this idea was
sold under the name ProVision:Windows. For me it's a bit
late to invest in a new set of CUI controls, tough.
[ If you mean to implement it in a very generic way so that
it works equally well for GTTRM and GTWVT (with Windows controls),
I'm in huge doubt if this is indeed viable inside the boundaries
of Harbour. ]
These classes can start simply as "empty bodies" that define standard
methods and properties and only after they should be mapped to "low
level" layers like text, CT, Win, X.
It's very dangerous to build the building from the top :)
This will lead to forced bad design decisions just
because we already have a higher level element that
needs to do something weird.
In this way we keep the "philosophy" of Harbour UI and we'll not end
with tons of xyz_funcs() that are not portable.
I think we should define what we want. At this point Harbour
is very far from implementing any native GUIs, or even UI.
The whole point of GT is to help console based output (meaning
a matrix of chars with colors). Multi-window still fits into
this. But it's not suited for GUI.
If we want to add a framework for GUI to Harbour core, that
should be built from ground up IMO. It will be a very tough trip :)
Maybe I misunderstood you.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
