Hi Pritpal, No, it's not scheduled for removal, but I'm in permanent and serious trouble because of GTWVG code and it essentially makes every build testing take much longer as it would normally take due to the tons of problems it generates, I haven't enough resources to clean it up myself, and I don't see these are being addressed by anyone else.
By current state of things I see no change that the code will ever comply to most of our guidelines which is there to assure some sort of quality and expectations regarding whole Harbour. GTWVG started as a simple GT, but in the last few months it became a behemoth lib with several different features and as far as I can see it, it's not possible to maintain it easily anymore, and as these new features got implemented into it, more and more Harbour rules have been broken. I used to signal every one of these with details, but I understand resolving them is either too huge task to ever happen, or against some compatibility concerns regarding your own local codebase, and/or you as an author are uninterested in doing appreciating these issue. I wouldn't tell all these if my experiences would have been smooth, and nobody can accuse me of not trying, since I've spent a significant amount of time testing, fixing, reporting these problems for a long time. We need to do something about it, please propose something, because I'm out of ideas. 1) It is a highly win specific lib with no counterparts on other > platforms. Your prg code will be win only. > > It was known from the DAY ONE. > How funny it is to conclude that it had a relevance THEN and > is irrelevant NOW... Group seems to think that it's better to comply with original Harbour rules and try to be portable as a whole. I agree with that. > 2) Plus it's x86 specific > > This is one part I am not conversant with. Probably it is > ActiveX Events Management code which draws this specific attenstion. > Even if it is x86, what does it stops to be usable, > x86 has many more years of life span I believe. Yes it is as I've reported it many times. I see no change for this to be ever fixed, but of course I would be very happy to see it happen anyway. Machine code stored as a byte array isn't very welcome in Harbour, and it was good to say goodbye to it, when Przemek rewrote runner.c. 3) was never successfully tested on ce > > This statement is valid for few weeks before, not now. > If used as pure consol it is not different then GTWVT in any > manner. I just commented out code which was not compiling > for WinCE. Now it compiles fine, so ... I was talking about working fine, not compiling fine. Notice however that we have 3 different compilers targeting WinCE, and regular testing of that amount of code has a huge impact. I wonder who tested all three recently. > 4) x64 > > This is something a future. And am confident that the way > we are moving, it will not be difficult to port a little code, > probably wvgcallb.c, to that platform or we can always drop Active-X > for x64 builds just guarding this .c with a define. It's a permanent struggle, with lots and lots of patches needed, at least that's the experience with much simpler and smaller code parts. And it doesn't work on x64, it's not only ActiveX as our last tests has shown. > 6) uses internals, non ansi c code, > > Th is one area I am not conversant with. Just point out what > this code is and I am eagerly willing to fix it. To begin with: comments, then wvgsink.c + wincallb.c direct access to internal HVM structures. 7) breaks core and other contrib namespaces > > This is totally a misleading statement. Where does it collides > with other libs ? And it is not something which becomes a > potent cause of its abolishan. WVT*, WIN*. No, it's just a rule we try to follow to keep things under control, and to not have to refix things and wasting time with issues which shouldn't have happened in the first place. > 8) has redundant winapi parts, code non portable between c compilers. > > Again a non-sense statement. Sorry if I am rude. I already gave > my node that it will be transferred to hbwin.lib as and when time > will permit. You've added a very specific and generally not very useful winapi part to hbwin, making that lib also prone to all Windows API portability problems. I've spend hours fixing it. We've discussed a completely different thing AFAIR. All the rest stayed in gtwvt. > Why there is a minimal hope? If a lib is consistently maintained and > is in production, this itself is a HOPE. If you don't mind we won't have a release because of GTWVG for the next 5 years until someone comes a cleans these issue up, it's okay with me too. I personally don't need a release BTW, but it would be important for the project. > For whom who are not aware I testify that GTWVG is in production > for over 250+ installations with MT and multi-windows, without even > a single GPF and memleak, with UNICODE enabled , with semi GUI modal, > with pure GUI modal ( Xbase++ implementation ). What elese is required > it to be a success. Good news, but that still doesn't clear up actual issues and you're probably talking about your own users. In Harbour we need to focus on the benefit for whole Harbour user base. > 11) We should focus on QT. We certainly cannot focus on both. > > True. But untill something usable comes up in QT, on which front > I have made some progress, we have to stay with GTWVG. Also GTWVG is > needed as references for QT port. Xbase++ classes are needed as a reference AFAICS. > 12) The code does not compiles with many win compilers. > > It compiles ( and runs ) fine with : > BCC55 > BCC58 > MSVC 2008 > WATCOM > PELLESC > MINGW > What other compilers this statement refers to? Please check our supported compiler list in config/win. > I need groups viewpoint if it is valid to REMOVE GTWVG from SVN > or to keep it. I am feeling a bit dejected as well and wish to have > a clear verdict. It will be helpful for me to concentrate on some > other corners of my life if it happens so. With all due respect: not to keep from me. It's nothing against your person or your work, I just feel this contribution would have a much better life as a separate entity due its size, focuses, and other misc properties I've repeated already too many times. We should focus here on multiplatform things. Brgds, Viktor
_______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
