HMG.4 Project Status

Moderator: Rathinagiri

User avatar
Roberto Lopez
HMG Founder
Posts: 3980
Joined: Wed Jul 30, 2008 6:43 pm
Has thanked: 27 times
Been thanked: 168 times

HMG.4 Project Status

Post by Roberto Lopez » Sat Nov 12, 2011 5:17 pm

Hi All,

I'm planning a project that I will start coding in a couple of weeks.

I want to use HMG.4, but I'm not certain about the current project status.

So, my question is which is the status of the project in these aspects:

- Stability / Reliability
- Completeness
- HMG 2/3 general compatibility
- .fmg level compatibility

The last item is specially important to me, because I always use IDE for my projects. If I start using HMG.4 for real, I must to be sure that, at least, I'll be able to use the IDE 3.x for form editing.

Design and maintain forms 'by hand' is unacceptably time-consuming for medium/big size projects.

TIA.
Regards/Saludos,

Roberto


(Veritas Filia Temporis)

mrduck
Posts: 497
Joined: Fri Sep 10, 2010 5:22 pm

Post by mrduck » Sun Nov 13, 2011 12:37 am

Hi Roberto,

Roberto Lopez wrote: I'm planning a project that I will start coding in a couple of weeks.

I want to use HMG.4, but I'm not certain about the current project status.
Good !
So, my question is which is the status of the project in these aspects:

- Stability / Reliability
- Completeness
- HMG 2/3 general compatibility
- .fmg level compatibility
.fmg level compatibility
I will start from the last item.
I implemented some code for .fmg compatibility. There are several issues: in .fmg code all parameters all listed, also parameters that have NIL values. This needs that each parameter must be translated in hmg.ch. Testing some .fmg from Malek I discovered that some were missing and added to hmg3.ch but not always they have real code behind them.
I also implemented a hmg.ch trick to handle the loading of .fmg forms and later activation. This trick worked at the time (august) but I don't know if it needs to be updated.

HMG 2/3 general compatibility
I think we are at 70/80% compatibility. Well, it also depends on which widgets you use ! About data-binded components, Luigi commited today the combobox (well, I don't know if there are other data-binded components in hmg3....)
A lot of features may be added to simplify hmg4 core code and use Qt internal code. For example in grids, Qt can handle internally different colors for cell background colors so that we don't need to use callbacks.
Grids vs VGrids... in hmg3 the grid area was filled with cells, also when there were no rows to show. In hmg4 no rows to show -> no rows in the grid. It's not possible to doubleclick on an empty row just because there are no empty rows... you have to programmatically add empty rows to the grid...
So, there are incompatibilities...

Completeness
Well, as I said it depends on which widgets you use !

Stability / Reliability
I don't have full programs developed. I know that Maurizio uses hbide a lot. Ricci has his orchid program and I think he is using it a lot. So hbQt is quite ok. I just have problems when cut/paste is used, exiting the program sometimes gives error.
hmg4 Reliability is quite ok... Stability: what do you mean ? there may be changes in hmg4 core code so that you need to change your source code ? Yes, there may be ! We are not at alpha stage yet !



Ricci started porting his program and found some problems. When he found a problem/incompatibility at first he asked me and Luigi to have a look, but then he started to supply patches directly.
He also did some interesting stuff, like a graph that appears hovering on a label... and he intelligently solved the problem of missing rows in a grid adding empty records..

So I say:
1)
how many days do you have for delivering the program ?
how many days do you think you will need using hmg3 ?
If the difference is more than 40% you may start to use hmg4

2)
is it possible for you to work with svn harbour and update it when required ? This means update all the pc you use
is it ok for you if some incompatible commit to hmg4 makes your program stops working and you need to update its source code or mantain your hmg4 fork ?

3)
do you know that some command parameters are not implemented ? There is no code in the methods...
are you willing to eventually implement some parameters present in .fmg files that are not yet present in hmg.ch file ? Simply as placeholder to compile the code or if really used in the code, implemnt the method ?

4)
do you use PICTUREs on textboxes ? they are not fully implemented
do you depend on onLostFocus to act as a VALID and not leave the textbox ? it doesn't work corerctly yet


5)
do you use EDIT EXTENDED ? not ready yet


Roberto, as you may understand, hmg4 is in a usable state, it is growing and improving but it is not a 100% clone of hmg3 !

If you have some time in excess it can be a good occasion to check hmg4 completeness and reliability.

If you are on a tight schedule, use hmg3 (except if hbQt gives you some other advantage, like working on mac/linux)

The last item is specially important to me, because I always use IDE for my projects. If I start using HMG.4 for real, I must to be sure that, at least, I'll be able to use the IDE 3.x for form editing.

Design and maintain forms 'by hand' is unacceptably time-consuming for medium/big size projects.
It can be the occasion to port the IDE to hmg4. Which was the status of ide code present in svn ? I was trying to adapt it hmg4...

Obviously, I will be happy to support you in your hmg4 use (time permitting) and I also think that Luigi and Ricci will help.

Francesco

User avatar
Roberto Lopez
HMG Founder
Posts: 3980
Joined: Wed Jul 30, 2008 6:43 pm
Has thanked: 27 times
Been thanked: 168 times

Post by Roberto Lopez » Sun Nov 13, 2011 4:45 am

Thanks for your detailed answer.

I have a 'tight schedule' indeed, so, based on that and all other of your considerations, I'll must use HMG 3.

Regarding IDE, I've started it in HMG.4, as an experiment. Anyway, we achieved (with a lot of help from Rathi) some interesting functionality.

It does not compile in latest binaries, so I guess that requires some update.

IMHO, some interesting ideas and code is there and it could be used as a base for a new IDE.

Most of hard things (like control moving and resizing) were working for a lot of controls (generate and read source are the easier part).

It's not possible for me to participate as a developer in the project (at least, at this moment).

I hope that someone take the IDE. It is a very interesting and exciting challenge.

Thanks again for your answer.
Regards/Saludos,

Roberto


(Veritas Filia Temporis)

mrduck
Posts: 497
Joined: Fri Sep 10, 2010 5:22 pm

Post by mrduck » Sun Nov 13, 2011 8:50 am

Roberto Lopez wrote:Thanks for your detailed answer.
I wanted to be honest, because if the schedule is very strict it's always best to use a framework you know and trust :-)

Anyway, I will be available to help if you want to port the code to hmg4. If you want you can send to me part of the code to check for hmg4 compatibility.

I recently took a hmg3 code and it worked in hmg4 with these changes:
- define -DHMG3
- call hmg3(.T.) in main code
- call hbqt_errorsys() (we spoke about this, it should be moved into the library...)
- @ x,y GRID syntax is not present in hmg.ch so I switched to oop syntax, but I could add the yntax to hmg...
- inside a TOOLBAR definition, you must use TOOLBUTTON and not BUTTON
- using a background color for the main window is not very well supported, since Qt uses different palettes for in focusa/out of focus/disabled status.
- removed NOMAXIMIZE and a couple of others parameters to window definition otherwise Qt doesn't show widgets....
Regarding IDE, I've started it in HMG.4, as an experiment. Anyway, we achieved (with a lot of help from Rathi) some interesting functionality.
I did some changes, to compile and "basic" run. I will commit in the next days so that we can continue the work.

Francesco

User avatar
Roberto Lopez
HMG Founder
Posts: 3980
Joined: Wed Jul 30, 2008 6:43 pm
Has thanked: 27 times
Been thanked: 168 times

Post by Roberto Lopez » Mon Nov 14, 2011 1:58 am

mrduck wrote: I wanted to be honest, because if the schedule is very strict it's always best to use a framework you know and trust :-)
Oh Yeah! ;)
mrduck wrote: Anyway, I will be available to help if you want to port the code to hmg4. If you want you can send to me part of the code to check for hmg4 compatibility.
I'll use HMG.3 this time, but I'm sure that I'll use HMG.4 for the next.
mrduck wrote: I did some changes, to compile and "basic" run. I will commit in the next days so that we can continue the work.
I'm glad to know that.
Regards/Saludos,

Roberto


(Veritas Filia Temporis)

Ricci
Posts: 255
Joined: Thu Nov 19, 2009 2:23 pm

Post by Ricci » Mon Nov 14, 2011 12:33 pm

Roberto Lopez wrote:...
So, my question is which is the status of the project in these aspects:
- Completeness
- HMG 2/3 general compatibility
...
Roberto,

I think ther question is wrong. ;)

If you want to use HMG4 the same way as HMG3 than you don´t need it. Platform independence sounds good but ... I just want to see a bigger program running on Win, Mac and Linux using the same code.

HMG3 is monolitic, controls can only be used the way they are defined in the HMG3 core. If someone want to enhance them, he has to change the core and build his own fork. I think that happens sometimes in the past.

HMG4 is OOP based and "open" for enhancements of every control without touching the core but using inheritance.
This conflicts directly with the old preprocessor commands like @ 10,10 LABEL oLabelName VALUE "xxx" WIDTH 100 HEIGHT 20 FONT "ARIAL" SIZE 09.

When using HMG3 you always have to think "What is possible?", with HMG4 you can think "What do I want to do?"

Ricci

mrduck
Posts: 497
Joined: Fri Sep 10, 2010 5:22 pm

Post by mrduck » Mon Nov 14, 2011 1:05 pm

Ricci wrote: HMG4 is OOP based and "open" for enhancements of every control without touching the core but using inheritance.


When using HMG3 you always have to think "What is possible?", with HMG4 you can think "What do I want to do?"

Ricci, I will print a poster and put it on the wall in front of my desk !

User avatar
Roberto Lopez
HMG Founder
Posts: 3980
Joined: Wed Jul 30, 2008 6:43 pm
Has thanked: 27 times
Been thanked: 168 times

Post by Roberto Lopez » Tue Nov 15, 2011 2:30 pm

Ricci wrote:
Roberto Lopez wrote:...
So, my question is which is the status of the project in these aspects:
- Completeness
- HMG 2/3 general compatibility
...
Roberto,

I think ther question is wrong. ;)
I don't agree at all :)

Ricci wrote: If you want to use HMG4 the same way as HMG3 than you don´t need it. Platform independence sounds good but ... I just want to see a bigger program running on Win, Mac and Linux using the same code.
You've misunderstood me :)

I want to use HMG4 to have HMG3 features PLUS HMG4 new things :)

Besides that, as I've already explained, my question, is mainly driven, to know about the possibilities of use HMG3 IDE form editor in HMG4 project (since HMG4 IDE is not ready).
Ricci wrote: HMG3 is monolitic, controls can only be used the way they are defined in the HMG3 core. If someone want to enhance them, he has to change the core and build his own fork. I think that happens sometimes in the past.
HMG3 'monolitic' design, can be perceived as a limitation by some people, but, it provides stability and a consistent programming style for all controls. Moreover, MOST of WIN32 API functionality is currently supported (I've only dropped things that could be redundant or useless for HMG3 intended use).

Despite that, I've created an user control interface that allows to expand HMG capabilities without compromising the library core and some interesting things has been created using it.
Ricci wrote: HMG4 is OOP based and "open" for enhancements of every control without touching the core but using inheritance.
Perhaps you don't remember that, but I've created HMG.4 and published in SVN, making it available to any volunteer that wanted work on it, with exactly such premises :)

Enhancements from HMG3 were present from the beginning, even on my own code (ie: TAB control among others).
Ricci wrote: This conflicts directly with the old preprocessor commands like @ 10,10 LABEL oLabelName VALUE "xxx" WIDTH 100 HEIGHT 20 FONT "ARIAL" SIZE 09.
Well... I've talked about this many times...

IMHO, preprocessor directives are not 'old'...

Such preprocessor directives gives a 'soul' to HMG, puts it in the xBase family, and makes it EASY TO USE.

That 'easiness', made HMG family of Harbour distributions, the most popular way to use Harbour compiler.

If the thinking about HMG.4, is that xBase preprocessor directives are 'old' and an impediment for enhance the library, prevails, it will become only 'another OOP GUI library for Harbour', most of which have failed because they are difficult to use for most of xBase users.

Specially, the VFP/VB way of using GUI objects visually created has been the base for HMG family success.

I've been reviewed carefully new HMG.4 code and, as Francesco and Luigi noted me, there is a lot work on compatibility area. This is good and a guarantee for HMG.4 success.

So, we are not talking about the 'old' and the 'new'.

We are talking about the xBase power and easiness. Without that, there is not xBase, just standard OOP.
Ricci wrote: When using HMG3 you always have to think "What is possible?", with HMG4 you can think "What do I want to do?"
A nice statement, but (as I've explained) not true about HMG3 :)

Of course, I'm an just an user right now, and this is just an user opinion...

Like my signature states... the time will be bring us the truth...
Regards/Saludos,

Roberto


(Veritas Filia Temporis)

Ricci
Posts: 255
Joined: Thu Nov 19, 2009 2:23 pm

Post by Ricci » Tue Nov 15, 2011 3:32 pm

Roberto Lopez wrote: IMHO, preprocessor directives are not 'old'...
Such preprocessor directives gives a 'soul' to HMG, puts it in the xBase family, and makes it EASY TO USE.
That 'easiness', made HMG family of Harbour distributions, the most popular way to use Harbour compiler.
Please don´t misunderstand me ... I like and use preprocessor directives in HMG4 too.
With old directives I mean these complex types like "DEFINE IMAGE oImage AT 10,10 WIDTH 100 HEIGHT 100 PICTURE cPicture". Whatever you do, this one is only valid for the predefined image object. If I overload the image class to a new class called MYIMAGE the preprocessor directive won´t work anymore and I have to copy and extend the whole translation block. And I take a look if it is still valid at every update of the HMG.CH.

The newer HMG4 directives are working different, you would define your image with

Code: Select all

DEFINE IMAGE oImage
	Row				 10
	Col				 10
	Width			 100
	Height			100
	PICTURE  		cPicture
end IMAGE
Still easy to read but ... not one translate command for the preprocessor but 7, each one independent from the others.
If I overload the Image class now to a new class like MYIMAGE I would define it with:

Code: Select all

DEFINE MYIMAGE oImage
	Row				 10
	Col				 10
	Width			 100
	Height			100
	PICTURE  		cPicture
	MyMethod		"abcde"
end IMAGE
Now I only need new translation commands for the first and 7th line. Less work and whatever will changed in the future in the HMG.CH and the IMAGE class ... not my problem.

User avatar
Roberto Lopez
HMG Founder
Posts: 3980
Joined: Wed Jul 30, 2008 6:43 pm
Has thanked: 27 times
Been thanked: 168 times

Post by Roberto Lopez » Wed Nov 16, 2011 11:58 am

Ricci wrote:
Please don´t misunderstand me ... I like and use preprocessor directives in HMG4 too.
With old directives I mean these complex types like "DEFINE IMAGE oImage AT 10,10 WIDTH 100 HEIGHT 100 PICTURE cPicture". Whatever you do, this one is only valid for the predefined image object. If I overload the image class to a new class called MYIMAGE the preprocessor directive won´t work anymore and I have to copy and extend the whole translation block. And I take a look if it is still valid at every update of the HMG.CH.
You have a point here, but, IMHO, only a minimal additional work is required. Not a big problem.
Ricci wrote: The newer HMG4 directives are working different, you would define your image with

Code: Select all

DEFINE IMAGE oImage
	Row				 10
	Col				 10
	Width			 100
	Height			100
	PICTURE  		cPicture
end IMAGE
Still easy to read but ... not one translate command for the preprocessor but 7, each one independent from the others.
The 'newer' HMG.4 directives, are not new :)

We call it 'alternate syntax'.

They exist from MiniGUI 1.x library era (about 8 years ago) and are based on a Rathi idea that I helped to implement.

It is my preferred way of coding HMG and the way I've selected for the IDE's form designer to process .fmg files.

So... I knew about that, I know how they work and I've added to HMG.4 code :)
Ricci wrote: If I overload the Image class now to a new class like MYIMAGE I would define it with:

Code: Select all

DEFINE MYIMAGE oImage
	Row				 10
	Col				 10
	Width			 100
	Height			100
	PICTURE  		cPicture
	MyMethod		"abcde"
end IMAGE
Now I only need new translation commands for the first and 7th line. Less work and whatever will changed in the future in the HMG.CH and the IMAGE class ... not my problem.
I agree on this.

A similar thing occurs in HMG 1.x,2.x and 3.x, where the property directives are used by different controls. Not OOP, but a similar advantage.
Regards/Saludos,

Roberto


(Veritas Filia Temporis)

Post Reply