HMGforum.com

It's not good idea to start HMG4 as new project, I think.
It will be hard to decide to move to HMG4 many of users.
I have some big projects and it's easier to work on them, when they are written in the same HMG.

But, it's only my honest opinion...

PS.
I'm ending some portion of my billing system. When I establish current version, I'll try to move it it to HMG4.
It will be very good material for testing..

Best regards, Marek

mrduck wrote: I'm for HMG/Qt but the / can be a problem. HMG-Qt ? If you agree, I will open a new project in sourceforge.

With Luigi we are already talking about changes in syntax allowed. It will break hmg.3 source code compatibility but with trivial changes, and it preserve "the spirit" of hmg.3. As I said, trivial changes for easier hmg.3 porting.
Other ideas are really more drastic: transform HMG.4 in a full OOP library that should programmed only in OOP (with just a thin dbase sysntax layer). It's my original idea, of a small and quick "business library" over hbQt that makes easier to write code... hbQt needs such a library, you ae going to write one yourself if you program is longer than 100 lines ! And infact I know a programmer that didn't know about HMG.4 and started to write his own, closed source, library.

Francesco

Well... at first I'm expressing my opinion as an user, since I'm not an active developer at this time.

The decisions *must* be done by the project administrator and developers that are currently working in the project.

Having clarified that, I'll answer your questions.

HMG had always been isolated from underlying GUI API logic. That is the reason because in HMG things like id's, handles, font objects and other WIN32 specific things are not exposed to the user.

Such philosophy, had been extremely successful.

In fact, most of the Harbour GUI applications around the world, are developed using some HMG-family GUI library (HMG, MiniGUI-Extended, or OOHG).

Various other Harbour GUI libraries whose code style was heavily based on WIN32 internals, ARE GONE. That happened because a simple reason: They are difficult to understand if you are not a Windows C programmer/WIN32 programmer.

Besides that a strong preprocessor command layer made the things easier.

In HMG.4, things like layouts concept (QT related) had been exposed to the user (I'm talking about that).

I've fully read this thread and reviewed the code before posting and my opinions are based on that and when I've talked about 'lack of interest' about backwards compatibility, I've was not talking about you specifically.

Regarding HMG.4 speed, it is clearly perceived as slow, since the application takes a lot of time to load (it is no required any test to verify that). Of course, that not implies that the application runs slower, but the bad impression created by load-time, is difficult to ignore. Anyway, I'm optimistic about that, I guess that this issue could be solved in some way.

Finally and to be more clear, I'm not complaining. By the contrary, is good to see that the project continued without me.

I'm simply pointing that a new name, could better reflect the project 'as-is' now.

If you decide to do it, there is no need to create a new project at SourceForge at all. You simply must rename the library here, in the sources and in the documentation. That's all.

mol wrote:It's not good idea to start HMG4 as new project, I think.
It will be hard to decide to move to HMG4 many of users.
I have some big projects and it's easier to work on them, when they are written in the same HMG.

But, it's only my honest opinion...

PS.
I'm ending some portion of my billing system. When I establish current version, I'll try to move it it to HMG4.
It will be very good material for testing..

Best regards, Marek

perhaps, I've not expressed my opinion clearly. I'm not talking about restart the project. I'm talking about a simple name change that reflects better the project 'as-is' now.

rathinagiri wrote:That's really a FANTASTIC idea Roberto.

Thanks.

I've was sure that you could support the idea.

Regarding resuming HMG.3 development, there is a lot of exciting future enhancements regarding the 'Metro' interface support for Windows 8.

Supporting 'Metro' will lead HMG to the tablet world.

Roberto Lopez wrote:

rathinagiri wrote:That's really a FANTASTIC idea Roberto.

Thanks.

I've was sure that you could support the idea.

So, if you agree, I guess that HMG/QT is good. Please go ahead.

Roberto Lopez wrote: Regarding resuming HMG.3 development, there is a lot of exciting future enhancements regarding the 'Metro' interface support for Windows 8.

Supporting 'Metro' will lead HMG to the tablet world.

MS had made a great move.

The decision of using the same Windows version for desktop and tablets with two interfaces (Win7 like and iPad like) switchable by the user as it desires at any time, will make that, we can have running all of our HMG applications on tablets the next year.

If we manage to add 'Metro' interface support to HMG 3, our applications will have a great future.

Roberto,
thank you for your reply.

Probably we don't understand each other. If you remember when I arrived here I wrote some messages saying that achieving hmg.3 compatibility could be a real pain. But then I embraced the idea, also to try to gather attention from other developers. Attention that didn't came as expected.

A lot of smart programmers here are what I call "end-user" and like you said the philosophy of HMG.3 is to hide all the win32 complexity to end-user. The library is a black box and they use it without knowing what's inside.

So my idea was to ask these programmer to compile their software adding just two things: hmg3(.T.) as first command, and -DHMG3 before including hmg.ch...
I asked, almost nobody answered. Just Ricci is porting the application to HMG4 fully OOP.

We are not "exposing" anything. Everything is encapsulated. We are expanding, yes, we are expanding, since Qt gives us some really powerfull stuff. Layout is one of this stuff. It's fully encapsulated in dBase style commands and IT IS WONDERFULL TO USE.

I imagine that hmg.3 end-users studied at least what a GRID behaves, how to change background color, or associate a codeblock to a button click.

All this remains. We are adding some features, you are not forced to use.

Various other Harbour GUI libraries whose code style was heavily based on WIN32 internals, ARE GONE. That happened because a simple reason: They are difficult to understand if you are not a Windows C programmer/WIN32 programmer.

Besides that a strong preprocessor command layer made the things easier.

In HMG.4, things like layouts concept (QT related) had been exposed to the user (I'm talking about that).

Look on page 4 of this thread at the picture of interest(int) calculator. No layouts were used, no source code changes applied... (just one since variables had the same conflicting name)

[quote
I've fully read this thread and reviewed the code before posting and my opinions are based on that and when I've talked about 'lack of interest' about backwards compatibility, I've was not talking about you specifically.
[/quote]

There is no interesting in "backwards compatibility", and also for "forward compatibility"... !

Regarding HMG.4 speed, it is clearly perceived as slow, since the application takes a lot of time to load (it is no required any test to verify that). Of course, that not implies that the application runs slower, but the bad impression created by load-time, is difficult to ignore. Anyway, I'm optimistic about that, I guess that this issue could be solved in some way.

Unfortunately I think this can't be solved, Qt is "heavy", it's a full windowing engine... probably with static linking, but it's not easy to achieve (you must recompile Qt yourself)

Finally and to be more clear, I'm not complaining. By the contrary, is good to see that the project continued without me.

I'm simply pointing that a new name, could better reflect the project 'as-is' now.

If you decide to do it, there is no need to create a new project at SourceForge at all. You simply must rename the library here, in the sources and in the documentation. That's all.

I don't know if it is possible to rename a project on sourceforge, and I'm not the project manager of HMG.4, perhaps you should do that.


Anyway, changing project goal is okay for me. Mol that has a quite big system completing in HMG.3 - I used his sources to start porting tests, just the polish variables and form names stopped me to use them further - and rewriting it completely in HMG.4 from scratch can be time-consuming... I believe he will never ever try....

So, Mol is interested to keep HMG.3 compatibility, MauriCio has code in production (with OOP afaik)... MauriZio is starting to port his library to HMG.4 (OOP syntax). Ricci is porting one of his projects
To all others, it seems they don't care.

So, Roberto, HMG is your "trademark". It's up to you the final decision. We may discuss here or in private if you want, and I hope that everybody partecipates, but the decision is your, after all.
If only 5 persons are interested in the project and 4 of them use OOP style.... I will help Mol to convert his code

Obviously, since this is the spirit of open-source, I reserve the right to fork if I don't agree with final decision, of course without using HMG name.

Francesco

I had a thought that something basic is getting changed in HMG4 and I shouldn't or couldn't interfere since I am not a OOP guy basically. And decided to get in once it is over.

But, recently before publishing the latest version, I tried HMG4 as is now and I found that HMG3 compatibility is 95%+ achievable. We can write a small documentation as to list out what are the things are not compatible and how to change them into HMG4 to work.

Now, I have started porting my projects one by one and getting success by minimum alterations. Thanks to HMG4, I studied something about OOP and saw it is very much suitable for my recent 'Costing' project.

However, Roberto's idea of changing the project name and starting with version 1.0 is nice because it embraces different architecture altogether.

Hi, I will put my $ 0.02

Roberto Lopez wrote:If we manage to add 'Metro' interface support to HMG 3, our applications will have a great future.

This sounds that we will have 2 flavors of HMG here, HMG3 and HMG4 ( or whatever it will be, or not, renamed ).
And energy divided in 2 fronts.
In my opinion HMG would be stronger in the future with only 1 flavor...
Won't QT be 'Metro' compatible ?

Ciao Roberto.

I am surprised to read some of your sentences after a long silence.
Maybe my English is not so good, so if I misunderstood, I beg your pardon.

I started using HMG long time ago, back when was used the bcc compiler, and I followed you because I loved the idea of using MinGW and then open the door to other operating systems. Then when you started the HMG4 project, I still believe in you and I wanted to participate as I know and able.

Looking at the current code, I've noted that some of the original project goals had changed.

Why write this? Perhaps because they have been introduced "commands" which did not exist in HMG3?
The concept of layout is identical to the concept of HTML DIV. If it is true that Windows is moving in the direction of a browser, perhaps it is good to implement these objects that give us those opportunities.

HMG had always been isolated from underlying GUI API logic.
That is the reason because in HMG things like id's, handles, font objects and other WIN32 specific things are not exposed to the user.
Such philosophy, had been extremely successful.

I do not understand. Here's an example: FONT. it is a command-style "XBase" that uses a logical API.
Using C code or a function QT, what's the difference? The user will always use the FONT command.

In fact, most of the Harbour GUI applications around the world, are developed using some HMG-family GUI library (HMG, MiniGUI-Extended, or OOHG).
Various other Harbour GUI libraries whose code style was heavily based on WIN32 internals, ARE GONE.
That happened because a simple reason: They are difficult to understand if you are not a Windows C programmer/WIN32 programmer.

I am not a guru, but then why did you choose QT, for the development of HMG4? I remember a thread where you faced the pros and cons. And the choice of QT, if I remember correctly, it was just to get rid by internals WIN32. Also, avoid writing code C.

Besides that a strong preprocessor command layer made the things easier.

True, but not always, and as for the C, not all are so good to coding preprocessor commands

Considering that, and the lack of interest (or available time) to achieve a higher degree of backwards compatibility, I think that the project name should change.

This I can not accept: I'm sorry.
I, Mauricio, MrDuck, Rathinagiri and others have always tried to get the best possible compatibility and we have spent a lot of time and energy. And many, many times we could take another way and loose HMG3 compatibility.
Anyway often we came across QT needs to be respected as well as cases designed specifically for the philosophy of HMG3.
Here's an example: many commands have the option NAME, but not all. Why? Perhaps because HMG3 was born this way.
window does not have the NAME, statusbar does not have the NAME, etc.. Why? BecauseHMG3 was born this way.

HMG3 compatibility: no HMG3 users have contributed time to test (not to develop!) HMG4, or to give us suggestions.

And, of course, the first version should be numbered 1.0, to make it clear, that it is a different thing.
So, HMG 3.x development could be resumed.

Please, Roberto, tell me the truth of this change.
I think because you have seen other things (windows 8 metro?) now you want to submit your new idea, leaving - in fact - HMG4. Do you want HMG4 name back?

You are the owner of HMG.
Please do not use these arguments to motivate the change.

Best regards

mrduck, l3whmg,

I'm answering to both.

Since your reactions, I've obviously not expressed clearly my thinking.

Again, I'm just posting an opinion as an user, that is, what I am right now.

My only intention proposing the name change, was to help to HMG.4.

My thinking was that 'freeing' the project of 100% backwards compatibility goal, it could reach a beta stage and a final first release soon.

So, giving a project a new name, could help on this.

Again, I'm surprised and glad to found all the work done since I've left the project.

And to l3whmg: I've have not other (hidden) intentions. I'm not such kind of person. I'm sorry that you think so.

Regarding a possible HMG 3.x continuation, please consider that ideas and statements are made in a time-context. I mean, that if new facts occurred, new ideas and decisions according the new facts must emerge. It is a good thing. I'm proud about to adapt my ideas to the context changes.

Two important new facts had emerged since HMG.4 inception:

1. Many Windows HMG users found QT slow and big and prefer to stick to Win32 version.

2. Our Win32 HMG applications, will run on tablets the next year via Windows 8.

Analyzing this new facts, appears to be clear that the best solution in this new scenario, is to have two HMGs and that the users select the one more convenient for them.

Windows-only users could continue using Win32 based HMG (that will need to be maintained and enhanced) and users interested in other platforms (or HMG.4 new features) will use QT version.

Again, I'm posting this idea as an user, with the intention to help and motivated by the subject of this thread. Was not my intention to hurt anybody. If so, I apologize.

I've just expressed an idea. That's all.