>>
>> So, the clean solution here is either to create a
>> HBXBP specific file format, which implements a portable
>> way of describing UI elements, OR (and this is definitely
>> the easiest) to implement such class in HBQT.
>>
>
> Ok, I do it.
> What be the name : hbqt_qtuiloader.prg ?
Thank you. It's good. Pls make sure that this
class won't contain anything XBP specific, f.e.
it cannot inherit from xbpWindow. So some slight
changes will be needed, f.e. to receive a QT
window object as parameter.
>> ...
>> As a workaround such QT-XBP connector functionality
>> can be contained inside HBIDE, but in this case
>> end-users will have to add this same hack to their
>> own app.
>>
>> Maybe some other GUI gurus could add some more
>> ideas to solve that.
>>
>
> hbXBP remains as is and I am transferring hbpQtUI to hbQT.
Okay.
>> I was thinking about HBDBFMODEL and HBQTABLEVIEW.
>> Where it seems that some more fine grained layering
>> could be used to keep HBQT on the generic side and
>> implement exact HBXBP needs as .prg level class/functions
>> in HBXBP.
>>
>
> This is essentially a Qt specific. There was no other way
> to receive protected events. One idea could be that
> parent class ( in this case QAbstractModelView and QTableView )
> are constructed from hbqt_* classes and delete separate
> classes. But in certain situations this is not possible.
> The constucture is designed with Harbour specific
> parameters. Ideas are welcome...
Not knowing the gory details I can't help here.
IMO it's enough to make sure that these classes
are useful in general, not just for XBP and they
contain no XBP specific specialities.
>> The naming is perfectly right. But, in HBXBP there
>> should be no such names. For reasons outlined many
>> times. Just think what happens if we want to implement
>> HBXBPGTK once in the future.
>>
>
> Already agreed.
Good.
>> Yes. We have one .c module, maybe that could be
>> replaced with some sort of generic .c function,
>> but that's not huge or priority issue for now.
>>
>
> This .c module is plain string parser on Harbour levels.
> Any other implementation can adopt it, no ?
It's a special string parser tailored for .prg
source lines, used in (AFAICS) speed critical
code. Here the only solution is to reimplement
it from Harbour core parts if possible, anyway
it's the "cherry on top" category, so let's just
forget this one for now.
>> I'd be glad to see the exact problems you were
>> having with HB_PROCESS*(), possibly with a small
>> and up to the point example. I'm sure that by addressing
>> those we may be able to either give better guidelines
>> on using this Harbour API, or make appropriate enhancements
>> in core to address the issues.
>>
>
> First and foremost, how we can disable console appearnce?
After checking the matter a little more closely
I'd think we will need core support for that.
> The secon - how we can capture the output in real time?
I hope Przemek can jump in, though I remember him
answering this exact question once in the past.
It would be useful to dig up this message.
I remember to implement WAPI_WAITFOR*() functions in hbwin
after reading this conversation to help the matter, though
we would need some portable core solution for this problem,
also.
>> For the first one: I wrote a msg asking "to
>> hold on for while", because I needed some time
>> to enhance it, which I did.
>>
>
> Till then I had already done.
> Also note that at the point I ask user to feed in
> an .xhb or .hbp I do not want to call hbMK2.
> The make engine is called on build process.
What is the reason? With it you could also easily
load hbmake and .xbp files with minimal extra
work. [ we need to solve the popping window though. ]
[ It's pretty easy to do, you copy the source filename
to a temp file, call hbmk2 with one parameter, pick the
same temp file but with .hbp extension and load it
as it as a regular .hbp file. ]
> You must have seen I retained the exact same
> code you sent for .hbp. I can replace my parser
> with yours it it helps any way.
If you want to maintain a copy of it and update it,
it's better but still not overly beautiful. I certainly
can't dedicate attention to update hbmk2.prg copy
in case the code changes in hbide.
>> As for the rest I'd
>> need to know what exactly do you need which is
>> missing from hbmk2, maybe it can be added in some
>> ways. If you needed the %HOME%-like variables,
>> I can convert them to {HOME} macros. But I need
>> to know which are these exactly.
>>
>
> No, I need an array to be returned with different
> components as you provided in .hbp code.
> %HOME% in xMate always points to resident folder
> of .xhp and it is already retrived.
> Again I have to host this code in hbIDE instead
> of calling hbMK2 at this point.
I don't understand it. All you'd need to do is
converting .xhp to pure .hbp file and use the standard
.hbp loader (which I've posted and which you've since
implemented) on it to load it. This way it's modular and
clean.
>> HBQT is fine in this respect (though QProcess is certainly
>> not needed), but it still have the problems, see the
>> TOFIXes in main lib, there is still a shortcut about
>> the :pPtr issue (you told it's too much work to change it),
>> which is now solved with a low-level hack, there is
>> the crash when exiting, there is the slots/events potential
>> leaks by requiring precis high level management. Plus
>> it's still has places where leaks or GPFs are possible.
>> Plus: MT issues. These are the known ones.
>>
>
> MT issue: I will turn to it later. I could not resolve the
> painting issue of Qt in MT scenario.
> For the rest I am aware of but probably there
> could be any way to eleiminate that altogether.
> The problem is : subsytem cannot recognize which object
> is firing this event. I will give it a thought again...
Thank you.
>> Here I can see a certain level of what I described.
>> I think it needs much more testing against original
>> Xbase++ and fixing existing problems before starting
>> to pump even more code into it.
>>
>
> Testing comes along the way.
> Angel has forwarded some issues which I resolved.
> Rest will be resolved as these are known. Currenly
> all concentration is on hbIDE.
That's exactly the problem :( (Wrong order of priority)
>> ...on the project pane, etc. Maybe these are HBQT or HBXBP
>> problems, but not addressing these tells to me that we're
>> rushing forward without fixing things behind.
>>
>
> I know your view points. And I always look into the
> points. Sometimes I can get to it, sometimes at some
> later time. It is all about developing an application.
> Features comes like a flow and you cannot resist it.
> If you look into the commits, everytime some aspects
> are reworked. This is a normal process in this direction.
> This is why I stalled Vailton's contributions for some time.
Okay.
Brgds,
Viktor
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
