>> 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.
>>
>
> The action would be :
>
> 1. Re-create contrib/hbqt/qtwebkit folder.
> 2. Place all the webkit related classes, auto generated, or otherwise, i.e.,
> hbqt.h.
If you include QtWebKit related stuff in hbqt.h,
there won't be guarantee that it's not used,
so it should have its own local hbqtwebkit.h header.
(this is true even for hbqtnetwork lib, or hbqtgui
for that matter, so it should also be fixed.)
> 3. Contains its own filelist.mk and makefile
> 4. Create separate lib hbqtwebkit.
> 5. This library will have dependancy on hbqt, hbqtcore, hbqtgui, hbqtnetwork
> but no other lib must have dependancy on hbqtwebkit.
> 6. None of the projects in SVN should have dependancy on hbqtwebkit.
Technically they could, but the whole chain
should be independent from core component parts.
> Is the above path OK ?
Yes, and you will also need autodetection to
avoid failure on platforms how chose not to provide
qtwebkit.
Using something like this instead of calling central detect.mk:
---
HB_HAS_QT_WEBKIT :=
_DET_DSP_NAME := qt
_DET_VAR_INC_ := HB_INC_QT
_DET_VAR_HAS_ := HB_HAS_QT_WEBKIT
_DET_FLT_PLAT := !dos
_DET_FLT_COMP := !mingw64 !watcom !bcc !pocc !pocc64 !poccarm !msvcia64
_DET_INC_DEFP := /usr/include/qt4 /usr/lib/qt4/include /usr/include
/Developer/qt/include
# untested
_DET_INC_HEAD := /QtWebKit/QtWebKit
include $(TOP)$(ROOT)config/detfun.mk
ifeq ($(HB_PLATFORM),darwin)
ifeq ($(HB_HAS_QT_WEBKIT),)
_DET_DSP_NAME := qt
_DET_VAR_INC_ := HB_INC_QT
_DET_VAR_HAS_ := HB_HAS_QT_WEBKIT
_DET_INC_DEFP := /Library/Frameworks/QtWebKit.framework/Versions/4/Headers
_DET_INC_HEAD := /QtWebKit
include $(TOP)$(ROOT)config/detfun.mk
endif
endif
---
To do that efficiently moc detection would be better moved
to separate mocdet.mk file and include that in all Makefiles.
>> 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.
>>
>
> No, I do not want to choose my own separate way, which
> will never get matured and will never be realized. Under the main
> banner, the likelyhood of realization are hundreds of time more.
>
> So far I was busy with integrating various visual components
> needed to present an effective user-interface. Now I think it has
> reached to some level of acceptance, so I will be focussing on
> bridging the gap between visual and non-visual components for
> the new couple of weeks. You can expect many questions in the process.
> One is already posted in another thread.
Thank you.
I didn't follow how is the memory unreleasing issue now,
but if possible it would be good find a solution for it.
Brgds,
Viktor
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
