> 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
