>> First we should discuss all concerns, if you care, pls >> answer them. BTW, it's supported on _some_ Linux distros. >> HB_WITH_QT_WEBKIT is no solution, but hack. Such setting >> should be resolved automatically. >> > > I was expressing the way help can be presented in hbIDE. > In no way I expressed that webkit should be part of hbQT > and be included in hbIDE. I had pointed out it load factor > which is of prime concern for me. This is the single most reason > that I wrote parser to read .uic files in place of calling QtUiTools > engine. And there is no need and place of such heavy load in hbIDE. > > To answer next messages, I would say that, at the point when > I removed QtWebKit, I was not equipped how to separate that > component as stand alone. Now probably I think I can do it, > I will exercise another effort.
Maybe it went unnoticed, but I've spent a considerate amount of time committing changes to help such separation. Aside from the base system, it needs continuous attention to avoid creating unwanted dependencies, so it's not a one-time task. Plus in case of QtWebKit, additional autodetection will have to be added to its Makefile. >> Or, it's still an option to move the whole QT related >> stuff from Harbour SVN to somewhere else and satisfy >> QT user special requests there. >> > > This is not an option, please... It's still an option. You've chosen to go your own separate way with these components, f.e. HBIDE lives in its own little "visual" world cut off from any interoperation with so called "non-visual" world. Harbour needs to offer more than that, and there is no technical reason not to do so. Anyway we're also facing a serious bloat by these components now. Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
