REALLY IMPORTANT: is anyone interested in HMG4 ?

[mrduck]

Won't QT be 'Metro' compatible ?

It is already.... well, it's a bit hackish... but Qt is part of Nokia (but there is a distribuited controlling infrastructure) and Nokia committed heavily on Microsoft... so there may be 2 possibilities: Qt banned from windows 8, Qt support of windows 8...

But anyway, Qt is in the open now, and anybody can create ports of it on different platforms... sometimes is more easy, sometimes is really difficult. Anyway, one "port" to metro is already possible...
https://projects.developer.nokia.com/qt ... ?version=6

It's not a real port, it is not fully integrated into metro...

Roberto, if you have time please read the article, it has some interesting infos I didn't know.

[mrduck]

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.

Happy to read this message Perhaps is not 95% comaptibility, probably a bit less...

Please report the changes you are doing, there may be a solution to avoid them...

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.

Really good

[mrduck]

mrduck, l3whmg,

I'm answering to both.

Thank you Roberto for this message. There may have been some misunderstanding and probably you were away from the project development for too much time.

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.

I think name is not important: HMG4, HMG/Qt, HMG-ng, mickie mouse, donald duck, spiderman... call it any way we want...

I prefer to have HMG in the name since it may be easily recognizable...

A question, since I don't know HMG (and branches) history: there was in these histories versions that broke 100% compatibility with the past ? Would it be a problem if this happens this time, if well documented ?
I think no. It was easy to download an installer and have everything ready in the hmg directory tree... but this time is better to have "end-user" programmers use 0,01% of their brain power to learn a couple of things: setting a environment variable, setup a couple of config files (if there is the need), easily build hmg themselves easily....
I think it is not too much...

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.

Hmg.3 must continue... and now that hmg.4 showed how well the OOP way works, probably a rewrite of HMG.3....

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.

Point 1: please transform "many" in a number.... yes, probaly it is slower to load than win32 software... but how many times are you loading your accounting package ? probably no more than twice per day... and once loaded it seems to be quicker than other libraries

Point 2: win32 + windows 8 + metro + tablets I tried to look for clear infos on how to program metro and I didn't find them... please read the link I posted 2 message ago...
tablets should be based on ARM processors, win32 is now winRT, everything should be double checked... harbour programs seems to be working right under i386 windows 8 "win32 side", but I don't know under Metro... and neither with ARM cpu... if you have more info please give them.

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.

I never thought that HMG.4 would supercede HMG.3... My idea was of parallel development... the only thing is that calling HMG.4 forces HMG3 to stay HMG3.x.y.z....

So moving HMG.4 to HMG/Qt we can free the name for the next version of win32/HMG

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.

Ok. I agree. I don't know if it is possible to change project name on sourceforge, or if we need to create a new one and import the old repository... I will check tomorrow.

Correctly you said that decisions are related to their time frame. Now it seems good to do this and we will do. Time will tell us if it was a good decision or not, and we may change it again in the future.

Idea from other people ?

[Roberto Lopez]

Thank you Roberto for this message. There may have been some misunderstanding and probably you were away from the project development for too much time.

I think name is not important: HMG4, HMG/Qt, HMG-ng, mickie mouse, donald duck, spiderman... call it any way we want...

I prefer to have HMG in the name since it may be easily recognizable...

The name is important in a minor aspect. Simply to point to the users that it is a somewhat different thing and not simply a new version.

A question, since I don't know HMG (and branches) history: there was in these histories versions that broke 100% compatibility with the past ? Would it be a problem if this happens this time, if well documented ?

My intention was always that every new version allowed compilation of user applications with no modifications. AFAIK, it was always achieved.

The exceptions were related to Harbour add-on libraries that were dropped or changed impacting certain HMG commands or functions.

I think no. It was easy to download an installer and have everything ready in the hmg directory tree... but this time is better to have "end-user" programmers use 0,01% of their brain power to learn a couple of things: setting a environment variable, setup a couple of config files (if there is the need), easily build hmg themselves easily....
I think it is not too much...

Well... we simply think different about this. I'm a zero-configuration fan

I've was an user too. I've was using and installing nice programming tools that not required any configuration for about two decades (yes... I'm quite old too .

IMHO, asking users to configure HMG prior to use is simply an involution.

Hmg.3 must continue... and now that hmg.4 showed how well the OOP way works, probably a rewrite of HMG.3....

I'll not answer to this

Point 1: please transform "many" in a number.... yes, probaly it is slower to load than win32 software... but how many times are you loading your accounting package ? probably no more than twice per day... and once loaded it seems to be quicker than other libraries

I've was not talking about the 'truth' but the 'user perception'

Point 2: win32 + windows 8 + metro + tablets I tried to look for clear infos on how to program metro and I didn't find them... please read the link I posted 2 message ago...
tablets should be based on ARM processors, win32 is now winRT, everything should be double checked... harbour programs seems to be working right under i386 windows 8 "win32 side", but I don't know under Metro... and neither with ARM cpu... if you have more info please give them.

There is not so much info yet, but there is for sure that will be x86 tablets running Windows 8 and that all our HMG Win32 and QT apps will run on it.

I never thought that HMG.4 would supercede HMG.3... My idea was of parallel development... the only thing is that calling HMG.4 forces HMG3 to stay HMG3.x.y.z....

Or changing its name

So moving HMG.4 to HMG/Qt we can free the name for the next version of win32/HMG

If HMG Win32 is to be enhanced and new versions arises, numbering could be eventually a problem.

To be more clear, I'll explain in other words: When I've started HMG.4 my thinking was that should be not more development based on Win32 version to work only on QT version, but the facts shown that both versions should co-exist.

Keeping current names and numbers could create a lot of confusion.

Ok. I agree. I don't know if it is possible to change project name on sourceforge, or if we need to create a new one and import the old repository... I will check tomorrow.

I don't understand you on this.

The SourceForge project name is currently HMG. It can hold all HMG flavors. I can't see the need to create a new one.

Correctly you said that decisions are related to their time frame. Now it seems good to do this and we will do. Time will tell us if it was a good decision or not, and we may change it again in the future.

You (in fact all of you) should make the change, only if you believe that it is the correct thing to do.

As I've said (and saying again) I'm talking as a simple user, since I'm not a developer right now. So, if you do not like my idea, you can drop it. No problem.

My intention was to help to get an HMG.4 first final release quick.

[mrduck]

Ok. I agree. I don't know if it is possible to change project name on sourceforge, or if we need to create a new one and import the old repository... I will check tomorrow.

I don't understand you on this.

The SourceForge project name is currently HMG. It can hold all HMG flavors. I can't see the need to create a new one.

Ok, so we may change all internal references from HMG.4 to HMG/Qt... but the svn repository is one and you won't be able to use it for HMG.3 development line... well, actually you can using svn branches and the like but I suggest to keep them separate. If you think instead that HMG.3 development will keep the actual release method, you or Rathinagiri creating an exe from time to time, then there is no necessity to change name.


So, Luigi, Rathinagiri, Ricci, concentra, Maurizio, do you agree on changing the project name to HMG/Qt ?

[Rathinagiri]

Yes. I do agree.

IMHO, '/' in the name is somewhat... How about HMG:Qt (Showing it as OOP)? or QHMG or any name as you wish.

[l3whmg]

Hi friends.

About project name: I think "special" characters like ":" or "/" and so on can be a problem. I like QHMG.
Cheers

[esgici]

QHMG

Regards

--

Esgici

[mrduck]

Hi friends.

About project name: I think "special" characters like ":" or "/" and so on can be a problem. I like QHMG.
Cheers

Then QtHMG

[concentra]

So, Luigi, Rathinagiri, Ricci, concentra, Maurizio, do you agree on changing the project name to HMG/Qt ?

Hmg.Qt ?