>> IMO, it should not require it, but may give extra features >> if available, and for sure _be compatible with it_. If current >> implementation _requires it_, which means it cannot work or >> cannot reliably work without it, we should document this fact. >> > > HBQT may/may not _require it_ but HBXBP certainly _requires_ it. >> From the day one HBXBP acquired first few lines of code, I was > very much clear about its objective, Xbase++ modal, which > is compulsory a MT modal. > > Probably I do not need to explain more.
Sorry, but it's still not clear if MT is required and why, you missed the point again. HBQT != HBXBP, so I don't care here whether Xbase++ supports, needs or requires MT mode. HBQT is independent from HBXBP, and is a wrapper for QT lib. QT lib has nowhere such requirement that MT HVM must be used. Such requirement would be nonsense anyway, as we're here talking about _HVM_ MT mode, and again QT doesn't know anything about our HVM, so it cannot have any requirements towards it. This should simply be cleaned. >> What I notice is that you repeatedly fix GPFs by tweaking .prg >> level code, which suggest that one can write such .prg code >> which makes lower level components fail. This is unacceptable >> IMO, and for sure makes it very difficult to work with such >> component. >> >> Since you know the HBQT details inside out, it would be nice >> if you could give some hints on this topic. >> > > I never tweaked the .prg to fix GPF, I just added the closing calls > which which were necessary to pacify the Qt engine, for example, > discooencting the slots which cannot be implemented through GC > engine. You can call it _lazyness_ to forget to write few more lines > which I should ever had. No, I call this an extremely dangerous implementation. I don't call it lazyness, I call business as usual to have mistakes in any code, like .prg level code in business app. If such mistakes can result in GPF for _whatever_ reason, it means the HBQT wrapper is lacking some extremely important features and it's not ready for prime time. I'm sorry I cannot comment on the exact issue, so can't argue whether there is better solution for it, but in programming in general, "cannot be implemented" very rarely holds, so I'm sure there is a way to solve it cleanly, maybe it needs some extra ideas or extra clever tricks. >> Not exactly. >> My only concern towards QT _which is out of our control_, >> is that it's very heavy and can't be linked statically. >> >> But, from all other aspects it looks quite good and it >> will probably catch on even more, so IMO we should not >> drop but, but rather try to fix all the parts we can >> and make it a robust platform for Harbour. >> > > The above all points are valid. > But probably I am not expert on all matters. So a deeper > attention by all of you is needed to address this issue. > My focus at this point is to create the framework and working > engine. Lately GC pointers were implemented but I could not > recover consumed memory completely. But may be it is just a > matter of time before me or someone else hits the bull's eye. > > Separation of Components: Well, I do not think any further > separation will do. QtWebKit was an exception and it is > isolated, though it is needed for HBXBP to be compatible > with Xbase++'s XbpHTMLViewer(), but we can live without it. > All other components are inter-dependant. They can be inter-dependent, but do you think there is a way to modularize the slot system f.e.? (hbqt_slots.cpp) Right now it seems that even by using the smallest bit of HBQT, it will automatically pull in the whole QT interface and I mean all of them. Maybe this is normal for QT apps, but to me it looks rather strange and makes HBQT unsuitable for anything but huge integrated apps. This also limits the extent HBQT can currently support QT components, as each new component adds to the overall "cost" of _all_ QT apps. I mean, if we added support for "QTFancy" class, everyone would have to start shipping qtfancy.dll whether he uses it or not. This doesn't make it "scale" well. Anyhow, for now this is rather optimization issue, so first we should solve the showstoppers, which is 1) and 2). BTW, QTWebKit was removed quickly, and I believe without fully evaluating the possibility of having it there, jut in a non-integrated way. Anyhow maybe in the future when we reach this topic and solve it, it will be possible to readd QTWebKit. And other extra QT components for that matter. > For deeper reasons I request today, and had requested in the past too, > Przemek's attention to this project. I also invite others to join the discussion and participation, but that's not something we can order, probably everyone is participating where he/she finds some personal interest. At this stage you can probably expect general input only and directions and you should do the bulk of coding, since you know it the best. It also helps if there are specific questions you're seeking answers for. Sometimes I feel that my comments are ignored and it doesn't really help the case from my side. F.e. here we have these 3 memory handling models... I'm still in the dark what they are and why do have three, what are the differences, etc. Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
