Visual Clipper

[Ash]

Hello,

I wish the following Clipper controls were part of Harbour core but in GUI form and using the same syntax - things like:

@... Say
@... Get

@... Box
Check Box
List Box
Push Button
Radio Button
Radio Group
Scroll Bar

These controls are enough to write very good looking business applications in a way that we have been used to from Clipper days. Writing business applications is hard enough never mind the complexities of add-on GUI libraries.

My 2 cents worth.

Regards.
Ash

[Dasun]

Hell yeah Ash,

Do not forget a data Grid!

I am currently using Marinas-GUI,  I think it is great, but I have spent a lot time making commands to do @ whatever stuff as defining all the controls in the standard Marinas (and most other Harbour GUI) way is very verbose.

[Ash]

Hello Dasun,

WVWTools V0.8.4 might do the trick. The source is available from xHarbour's website. I thank the authors for sharing their code. 

I tried to compile it using Harbour but wasn't successful. There are many compile time errors mostly due to coding style and/or language differences between Harbour and xHarbour. Here are some examples:

GLOBAL variables.

Use of IN instead of $

SWITCH constructs

ARRAY[-1]

ADEL() with third parameter that shrinks the array by one.

...

Most can be fixed with find/replace.

There is also some C code that is beyond me.  However, I will have a go at converting this library to work with Harbour.

Regards.

Ash

[Juan Francolino]

Hi,

See you qtcontribs?

\harbour\addons\hbqtwidgets\tests\pureclip.prg



//-----------------------------------------------------
...
 /* Harbour standards SAYs and GETs */
   @ 1, 02 SAY PadL( "Upper Cased Alphabets:", nPdL ) GET cText VALID {|oGet| cText == "ABC" .OR. cText == "DEF" .OR. Udf1( oGet ) } PICTURE "@!KA"

   @  2, 02 SAY PadL( "Birthday:", nPdL )
   @  2, nColGet GET dDate WHEN {|| cText == "ABC" } COLOR "B/GR*" ;
      VALID {|| AChoice( 5, 5, 12, 20, { "Abc","Cde","Efg","Fgh","Ghi" } ), dDate >= 0d19560604 }

   @  3, 02 SAY PadL( "Max 6 Decimals:", nPdL )
   @  3, nColGet GET nNumb PICTURE "@Z 9,999,999.999999" WHEN {|| DispOutAt( MaxRow(), 20, "Harbour" ) } VALID nNumb > 600 .AND. nNumb < 6000000

   @  4, 02 SAY PadL( "Logical - Married:", nPdL ) GET lMrd  PICTURE "Y"

   @  5, 02 SAY PadL( "Telephone Number:", nPdL )
   @  5, nColGet GET cTele PICTURE "@! (999)999-9999"

   @  6, 02 SAY PadL( "Upper Lower Upper:", nPdL )
   @  6, nColGet GET cJust PICTURE "@A" COLOR "W+/B*" VALIDATOR {|cText,nPos| UpperLowerUpper( @cText, @nPos ) } VALID {|| GetAsChild_1() }

   @  7, 02 SAY PadL( "Scrolling Catalog:", nPdL )
   @  7, nColGet GET cCata PICTURE "@S15 !!!-!!!-!!!!!!!!!!!!"  VALID {|| GetAsChild() }

   @  1, 52 SAY "Val[1]"
   @  1, 60 GET val[1] PICTURE "@!"
   @  2, 52 SAY "Val[2]"
   @  2, 60 GET val[2] PICTURE "@K 99"
   @  3, 52 SAY "Val[3]"
   @  3, 60 GET val[3]

   @  5, 52 SAY "Deptt:"
   @  5, 60, 5, 69 GET cDeptt COMBOBOX aDeptt VALID {|oGet| HB_TRACE( HB_TR_ALWAYS, oGet:varGet() ), .T. }

   @  7, 52 SAY "Salary:"
   @  7, 60 GET nSlry PICTURE "@KE 99,999" VALID {|| nSlry > 600 .AND. nSlry < 17000 }

   @  9, 48 SAY "Done:"
   @  9, 54 GET lDone CHECKBOX

   @  9, 02 SAY "Notes:"
   @ 10, 02, 16, 55 GET cNotes MEMOEDIT COLOR "N/rgb(255,255,230)" WHEN cText == "DEF" VALID "Harbour" $ cNotes ;
                                  PROPERTIES {|oGet,oControl| SetControlProp( oGet, oControl, "tooltip", "The notes must contain 'Harbour' somewhere" ) }

   @  9, 60 SAY "Select:"
   @ 10, 60, 16, 69 GET cList LISTBOX aList WHEN cText == "ABC" VALID {|| HB_TRACE( HB_TR_ALWAYS, cList ), .T. }

   oBrowse := BrowseArray( NIL, .F. )
   //
   @ 18, 02, 24, 42 GET lBrowse HBQTBROWSE oBrowse

   //@ 18, 44, 24, 69 GET s_cImage IMAGE DONOTSCALE WHEN {|| .F. }
   @ 18, 44, 24, 69 GET s_cImage IMAGE WHEN {|| .F. }

   @ 26, 25, 26, 44 GET lOk     PUSHBUTTON "OK"     ACTION {|| iif( Alert( "Save Data?", {"Yes","No"} ) == 1, "cText", "cNotes" ) } ;
                                                        WHEN nSlry > 700 .AND. nSlry < 17000
   @ 26, 50, 26, 69 GET lCancel PUSHBUTTON "Cancel" ACTION {|v| v := Alert( { "Cancel Pressed!", "Should we terminate the Form ?" }, { "Yes","No" }, "W+/N", 5, "Really?", 2 ), ;
                                                        iif( v == 1, GetActive():parent():close(), NIL ) }

   /* Bring on browser as a selection list */
   SetKey( K_F2, {|| BrowseArray( GetActive():parent(), .T. ) } )

   /* Caclulator callable with F10 */
   SetKey( K_F10, {|| HbQtCalculate( GetActive():parent() ) } )

   READ PROPERTIES {|oWnd,oGetList| SetFormProperties( oWnd, oGetList ) }

...
//-------------------------------------------------------------------------------------------------------------------






Regards,


Juan

--
--
You received this message because you are subscribed to the Google
Groups "Harbour Users" group.
Unsubscribe: harbour-user...@googlegroups.com
Web: http://groups.google.com/group/harbour-users

---
You received this message because you are subscribed to the Google Groups "Harbour Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sami Laham]

Hi Ash if you want use wvw see in Viktor fork 

https://github.com/vszakats/harbour-core/tree/master/contrib/gtwvw

Regards

Sami

[Dasun]

Hi Ash,

Thank you for bringing  WVWTools V0.8.4 to my attention, I will look into  when I get a chance -  my C is rusty but still passable.

My interest is in multi-platform stuff, so I kind of wish QT was built into the core Harbour @SAY, GET engine not just as a contribution.  I think that approach would a have reduced the multitude of Harbour based GUI developments that have spring up in recent years and provided a better platform for moving Harbour into the future...which should include Touch.

Think how easy it would be if all one had to do was to type something like this:

SET GUI ON

SET METRICTS CHAR //Use Char size tiles instead of pixels for character position - for business apps that would make screen design a snap, but you would need to use a mono-space font

CREATE WINDOW MAIN 100 100 CENTRE TITLE "It is a test"

CREATE WINDOW w_Test 50 50 TITLE "Test" RESPONSE

@ 10,10 SAY "WOW"

@ 11,10 SAY "Your Name" GET ls_Name VALIDATE uf_Name(ls_Name)

@15,25 GET COMMANDBUTTON OK ACTION {|Value |uf_Process_OK(Value)}

...

...

To Create a GUI main window, open a response window  setup some text, get a variable and add a button - which is exactly the original spirit of clipper and - in my view - should be built into Harbour.  We should not  have to futz around with 10's of lines of code to achieve the same thing or be looking into various addon contribs  - and I really appreciate the work of the authors that have done this.  I know I have had this discussion before, and not all agree but it would really speed up development of business apps.

I use Marains-GUI as it a complete package that compiles Windows and Linux with QT, but I find myself writing commands like the above to simplify later development.

My 2 cents worth

[Ash]

Hello Sami,

I have been using GTWVW for many years. As it is the easiest GUI to use, in my view, it  is a good candidate for harbour core.

Here is an example of what I have been able to do after getting over some initial integration issues.

Regards.

Ash

[Ash]

Hello,

Here is an attempt at bringing the idea of Visual Clipper to life. If it is of any value then we can build on it.

I didn't have the time to format the code to Harbour standards.

Regards.
Ash

[Dasun]

Ash,

This is an excellent start and in my view should be part of core and not contrib.  This would make Harbour much more attractive for business developers, in Linux and Windows. I have been very busy with a number of things, and trying to massage Marinas the same way when I can but your implementation is a better Harbour fit.  I would like to hear what others think, but this should be  core - maybe a compiler switch to enable disable - for headless/server Harbour applications.

One suggestion I have is to define position with pixel or char coordinates - as it is easier to layout a screen in char mode as the numbers are smaller and easier to imagine!  If you want help I can try and allocated some time, I will test your code a bit later today ...

I think this is a very positive direction to take...

On Monday, February 29, 2016 at 3:53:22 PM UTC-4, Ash wrote:

[Ash]

Hello Dasun,

Another attempt at cleaning up the code - fluff moved to other files.

BTW, screen positioning is row/column based as in Clipper.

I settled on GTWVW many years ago. It has served my customers well.

Regards.
Ash

[Daniele Campagna]

--

Unfortunately the wvw library is a Windows-only solution. (I use it and migrated some clipper-era programs with limited rework - but Linux?)

Dan

[Dasun]

What is the Linux one I am getting confused with ? GTK or something similar?? .. Mr Kresin  from Russia used it for a multi-platform GUI library.    If this route is taken, need a mutli-platform solution and the current ability to support headless servers.

The reason I uses Marinas is because it has good multi-platform support (QT based) but I really feel this sort of functionality should be part of Harbour core - a GUI TSBrowse would be something to get excited over!!! 

[El Oso Pedrozo]

I find this project very good idea to make a Visual Clipper applications that can be done with a good graphical interface. I hope it is well organized with their website, complete documentation of language, reference manuals, updates binaries and everything related to it, as well as draft Python-Lazarus Free Pascal, FreeBasic. Among others.

A and that can be done both graphical applications as console .... You have to provide this new project ....

[Alain Aupeix]

Le 01/03/2016 17:25, Dasun a écrit :

What is the Linux one I am getting confused with ? GTK or something similar?? .. Mr Kresin  from Russia used it for a multi-platform GUI library.    If this route is taken, need a mutli-platform solution and the current ability to support headless servers.

Hwgui uses gtk and is avalaible for Linux and Windows.
I use it since a few year and it has all the things needed to build gui harbour programs.

The reason I uses Marinas is because it has good multi-platform support (QT based)

I never like Marinas which is too heavy, and I don't like QT (to much problems with it, due to different version qt4 or qt5 on my ubuntu). Same with hbqt.

I'm happy with hwgui

A+

--

---

Alain Aupeix
http://jujuland.pagesperso-orange.fr/
http://pissobi-lacassagne.pagesperso-orange.fr/

---

U.buntu 12.04 | G.ramps 3.4.9-1 | H.arbour 3.2.0dev (2016-02-11 10:54) | Hw.Gui 2.19-5 (2533)

---

[Daniele Campagna]

Il 03/01/2016 09:02 PM, Alain Aupeix ha scritto:

I'm happy with hwgui

A+

--

I have the feeling that somebody here misses the point.
I tried, even heavily, Fivewin, Hwgui, gtwvw, and I tested a bit Marinas and undervaluate probably HMG and Minigui Extended (that's unfortunate).

I think that wvw is unique in his capability to mix console/pseudoGUI elements in a way that allows  to convert a Clipper program with the minimal effort.

All of my former Clipper programs run now under GTWVW + HWGUI (they can coexist).

Every and all other GUI library need a rewrite of the whole UI, not so for GTWVW.

Unfortunately it's a Windows-only solution and, AFAIK, a slightly discouraged one. Not standard-complaint probably, nor "the right way to do it".

There is nothing like GTWVW, still it is probably exactly what clipperians wanted. But not a "mainstream" nor "advisable" solution. It's just seen as a "workaround". Eh, but very effective.

It is inane to compare, f.e., HWGUI to GTWVW, they are inherently different and have different goals. The success GTWVW has, even with not great support, is anyway remarkable.

GTWVW allows you to keep, in a way, your Clipper way to do things, while any other GUI library forces you to do things in a "better"way, but impose a deep rewrite, too.

That's the reason for old clipperheads feel comfortably with GTWVW, and comparisons with other, "better" solutions are of little value for them, IMHO.

Just an opinion,
Dan

[Alain Aupeix]

Le 01/03/2016 22:00, Daniele Campagna a écrit :
> Il 03/01/2016 09:02 PM, Alain Aupeix ha scritto:
>>
>> I'm happy with hwgui
>>
>> A+
>> --
> I have the feeling that somebody here misses the point.
> I tried, even heavily, Fivewin, Hwgui, gtwvw, and I tested a bit
> Marinas and undervaluate probably HMG and Minigui Extended (that's
> unfortunate).
>
> I think that wvw is unique in his capability to mix console/pseudoGUI
> elements in a way that allows to convert a Clipper program with the
> minimal effort.

gtwvw isn't linux supported ... and I'm under Linux.

Yes, I had to rewrite a few parts to have a gui program, but after some
unsuccess tries at the beginning, now I'm ok.

A+
--
------------------------------------------------------------------------

Alain Aupeix
http://jujuland.pagesperso-orange.fr/
http://pissobi-lacassagne.pagesperso-orange.fr/

------------------------------------------------------------------------

U.buntu 12.04 | G.ramps 3.4.9-1 | H.arbour 3.2.0dev (2016-02-11 10:54) |
Hw.Gui 2.19-5 (2533)

------------------------------------------------------------------------

[Daniele Campagna]

Il 03/01/2016 10:54 PM, Alain Aupeix ha scritto:
> Le 01/03/2016 22:00, Daniele Campagna a écrit :
>> Il 03/01/2016 09:02 PM, Alain Aupeix ha scritto:
>>>
>>> I'm happy with hwgui
>>>
>>> A+
>>> --
>> I have the feeling that somebody here misses the point.
>> I tried, even heavily, Fivewin, Hwgui, gtwvw, and I tested a bit
>> Marinas and undervaluate probably HMG and Minigui Extended (that's
>> unfortunate).
>>
>> I think that wvw is unique in his capability to mix console/pseudoGUI
>> elements in a way that allows to convert a Clipper program with the
>> minimal effort.
> gtwvw isn't linux supported ... and I'm under Linux.
>
> Yes, I had to rewrite a few parts to have a gui program, but after
> some unsuccess tries at the beginning, now I'm ok.
>
> A+

Lucky you, best wishes. It's not that I don't develop under Linux. I
wrote from scratch an entire web development framework, using harbour.
It does not need a bit of GUI, since it's all based on gtCGI and,
client-side, HTML/Javascript.

I don't see unfortunately here any market for GUI programs under Linux,
there is simply no request.
And under Windows I have serious doubts one can blindly rely on Hwgui,
without some aces in the sleeves, it has still some quirks and no
documentation apart sources (I still have not tried it under Linux anyway).

What about converting a 36000+ lines program from Clipper to GUI? Not an
easy task, when the program logic should be reworked completely in fact.
It's simply not the same approach.

And if you really want to go GUI and exploit the power of windows, f.e.
doing image processing, it's a problem even to find out how to integrate
Freeimage with hwgui. The only example (imgview.prg) has been stripped
away from recent version 2.19 (widely undocumented anyway in v. <=2.17).

So... if it's all about adding some controls to have a nice appearence
to substitute an input mask from character to graphical appearence, OK.
But real-life programs need something more. You need time and effort to
load a jpeg via freeimage and figure out how to display it in a hwgui
control. There is no documentation about it. How to select a file
outside the current directory with hwg_fileselect() if it changes the
current directory and there is no way to pass the flag OFN_NOCHANGEDIR? Etc.

There are no free lunches.
This post is just about being impartial and not making people think that
hwgui is the perfect solution: easy, free and wonderful. I use it and
appreciate it, but it's right to give some caveats. :-)

Dan

[do...@people.net.au]

Hi all

One of the great things about Harbour is it is so flexible

You can run it on a wide variety of operating sytems

You can write procedural and / or OOP code

You can use pretty much any data base you like

You can write console, TUI or GUI applications

There are a range of interfaces to graphical libraries, eg GTK, QT and those libraries can be made to work either using Cl*pper style commands or accessing the classes directly.

That same flexibility does have a drawback - a programmer new to Harbour who has come from an environment where all those decisions have been made for you faces a rather steep learning curve to get started and depending upon the decisions taken a larger or smaller task in terms of modifying any existing application.

I believe that the core of Harbour should remain exactly that - a core to which you add the database of your choice, the GUI or TUI of your choice etc.  However there could be some advantage in having some download "package" for say a programmer wanting to recompile Cl*pper code with almost no code changes required.  The trouble is whatever choices you make re OS, database, GUI won't suit evryone.

Regards
Doug

[Ash]

Hello,

Here is the output of wvwtest.prg.

Regards.
Ash

[Alain Aupeix]

Le 01/03/2016 23:44, Daniele Campagna a écrit :
> Il 03/01/2016 10:54 PM, Alain Aupeix ha scritto:
>> Le 01/03/2016 22:00, Daniele Campagna a écrit :
>>> Il 03/01/2016 09:02 PM, Alain Aupeix ha scritto:
>>>>
>>>> I'm happy with hwgui
>>>>
>>>> A+
>>>> --
>>> I have the feeling that somebody here misses the point.
>>> I tried, even heavily, Fivewin, Hwgui, gtwvw, and I tested a bit
>>> Marinas and undervaluate probably HMG and Minigui Extended (that's
>>> unfortunate).
>>>
>>> I think that wvw is unique in his capability to mix
>>> console/pseudoGUI elements in a way that allows to convert a
>>> Clipper program with the minimal effort.
>> gtwvw isn't linux supported ... and I'm under Linux.
>>
>> Yes, I had to rewrite a few parts to have a gui program, but after
>> some unsuccess tries at the beginning, now I'm ok.
>>
>> A+
> Lucky you, best wishes. It's not that I don't develop under Linux. I
> wrote from scratch an entire web development framework, using harbour.
> It does not need a bit of GUI, since it's all based on gtCGI and,
> client-side, HTML/Javascript.

The main difference between us is that I'm not a professionnal, and I'm
in retirement. I just program like an hobby ...

> I don't see unfortunately here any market for GUI programs under
> Linux, there is simply no request.

market ...

> And under Windows I have serious doubts one can blindly rely on Hwgui,
> without some aces in the sleeves, it has still some quirks and no
> documentation apart sources (I still have not tried it under Linux
> anyway).

Yes, that's an ennoying point : no actualized documentation since 2006 ...

> What about converting a 36000+ lines program from Clipper to GUI? Not
> an easy task, when the program logic should be reworked completely in
> fact. It's simply not the same approach.

I agree, but is all the job only to rewrite an old program, no new program ?

> And if you really want to go GUI and exploit the power of windows

I don't use anymore Windows since about 8 years ...

> , f.e. doing image processing, it's a problem even to find out how to
> integrate Freeimage with hwgui. The only example (imgview.prg) has
> been stripped away from recent version 2.19 (widely undocumented
> anyway in v. <=2.17).

Haven't tried it ... my needs are a bit smaller ...

> So... if it's all about adding some controls to have a nice appearence
> to substitute an input mask from character to graphical appearence,
> OK. But real-life programs need something more. You need time and
> effort to load a jpeg via freeimage and figure out how to display it
> in a hwgui control. There is no documentation about it.

I agree

> How to select a file outside the current directory with
> hwg_fileselect() if it changes the current directory and there is no
> way to pass the flag OFN_NOCHANGEDIR? Etc.

I use hwg_SelectFileEx, and it doesn't change the current directory

Running since a console
//
============================================================================
function FileOpen
//
============================================================================
local fname
local aftypes:={{"Fichiers PDF (*.pdf)", "*.pdf", "*.PDF"},;
{"Fichiers Images ", "*.png", "*.jpg",
"*.bmp", "*.gif", "*.jpeg", "*.PNG", "*.JPG", "*.BMP", "*.GIF", "*.JPEG"},;
{"Tous les fichiers (*.*)", "*"}}

oStatus:SetText(" Ouvrir un fichier par défaut PDF, mais çà peut être
changé ...")

run("pwd")

fname=hwg_SelectFileEx( "Sélectionner un fichier",mypath, afTypes)
IF !empty( fname )
run("xdg-open '"+fname+"' &")
endif
oStatus:SetText("")

run("pwd")

return nil
//
============================================================================

and the result

---------------------------------------------------------------
alain@Gramps-JujuLand:/opt/TuxPrograms/GedTools/GeneTools$ ./GeneTools_077

>>>>> /opt/TuxPrograms/GedTools/GeneTools

(GeneTools_077:31615): GdkPixbuf-CRITICAL **:
gdk_pixbuf_new_from_file_at_scale: assertion `filename != NULL' failed

(GeneTools_077:31615): GdkPixbuf-CRITICAL **:
gdk_pixbuf_new_from_file_at_scale: assertion `filename != NULL' failed
>>>>> /opt/TuxPrograms/GedTools/GeneTools
---------------------------------------------------------------

No directory change ...

But I don't like all these warnings (errors?) ...

For sure, this function which is new (a few monthes) doesn't appear in
hwgui documentation ...
I hope that Alexander can take time to update the old documentation.
I have sometimes some problems with hwgui because of this missing ...

> There are no free lunches.
> This post is just about being impartial and not making people think
> that hwgui is the perfect solution: easy, free and wonderful. I use it
> and appreciate it, but it's right to give some caveats. :-)

Sure, but is there a better solution now for multi-os harbour gui
programming ?
qt is a false good idea, as Linux builds (Ubuntu for example) use
different version qt4 or qt5, and there is no integrated install, which
causes ennoying problems ... That's the reason why I leave hbqt

[Francesco Perillo]

Sure, but is there a better solution now for multi-os harbour gui programming ?

Yes, it's Qt.
 

qt is a false good idea, as Linux builds (Ubuntu for example) use different version qt4 or qt5, and there is no integrated install, which causes ennoying problems ... That's the reason why I leave hbqt

If you weren't able to have it running correctly doesn't mean Qt is bad. Actually I was able to port a Windows harbour+hbQt program to linux and Mac in 24 hours since I switched on a osx notebook for the first time....

I'm not using Ubuntu but since it is a very widely used linux distribution, I'm quite sure Qt works very well on it.

Finally, you can download source code and compile it yourself, it's easy on linux....

[Francesco Perillo]

Please have a look at hbQt, hbqtWidgets and the Qt based gt.

[Alain Aupeix]

Le 02/03/2016 10:15, Francesco Perillo a écrit :
>
>
> Sure, but is there a better solution now for multi-os harbour gui
> programming ?
>
>
> Yes, it's Qt.
>
> qt is a false good idea, as Linux builds (Ubuntu for example) use
> different version qt4 or qt5, and there is no integrated install,
> which causes ennoying problems ... That's the reason why I leave hbqt
>
>
> If you weren't able to have it running correctly doesn't mean Qt is bad.

Yes, but I prefer having Ubuntu running correctly that searching for a
qt install which doesn't causes problems.
I use Ubuntu 12.04 on an old machine (2007), and don't want to change it
for now, so it's a real pain to have qt4 and qt5 on such machine

> Actually I was able to port a Windows harbour+hbQt program to linux
> and Mac in 24 hours since I switched on a osx notebook for the first
> time....

I'm sure that qt is a good product, but too much problems for me.
And I prefer gtk visual, qt too much Windows like ...

> I'm not using Ubuntu but since it is a very widely used linux
> distribution, I'm quite sure Qt works very well on it.

For sure

> Finally, you can download source code and compile it yourself, it's
> easy on linux....

> Please have a look at hbQt, hbqtWidgets and the Qt based gt.

Unable to build with qt4

[elch]

Hi Francesco,
 

... as Linux builds (Ubuntu for example) use different version qt4 or qt5, and there is no integrated install, which causes ennoying problems ...

If you weren't able to have it running correctly doesn't mean Qt is bad. ...

e.g. the KDE desktop is since its v4.x based on QT. Sure, that runs correctly, and is covered by the package management dependecies.
But in this point Alain is right, managing two different versions of QT used at SAME TIME needs complex manually action -- as the one needed for KDE or other packages can not be deleted.
AFIK QT5.x is not backward compatible to QT4.x ? -- and wasn't it QtContribs cutting backward compatibility to 4.x after r316 ?

best regards
Rolf

[Lorenzo Fiorini]

On Wed, Mar 2, 2016 at 11:03 AM, Alain Aupeix <alain....@wanadoo.fr> wrote:

> Yes, but I prefer having Ubuntu running correctly that searching for a qt
> install which doesn't causes problems.
> I use Ubuntu 12.04 on an old machine (2007), and don't want to change it for
> now, so it's a real pain to have qt4 and qt5 on such machine

The same for RHEL 6 and Centos 6: the official is qt4 and mixing qt4
and qt5 is not an option.

Is there anyone with experiences with wxWidgets?
There is a wxHarbour project in SF.
wxWidgets is much smaller than QT and easier to deploy than GTK in OSX.

best regards,
Lorenzo

[elch]

Hello Ash,

Here is the output of wvwtest.prg.

you still miss a very important point: how and where do you 'destroy' the created GUI objects ?
You may have a look into: harbour/extras/gtwvw/tests/cbtest6.prg for wvw_cbdestroy() to recognize the problem.
Doing it with help of a global array BTW ugly hurts OOP programming style.

Viktor did a lot in his fork by cleaning GTWVW of its internal sloppy parameter checking and global variable usage.
And even after all his valuable work GTWVW is still not thread-safe, he left a TOFIX note about that.

I wonder who nowadays have interest for an only Windows version, with creating new syntax never existed in Clipper v5.3.
There never was a 'ComboBox', but a ListBox in conjunction with a 'GET':
http://x-hacker.org/ng/53guide/ngb388e.html
[ BTW, seem available in Harbour with all its parameters ]
Hombrew versions of programming language to create GUIs exists since decades a lot, sure you can create another one for yourself use.

best regards
Rolf

[elch]

Hi,

> Please have a look at hbQt, hbqtWidgets and the Qt based gt.

Unable to build with qt4

for completeness:

'svn co http://svn.code.sf.net/p/qtcontribs/code/trunk@316 .'

that have the advantage not must to follow QtContribs development,
and the disadvantage if you find a bug ...

best regards
Rolf

[Ash]

Hello Rolf,

where do you 'destroy' the created GUI objects ?

I missed that bit.

There never was a 'ComboBox', but a ListBox in conjunction with a 'GET':

I'll change COMBOBOX to LISTBOX in wvwstd.ch.

Thanks.
Ash

[Alain Aupeix]

It was what I done, I stop updating to 216, but as you said, if I found
a blocking bug, I have no way to bypass, as Pritpal decided not to keep
qt4 compatibility.

As I found a simplest solution with hwgui, I decided to use it, and
remove qt5 and hbqt.
That's as simple as this ...

[Przemyslaw Czerpak]

On Wed, 02 Mar 2016, Francesco Perillo wrote:

Hi,

It's not such simply.
HBQT needs general cleanup. Just try to install Harbour and HBQT
source on new computer compile harbour then HBQT. You will find
the the build process is broken in few places:
1. The location in practice is hard coded to <harbour_path>/addons/
This hard coded location is broken and build process find intermediate
.hb[cpm] files instead of final ones so HBQT cannot be compiled.
This problem is hidden when HBQT files are installed to final location
or such location is visible during HBQT compilation. In such case
HBQT header files are taken from different place then source code.
It this 2-nd location is destination of install directory then it's
not such big problem. It only means that after update users should
make install, clean and yet another install to be sure that everything
was rebuild with the same header files.
It means that whole build process should be recreated.
- all intermediate files added as "path include connectors" which
have the same names as final ones should be removed:
No more repeated names for .hb[pcm] files.
Only clean includes, if necessary with nested paths.
- HBQT should compile cleanly in any directory. <harbour_path>/addons/
is only helper directory which allows to bind harbour and HBQT build
process. Viktor added such functionality for all projects but it
does not mean that <harbour_path>/addons/ is private directory for
HBQT.
2. The QT version. I've recently tired to compile HBQT on Windows and
Linux with different QT versions. I was not able to find QT version
which can be used for clean compilation. HBQT contains unguarded
code for the newest QT releases what blocks compilation with older
ones and these new features are not supported on all platforms.
I had to manually disable some parts of HBQT just to finish the build
process with core functionality. Compilation with QT4.[5678] is in
practice impossible now and this QT versions are still standards for
most of systems. This is the most serious problem because it means
that system QT libraries cannot be used and final user of HBQT
application needs admin rights and enough knowledge to install QT5
libraries in the system without breaking existing QT4 installation.
BTW in some cases QT5 still does not work correctly, i.e. try to switch
GTQTC to fullscreen mode (ALT+ENTER) in MacOSX. Fortunatelly QTQTC
supports QT4.X [X>=5] so it's not a problem.

Above have to be definitely fixed.

I hope Viktor can give some advices about HBMK2 usage to fix problem 1.
I believe that it will help also other projects. We need some clean
examples of projects created as harbour addons.

The second problem is a job for HBQT developers. It's necessary to
restore QT4. Ideal would be support for QT4.5 anyhow if it's a big
problem then I suggest to chose QT 4.7 as supported mininimum.
For QT5 HBQT should compile cleanly with all recent releases of:
QT5.2, 5.3, 5.4, 5.5

best regards,
Przemek

[vszakats]

Indeed. <harbour>/addons/ must never be used for _hosting_

any project under any circumstances (it _may_ work that way, 

but incorrect still and it's definitely not something that should be

required to make any project work). '/addons/' is there to serve as 

an _install target directory_ for .hbc files, public project headers 

and generated static libraries, implibs. (IOW any file the project 

aims to _redistribute_ for its users, IOW any file that is required 

to _use_ any given project)

If the project satisfies some basic assumptions about file/dir 

layout, the functionality to install target files to '/addons/' can 

be easily enabled by including `$hb_pkg_install.hbm` in the 

.hbp file. If a project cannot fit into these assumptions, the install

process can be done manually as well.

The built-in logic is here:

   https://github.com/vszakats/harbour-core/blob/master/utils/hbmk2/pkg_inst.hbm

A usage example here:

   https://github.com/vszakats/harbour-core/blob/master/extras/template/hbtpl.hbp

The end goal is to have `<project>.hbc` files be installed 

inside `/addons/` so they can be found automatically by 

hbmk2 when building a dependent project.

In case of HBQT the problem is exacerbated by multiple 

QT subcomponents meaning it's rather a group of 

projects than a single one. Yet for practical reasons 

some files are made common between them. Keeping 

the dependencies clean and well-defined needed 

constant policing. I'm not sure what is the current state.

Above is finally made complicated by the multitude 

of incompatible QT revisions with feature coming and 

going also depending on the platform/distro.

HBQT should also be fixed to not touch any internal Harbour 

core files, like icon, manifest, resource, etc. It should only 

use _public/distributed_ Harbour tools, headers and libs.

Remembering the gargantuan task to deal with QT+HBQT, 

I can't promise to delve into this deeply again as I estimate it 

would take weeks of (or endless) heavy work :( But if there is 

any specific question, I'll try to answer them.

[ I personally find QT way too heavy to be a pleasant tool to 

use or distribute. Combined with the known structural issues 

of HBQT I have no plans with it ATM. Unfortunately, not even

GTQTC was usable in my OS X tests, but it's possible that I'm 

not installing the right revision the right way. (Tried with both

qt4 and 5). I find it problematic that it QT dependent code 

cannot even be built without a very lengthy list of compiler 

warnings in most cases. ]

-Viktor

[TV do Povo TV do Povo]

so personal, that function or qtcontribs is where the harbor 3.4.0?
or where low power to use?
which link / website?

Em terça-feira, 7 de abril de 2015 19:00:09 UTC-3, Juan escreveu:

Hi,

See you qtcontribs?

\harbour\addons\hbqtwidgets\tests\pureclip.prg



//-----------------------------------------------------
...
 /* Harbour standards SAYs and GETs */
   @ 1, 02 SAY PadL( "Upper Cased Alphabets:", nPdL ) GET cText VALID {|oGet| cText == "ABC" .OR. cText == "DEF" .OR. Udf1( oGet ) } PICTURE "@!KA"

   @  2, 02 SAY PadL( "Birthday:", nPdL )
   @  2, nColGet GET dDate WHEN {|| cText == "ABC" } COLOR "B/GR*" ;
      VALID {|| AChoice( 5, 5, 12, 20, { "Abc","Cde","Efg","Fgh","Ghi" } ), dDate >= 0d19560604 }

   @  3, 02 SAY PadL( "Max 6 Decimals:", nPdL )
   @  3, nColGet GET nNumb PICTURE "@Z 9,999,999.999999" WHEN {|| DispOutAt( MaxRow(), 20, "Harbour" ) } VALID nNumb > 600 .AND. nNumb < 6000000

   @  4, 02 SAY PadL( "Logical - Married:", nPdL ) GET lMrd  PICTURE "Y"

   @  5, 02 SAY PadL( "Telephone Number:", nPdL )
   @  5, nColGet GET cTele PICTURE "@! (999)999-9999"

   @  6, 02 SAY PadL( "Upper Lower Upper:", nPdL )
   @  6, nColGet GET cJust PICTURE "@A" COLOR "W+/B*" VALIDATOR {|cText,nPos| UpperLowerUpper( @cText, @nPos ) } VALID {|| GetAsChild_1() }

   @  7, 02 SAY PadL( "Scrolling Catalog:", nPdL )
   @  7, nColGet GET cCata PICTURE "@S15 !!!-!!!-!!!!!!!!!!!!"  VALID {|| GetAsChild() }

   @  1, 52 SAY "Val[1]"
   @  1, 60 GET val[1] PICTURE "@!"
   @  2, 52 SAY "Val[2]"
   @  2, 60 GET val[2] PICTURE "@K 99"
   @  3, 52 SAY "Val[3]"
   @  3, 60 GET val[3]

   @  5, 52 SAY "Deptt:"
   @  5, 60, 5, 69 GET cDeptt COMBOBOX aDeptt VALID {|oGet| HB_TRACE( HB_TR_ALWAYS, oGet:varGet() ), .T. }

   @  7, 52 SAY "Salary:"
   @  7, 60 GET nSlry PICTURE "@KE 99,999" VALID {|| nSlry > 600 .AND. nSlry < 17000 }

   @  9, 48 SAY "Done:"
   @  9, 54 GET lDone CHECKBOX

   @  9, 02 SAY "Notes:"
   @ 10, 02, 16, 55 GET cNotes MEMOEDIT COLOR "N/rgb(255,255,230)" WHEN cText == "DEF" VALID "Harbour" $ cNotes ;
                                  PROPERTIES {|oGet,oControl| SetControlProp( oGet, oControl, "tooltip", "The notes must contain 'Harbour' somewhere" ) }

   @  9, 60 SAY "Select:"
   @ 10, 60, 16, 69 GET cList LISTBOX aList WHEN cText == "ABC" VALID {|| HB_TRACE( HB_TR_ALWAYS, cList ), .T. }

   oBrowse := BrowseArray( NIL, .F. )
   //
   @ 18, 02, 24, 42 GET lBrowse HBQTBROWSE oBrowse

   //@ 18, 44, 24, 69 GET s_cImage IMAGE DONOTSCALE WHEN {|| .F. }
   @ 18, 44, 24, 69 GET s_cImage IMAGE WHEN {|| .F. }

   @ 26, 25, 26, 44 GET lOk     PUSHBUTTON "OK"     ACTION {|| iif( Alert( "Save Data?", {"Yes","No"} ) == 1, "cText", "cNotes" ) } ;
                                                        WHEN nSlry > 700 .AND. nSlry < 17000
   @ 26, 50, 26, 69 GET lCancel PUSHBUTTON "Cancel" ACTION {|v| v := Alert( { "Cancel Pressed!", "Should we terminate the Form ?" }, { "Yes","No" }, "W+/N", 5, "Really?", 2 ), ;
                                                        iif( v == 1, GetActive():parent():close(), NIL ) }

   /* Bring on browser as a selection list */
   SetKey( K_F2, {|| BrowseArray( GetActive():parent(), .T. ) } )

   /* Caclulator callable with F10 */
   SetKey( K_F10, {|| HbQtCalculate( GetActive():parent() ) } )

   READ PROPERTIES {|oWnd,oGetList| SetFormProperties( oWnd, oGetList ) }

...
//-------------------------------------------------------------------------------------------------------------------






Regards,


Juan

El 04/04/2015 a las 12:06 a.m., Ash escribió:

Hello,

I wish the following Clipper controls were part of Harbour core but in GUI form and using the same syntax - things like:

@... Say
@... Get

@... Box
Check Box
List Box
Push Button
Radio Button
Radio Group
Scroll Bar

These controls are enough to write very good looking business applications in a way that we have been used to from Clipper days. Writing business applications is hard enough never mind the complexities of add-on GUI libraries.

My 2 cents worth.

Regards.
Ash

--

--
You received this message because you are subscribed to the Google
Groups "Harbour Users" group.
Unsubscribe: harbour-user...@googlegroups.com
Web: http://groups.google.com/group/harbour-users

---
You received this message because you are subscribed to the Google Groups "Harbour Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dasun]

Thank you Ash, having gone through the code and the syntax, I still think this is a very promising direction and worthy of pushing forward with.  However high level decision's need to be made first and some serious thinking needs to be done first..

1) How is a multi-platform GUI to be achieved? 

•     I consider this a core capability, Harbour compiles and runs on multi platforms, a visual clipper  needs to do the same - in my view, given I am writing a Linux GUI app currently!
•     QT seems to be the most obvious candidate to me as it covers so many bases,
• HBQT has been used in Marinas successfully on multi-platforms but I am hearing from Viktor and Przemek  further down thread there are major structural issues with the current incarnation that need to be addressed before it can be used
• Can Object Oriented abstraction be used  as a shield between different QT versions ?
• QT has a large following and is not going away anytime soon
• What options are there other than QT?
• What platforms do they work on?
• And what experience have people had with them?
• What is there likely future?

2) The use of standard Harbour/Clipper @SAY/GET syntax - particularly with char position mapping  and extended as needed for the event driven GUI environment - is essential.

• We need to decide on the Visual Clipper GUI syntax upfront and define it.
• The main issue, in my view, with all the current GUI libraries - Marinas, HMG etc is the resulting fragmentation of the GUI elements of the Xbase language.
• This make it difficult to port programs
• This makes it difficult to learn - despite similarities they all do it differently
• This dilutes the user base - meaning there are many different GUI camps out there, we would be stronger together and could achieve more together

3) How do the current Harbour architects feel about this Visual Clipper direction and how does it fit into there long term plans? (Przemek  and Viktor?)

4) Who here is willing to make a long term commitment - in terms of coding and documentation -  to make this happen? 

• We can not expect Przemek and Viktor to do this as standard Harbour is already more than a full time jog for them.

5) Something to consider is that Harbour seems to have a strong  following in places like South America and parts of Europe - non English speaking in the main.

• We need to reach out to them and get their input and involvement.

In rough marching order I guess.....

• Find out if the Harbour community can get behind this
• Find out who is willing to work on this - long term
• Some will need to do doco
• Some will need to do code
• Some will need to decide direction and architecture
• And all will need to work as a cohesive group
• Decide on version 1 capabilities
• Decide and define the syntax
• Define multi-platform means and targets
• Rough out some idea of how long this will take
• Allocate work packages based on who is interested in working on what

I have probably said enough - but I am trying to fuel thinking on this and get it moving along ... full marks to Ash for stepping up to the plate.

[vszakats]

Hi Dasun,

On Wednesday, March 2, 2016 at 6:46:28 PM UTC+1, Dasun wrote:

 

3) How do the current Harbour architects feel about this Visual Clipper direction and how does it fit into there long term plans? (Przemek  and Viktor?)

My opinion in unchanged, I think there is no point and 

no practicality to add such a huge and technically 

unrelated subproject onto the core as a monolithic 

component. There is also no technical reason why such 

a component needs to physically reside inside the core 

repository, or need to be discussed in existing core 

communication channels.

If the core itself is missing a feature essential to implement

a GUI, or something could make it easier or simpler, it 

can still be added as a regular documented API/feature 

as part of a core update.

What such a project needs is a goal, a team, a communication 

channel and a code repository. A relatively small amount 

of energy needs to be spent on integrating well with an 

"official" Harbour installation, f.e. as described in my 

previous post. Build the thing from source and install into 

/addons/.

[ Harbour has no package manager, but this shouldn't be 

a showstopper at all. ]

Also notice that this is the method chosen by most other 

programming language projects. In Harbour we had already 

tried how it looks when such a noisy and heavy subproject 

is part of the core.

[ On the same note I think most existing contribs would 

better be maintained in their own separate repositories, 

particularly those that have heavy-ish external dependencies.

They already pose a packaging/distribution problem, f.e. 

Homebrew rejected to add most contrib dependencies even 

as optional ones and I can understand their reasons. ]

-Viktor

[Bruno Luciani]

People , take a look to Marinas-GUI  , its solve practivally al the questions , included the problem

to CO-exist with Linux local QT

Marinas manage libraries path , to avoid problems with that

I think that it is one of the best multiplatform harbour based GUI , a great solution , it includes Installer for the program

and it is based on HBQT

Bruno

--
--
You received this message because you are subscribed to the Google
Groups "Harbour Users" group.
Unsubscribe: harbour-user...@googlegroups.com
Web: http://groups.google.com/group/harbour-users

---
You received this message because you are subscribed to the Google Groups "Harbour Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Bruno Luciani
Area Ingenieria
Brawnius Tecnologia y Servicios 
BWS Central de Monitoreo
San Francisco Javier 1066
Ramallo - 03407-422178/422185
www.brawnius.com.ar
www.bwsalarmas.com.ar

[Dasun]

As a Marinas user I agree Bruno and am really impressed by the entire integrated experience - needs a form designer and still some gap but it achieves many of the goals - it is certainly a very good model and I urge anyone about to do Harbour GUI development to take a good long look at Marinas 

My Visual Clipper thoughts are something along Marinas lines, except with @SAY/GET syntax (something I started to do with Marinas) as a core part of Harbour - and I thank Viktor for his views.  This is really a Harbour community decision...

[Gustavo Fidelis]

Gentlemen

Sorry for the intrusion but it's hard to carry the FLTK to harbour?

Fast Light Toolkit - Fast Light Toolkit (FLTK)

				Fast Light Toolkit - Fast Light Toolkit (FLTK)   Quick Info   Stable Release: v1.3.3 Stable Release Info: View Snapshots: v1.3.x-r11217 Developer Roadmap: View
				Visualizar em www.fltk.org	Visualizado por Yahoo

It's run on windows and linux.

Gustavo.

[Domenico D'Oria]

Hi fellows

my simple though ( one more cent )

there are many GUI for Harbour: HMG, MiniGUI, HWGUI, and Marinas-GUI and probably others.

Which is the best ?

I'm not an Harbour Guru, nor the best programmer of the world, personally I choose Marinas-GUI, becouse works on Windows, on Linux, and probably on OSX ( not tested yet ).

but i think that Harbour should need a "property/method" GUI calling standardization, so all programmers can jump from one GUI to another only changing "mygui.ch" in the top of the prg.

Who can do this?

gathered all master programmers , have them discuss how to declare the calling properties and methods , and push them to follow the rules

it's simple

regards

Domenico

[Pritpal Bedi]

Przemek and All

Thanks for jumping in and pointing out the pitfalls in 

building process of HbQt in general, and, on Linux specifically.

Here is my viewport on the subject.

BTW, before starting, I must state that _your mere attention_ towards 

HbQt is a big _reward_ for me. This is the first time in the whole history 

of HbQt that Harboureans are reading something written about HbQt by your pen.

Thank you very much, you have made my day!

Since Oct 2012, I am the only one who developed, maintained, released,

HbQt. Some help was extended by HbQt users here and there, but 

mainly it remained a single handed task. 

When HbQt was hosted on separate repository, I specifically pointed

out that I am least experienced about Harbour's build system. You can 

look into the details of this declaration at:

https://sourceforge.net/projects/qtcontribs/?source=directory

Moreover, I am a Windows guy and have almost zero experience 

on Linux. So I could never update .hbc/hbm/hbp files for Linux 

part with any degree of confidence. The folder and file structure of HbQt 

in Harbour contribs was carried over in new repository "as is", which 

also carried its build algorithm. Till then Viktor has done with the 

_addon_ concept which came as a _rescue port_ for us 

to continue with the same build logic as /addons was exactly 

parallel to /contrib. And that was it. I could never dare to 

re-shuffle its file/folder structure the way Viktor conceived _addons_ idea.

All this contributed to broken build process, at least for Linux.

Qt4 -> Qt5

Qt5 arrived with many new goodies, and also with many problems for HbQt.

Till Qt 5.3 I kept it synchronized with Qt4.5 and beyond. But with the arrival 

of later versions it became impossible to keep two versions going 

together. It was mainly because of the two reasons; 

1) Qt introduced altogether new folder structure breaking once composite module into parts, 

2) Qt dropped many classes and introduced entirely new members structure for old classes.

3) Qt was fast heading towards mobile devices, and this was my priority.

But this is possible to separate Qt 4 and Qt 5 repositories even now.

This should not be a problem, if someone comes forward to share 

some burden.

OR

It is also possible through restructuring the source generation engine.

But this will also require a large amount of time, and for sure which 

is at a premium at my current state of responsibilities.

>HBQT needs general cleanup.

This phrase itself speaks volume. HbQt is a professional and 

production grade library for sure but needs little tweaks but by them

who are knowledgeable enough to do so. On build process 

I admitted my incapability, I am sorry but cannot help much.

Viktor can, but he simply has refused. And I understand his viewpoint, no regrets. 

Having said  I again testify that HbQt is the only GUI library through 

which Harboureans can develop for any platform, including but not 

limited to Mobile devices as well.

Regards

Pritpal Bedi

a student of software analysis & concepts

[elch]

Hi Pritpal,

Thanks for jumping in and pointing out the pitfalls in 

building process of HbQt in general, and, on Linux specifically.

pitfall ? -- it is an extreme horror even for somehow very little professional experienced.
It needs very ugly workarounds as root user ...
 

Since Oct 2012, I am the only one who developed, maintained, released,

That is intention -- you! never will accept a co-developer.
You just do what is useful to yourself, without any feedback or discussion about.
If someone afterwards would say: hey, this or that is not good -- it will be ignored or personally bashed.

>HBQT needs general cleanup. [ ... ]

Viktor ...

You surely recognized, that PRZEMEK have noted that.
Viktor is aside of all game, he need not any more to take care of your escapades.

best regards
elch

[a...@poswithlogic.com]

On Wednesday, March 2, 2016 at 4:04:47 PM UTC-5, Pritpal Bedi wrote:

Przemek and All

BTW, before starting, I must state that _your mere attention_ towards 

HbQt is a big _reward_ for me. This is the first time in the whole history 

of HbQt that Harboureans are reading something written about HbQt by your pen.

Thank you very much, you have made my day!

What!? This is the first time!?  Didn't you get some 'hints' from Przemek that saved the situation??   

Gathering from messages all these years is seems that HbQt was started to be developed before having sufficient knowledge of Qt  and C!

[vszakats]

On Wednesday, March 2, 2016 at 10:04:47 PM UTC+1, Pritpal Bedi wrote:

Viktor can, but he simply has refused. And I understand his viewpoint, no regrets. 

Hi Pritpal, you know the best that I had poured _many_ 

man-months into HBQT in the past (even committed directly into 

its new repository a few times). I ultimately felt it was time wasted 

with the bonus of becoming a target for some people's rage.

Sadly HBQT didn't became a product that I would consider 

using, or develop. I'm not exactly sure where the problem is, 

whether it's QT itself, HBQT as a wrapper, too wide focus 

(HBIDE), too narrow focus (Windows), the way we developed 

it or just the fact that I could never wholeheartedly commit to 

the idea of a fat desktop client, and on mobile I'd prefer to invest 

in learning native tools. Likely all combined.

One can only "refuse" what it's obliged to do. This is a FOSS 

project, so obligations can only come from one's own free will,

with no implicit guarantee. It's my own, unpaid, limited, free time.

I agreed to answer to specific questions, so even "refusal" 

is untrue, besides not quite motivating.

Once again, the sole reason I "can" do these things, is 

because I spent substantial amount of time on it in the past.

Anybody is able to do the exact same thing, possibly even in 

much shorter time or better. There is no secret knowledge. If 

someone started a similar effort when it was left years ago, 

it would have far surpassed my best ever understanding about 

the topic. The issue is rather that nobody felt to pick it up.

For sure anybody picking up on such project, must be ready 

to be (or get) familiar with Linux, OS X, Windows (+ Android 

and iOS), if the goal is to create a portable GUI. It won't work 

on Windows-only.

I hope HBQT (or an alternate) can reach a point where contribution 

might make sense and fun, and I'l sure be there. Przemek's 

alternate QT wrapper proposal looked like one. Sadly it quickly 

went into a toxic discussion about minor details, and died 

prematurely. I'd still be happy to see that spring into a good 

solution.

-Viktor

[M., Ronaldo]

Hi Viktor !

... or just the fact that I could never wholeheartedly commit to 

the idea of a fat desktop client ...

 

hbQT is a wonderful project and worth each second needed to learn about it :-)
.
QT files I need on desktop ( IMHO: not a fat client )

---------- 6 files(s)
 5.621.248 Qt01.exe ( My App )
 4.634.112 Qt5Core.dll
 5.004.800 Qt5Gui.dll
   267.776 Qt5PrintSupport.dll
 4.410.368 Qt5Widgets.dll
19.938.304 bytes

Regards

[vszakats]

Hi Ronaldo,

On Thursday, March 3, 2016 at 4:33:37 AM UTC+1, M., Ronaldo wrote:

Hi Viktor !

... or just the fact that I could never wholeheartedly commit to 

the idea of a fat desktop client ...

 

hbQT is a wonderful project and worth each second needed to learn about it :-)

I'm glad it works for you. I learned about it quite a lot 

while participating in its development for some years.

QT files I need on desktop ( IMHO: not a fat client )

---------- 6 files(s)
 5.621.248 Qt01.exe ( My App )
 4.634.112 Qt5Core.dll
 5.004.800 Qt5Gui.dll
   267.776 Qt5PrintSupport.dll
 4.410.368 Qt5Widgets.dll
19.938.304 bytes

I meant this:

   https://en.wikipedia.org/wiki/Fat_client

I don't in particular meant the shear size of the client (albeit 

it's also significant in case of QT and above may be the ideal 

case [1]). I mean a client that requires a non-trivial 

installation/maintenance on the client side, one which requires 

data/settings to be locally available to work, and one which 

requires local processing power and bandwidth available to work 

adequately. To mitigate these drawbacks with a fat client, your 

options are to buy Citrix, Windows TS or some other expensive 

layer on top. Which, for certain types of uses (f.e. business 

applications), seems like a non-ideal setup to me.

[1] https://wiki.qt.io/Deploying_Windows_Applications

Anyhow, this is a topic about GUIs, so I'm sure everyone 

knows the pros and cons well enough already and thus it's not 

the place about convincing each other about preferences.

I was merely weighting the reasons why it didn't work out.

-Viktor

[vszakats]

BTW, on a productive note: for reasons unrelated to QT,

I shifted my Windows build environment to MSYS2 and 

plan to shift further to use the single-target MINGW distros 

from current dual-target aka "multilib" one. My fork [1] and 

the dependencies [2] already reached a point to support 

that setup, now it's only a matter of switch to enable.

In coming months I'll be evaluating how MSYS2 is keeping 

up with MINGW updates, in general how stable the 

experience is [3][4] and how CI systems like AppVeyor [5]

is keeping up with MSYS2/MINGW updates. It's also 

important how easy/possible it is to migrate the CI process 

onto a Linux machine and using cross-build tools exclusively.

Single-target MINGWs have a few consequences:

- 64-bit apps can only be built on a 64-bit host

- 32-bit will use DWARF2 instead of SJLJ

- 64-bit will use SEH instead of SJLJ

- DWARF2 and SEH offers less runtime overhead

than SJLJ, which means faster execution.

- DWARF2 results in about 10% _larger_ binaries.

(SEH remains about the same size)

Why is this good for QT? Well, QT continues to use DWARF2,

so it means that Harbour CI-generated binaries will be compatible 

with it by default.

[1] https://github.com/vszakats/harbour-core

[2] https://github.com/vszakats/harbour-deps

[3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69880

[4] https://github.com/Alexpux/MSYS2-packages/issues/454

[5] https://www.appveyor.com/updates/2016/02/07

[Massimo Belgrano]

qt 5.6 is  plaed for 16th March 2016  and is   a Long TermSupport Release like  Qt 4.8
http://blog.qt.io/blog/2015/12/18/introducing-long-term-support/

--
--
You received this message because you are subscribed to the Google
Groups "Harbour Users" group.
Unsubscribe: harbour-user...@googlegroups.com
Web: http://groups.google.com/group/harbour-users

---
You received this message because you are subscribed to the Google Groups "Harbour Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Massimo Belgrano
Delta Informatica S.r.l. (Cliccami per scoprire ) 

[JoséQuintas]

Long term support, because in next release...

"The next release, Qt 5.7, will drop support for older compilers allowing us to leverage C++11 functionality in the Qt modules themselves. So for those wishing to use compilers such as VS2008, VS2010, and gcc 4.6, Qt 5.6 continues to be an excellent choice in the years to come."

José M. C. Quintas

Em 03/03/2016 12:05, Massimo Belgrano escreveu:

qt 5.6 is  plaed for 16th March 2016  and is   a Long TermSupport Release like  Qt 4.8
http://blog.qt.io/blog/2015/12/18/introducing-long-term-support/

2016-03-02 22:04 GMT+01:00 Pritpal Bedi <bedipr...@gmail.com>:--

Massimo Belgrano
Delta Informatica S.r.l. (Cliccami per scoprire ) 

-

[vszakats]

Requiring gcc 4.6, released 5 years ago. Promising.

[vszakats]

On Thursday, March 3, 2016 at 4:43:32 PM UTC+1, José M. C. Quintas wrote:

Long term support, because in next release...

So what will be the next gcc version supported?

More importantly: will they start adopting new 

compiler versions as they are released or stick 

with their choice for the next 5 years?

[Dasun]

All in all one thing this thread demonstrates is the lively interest in a Visual Harbour/Clipper .... QT still seems the most likely multi-platform candidate, although the Fastlight toolkit (mentioned above) could also be an option - personally I have never heard of it and need to find time to have a look.

HbQT can work - it does for Marinas - and it would be interesting to get Carozo's view on HBQT as he must be something of an expert on its advantages and disadvantages by now.

If HBQT was to be used as a base for Visual Harbour/Clipper then we need to document its shortcomings and formulate a path forward - Viktor has already made interesting comments upthread.  There is no point in throwing out the baby with the bathwater, Pritpal and other have put a huge amount of work into HbQT and it is unlikely to be so architecturally deficient a complete rewrite is needed .  What is needed is a spirit to move forward, and make those changes needed to HbQT to remediate whatever shortcomings it has -  and that means others have to join with Pritpal and find a way to work together which is why documenting shortcomings upfront and building a roadmap to move forward is important.

Just my 2 cents ... I think there is value in a core Visual Harbour/Clipper but it is essential to get the foundation right before moving forward and it is essential to scope out the task first and find out how many are willing to help.  We could start with a simple shared google doc and start brainstorming together

[vszakats]

HBQT can work, if memory is managed manually. This is 

what Marinas seems to be doing [1]: There is a central hash,

declared as PUBLIC to keeps track of objects.

It's a sign that memory management is still not a resolved 

issue, which was one of the key architectural shortcomings 

of HBQT+QT (it's still unclear which of these components 

is contributing to this to what extent).

These are known issues, discussed on devel list many times 

in the past.

Currently the only way to avoid them is to:

- know every detail and manually release/retain accordingly

  (practically impossible/impractical)

- retain everything (PUBLIC/STATIC) (leak by design)

- brace for potential and "random" crashes and

  tweak .prg code as these appear.

Maybe this is normal experience in GUI programming, 

but surely not a ideal one, and certainly not inline with 

Harbour core experience.

It can be brainstormed indefinitely, but IMO a fresh start 

would seem more realistic to reach a well-defined state in 

memory management, not mentioning the others, like 

proper portability, QT-version support, automatic generation 

of wrapper stubs based on QT headers, proper layering

where app code doesn't need C++ hacks to tap into QT 

features. There are probably more I forgot.

There is an other factor: People started building upon 

a unfinished and broken foundation quite early on. This

was pretty bad even years ago and didn't help to make 

updates or changes.

Lastly there is the human factor: for some reason all 

attempts to touch the fundamentals in HBQT derailed 

in some ways or another.

[1] https://sourceforge.net/p/marinas-gui/code/HEAD/tree/v3/gui/source/mg_core.prg

[Przemyslaw Czerpak]

Hi Pritpal,

If you want to separate HBQT for QT4 and QT5 then it's OK for me.
Please remember that QT4 is still base library in many *nix systems
so programs using HBQT4 will not need any additional libraries and
functionality given by QT4 is usually enough for these systems.

Anyhow I also tested HBQT in MS-Windows and all what I wrote about
it is also a problem in this system. Just try to load Harbour and
HBQT source code to new "clean" system. Install also QT version you
prefer. Then compile harbour and HBQT and check if the process can
be completed with single compilation step.

QT is huge library which tries to wrap everything. We do not need
all it's functionality because we have our own native solutions.
The second problem with this library is C++. It introduces additional
dependencies and it's very hard to create clean wrappers for other
languages (it's not harbour only problem, just read about limitation
and problems in PyQt) anyhow it's possible though it needs a lot of
works. HBQT is incredible big job and I believe it's production
ready for people knowing it well and their internal bindings so
can write code on Harbour level which do not volatile some hidden
for normal users rules. I also created few small test programs
recently and I like the results. But when I made some deeper
experiments I've found the not all things are cleanly cleanup
and I had to update the code. It means that it's possible to write
well working application but it's also possible to make it in wrong
way what may cause more or less serious problems with unreleased or
corrupted memory. I do not know if over all protection for wrong
code can be even reached but I hope we can at least well document
constructions which need special user attention.
Now HBQT is such big project that I cannot even say what it does
in all places. It's very hard for me to start working on it. Of
course I can change some separated things I need but I do not see
the "whole picture". Maybe I can help in a little bit different way.

For most of GUI programs users need rather simple set of graphic
widgets. I've seen that FLTK (http://www.fltk.org) was suggest as
good backend for Harbour GUI library. It's small and license is
Harbour compliant (LGPL + exception for static linking just like
in our license). It's possible to create final self contain quite
small static binaries easy to install. The only one drawback is
C++ though it seems that they not use any tricks with metaclasses
and dynamic bindings like in QT (slots and signals) so maybe some
more restrictive modern C/C++ compilers will not complain about it.
Viktor can you check it?
If it can be cleanly compiled on MacOSX with new CLANG then I'll
look closer on it and check what is the chance to create simple
wrapper. If it's possible then we can try to create general PRG
layer for GUI libraries with replaceable backend. This backend
will use FLTK at the beginning and then we can try to replace it
with backend for QT and finally bound with HBQT adding all other
functionality and documenting what cannot be ported or what was
ported with some potential problems and how user should avoid it.

I agree it should be separated project. Anyhow we will need
developers who can work on it. I will not find enough spare time
to make it myself.

best regards,
Przemek

[Francesco Perillo]

As a person that spent endless nights on hbQt internals I think I can say something on the project.

First of all, hbQt internals are not what I think they should be. There is a post in this mailing list by me, dated YEARS ago, with my idea (inspired by the bindings of other languages) on how it should be done - it also allows perfect (?) subclassing at prg level. Teo' qth project uses a similar approach.

Qt is a big beast, and it handles memory on its own. Objects are created and "ownership" transferred to another object, the "parent". The parent will delete the object when it sees fit, with some flags to change the behaviour.

At the beginning, hbQt needed a prg variable for each Qt object. Then it was asked that a more Harbour GC-ready approach to be used. So, thanks also to code sent by Przemek and also a new internal function added to Harbour, a linked list keeps track of couples ( Qt c++ object <-> hbQt prg object ) so that we can retrieve one from the other.

The pointers to hbQt prg object uses GC reference counters so that when a c++ is deleted we intercept the delete request, lookup in the linked list, release the hbQt prg object, remove the couple from the list. Harbour GC garbage will take care of the object at prg level.

The problem is when a reference to a prg level hbQt object is held into another variable/DATA member that must also go out-of-scope to have the GC complete the work...

... and since Qt decides what and when to destroy objects, it is necessary to cooperate a bit with Qt to handle everything.

Correct and complete object release is possible. I and Luigi created a library that is a layer above hbQt and correctly handles all the release of the objects without unnecessary lists at prg level. It is fully OOP: the objects inherits directly from hbQt objects, provides some business-level objects composed by several hbQt objects, provides defaults for almost all hbQt objects, can be used to create userlevel objects...

YOU CAN'T USE HBQT DIRECTLY IF YOU DON'T KNOW HOW QT WORKS. So Marinas, or our library, or another lib may help programmers with a quick start.

I will later say something on hbQt project organization.

[Teo Fonrouge]

Hi Viktor,

Totally agree.

 

There is an other factor: People started building upon 

a unfinished and broken foundation quite early on. This

was pretty bad even years ago and didn't help to make 

updates or changes.

Lastly there is the human factor: for some reason all 

attempts to touch the fundamentals in HBQT derailed 

in some ways or another.

[1] https://sourceforge.net/p/marinas-gui/code/HEAD/tree/v3/gui/source/mg_core.prg

Here just to say wooohaaaaa!!!!   more than 18K lines of code only to keep track of qt objects used. I can't imagine the hurdle when a new qt version arrives.

This a job that the HBQT library would have to make. Period

best regards to all.

Teo

[Francesco Perillo]

On Thu, Mar 3, 2016 at 9:23 PM, Teo Fonrouge <tfon...@gmail.com> wrote:

Hi Viktor,

On Thursday, March 3, 2016 at 12:57:42 PM UTC-6, vszakats wrote:

HBQT can work, if memory is managed manually. This is 

what Marinas seems to be doing [1]: There is a central hash,

declared as PUBLIC to keeps track of objects.

I don't know if this is the real reason for the central hash. Marinas uses a procedural approach to work on objects. I think that changing preprocessor from procedural to OOP allows to lower the lines of code to no more than 500....

Anyway, Marinas works flawlessy, but it may run 10x the speed if moving to a fully OOP way...

Totally agree.

 

There is an other factor: People started building upon 

a unfinished and broken foundation quite early on. This

was pretty bad even years ago and didn't help to make 

updates or changes.

Yes, really. A lot of code was written, and never updated when changes were made to hbQt internals. More, xhbp compatibility layer was written and it was also used to write hbide, but it was used only for some widgets...

 

[1] https://sourceforge.net/p/marinas-gui/code/HEAD/tree/v3/gui/source/mg_core.prg

Here just to say wooohaaaaa!!!!   more than 18K lines of code only to keep track of qt objects used. I can't imagine the hurdle when a new qt version arrives.

This a job that the HBQT library would have to make. Period

Qt and hbQt can do it, indeed ! It is just necessary make Qt cooperate :-.)

[elch]

Hello Francesco,

Anyway, Marinas works flawlessy, but it may run 10x the speed if moving to a fully OOP way...

i gave Marinas a fresh try.
Surely i am not one of these annoying ones expecting all open source avalaible to be perfect -- try to do my best possible support:

Just only checked their for sure well prepared 'maindemo'.
Start up and immediately shot down takes > 20 seconds, and during start-up i got extreme heavy! screen flicker - same if i'm building any other project.
Then there are hanging around old tooltips -- or in their IDE, browsing of source files belonging to a project or text view is cut off at bottom with unreachable areas, if IDE not used all in fullscreen mode.
They use an own make tool, not hbmk2 -- and BTW a binary! Harbour version from 09.2014 -- found no way to set options for debug mode to be used with valgrind.
So i was not able to do a Valgrind check, maybe it's better not to know .. ;-)

NO!, no bashing against Marinas -- i somehow feel they try to do their best ...

best regards
Rolf

[Francesco Perillo]

About hbQt project.

The project should be split into several parts:

hbQt: simple layer over Qt c++

it is quite complete, it has several problems, it may be updated, can be retro-updated to support Qt4.x

It supports a lot of Qt modules but for example hbqtxing should not be there...

hbqtqmlparts: layer over qml

I don't know the state of this, it seems that it has been developed to support the need to use the camera and/or other things.

hbqtwidgets: a Harbour compatible GET system

it seems quite complete

hbxbp: a compatibility layer for xbp system

don't know how complete it is

hbnetioqt: netio frontend

it has some flaws, for example when data refresh in the table of connections, the columns widths are also reset.

hbdbu: dbu replacement
hbide: ide

Both are very complete, but also very incomplete :-)))) A lot of icons, features not completed, layouts not always working on different platforms; code probably needs deep refactoring :-)

Question: how many person are using hbdbu ? How many are using hbide ?

How many are using hbQt at all ??????

I support separating hbQt binding library from all the other stuff, to be served in different repositories. I think it is quite mandatory now...

A package manager for handling external libraries would be a great addition.

[vszakats]

Hi Francesco,

I don't know if this is the real reason for the central hash. Marinas uses a procedural approach to work on objects. I think that changing preprocessor from procedural to OOP allows to lower the lines of code to no more than 500....

Anyway, Marinas works flawlessy, but it may run 10x the speed if moving to a fully OOP way...

As a general comment I think there is a fundamental 

problem if OOP vs. non-OOP code on the higher level 

would result in 10x (or 1.5x even!) speed difference in 

any direction for the same given task. Typically one 

would expect OOP to be slightly slower due to extra 

overhead an OOP layer poses. Anyhow, I think we 

should avoid to regard OOP as some sort of silver bullet 

here. If it the low-levels work correctly, they should 

work so regardless of the syntactic sugar/coding 

methodology used above it.

[ Also note that OOP is a sort of "hidden" way to _retain_ 

objects, similarly to STATIC/PUBLIC. Maybe that's 

not what you meant here, but it's a valid possibility. ]

updates or changes.

Yes, really. A lot of code was written, and never updated when changes were made to hbQt internals. More, xhbp compatibility layer was written and it was also used to write hbide, but it was used only for some widgets...

Indeed. Forgot about HBXBP.

Qt and hbQt can do it, indeed ! It is just necessary make Qt cooperate :-.)

Okay, so you say that QT _can_ be made work to 

manage memory correctly.

[Przemyslaw Czerpak]

On Thu, 03 Mar 2016, Francesco Perillo wrote:

Hi Francesco,

> hbQt: simple layer over Qt c++
> it is quite complete, it has several problems, it may be updated, can be
> retro-updated to support Qt4.x

The main problem with such libraries (especially C++ ones) is well
define the life time of wrapped objects. Who is responsible to free
them and when it can be safely done? How are cross references supported?
How can they be safely unlinked? How C references can be detected and
integrated with our garbage collector? How objects can be accessed by
different threads?
It's a basic set of questions which should be precisely answered before
we start to create new code. Then we can decide how to create wrapper
for C/C++ objects and functions. In case of C libraries like GTK there
is one important functionality. GTK objects have their own references
counters which support also leak reference concept. It's also possible
to bind custom destructor with custom data pointer with them. It means
that this library is ready be default to create wrappers and it's much
easier job then in case of QT. Of course not in all places, structures
which are not GOBJECT based do not have such functionality so they have
to be wrapped differently and each such implementation should be well
defined and describe any potential anomalies. Situation when someone
commits 100 new classes wrapped "as is" is unacceptable because instead
of helping it my ruin completely whole concept.
In general C code has one important for us functionality. Destructors
have to be explicitly defined and called it means that it has to be
well documented who is responsible to free the object. In C++ it's
often hidden in library code and usually not documented in user API.
Additionally casting in C++ can be overloaded so without looking at
the library source code we often do not know what is really done
when objects are casted. This can be nightmare when big project like
QT is wrapped. In such case the best method is implementing the code
which fully restores potential casting path when object pointer is
extracted from harbour item.
When we precisely answer for above questions then we can try to
implement core wrapper code. When this code will be ready then we
can try to wrap few objects. If we find it's possible to automate
some things then we can define some meta files with class definition
like .qth files in HBQT. Anyhow now I cannot even say if they are
usable. Just simply I do not know if they contain all information
I may need. For sure it's not possible to generate them from QT
headers. Just simply they do not contain critical for us information:
if I call:
obj1:method( obj2 )
then it causes that obj1 is responsible to release the object or
not. Without such information the life time of obj2 is unknown after
above call so sooner or later we corrupt the memory. In real life
the problem is even bigger because if obj1 becomes to be owner of
obj2 then we have to know when it release obj2 just to unlink it
from Harbour item. When this functionality is not well supported
then users begin to create workarounds like some holders for wrapped
objects which exists for the application life. It may hide the
problem for some time consuming more and more memory but sooner
or later they have to be released and we have crash, i.e. on
application exit. As next workaround users disable automatic
destructors in such case and so on. Looks that marinas also uses
such storage.
It also shows how important is to add slowly well wrapped classes.
Even single class with bugs can ruin rest of code and we end with
something close to current HBQT state. Even single method call
wrongly wrapped can cause such bad side effects. If some class
cannot be cleanly wrapped then developers should discuss if it's
possible to wrap it only partially or it should be dropped at all.
It's not necessary to wrap everything. Mush more important is wrap
correctly what is possible. If some vital functionality cannot be
well wrapped then possible anomalies should be documented and the
access to danger places limitted by public API.

OK, Enough now - it's late ;)
I hope that above shows how such process should be done.
I have very limited spare time recently anyhow for small
project I can try find time to work on such wrapper.
I believe that it can be good start point and base of source
code for next ones.

best regards,
Przemek

[JoséQuintas]

Hi

Em 03/03/2016 16:15, Przemyslaw Czerpak escreveu:
> For most of GUI programs users need rather simple set of graphic
> widgets. I've seen that FLTK (http://www.fltk.org) was suggest as
> good backend for Harbour GUI library. It's small and license is
> Harbour compliant (LGPL + exception for static linking just like
> in our license). It's possible to create final self contain quite
> small static binaries easy to install. The only one drawback is
> C++ though it seems that they not use any tricks with metaclasses
> and dynamic bindings like in QT (slots and signals) so maybe some
> more restrictive modern C/C++ compilers will not complain about it.

I think developers are in the wrong way.
Problem is not to use a library, controls in a library, but to use Harbour.

Harbour is excelent, for text use.
I think it's time to Harbour have graphic features.

If games can be done without Windows controls, why not a application screen?

Create controls?

Multithread and hb_gtLoad( )
This is available in Harbour.

More libraries, more work to developers, less users on each library,
less developers time on each library, and the feeling that Harbour will
allways be looking for some graphic library and will not have it's own
graphic capability.

A quick solution:
Harbour do in screen the same as harupdf do in pdf, adding the clear
area option.
This can be compatible with any graphic library.

José M. C. Quintas

[Francesco Perillo]

On Fri, Mar 4, 2016 at 1:11 AM, vszakats <vsza...@gmail.com> wrote:

Qt and hbQt can do it, indeed ! It is just necessary make Qt cooperate :-.)

Okay, so you say that QT _can_ be made work to 

manage memory correctly.

With a flag you may request Qt to delete an object immediately (usually, it will keep in memory to reuse it, or delete when it thinks it is good thing to do) and you may intercept the delete message (if it is a subclass of QObject) and start the necessary steps to release prg level objects.

It's not difficult, it's not easy. And there are strange cases as when in a form there are 2 QLabel() and when the form closes one prg level QLabel is correctly destroyed (class destructor is called) and the other not... because the second is referenced in a :connect codeblock created to overcome the possibility of creating SIGNALs and SLOTs in hbQt... These codeblocks can create a circular regerence that must be broken...

To be short: you know the form widget, and you know the children widgets (QT knows, you don't need to keep track of them!!!!!!!!!!) as QLabel, QLineEdit, etc, and Qt tells you that the form is going to be deleted 3.2.1.NOW... and also for the widget you will get the signal... hbQt will handle them with almost no problem, but it you have an object you created, let's say, a "business-level" object like a table that has internally, as DATA members, references to other objects... well... when Qt tells at c++ level that you are going to be deleted, at prg level you have to clean up all your references to other objects... otherwise GC won't destroy them (aka, DESTRUCTOR won't be called).... unfortunately you can't do that in the destructor because it WON'T be called if there is a reference pointing to you stored somewhere else...

 

[Francesco Perillo]

Hi Przemek,

I'm happy you want to have another look at Qt.

We have already implemented some ideas you described in this post, and you sent the code too!

Please read my answer to Viktor. One of the problems is how the connect SIGNAL/SLOT is implemented.
In Qt:

connect( object1, SIGNAL(), object2, SLOT() )

with metadata created by moc preprocessor, when object1 emits SIGNAL, object2:slot() method is called. The 2 objects are loosely coupled, they may also be in different thread - it is the only way to change GUI widgets from othre threads !!!  Qt keeps track of this "couple", so when object1 or object2 gets deleted, the connect is automatically disabled.

in hbQt:

object1:connect( SIGNAL, {|| object2:any_method() })

with the codeblock, there is a reference to object2. We have to store this codeblock. If c++ level object2 is deleted, we try to release from GC but this reference is inside object1... and we don't know that it references object2...
So object2 prg level destructor will be called only when object1 disconnects the signal and if the signal is fired in the meantime... nothing happens ...

If object1 and object2 are DATA member what happens?

::object1:connect( SIGNAL, {|| ::object2:any_method() })

[vszakats]

Hi Przemek,

On Thursday, March 3, 2016 at 8:15:06 PM UTC+1, druzus wrote:

For most of GUI programs users need rather simple set of graphic
widgets. I've seen that FLTK (http://www.fltk.org) was suggest as
good backend for Harbour GUI library. It's small and license is
Harbour compliant (LGPL + exception for static linking just like
in our license). It's possible to create final self contain quite
small static binaries easy to install. The only one drawback is
C++ though it seems that they not use any tricks with metaclasses
and dynamic bindings like in QT (slots and signals) so maybe some
more restrictive modern C/C++ compilers will not complain about it.
Viktor can you check it? 

Quick assessment:

Good news it's on Homebrew [1]. Less good news, the latest 

stable version doesn't support the latest OS X version, nor 

clang - due to what it looks like a 5 years old clang bug. clang 

is the only compiler shipping with Xcode now.

Installing from Homebrew:

```

$ brew install fltk

fltk: This formula either does not compile or function as expected on OS X

versions newer than Yosemite due to an upstream incompatibility.

Error: An unsatisfied requirement failed this build.

```

Building latest stable on OS X:

```

Compiling fl_line_style.cxx...

fl_line_style.cxx:38:13: error: elaborated type refers to a typedef

static enum CGLineCap fl_quartz_line_cap_ = kCGLineCapButt;

            ^

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks/CoreGraphics.framework/Headers/CGPath.h:33:26: note: 

      declared here

typedef CF_ENUM(int32_t, CGLineCap) {

                         ^

[...]

```

Overall the project looks rather stale and/or very small scale,

with GUIs on the non-native-looking side. I'd be a cautious about 

it. Windows build instructions look dated and quite adventurous, 

made complicated by some dependencies, but it's available on 

MSYS2, with a clean build formula. [ I haven't made experiments 

to use MSYS2 packages as Harbour dependencies yet. ]

I'll take look at it more closely in the next few days. 

In the meantime, what about wxWidgets? It looks active, with 

a fresh release, maintained homepage, downloads, relatively 

clean packages in Homebrew and MSYS2 (with slightly less 

intrusive dependencies). It looks rather good on Windows 

and Linux and seems to be at least QT-ish quality on OS X

(disclaimer: based on internet screenshots). I also have some 

good experiences with it while making tests with Teo's wxHarbour.

Overal larger than FLTK though, but both include vendored 

code and wxWidgets hosts code for every conceivable native 

GUI backend.

-Viktor

[1] https://github.com/Homebrew/homebrew/blob/master/Library/Formula/fltk.rb

[Francesco Perillo]

Viktor,

the authors of Marinas choiced to implement the library in a way that I don't agree. Sincerely, I don't know if they needed to keep compatibility with a previous library or not.

Look at these 2 lines from the sample code:
mg_Do( "d_window" , "center" )
mg_Set( "d_window" , "row" , mg_Get( "d_window" , "row" ) + nDesp )

They need that ugly hash because they refer to objects by name, so in mg_Do they look up the hash for d_window (and they use the name) and then enter a mastodontic DO CASE to select which is the function that is called, CENTER. So, on line 6043 of mg_core, it sets two properties, like the mg_Set above, that does the same of mg_Do: retrieve the object and enter the mastodontic DO CASE...

Why don't transform to pure OOP and have ONE active variable, d_window, and do:

d_window:center()

d_window:row := d_window:row() + nDesp

You can use "decorator pattern" so that you may have just the "published API" methods available, or the "inheritance" style, where d_window inherits directly from hbQt objects, so you can call standard Qt methods on them....

And if d_window has a QLabel named lbl1 inside, code can be:

d_window:lbl1:setText( "this is a QLable" )

To achieve this result, you don't need to keep track of lbl1.... in our library (HQL3) you will use:

WITH OBJECT d_window := HqlMainWindow( "my_window" )
   WITH OBJECT HqlLabel( "lbl1" )

      

and you can do

d_window:lbl1:setText()

or if you want, can do

Hql():my_window:lbl1:setText()....

Please note that we are not storing references, names, anything about the object names at prg level.... Qt has been built to deal with this stuff and we say thank you to Qt developers and use the features they gave to us :-))))

No prg level table of objects, no storing of redundant informations, no duplicate code at prg level that Qt and hbQt do at c++ level.... just cooperate with them to complement them...

PS: I have nothing against Marinas GUI, that implements a lot of stuff, and works flawlessy for a lot of people and probably needs to support a lot of legacy code

PS2: also with the actual implementation, I think that Marinas internal code may be updated a bit to be quicker to run; I believe that switching to real OOP can have 10x speedup. but if you have the screen drawn in 10 ms or 100, would you really notice?

On Fri, Mar 4, 2016 at 1:11 AM, vszakats <vsza...@gmail.com> wrote:

[Lorenzo Fiorini]

On Fri, Mar 4, 2016 at 2:24 AM, vszakats <vsza...@gmail.com> wrote:

> In the meantime, what about wxWidgets? It looks active, with
> a fresh release, maintained homepage, downloads, relatively
> clean packages in Homebrew and MSYS2 (with slightly less
> intrusive dependencies). It looks rather good on Windows
> and Linux and seems to be at least QT-ish quality on OS X
> (disclaimer: based on internet screenshots). I also have some
> good experiences with it while making tests with Teo's wxHarbour.
> Overal larger than FLTK though, but both include vendored
> code and wxWidgets hosts code for every conceivable native
> GUI backend.

On OSX 10.11:

1 - brew install wxwidgets

2 - copy and paste helloworld.cpp from
http://docs.wxwidgets.org/stable/overview_helloworld.html

3 - g++ helloworld.cpp `wx-config --cxxflags --libs` -o helloworld

./helloworld

109KB with frame, menu and messagebox.

$ otool -L ./helloworld
./helloworld:
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
(compatibility version 1.0.0, current version 275.0.0)
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
(compatibility version 2.0.0, current version 157.0.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa
(compatibility version 1.0.0, current version 22.0.0)
/System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox
(compatibility version 1.0.0, current version 492.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1226.10.1)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
(compatibility version 1.0.0, current version 1.0.0)
/usr/local/opt/wxmac/lib/libwx_osx_cocoau_xrc-3.0.dylib (compatibility
version 3.0.0, current version 3.0.0)
/usr/local/opt/wxmac/lib/libwx_osx_cocoau_webview-3.0.dylib
(compatibility version 3.0.0, current version 3.0.0)
/usr/local/opt/wxmac/lib/libwx_osx_cocoau_html-3.0.dylib
(compatibility version 3.0.0, current version 3.0.0)
/usr/local/opt/wxmac/lib/libwx_osx_cocoau_qa-3.0.dylib (compatibility
version 3.0.0, current version 3.0.0)
/usr/local/opt/wxmac/lib/libwx_osx_cocoau_adv-3.0.dylib (compatibility
version 3.0.0, current version 3.0.0)
/usr/local/opt/wxmac/lib/libwx_osx_cocoau_core-3.0.dylib
(compatibility version 3.0.0, current version 3.0.0)
/usr/local/opt/wxmac/lib/libwx_baseu_xml-3.0.dylib (compatibility
version 3.0.0, current version 3.0.0)
/usr/local/opt/wxmac/lib/libwx_baseu_net-3.0.dylib (compatibility
version 3.0.0, current version 3.0.0)
/usr/local/opt/wxmac/lib/libwx_baseu-3.0.dylib (compatibility version
3.0.0, current version 3.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0)

best regards,
Lorenzo

[vszakats]

Most of the dylib dependencies are not need (at least not directly).

Here's a reduced example:

```

g++ helloworld.cpp -o helloworld \

   -I/usr/local/lib/wx/include/osx_cocoa-unicode-3.0 \

   -I/usr/local/include/wx-3.0 \

   -D_FILE_OFFSET_BITS=64 -DwxDEBUG_LEVEL=0 -DWXUSINGDLL -D__WXMAC__ -D__WXOSX__ -D__WXOSX_COCOA__ \

   -L/usr/local/lib \

   -lwx_osx_cocoau_core-3.0 \

   -lwx_baseu-3.0

```

$ otool -L ./helloworld

./helloworld:

/usr/local/opt/wxmac/lib/libwx_osx_cocoau_core-3.0.dylib (compatibility version 3.0.0, current version 3.0.0)

/usr/local/opt/wxmac/lib/libwx_baseu-3.0.dylib (compatibility version 3.0.0, current version 3.0.0)

/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0)

[Dasun]

Hi fperillo,

Actually Marinas performance - with one or two exceptions - seems quite good, although architecturally it could be improved in my view .  Not liking to tie my projects to one special syntax -  I tried two methods, both relying on wrapping Marinas commands - so they were coded in only one place .  Firstly, I tried a kind of @SAY/GET syntax and used that to map onto  functions that encapsulated the Marinas commands, this kind of worked.  Next I tried defining objects that wrapped the Marinas commands and that kind of worked as well. 

My main take away from these effforts was that the @SAY/GET syntax was the cleanest and most readable  way to define the graphics elements - the least code to write.  This should be the way forward with Visual Harbour/Clipper.

I am willing to help with Visual Harbour/Clipper code - my C is rusty, but I have worked as a commercial C coder in the past so I guess it will come back.

I read through the  wxWidgets and FLTK websites and both seem viable candidate's, but further investigation is needed. wxWidget is just as heavy as QT and FLTK is much lighter - which justifies Przemek suggested path forward but I understand Vicktors concerns. Really Visual Harbour does not a full set of widgets just a subset. 

I still think HbQT is the foundation we should build on, certainly moving to wxWidgets will mean a lot of code writing to get to HbQTs current standard. I am going to try and find time in the next few days to take a proper look at FLTK.

[Lorenzo Fiorini]

On Fri, Mar 4, 2016 at 6:00 PM, Lorenzo Fiorini
<lorenzo...@gmail.com> wrote:

> On OSX 10.11:
>
> 1 - brew install wxwidgets
>
> 2 - copy and paste helloworld.cpp from
> http://docs.wxwidgets.org/stable/overview_helloworld.html
>
> 3 - g++ helloworld.cpp `wx-config --cxxflags --libs` -o helloworld
>
> ./helloworld
>
> 109KB with frame, menu and messagebox.

On Centos 7 64:

1 - sudo yum install wxGtK-devel

2 - download another hellworld from https://wiki.wxwidgets.org/Hello_World

3 - g++ helloworld.cpp `wx-config --cxxflags --libs` -o helloworld

gives a 34K simpler app with a frame and a status message.

The version is 2.8.12 while in OSX was 3.0.2.

best regards,
Lorenzo

[vszakats]

I read through the  wxWidgets and FLTK websites and both seem viable candidate's, but further investigation is needed. wxWidget is just as heavy as QT and FLTK is much lighter - which justifies Przemek suggested path forward but I understand Vicktors concerns. Really Visual Harbour does not a full set of widgets just a subset. 

wxWidgets just as heavy as QT - in what way exactly?

Looking at the source sizes:

  21MB fltk-1.3.3-source.tar

 119MB wxWidgets-3.1.0.tar

 687MB qt-everywhere-opensource-src-4.8.7.tar

1850MB qt-everywhere-opensource-src-5.5.1.tar

QT4 = 6 times the source size of wxWidgets

QT5 = 15 times the source of wxWidgets

As I said wxWidgets offers _native_ GUI, like QT, not a 

generic looking ugliness like FLTK. I'd argue the latter 

doesn't offer a much better user experience than f.e. 

existing GTWVW, even though it's "more GUI", so it's 

only good tick the "portable GUI" checkbox.

wxWidgets comes with some optional components, 

which can just be ignored, like a web components, 

XML and whatnot.

-Viktor

[vszakats]

> I still think HbQT is the foundation we should build on, certainly moving to wxWidgets will mean a lot of code writing to get to HbQTs current standard. I am going to try and 

> find time in the next few days to take a proper look at FLTK.

Not sure I follow you conclusions.

- First you diss wxWidgets for FLTK because former is "as large as QT". (not true)

- Then you repeat to use HBQT. Where QT itself is 6-15 times larger than wxWidgets.

- Then you state that "wxWidgets will mean a lot code writing". 

  Based on/compare to what?

[Dasun]

Hi Viktor,

I was looking at the Widget object depth and relationships in the documentation ... not total source code - apologies for not being clearer.  I plan to look closer at FLTK but judging from screenshots I think wxWidgets  is better looking and would be happier with either a wxWidgets ot QT path - and given the huge amount of work on HbQT I still think it might save time starting with trying to fix it and move forward .  FLTK is only attractive because it is lightweight and should be fairly straightforward - except on the Mac platform.

[Teo Fonrouge]

Hi Przemek,

I strongly believe that writing a Harbour wrapper library for a such big beast like Qt

needs the help of a utility able to create .cpp sources from a form of header text file,

which contains definitions of each class, inherited class, messages / members, type

of binding to the Harbour object, conditionals in order to check at compile time ( the .cpp)

of a determined qt/wxWidgets/... version, conditionals to check platform ( X11, Windows,

OSX, ... ), override methods, ...

In order to achieve this in the qtHarbour project, I write a simple parser that is able to

convert this .wip text file which contains header prototypes of a qtPixmap cpp class:

https://sourceforge.net/p/qth/qtharbour-core/ci/master/tree/wip/qthQPixmap.wip

into this .cpp file:

https://sourceforge.net/p/qth/tmp/code/ci/master/tree/qth/qthQPixmap.cpp

the resulting .cpp file is able to build the wrappers for each method, even builds override

methods by using parameter checking. In fact it builds the whole Harbour class and methods

The result is a automated Harbour class with the same members that original .cpp Class.

I think that in Harbour would be handy a tool that, using a predetermined a formatted text file

containing prototypes, it builds automatically the wrapper for the equivalent Harbour function/

method/class. this way one can use this tool to help create wrappers for any C++ / C library.

Now, on the other hand, the original post stated only 9 controls in order to have a basic GUI,

and may be will be much more easy to build (using graphics primitives for each platform) an

'propierary' basic GUI library for Harbour

9 controls vs hundreds of classes on Qt     :D

with best regards,

Teo

[vszakats]

Hi Dasun,

On Friday, March 4, 2016 at 8:20:15 PM UTC+1, Dasun wrote:

Hi Viktor,

I was looking at the Widget object depth and relationships in the documentation ... not total source code - apologies for not being clearer.  I plan to look closer at FLTK but

I understand. What's key is memory management, this 

checked out with Przemek, regarding FLTK, it'd be interesting 

to see how wxWidgets fare in this area.

judging from screenshots I think wxWidgets  is better looking and would be happier with either a wxWidgets ot QT path - and given the huge amount of work on HbQT I still think it might save time starting with trying to fix it and move forward .  FLTK is only attractive because it is lightweight and should be fairly straightforward - except on the Mac platform.

Based on screenshots, FLTK's visuals is not Mac problem

only. It looks very rough on Linux and Windows as well. It 

appears to be drawing its own controls, and doing so the 

same way regardless of platform. On Mac the main 

problem is that it doesn't even compile. Maybe the dev branch 

does, I haven't tried that yet.

[Teo Fonrouge]

Hi Dasun,

On Friday, March 4, 2016 at 11:33:28 AM UTC-6, Dasun wrote:

Hi fperillo,

Actually Marinas performance - with one or two exceptions - seems quite good, although architecturally it could be improved in my view .  Not liking to tie my projects to one special syntax -  I tried two methods, both relying on wrapping Marinas commands - so they were coded in only one place .  Firstly, I tried a kind of @SAY/GET syntax and used that to map onto  functions that encapsulated the Marinas commands, this kind of worked.  Next I tried defining objects that wrapped the Marinas commands and that kind of worked as well. 

My main take away from these effforts was that the @SAY/GET syntax was the cleanest and most readable  way to define the graphics elements - the least code to write.  This should be the way forward with Visual Harbour/Clipper.

I am willing to help with Visual Harbour/Clipper code - my C is rusty, but I have worked as a commercial C coder in the past so I guess it will come back.

I read through the  wxWidgets and FLTK websites and both seem viable candidate's, but further investigation is needed. wxWidget is just as heavy as QT and FLTK is much lighter - which justifies Przemek suggested path forward but I understand Vicktors concerns. Really Visual Harbour does not a full set of widgets just a subset. 

wxWidgets, even in their latest version is just a minimal part of the whole Qt

what is more, the is a wxQt port, IOW a wxWidgets wrapper which uses Qt libs.

 I dare to a fat Qt to do the same :D

best regards,

Teo

[Pritpal Bedi]

Hi Przemek

Sorry for the delay in response, but I was experimenting with HbQt 

to reply in a proper manner.

If you want to separate HBQT for QT4 and QT5 then it's OK for me.
Please remember that QT4 is still base library in many *nix systems
so programs using HBQT4 will not need any additional libraries and
functionality given by QT4 is usually enough for these systems.

So I have a subset of HbQt containing only three modules, viz., 

QtCore, QtGui, QtNetwork functional for Qt 4.8.6 [ And I see no issues 

with earlier versions since till then all version based methods are 

well protected ]. The distro also contains HbQtWidgets, HbIDE, HbDbu 

and HbXbp. To keep it relevant to current build engine, i.e., hbmk2_qt.hb,

I used latest hbmk2 plugin and mingw 4.9.2 shipped with Qt 5.6 RC.

To start with I used r314 and then brought current hbmk2_qt.hb.

I needed to add one function QApplication_translate() in hbqt_misc.prg.

This is needed because .ui files parsed through current plugin does not 

handle it. It can be fixed in the parser but to be quick adding a function 

did the trick.

So we are ready with a GUI only stripped-down version of Qt 4.x compatible.

Let me know how should we proceed. But still I am trying to have only 

one distro instead of two, and hope to be successful in a couple of days.

 

Anyhow I also tested HBQT in MS-Windows and all what I wrote about
it is also a problem in this system. Just try to load Harbour and
HBQT source code to new "clean" system. Install also QT version you
prefer. Then compile harbour and HBQT and check if the process can
be completed with single compilation step.

I tried on a fresh drive and, yes, you are correct. It needs tweaks.

Let me know what did you do other steps to let it compile.

 

QT is huge library which tries to wrap everything. We do not need
all it's functionality because we have our own native solutions.

True, and now we have  a stripped down version. It will serve this goal well.

The second problem with this library is C++. It introduces additional
dependencies and it's very hard to create clean wrappers for other
languages (it's not harbour only problem, just read about limitation
and problems in PyQt) anyhow it's possible though it needs a lot of
works.

Yes, indeed. That's why I had to write c++ code in the source files.

 

HBQT is incredible big job and I believe it's production
ready for people knowing it well and their internal bindings so
can write code on Harbour level which do not volatile some hidden
for normal users rules.

I agree.

So many times I wrote that try to re-use the objects as much as possible.

And few more caveats. But I agree that we document those rules 

as much as possible.

 

I also created few small test programs
recently and I like the results. But when I made some deeper
experiments I've found the not all things are cleanly cleanup
and I had to update the code.

Can you share your experience what code you exactly updated 

for which type of issue. It will greatly enhance my knowledge

on the internals of Qt.

 

It means that it's possible to write
well working application but it's also possible to make it in wrong
way what may cause more or less serious problems with unreleased or
corrupted memory. I do not know if over all protection for wrong
code can be even reached but I hope we can at least well document
constructions which need special user attention.

Very well said.

 

 

Now HBQT is such big project that I cannot even say what it does
in all places. It's very hard for me to start working on it. Of
course I can change some separated things I need but I do not see
the "whole picture".

Please change those separate things. I am very sure about the 

positive results once you touch the sources. And let me know in what 

way I can express the "whole picture".

 

Maybe I can help in a little bit different way.

Any way help is more than enough for us. I am aware of the 

gap between a student and a master.

 

For most of GUI programs users need rather simple set of graphic
widgets. I've seen that FLTK (http://www.fltk.org) was suggest as
good backend for Harbour GUI library. It's small and license is
Harbour compliant (LGPL + exception for static linking just like
in our license). It's possible to create final self contain quite
small static binaries easy to install. The only one drawback is
C++ though it seems that they not use any tricks with metaclasses
and dynamic bindings like in QT (slots and signals) so maybe some
more restrictive modern C/C++ compilers will not complain about it.

Probably, this will be a lot more work, than, fixing the parts of HbQt 

and documenting which cannot or can be achieved. No ?

 

Viktor can you check it?
If it can be cleanly compiled on MacOSX with new CLANG then I'll
look closer on it and check what is the chance to create simple
wrapper. If it's possible then we can try to create general PRG
layer for GUI libraries with replaceable backend. This backend
will use FLTK at the beginning and then we can try to replace it
with backend for QT and finally bound with HBQT adding all other
functionality and documenting what cannot be ported or what was
ported with some potential problems and how user should avoid it.

Maybe, may-not-be. But for sure I have no doubts about your capabilities.

 

 

I agree it should be separated project. Anyhow we will need
developers who can work on it. I will not find enough spare time
to make it myself.

I can count on me but only when Qt or HbQt is triggered by such a project.

Regards

Pritpal Bedi

a student of software analysis & concepts.

 

[Luigi Grella]

Pritpal Bedi,
You are doing a fine job, and I hope you will persist with your efforts.  There always are personalities on forums who will disagree with you, and the correct attitude (which you have) is to accept their knowledge and ignore their ignorance.
All the best.

On Saturday, April 4, 2015 at 8:36:44 AM UTC+5:30, Ash wrote:

Hello,

I wish the following Clipper controls were part of Harbour core but in GUI form and using the same syntax - things like:

@... Say
@... Get

@... Box
Check Box
List Box
Push Button
Radio Button
Radio Group
Scroll Bar

These controls are enough to write very good looking business applications in a way that we have been used to from Clipper days. Writing business applications is hard enough never mind the complexities of add-on GUI libraries.

My 2 cents worth.

Regards.
Ash

[Pritpal Bedi]

Hi Przemek

 

If you want to separate HBQT for QT4 and QT5 then it's OK for me.
Please remember that QT4 is still base library in many *nix systems
so programs using HBQT4 will not need any additional libraries and
functionality given by QT4 is usually enough for these systems.

Achieved, and within the same distro:

2016-13-05 02:00 UTC-0800 Pritpal Bedi (bedipritpal at hotmail.com)(r424)

  * hbide/actions.prg

  * hbide/editor.prg

  * hbqt/hbmk2_qt.hb

  * hbqt/qtcore/hbqt_hbqevents.cpp

  * hbqt/qtcore/hbqt_misc.prg

  * hbqt/qtcore/hbqtcore.hbc

  * hbqt/qtcore/qth/QVariantAnimation.qth

  * hbqt/qtgui/hbqt_hbqabstractitemmodel.cpp

  * hbqt/qtgui/hbqt_hbqgraphicsitem.h

  * hbqt/qtgui/hbqt_hbqgraphicsscene.cpp

  * hbqt/qtgui/hbqt_hbqgraphicsscene.h

  * hbqt/qtgui/hbqt_init.cpp

  * hbqt/qtgui/hbqtgui.hbc

  * hbqt/qtgui/qth/QApplication.qth

  * hbqt/qtgui/qth/QComboBox.qth

  * hbqt/qtgui/qth/QHeaderView.qth

  * hbqt/qtgui/qth/QPrinter.qth

  * hbqt/qtgui/qth/QScrollEvent.qth

  * hbqt/qtgui/qth/QScrollPrepareEvent.qth

  * hbqt/qtgui/qth/QSplitterHandle.qth

  * hbqt/qtgui/qth/QTabBar.qth

  * hbqt/qtgui/qth/QTabWidget.qth

  * hbqt/qtgui/qth/QTextTable.qth

  * hbqt/qtgui/qth/QTextTableCell.qth

  * hbqt/qtnetwork/hbqtnetwork.hbc

  * hbqtwidgets/hbqtbrowse.prg

  * hbqtwidgets/misc.prg

  * hbqtwidgets/tests/browgets.prg

  * hbqtwidgets/tests/composite.hbp

  * hbqtwidgets/tests/validator.prg

  + qtcontribs4.hbp

    + Added new Qt 4.x relevant Harbour project file.

    ; Brought back Qt 4.x compatibility for QtCore, QtGui and QtNetwork modules.

      NOTES:  1. Set environment HB_QT_MAJOR_VER=4.

              2. Set environment HB_USER_PRGFLAGS=-d__HB_QT_MAJOR_VER_4__

              3. Set environment variable HB_BUILD_NAME=-486 (where -486 == QtVer)

              This is the .bat used to compile for any version of Qt:

              @ECHO OFF

              SET HB_QT_MAJOR_VER=4

              SET HB_USER_PRGFLAGS=-d__HB_QT_MAJOR_VER_4__

              SET HB_BUILD_NAME=-486

              SET QT_PATH=C:\Qt486

              SET GW_PATH=C:\Qt550\Tools\mingw492_32

              SET PATH=D:\harbour\bin\win\mingw%HB_BUILD_NAME%;%GW_PATH%\bin;%QT_PATH%\bin;%PATH%

              SET HB_ARCHITECTURE=win

              SET HB_COMPILER=mingw

              SET HB_INSTALL_PREFIX=C:\harbour

              SET HB_WITH_QT=%QT_PATH%\include

              SET HB_QTPATH=%QT_PATH%\bin

              SET HB_USER_CFLAGS=-DHB_LEGACY_TYPES_ON

              SET HB_LEGACY_TYPES_ON=YES

              SET HB_BUILD_CONTRIB_DYN=no

              SET HB_TR_SYSOUT=yes

              :__eof__  Add your build relevant other settings

              Convert above to Linux Script syntax.

      Now onwards compatibility for Qt 4.x will be maintain for base 3 modules.

      HbIDE, HbDBU, and many tests in HbQt and HbQtWidgets are running 

      normally. HbIDE sometimes throughs exception at exit. Every other 

      test app works flawlessly.

      

      Enjoy

[Luigi Ferraris]

Hi to everyone

I'm the last wheel of the car, so just for laugh... but not a lot
Ladies and Gentlemen welcome to the "Gui for CLIPPER" annual award; this year the winner is.... FLTK.

For many years, people ask (me too): what is preferred Open Source GUI for CLIPPER programs?
The answers were: you can use this, that, those! A lot, but not very clear!
So, everyone choose something and there is a lot of CLIPPER code around the world.
Many of that projects are dead, many are hard to be used other are OS concentric, etc., etc.
On the other hand, I remember a phrase that sounds (more or less) like this: Harbour is not the right place for a GUI

There are some main CLIPPER/Harbour projects based upon Qt: HbQt(Pritpal) and QtHarbour(Teo) I don't know other.
There are some projects based upon HbQt: Marinas, HMG4 sorry if I lost someone
At the end source code everywhere like Hql3 as mentioned by Francesco based on HbQt.

Qt is a worldwide library: used on several devices with several OSes with a big community, etc. and it's not born yesterday
Many developers, Microsoft itself, choose Qt as backend.
We only want to have the ability to mimic some CLIPPER aspects like @ 10, 20 SAY ... GET?
getSys, getList, listbox or special chars to paint a form?
Many libraries (e.g. contrib) can have problem when the original source breaks some functionality. The same for CLIPPER code.
Try to use e.g. hb_Ains() in your program and then use an old CLIPPER compiler to build: I think it doesn't work.
(in general) OOP offers many advantages than a line command or many functions.

Sorry, probably I'm too stupid: but I don't understand why opposing to the HbQt | qtHarbour projects, at least Qt usage.

There are a lot of "errors" in HbQt project? Perhaps yes.
This project doesn't follow Harbour directives? Probably yes.
The project must be cleaned, revised, well update? Probably yes.
HbQt is too heavy (build processing, redundant, etc.)? Probably yes. Can be reduced? Probably yes.
A big (complex) projects like Qt (so the wrapper) can follow current Harbour philosophy?
(I think about some C++ abilties that can't be replicated or it's not so easy.)
I'm in  agreement (and me too I have requested) to create two different versions: before Qt5 and from Qt5.
(my personal pov is to stop development on version < Qt5)
etc, etc.

If there are problems to interface between Harbour object and C++ object, these problems arise with Qt or any other complex GUI
Objects life is a beast and it creates problems; perhaps, many CLIPPER programmers think that can be always solved with a simple out of scope.
As Francesco mentioned, we write a layer (Hql named and now on 3 ver) and it doesn't need any additional structure to keep objects alive; it's based on current HbQt implementation, Harbour class inheritance.
My programs run well on WindowsXp and Xubuntu: simply rebuild; Harbour powerful, HbQt powerful, Qt powerful
Qt installation is problematic? I never use standard path (Linux /opt) and I can remove. The same concept used with Harbour installation
Qt is complex? Oh yeah. I need to understand its pov before use.
There will be conflicts with OS shipped with Qt4 and my program using Qt5? I don't know.

I think that many of these problems can be solved if we cooperate.

So, my fundamental question is: why we (Harbour community) can't cooperate on that started/used projects?
I think this is (and must be) the Open Source spirit of this big community.

@Pritpal: sometimes I disagree with you, but your job (though criticized as others, the first mine) open a new scenario / life for CLIPPER/Harbour code.

Many thanks to every Harbour Developer, many thanks to the Harbour Community

Best Regards
Luigi Ferraris

p.s. I hope my English it's not so bad

[M., Ronaldo]

Hi Friends !

For years I experienced graphical libraries available for Harbour (and many other users, for sure)!
An extreme waste of time (given the lack of stability and all time memory leak! we expect a program that works continuously 24x7, never a few seconds and then break)

It would be interesting to have a graphical interface recommended by Harbour community!
I believe hbQT is the best option and is available for use now (not future possibilities wxWidgets, FLTK, ...)

A full refactory for hbQT will be great, then separate optional parts like xbp, xing, hbqtwidgets...


Regards

[El Oso Pedrozo]

Hola Luigui no se si has visto los proyectos de Lazarus, Free pascal, Python, FreeBasic si en realidad comenzaran con un proyecti visual clipper ojala sean parecidos a estos.

Saludos........

--
--
You received this message because you are subscribed to the Google
Groups "Harbour Users" group.
Unsubscribe: harbour-user...@googlegroups.com
Web: http://groups.google.com/group/harbour-users

---

You received this message because you are subscribed to a topic in the Google Groups "Harbour Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/harbour-users/A4SCm8a6W8w/unsubscribe.
To unsubscribe from this group and all its topics, send an email to harbour-user...@googlegroups.com.

[Massimo Belgrano]

Regarding qt i hope also also in better flexibility in merge source
now is not possible add hbdbu to hbide because is written in different way
so or  you need do rewriting hbide or not able to merge other hbqt class , xbp or other

 

2015-04-04 5:06 GMT+02:00 Ash <jun...@gmail.com>:

Hello,

I wish the following Clipper controls were part of Harbour core but in GUI form and using the same syntax - things like:

@... Say
@... Get

@... Box
Check Box
List Box
Push Button
Radio Button
Radio Group
Scroll Bar

These controls are enough to write very good looking business applications in a way that we have been used to from Clipper days. Writing business applications is hard enough never mind the complexities of add-on GUI libraries.

My 2 cents worth.

Regards.
Ash

--

--
You received this message because you are subscribed to the Google
Groups "Harbour Users" group.
Unsubscribe: harbour-user...@googlegroups.com
Web: http://groups.google.com/group/harbour-users

---

You received this message because you are subscribed to the Google Groups "Harbour Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to harbour-user...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Massimo Belgrano
Delta Informatica S.r.l. (Cliccami per scoprire ) 

[Francesco Perillo]

I think that what Massimo is saying is a clear sign of the situation of hbQt project.

Inside hbQt repository there are several sub-projects, each one developed in a particular time-frame (and so depends on hbQt features in that moment) and in a particular style.

hbQt is the layer, the glue between Qt and Harbour. It's the only part that - in order to contribute - needs specific c++ and Qt knowledge and it may be difficult to start with.

All the others sub-projects are based on this one and are written in Harbour language. And since we are all Harbour programmers here, almost everybody can update the sources.

Regarding hbDbu, Pritpal refactored the code so that now the hbdbu.prg is actually a "container" and class HbQtDBU in hbqtwidgets directory is the real dbu class. He did so in order to be able to use dbu functionalities in our own programs. Sincerely, I never tried :-)

But he did, and infact dbu functionalities are present in hbIde: View -> IDEParts -> ideDBU. So, definitively, you can use dbu inside your programs.

[vszakats]

On Monday, March 7, 2016 at 3:54:26 PM UTC+1, fperillo wrote:

All the others sub-projects are based on this one and are written in Harbour language. And since we are all Harbour programmers here, almost everybody can update the sources.

Sadly, this is not true. App specific C++ code is 

included _inside the HBQT source code_. F.e.:

   https://sourceforge.net/p/qtcontribs/code/HEAD/tree/trunk/hbqt/qtgui/hbqt_hbqplaintextedit.cpp

These have been moved from HBIDE code in the past,

to ""resolve"" the rule/goal that every QT feature should 

be accessible via .prg code. It's not resolved, just hidden.

I have noticed that in this source code repository that is 

supposed to be a GUI wrapper, _OpenSSL binaries_ are 

now included as well:

  https://sourceforge.net/p/qtcontribs/code/HEAD/tree/trunk/libs/openssl-1.0.2/

They have been updated a year ago, meaning they 

have a long list of unfixed, highly critical security issues.

[Przemyslaw Czerpak]

On Thu, 03 Mar 2016, vszakats wrote:

Hi Viktor,

Looks that we will have to clean FLTK code to be compliant
with this clang version. I do not like such things :(

> Overall the project looks rather stale and/or very small scale,
> with GUIs on the non-native-looking side. I'd be a cautious about
> it. Windows build instructions look dated and quite adventurous,
> made complicated by some dependencies, but it's available on
> MSYS2, with a clean build formula. [ I haven't made experiments
> to use MSYS2 packages as Harbour dependencies yet. ]
>
> I'll take look at it more closely in the next few days.

Thank you very much for your tests. I do not think it's
worth to invest more time if it has such problems in OSX.

> In the meantime, what about wxWidgets? It looks active, with
> a fresh release, maintained homepage, downloads, relatively
> clean packages in Homebrew and MSYS2 (with slightly less
> intrusive dependencies). It looks rather good on Windows
> and Linux and seems to be at least QT-ish quality on OS X
> (disclaimer: based on internet screenshots). I also have some
> good experiences with it while making tests with Teo's wxHarbour.
> Overal larger than FLTK though, but both include vendored
> code and wxWidgets hosts code for every conceivable native
> GUI backend.

Probably it's much better choice with the exception to size
and static self contain binaries. Anyhow it would be nice if
can reuse meta class descriptions created for wrappers to
other languages. I.e. such description exists for PyGTK and
Phil Krylow used it in xbGTK. BTW xbGTK looks realy nice:
http://xbgtk.sourceforge.net/
It's small and compact. I haven't tried it in last years so
as soon I'll find some spare time I'll do that.

wxWidget is actively developed so here we can expect that
core functionality will work as expected. Anyhow if we plan
to create wrappers for C++ code then we will have to define
how to resolve problems which are common to C++ libraries
and exists also in QT.
In the upper level languages with automatic detaching of local
variables like Harbour people used to write code without setting
and removing explicit references. If we want to replicate it and
add support for inheritance from wrapped objects so users can
define new instance variables then we have to add code which
creates such bindings in hidden way and remove them when
necessary. Such general layer can be used by different projects.
I also agree that classes should be generated automatically
from metafiles. We can save a lot of time if we can reuse
already created descriptions.

best regards,
Przemek

[Francesco Perillo]

Viktor,

hbqt subdir is the only one requiring c++ knowledge. qtgui is part of hbqt.

With other sub-projects I was referring to hbqtwidgets, hbide, hbdbu....these are pure Harbour code

so hbqt_hbqplaintextedit.cpp is part of section in which c++ is required....

Unfortunately, the naming used doesn't help and I didn't help too...   The project is called qtcontribs ( https://sourceforge.net/p/qtcontribs/code/HEAD/tree/trunk/ ) and has several sub-projects inside, one of with is hbQt, the only one that requires c++ knowledge if you want to cooperatare and contribute code.

All the other sub-projects are Harbour code. My proposal is to move hbQt sub-project in another repository, on its own, since it is the layer that is necessary to integrate Qt and Harbour. And keep the rest as needed



hbqt_hbqplaintextedit.cpp has been moved from hbide because it was said that hbide and other sub-projects should not contain c++ code. It is necessary to have it in c++ because in its current form, there is no other standardized way to overload protected methods.

hbqt_hbqabstractitemmodel.cpp, instead, is needed to overload some virtual methods... using a sub-class is a must required by Qt. Unfortunately, hbQt is not good at subclassing, at the moment...

So, there is nothing hidden but if you ask for 100% Harbour access to Qt features, well, no, we are not there... and current implementation of hbmk2_qt.hb can't reach that goal, it must be re-written completely.

Now to your last point: the repository includes stuff that has nothing to do with it. As Rolf said, Pritpal used the public repository to help others (I'm sure about this) but also to fulfill his job needs. Openssl is there but is not used...

Dbu engine was moved but the code was not completely refactored, for example there are 2 STATIC FUNCTIONs, __arrayToString( aStrings, cDlm ) and hbide_array2string( a_, cDlm ) with the same code (except for variable names) inside hbqtdbu.prg.

Or references to his production environment in another source:
    /* Indicate that the table belongs TO production environment and hence be modified WITH care */
   IF oMdiBrowse:connection() $ "ECP_1,ECP_2,ECP_3,Cluster"
      oHbQtBrowse:showIndicator( "red" )
   ENDIF

In several cases the new() method is overload instead of init() so it is almost impossible to subclass.

So, if you want to list what is bad in the repository... well, I already know! :-)))

If you'd like to help a bit, one thing would be how to compile and use the library with or without a "make install", also splitting hbQt from the other sub-projects.

[Francesco Perillo]

On Mon, Mar 7, 2016 at 6:24 PM, Przemyslaw Czerpak <dru...@poczta.onet.pl> wrote:

On Thu, 03 Mar 2016, vszakats wrote:

Anyhow it would be nice if
can reuse meta class descriptions created for wrappers to
other languages. I.e. such description exists for PyGTK and
Phil Krylow used it in xbGTK.

These meta class description files exist for Qt too.

 

[vszakats]

On Monday, March 7, 2016 at 6:25:51 PM UTC+1, fperillo wrote:

Viktor,

hbqt subdir is the only one requiring c++ knowledge. qtgui is part of hbqt.

hbqt_hbqplaintextedit.cpp has been moved from hbide because it was said that hbide and other sub-projects should not contain c++ code. It is necessary to have it in c++ because in its current form, there is no other standardized way to overload protected methods.

Emphasis mine. This is one of the structural problems I mentioned 

above.

So, if you want to list what is bad in the repository... well, I already know! :-))) 

If you'd like to help a bit, one thing would be how to compile and use the library with or without a "make install", also splitting hbQt from the other sub-projects.

First everything should be deleted that is not absolutely 

necessary, leaving QTCORE/QTGUI wrappers only. But 

at that moment that would be a different project.

So, no sorry. This is wrong/impossible in too many way.

[Francesco Perillo]

So, if you want to list what is bad in the repository... well, I already know! :-))) 

If you'd like to help a bit, one thing would be how to compile and use the library with or without a "make install", also splitting hbQt from the other sub-projects.

First everything should be deleted that is not absolutely 

necessary, leaving QTCORE/QTGUI wrappers only. But 

at that moment that would be a different project.

So, no sorry. This is wrong/impossible in too many way.

Why qtcore and qtgui only? I understand qzxing should not be there, neither qscintilla.... but why you say no to the others?

Let's say we start from qtcore and qtgui, why do you say it is still not ok?

[Massimo Belgrano]

I pray and hope that Przemek and Viktor give a foundation for hbqt resolving same bad feature
also other harbour lib can evolve 

--
--
You received this message because you are subscribed to the Google
Groups "Harbour Users" group.
Unsubscribe: harbour-user...@googlegroups.com
Web: http://groups.google.com/group/harbour-users

---
You received this message because you are subscribed to the Google Groups "Harbour Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Francesco Perillo]

Viktor, disregard my message... probably we will never agree on hbQt :-)

I have an idea on how to proper implement inheritance and everything but I have no time to implement it. I can retrieve the original post I did in the past.

One question: is there a way to specify a directory in which to search for .hbc files in current hbmk2 using environment variables?

[vszakats]

On Monday, March 7, 2016 at 8:24:20 PM UTC+1, fperillo wrote:

Viktor, disregard my message... probably we will never agree on hbQt :-)

I have an idea on how to proper implement inheritance and everything but I have no time to implement it. I can retrieve the original post I did in the past.

One question: is there a way to specify a directory in which to search for .hbc files in current hbmk2 using environment variables?

No, it's hardcoded to be the `/addons/` directory, which the central 

repository for 3rd party packages. (`/contrib/` will also be searched,

which is the central repository for packages bundled with core.)

You can override the addons directory with an envvar, though.

[vszakats]

Hi Przemek,

On Monday, March 7, 2016 at 6:24:33 PM UTC+1, druzus wrote:

On Thu, 03 Mar 2016, vszakats wrote:

Hi Viktor,

[...]

Thank you very much for your tests. I do not think it's
worth to invest more time if it has such problems in OSX.

Agreed!

 

> In the meantime, what about wxWidgets? It looks active, with
> a fresh release, maintained homepage, downloads, relatively
> clean packages in Homebrew and MSYS2 (with slightly less
> intrusive dependencies). It looks rather good on Windows
> and Linux and seems to be at least QT-ish quality on OS X
> (disclaimer: based on internet screenshots). I also have some
> good experiences with it while making tests with Teo's wxHarbour.
> Overal larger than FLTK though, but both include vendored
> code and wxWidgets hosts code for every conceivable native
> GUI backend.

Probably it's much better choice with the exception to size
and static self contain binaries. Anyhow it would be nice if
can reuse meta class descriptions created for wrappers to
other languages. I.e. such description exists for PyGTK and
Phil Krylow used it in xbGTK. BTW xbGTK looks realy nice:
   http://xbgtk.sourceforge.net/
It's small and compact. I haven't tried it in last years so
as soon I'll find some spare time I'll do that.

The layout of xbgtk (and xhgtk) is indeed nice. It's a little 

unclear which project is which and why there are two of 

them though :o

Downside with GTK is that it used to look quite foreign on 

both Windows and OS X. Once you got over this, it usually 

works quite fast and feels less heavy than QT. Lately on 

OS X there has been a great improvement by removing 

the X11 layer and moving to Cocoa/Quartz. The result is 

not fully native (except the menu), but not a bad one regardless.

I've tested with GIMP (which should be the ultimate demo 

app for GTK). Haven't checked it on Windows since very 

long time, so I don't know [Internet says it also became 

(more) native]. Another advantage is that GTK is closer 

to being a "standard" as wxW.

Hard to say how the GUI part compares to QT GUI 

parts in terms of "heaviness". It does "feels" much 

lighter, and doesn't appear to want become a complete 

operating system like QT. Since it uses C not C++, it 

should be much easier to build/compile/integrate.

Not sure how/if it runs on mobile. AFAIK it doesn't. If 

that's a important aspect.

For sure none of these is good for little projects, f.e. an 

installer, small utility or thin-client, due to their dependencies.

Found this too, with interesting information:

   https://www.wikivs.com/wiki/GTK_vs_Qt

QT may be native on OS X, but something must not 

be completely right with it, as all the QT apps feel 

_very_ bad compared to native apps. They look odd 

and they work odd. F.e. Microsoft's Remote Desktop 

Client. Another worrying trend in QT is they have 

apparently no set limit as to what to include and what 

not to, so they appear to include everything.

FWIW, the two required dynlibs for the wxW demo:

libwx_baseu-3.0.0.2.0.dylib               1869 kB

libwx_osx_cocoau_core-3.0.0.2.0.dylib     4760 kB

wxWidget is actively developed so here we can expect that
core functionality will work as expected. Anyhow if we plan
to create wrappers for C++ code then we will have to define
how to resolve problems which are common to C++ libraries
and exists also in QT.
In the upper level languages with automatic detaching of local
variables like Harbour people used to write code without setting
and removing explicit references. If we want to replicate it and
add support for inheritance from wrapped objects so users can
define new instance variables then we have to add code which
creates such bindings in hidden way and remove them when
necessary. Such general layer can be used by different projects.
I also agree that classes should be generated automatically
from metafiles. We can save a lot of time if we can reuse
already created descriptions. 

Agreed. It's required to scale well, to adapt well to 

different versions/builds/etc and to extract as much 

information as possible and do it without manual errors.

-Viktor

[elch]

Hello Viktor,

Downside with GTK is ..

 

just did a deeper inspektion of hwGUI from A.Kresin, also based for Linux on GTK v2:
it is impressive memory leaking, its footprint is growing and growing with each app action.

After 1000 times "@ .. SAY .. " in a loop i got something alike:
definitely lost: 39,394 bytes in 922 blocks
indirectly lost: 57,660 bytes in 1,107 blocks
possibly lost: 2,123,186 bytes in 5,346 blocks
still reachable: 741,936 bytes in 6,990 blocks

I even used a special suppression file for Valgrind:
https://github.com/dtrebbien/GNOME.supp
but even with it, it looks more bad as i expected.

I followed just only one 'definitely lost':
HWG_CREATEBROWSE()
-> set_event():
g_strdup( buf ) ! for g_signal_connect()

and my 'fun' about further searching stopped after reading:
https://developer.gnome.org/gobject/unstable/gobject-Signals.html#signal-memory-management

Also there seem a discontinuation for GTK: professionals seem to avoid GTK v3 ...

just my cents, best regards
Rolf

[JoséQuintas]

I do not know if this library can be a option:

http://webserver2.tecgraf.puc-rio.br/iup/

José M. C. Quintas

[Massimo Belgrano]

Nice discussion on facebook group of harbour after link to this discussion

[hmpaquito]

Demonstrates not know that speaker about harbour as synonymous with DOS / Windows. Here a way to make programs for the web, based on harbour: https://bitbucket.org/fivetech/fiveweb/wiki/Home

-

Demuestra no conocer harbour, quien  habla de harbour como sinonimo de dos / windows. Aquí una forma de hacer programas para la web, basado en harbour: https://bitbucket.org/fivetech/fiveweb/wiki/Home

[Francesco Perillo]

It just confirms that Harbour is a niche language and that everyone is carving his own niche of the niche....

It just confirms that Harbour is so powerfull that it can enable developers to different programming styles (procedural, oop), different DB, different GUI (text mode, win32, cocoa, Qt, X, web, android...).

For GUI there are a lot of choices: for win32 we have HMG, Minigui extended, "pure" Qt, Marinas, Hwgui, Fivewin. There are also many other abandoned, or proof of concept projects.

Should Harbour have an official GUI library?

[Ash]

Hello Francesco,
 

Should Harbour have an official GUI library?

Yes, at least for those @ commands provided by Clipper 5.3, fueling the idea of Harbour Spring.

One could write good looking GUI business applications using those commands.

Regards.
Ash

 

[Fernando Yurisich]

Please, don't forget OOHG for win32.

Regards

Fernando

Q.P.M. is the continuation of Q.A.C. project manager for (x)Harbour and OOHG/Minigui based projects.

Visit us at https://sourceforge.net/p/qpm and join the user list.

For OOHG samples and documents, visit http://oohg.wikia.com/wiki/Object_Oriented_Harbour_GUI_Wiki

Please support me with a donation via PayPal.

[Pete]

Τη Τετάρτη, 9 Μαρτίου 2016 - 6:31:24 μ.μ. UTC+2, ο χρήστης fperillo έγραψε:

Should Harbour have an official GUI library?

after the nightmarish existential question: "to qt or not to qt"[*]
that's a refreshing query, after all. 8-)

_________________________________________________________
[*]too bad Qt had not been invented those medieval times.
would perfectly help poor Hamlet to reconsider the futility of life
as seen from a software point of view.