>>> + contrib/hbqt/hbqt.h >>> + Added: constants hbqt_par_Qsci* >>> ; TODO make them local. >> >> This is serious modularization fault, >> even for an initial upload. Pls fix it. >> > > Yes, sure. > I need a name of such .h - hbqt_local.h ?
contrib/hbqt/qscintilla/hbqscintilla.h which refers to ../hbqt.h >>> + Initial upload of wrappers for QScintilla. >>> To generate the sources auto you need to stay in hbqt/hbqscintilla >>> and issue ../generator/hbqtgen. >>> >>> HB_WITH_QSCINTILLA and HB_WITH_QT need be properly defined. >>> I am still finding where to host modified QScintilla, any tips ? >> >> Are you sure you need to modify this >> external lib to make it work with HBQT? >> > > My experiments say it is must. > > 1. Flagship lexer is not implemented in QScintilla which I did. Smells like an upstream patch. > 2. May be it can go, but a lot of warnings while compiling QScintilla as per > Harbour make system. It can be suppressed, or just simply ignored. It's not our code, they are not our warnings, if it works, it's good for us. > 3. I could only build static lib, .a, and do not know how to a shared one, > .dll. That's a problem hitting distribution, not code hosting. If the code needs to be patched, it looks like a definite upstream patch. > 4. One serious issue which I could not resolve, commenting out a line > delete [] words; solved the problem, otherwise GPF. I know it may lead > to leaked memory but unless someone with more knowledge look into it, > I could not fix. "words" is defined as - char * words. Looks like a serious problem to me. Current solution is not a very good hack. Could be upstream bug to fix, I don't know. > 5. It is just the begining, I may need some more tweaking to achieve > some more goals, so may be needing to tweak Scintilla sources itself. That's bad direction, I'd very strongly suggest to avoid forking. Take it a black-box and use as is, as documented. If there is a problem, report back to author or qscintilla forums. > 6. Author, Phil Thomson, did not reply when I offered Flagship lexer code > to him plus few fixes to get rid of the warnings. His only reply was, > > "I don't understand this. By including QScintilla your application must > becompatible with the GPL. This means that you must make all the source > codeavailable to your users, and allow them to rebuild the application. So > whycan't you build it yourself as well? " Because we do not want to fork. But it's possible that your patch wasn't generic or had other problems, so upstream patch is not always the answer, or it may need to be reiterated. > It was on request that if he can provide a binary distro anyway because > Harbour > users do not know enough about Qt and its build system. > As hbIDE itself is open source, it confirm to GPL license, so no issues. > The only problem is how to manage it. My impression is still that it'd be the best to move hosting of complete HBIDE and even HBQT to a different repository with more lax rules, so you could manually maintain a fork if you think it's the best solution. While I believe it should be technically possible to avoid the fork and solve everything without massive (or even any) QSCINTILLA patches), I see a very bumpy road ahead and lots of wasted energy. Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
