Hi Pritpal,
>> Specifically we decided that HBXBP should be
>> a layer which implements Xbase++ compatible
>> GUI classes, with future provision that the
>> underlying GUI engine can be changed, so f.e.
>> we can have HBXBPGTK or HBXBPWX as plugin
>> replacements. This assumes/requires that HBXBP
>> can have _no_ QT, GTK or WX specific parts,
>> simply because if we introduce such things, we
>> break this idea, and reimplementing HBXBP for
>> GTK or WX becomes impossible. (who will implement
>> an emulator for QT UILOADER class...?) Another
>> rule we agreed upon is that HBXBP is pure
>> .prg code. [This is adhered,
>>
>
> I have scheduled a detailed reply to HbpQtUI issue,
> but in brief I would like to suggest that just review
> the code. QUiLoader() class is just a wrapper to
> load different components of a dialog from an .xml
> file, nothing more. It essentally calls other Q*
> functions to generate the dialog. In Windows you
> can design a dialog in ant resource toolkit which
> in turn produces a .rc embeddable in the appln,
> wheras Qt offers this class to load. If you look into
> HbpQtUI() class, you will immediately recognize
> that it reads .ui ( .xml ) format and then the
> QUiLoader() is called and recognized various
> window components from .ui read parsing.
> Also this class adheres to Xbp class modal
> convensions. If we need to put it along Qt libs,
> then I have to rewrite this class adhering only
> Qt calls. Any other engine can achieve the similar
> job just reading a specifically formated file or even
> .ui. Even now with some extra effort I can do so
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.
> purely on class level without calling QUiLoader().
> This is not an issue at all. We have already decided
> on namespace, so this class can be separated from
> hbXBP any time. For this matter we can think
> of a separate lib called hbHBP and club all such
> classes which are based on Xbp there. Xbp remains
> the placeholder of only those classes which are in
> Xbase++ distribution.
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.
>> but shortcuts
>> are made by implementing HBXBP specific parts
>> inside HBQT, which is not the best.]
>>
>
> I need more explanation what is this. It is not too
> late to correct if such situation exists.
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.
>> Instead, the proper solution is to implement
>> all QT specific functionality in HBQT, implement
>> all Xbase++ compatible functionality in HBXBP
>> (with possible extensions, which are strictly
>> QT/GTK/etc _independent_).
>>
>
> I even propose to separate all such classes
> which are not Xbp specific but are fully in par with
> Xbp calling convensions. Qt specif classes which
> call Qt wrappers are under the domain of Qt only.
> And you see I have done it exactly like that.
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.
>> Finally we have HBIDE, which can basically use
>> any functionality which is provided by HBQT
>> or HBXBP, and it can mix these in any ways.
>> It's a end-user application (not a library), so
>> such things have no deeper consequences.
>> Although as a rule, HBIDE should stay portable,
>> so f.e. hbwin usage is out of question, and
>> usage of Harbour core functionality is encouraged,
>> even C/C++ code is better to be avoided.
>>
>
> This is exactly adhered exept HbpProcess(), below...
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.
>> There are other "shortcuts" made which are not
>> terrible problems functionally, but are wrong
>> decisions nevertheless, f.e. HBIDE uses
>> QProcess class, where we have one such class
>> already in Harbour core. It's a waste of
>> energy in several ways to re-implement
>> existing portable core functionality using
>> vendor specific solutions.
>>
>
> I tried with, and the code stayed for quiet some time,
> but I could not get rid of console appearing in front
> of the IDE and hanging ther until the process finished.
> Also the process output captured at the end.
> Przemek guided handsomely how other parts could be
> used but I could not get them working. Moreover
> Qt's implementation gave me very fine control over
> very basic points, and may by my lack of time or
> efforts, I could not achieve with hb_processRun().
> I thought you will jump in to fix it. But still it is
> not too late. If someone can do so please come forward.
> It should a matter of minutes.
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.
> We also have now
> .xhp reading functionality in HBIDE, while
> I made efforts in the past to implement
> the same thing in hbmk2. Well, instead of
> testing/fixing hbmk2, we now have a duplicate
> implementation to maintain and fix. Efficient?
> Not entirely. [ remaining, even more grave
> problems can be looked up from mail archives. ]
> </quite>
>
> Again we are missing a vital point.
> Visual vs Notepad. I looked in hbMK2 code
> before I wrote my parser and found it quite limited
> at that point of time, which you enhanced
> later. I also needed some more info which was
> not .hbp specific. Correct me if I am missing
> something...
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. 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.
> If you are saying the parsing of .xhp was unneccessary,
> it could have been issued via -xhp=filename option,
> then perhaps it is not the goal of hbIDE.
> hbIDE is essentially a visual environment to fetch
> all such information from the user in a visual
> way and supply to hbMK2. And visual environment
> needs sectionized and identified information,
> stored in a manner it could carry many tasks
> to make user's life easier.
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.
>> Overall IMO the main problem is that in case
>> of HBQT/HBXBP/HBIDE in the heat of enthusiasm
>> the development path goes into a certain level
>> of "featuritis" and rush, where we want everything
>> at any future cost and now. IOW quantity is
>> favored instead of quality. IMO we should
>> not have "all" features, but only the important
>> ones in order of priority, in a stable and working
>> fashion.
>>
>
> Something I cannot reply to...
> I cannot demarcate what you mean by essential
> and what is futuristic? Some detailed analysis
> may help me to understand your view point.
>
> Qt framework is minimum basic to start
> developing anything meaningful...( raw material )
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.
> hbXBP (or any other class framework ) is
> the foundation to lay your creativity on....( backbones )
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.
> hbIDE is the final result show casing the above two...( bulding )
> What got developed extra ?
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.
Brgds,
Viktor
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
