Hello Viktor
Viktor Szakáts wrote: > > We will need a HB_INC_QT and HB_DIR_QT envvars > for include, otherwise the hbqt dir should look the exact > same as any other 3rd party dependent dirs. Only the > list of files, platform/compiler guards and autodetection > dirs will need to be adapted. > > set HB_INC_QT=C:\devl\Qt\2009.01\qt\include > set HB_DIR_QT=C:\devl\Qt\2009.01\qt > ... > Ok. I will try though I feel suseptible about my abilities. > Yes, it indeed looks very fine and has every property to > become a good base for a portable Harbour GUI. > > Maybe it's not too late to ask such thing, and since QT > can easily become such crucial core component of Harbour, > I'd very strongly recommend for you and everyone involved > to try to create a well laid out, modular base, where we > use the Harbour API the best available way. This ensures > that QT won't become bloated and unmaintainable quickly. > For this to happen any QT related parts should only rely > on QT headers and Harbour API, most importantly *no* > Windows API in *any* form. > > The other important part is modularity. Few things we can > create using QT: > - QT wrappers, in .cpp. Separate lib: "hbqt" > - Pure QT CUI GT: "GTQTC". This needs to be done separately and > compatible with GTWVT, GTXWC. > - Xbase++ class on top of hbqt lib. Preferable a separate lib, > or at least separate .prg-only files. > - Mixed CUI-GUI GT. I'm not sure if that was what you had > in mind, but in this case, this should be a separate GT, > by the name "GTQTG". > The above is almost right directions. My proposed roadmap: 1) have QT wrappers in place in contrib/hbqt - only HB Api and QT headers 2) GTQTC in contrib/gtqtc - a pure console implementation along lines of GTWVT - I do not much about GTXWC so cannot take advantage - probably it is similar to GTWVT as I could understood via this list. 3) On top of GTQTC, Xbase++ Parts - here Xbase++ parts PRG code will be common for GTWVG also - as it is purely a PRG code. 4) GTQTG - GTWVG implementation on top of GTQTC if there would be - a need to do so. For sure no Windows API at all, otherwise it will not be portable. Can you setup contrib/hbqt environment there with hbqtapi.h hbqt_qdialog.cpp hbqt_qabstractbutton.cpp as outlined in post above. keeping it away from default builds. > Since DOS isn't supported anyway in QT, I'd like to propose > to lift 8.3 rule in QT related contribs dirs. If there are no > objections, let's go that way. > > In the future we can group these related contribs under one > main directory, or shuffle them as looks best, but let's keep > it clean and modular please. > Perfectly OK. Regards Pritpal Bedi -- View this message in context: http://www.nabble.com/QT-and-some-...-tp22580862p22585684.html Sent from the Harbour - Dev mailing list archive at Nabble.com. _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
