Hello Viktor
Because this is pure technical message so I am
here to clarify some points which I think have either
been misunderstood or ( by me also, no issues )
interpreted in a wrong way.
Viktor Szakáts wrote:
>
> Since it's very difficult to make an
> ultimate decision about the best GUI API as
> "official" Harbour, and as it's not very good to
> tie us exclusively to one vendor (like Nokia
> in case of QT), we - before beginning - decided to
> use separate abstraction layers to ease switching
> components in the future.
>
You are right and we are sticking to the same rule.
And in the future too, no two thoughts.
> 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
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.
If this is acceptable, it is matter of little time. But
because I am not a make expert, so you have to
look into the basics.
> 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.
> 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.
> 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...
> 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.
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...
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.
> 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 )
hbXBP (or any other class framework ) is
the foundation to lay your creativity on....( backbones )
hbIDE is the final result show casing the above two...( bulding )
What got developed extra ?
Regards
Pritpal Bedi
-----
enjoy hbIDEing...
Pritpal Bedi
_a_student_of_software_analysis_&_design_
--
View this message in context:
http://n2.nabble.com/hbpqtui-class-tp4464679p4471535.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
