Hi Pritpal,
> > The question is which way to choose to rewrite it _once_. > > Options: GUI and WUI (web UI). For me a GUI is only an > > option if it's at least portable, and it's a plus if it's relatively > > easy to migrate CUI source, possibly with gradual rewrite. > > > > This is EXACTLY the theme of GTWVG. Reusability of Clipper source. > Just add few lines and have a nice look and feel. Personally I don't want to keep UI source code by all means. The problem with this approach is that it rarely gives a native GUI feel. What would be important though is to have a relatively easy upgrade path, and what helps a lot is if you can convert your app window-by-window. > classes can live by themselves (or not), and its also unclear > > how the different namespaces / internal components are > > connected to each other. > > > > Yes, off course, too many things. But all are detachable, all > can be used separately as well as cummulatively. Namespaces > are strikingly distinguished. None interfare with others. And it is > relatively easy to separate if there is a need for so. I would suggest this route, if for nothing else, for the reason of clarity. If it's clear, maybe other can also join the effort of developing it, or we can at least have a better idea of what "assets" we have there. This is a question of debate. I choose Xbase++ modal on the strength > of its sheer uniformity in calling conventions and parameter passing > PLUS a decent documentation you need not to rewrite PLUS a large > user base. Enough reasons to base. Yes, these are absolutely valid ones. I really cannot judge here by lack of experience and knowledge. Xbase++ compatible framework is purely on PRG level. To make it > multi-platform you need to call the OS API. So it it is just a matter > of time when someone copy its class structure and implement the > next platform. Jumping on the theoretical level: .prg code _can_ be non-portable for several reasons, starting from non-portable concepts, through focusing on OS specific features / models, ending with simple non-portable code (filename handling, using OS specific Harbour features, using non-portable OS features.) So, generally speaking .prg code is not a guarantee for portable code. I didn't speak here about Xbase++ classes, or your implementation, since I don't know them enough, but rather in general terms. Sadly. And hence GTWVG + Xbase++ implementation is a > single handed effort in that direction. Yes, one problem I see, is the mentioned problem of everything being meshed together which makes is very difficult to oversee. The sheer size of GTWVG also became huge, 1.5MB of source. This IMO needs to be organized. The other part is deep deep Windows dependence. I understand this is a Windows-only contrib, but still, staying along the Harbour dev guidelines and trying to isolate (or even avoid some of) these parts would certainly help in suggesting a portable approach. GTWVG is doing everything by itself, I don't see why does it need to have a duplicated OLE engine. Time would better be spent on fixing our existing implementation, rather than adding another one with similar or other flaws. Big problem is that Xbase++ parts are closely tied to WVG GT, so it cannot even be tried out without using WVG GT. A few points which could be fixed: - To avoid xhb.lib (which isn't terribly portable) - To not use Harbour internals. - To not use CPU specific code. - Separation of OLE/ActiveX. - Maybe it's impossible now, but GTWVG could inherit from GTWVT, instead of copy-pasting (duplicating) functionality. - Modularize, modularize, modularize :) I'd imaging these layers with clear namespace and file structure: - GT (inheriting from WVT and others in the future) - WAPI functions - WIN functions - WVG functions (named WVT_* - this is also a big reason for confusion) - Xbase++ parts - GTWVW functions. With clear call rules: - Xbase++ parts call WAPI/WIN API only. - WVG functions call WAPI/WIN API, uses WVG GT dependent features only. - GTWVW functions call WAPI/WIN API only. - WIN calls WAPI only. - All above parts can of course you any std Harbour API. Since I understand you have a strong concern of being compatible with your own software, I think you should somehow detach this need from GTWVG general development, maybe with a set of compatibility API (not necessarily public), or by other means. But this is really something I can only advise on, it's your time and your effort. Brgds, Viktor
_______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
