I agree with Viktor.
GT concept is very different of XBP parts.
We can use Alaska's prg samples to test compatibility.
The true proof of compatiblity of xbp qt compatible parts would be to
recompile TopDown library in QT. Here we can test GUI Development +
Multithreaded windows.
My humble oppinion...
Angel
PD: Wouldn't it be more easy to implement a QT's own Gui design method ?
Why should we carry old practices when we have an opportunity to
create something new, light and clean ?
Viktor Szakáts escribió:
I am done with the preliminary preparations and
am about to start Xbase++ Parts implementation.
Here are few concerns:
As we discussed earlier it should be separate lib with
hbqtxbp.lib and hence will reside in that folder. As Xbase++
is essentially a GT + GUI Dialogs, I propose to use GTQTC
as its placeholder. That way both purpose will be solved
with a single lib. It is also important for me because I will
be eliminating duplicacy as many components already developed
in GTQTC are reusable in XBP context also.
Strongly voting against this. Attaching such classes with
a GT seriously limits its usage (I'd personally not even
consider using it). First, this will create a much more difficult
to maintain mixture of .prg level class code, plus the very
different and quite complicated GT .c code plus its support
routines. Such mixture is much more difficult to use, maintain
and test. We've already seen that with GTWVG.
Maybe I'm misunderstanding the meaning of XBP classes,
but to me it looks like the GUI solution provided by Xbase++.
If this is the case, this has nothing to do with any sort of
CUI emulation. If it has, we should discuss how to layer
these levels of functionality.
Mixing these two into one, would mean that no apps could
be gradually converted to use HBQT + HBQTXBP, since
the first thing to do would be to drop existing GTs in favour
of a new one, which can be immature, and possibly incompatible.
IMO usage of any libraries should *never* force a user to
use a specific GT. GTs are there to be replaced and if they
are attached with a complete library, this isn't possible.
So the reverse is also true: If someone writes an app with
such mixed GT+XBP, he will never be able to switch GTs
anymore, IOW it defeats the whole purpose of replaceable
GTs.
IMO if you want to support mixed CUI and GUI (using XBP
or whatever else), the proper way is to have a GTQTG
GT which uses HBQTXBP which in turn uses HBQT. This
ensure proper layering and using standard, documented
interfaces between these components.
If for some serious technical reason, XBP can only be
implemented as a GT+classes+HBQT mixture, I vote to
implement it outside the Harbour repository. I personally
highly doubt such serious technical reason exists.
"xbp.ch" header file should essentially retain the same name
as is but I am not sure if this violates Alaska's copyrights in any way.
The idea is that Xbase++ user, if he/she opts to compile their
existing code, are not subjected to change anything.
Filenames cannot be copyrighted, so the name is OK.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
