Viktor Szakáts wrote:
>
> I understand that, but .xml is just the container
> format, what really matters is the content and the
> specification which describes this content. In this
> case the content of the .ui file is seemingly a
> QT specific implementation of UI element description,
> with QT specific rules to describe UI elements,
> positions, string and visual behavior. We may not
> even know some parts of it which may be used in final
> Harbour apps, so to switch to GTK someone will need to
> create a _complete QT compatible parser for the .ui format_.
> Moreover it may be that GTK, WX or other GUI have their
> own similar formats already, and in this case such
> emulated QT version will even look alien there. So IOW
> IMO it's not a good idea to adopt QT-specific .ui
> format as _the_ portable format for HBXBP.
>
> F.e. current .ui file have such line:
> <widget class="QDialog" name="ProjectProperties">
>
> I can't see how that can be made to look/work portable
> and QT independent. It has the QT class name in it.
>
> 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 ?
> I can understand that. Well, I'm not sure if it
> helps our case to introduce a 4th contrib for QT
> to address QT - XBP specific needs, so if such
> issues are too pressing, maybe we should
> simply drop original ideas and rename HBXBP to
> HBQTXBP, which allows you to add HBPQT* classes.
> This of course means that HBXBP won't live up
> to original promise to be a generic Xbase++
> class implementation, which can either mean the
> original idea was over-optimistic and such thing
> can't exist (possible), or it can mean it would
> require a too complicated layout not usable in
> practice, or over our capacity.
>
> 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.
> 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...
> 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.
> 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 ?
> 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?
The secon - how we can capture the output in real time?
> 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.
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.
> 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 can see it, but reusing our own code is
> essential. There are other ways like moving
> these conversions into a lib, anyhow I can't
> see what's wrong in calling an external utility
> for some rare, one-time functionality. Tools
> do that all the time. If the popping up window
> is an issue, we should solve that.
>
As above.
> 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...
> 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.
> Here I find the priorities mixed. F.e. until an app
> crashes on exit every time, I simply couldn't find it
> justified to add theme support or similar things. For
> me even a simple build didn't work until I added the hbmk2
> dir solution. Here I cannot help without big time
> investment, but as a general idea: Make it usable and
> complete first for basic cases, then extend it with
> "bells and whistles". My general impression is that
> even HBIDE basic features have things lacking, and the
> UI looks casual and it's not getting fixed. F.e. look
> at how the menu gets greyed and stays that way when
> opening a dialog and closing it, strange focusing issues
> 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.
-----
enjoy hbIDEing...
Pritpal Bedi
_a_student_of_software_analysis_&_design_
--
View this message in context:
http://n2.nabble.com/hbpqtui-class-tp4464679p4474576.html
Sent from the harbour-devel mailing list archive at Nabble.com.
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
