HMGforum.com

2 weeks without a new build .... that´s hard.

Due to some changes in hbqt some files must be changed in hmg too.

mrduck wrote:Due to some changes in hbqt some files must be changed in hmg too.

HBQT is under revision and many changes are being done.

I'm waiting that this changes be completed to update the binaries.

The new binaries will require changes in most of HMG sources too.

The new binaries will require changes in most of HMG sources too.

However, on the development side, HMG is doing great.

Roberto Lopez wrote:

mrduck wrote:Due to some changes in hbqt some files must be changed in hmg too.

HBQT is under revision and many changes are being done.

I'm waiting that this changes be completed to update the binaries.

The new binaries will require changes in most of HMG sources too.

Like the commit just done...

almost all (not all!) :from() must be removed since methods now returns objects.

parameters passed in callback functions (codeblocks used in connect) must still convert parameters with :from()

mrduck wrote: Like the commit just done...

almost all (not all!) :from() must be removed since methods now returns objects.

parameters passed in callback functions (codeblocks used in connect) must still convert parameters with :from()

Before update binaries and start the changes we must be fully sure about what things must be changed to keep HMG working.

We must create a list with all the rules to apply.

Also we can have another sub-directory for the newHBQT source codes. Once the existing prg file is converted it can be copied to the new directory. When all the old source codes are changed, we can replace the old directory with the new prg files.

rathinagiri wrote:Also we can have another sub-directory for the newHBQT source codes. Once the existing prg file is converted it can be copied to the new directory. When all the old source codes are changed, we can replace the old directory with the new prg files.

Ok.

Perhaps, the best way to go is to create a binary distribution for developers only to work on conversion.

When it be finished, we could do a standard release with the new binaries and updates sources.

Anyway, I guess that we should wait until all the main changes be completed.

Roberto,
I think that "standard"/"end-user" developers should continue using the harbour compiler provided in your package.

The "hmg-core" developers should instead be requested to install the nightly build and set a couple of environment variables... they are requested to checkout/update/commit to svn so they already have something dofferent.

I have now two harbour directory, one is at level of the one you bundled since I have a small program I'm developing with hmg for my wife, and another harbour directory were I'm developing some features for hbqt itself.

PS: which forum area should I post a request for help to write a printing procedure for hmg4 ?

mrduck wrote:Roberto,
The "hmg-core" developers should instead be requested to install the nightly build and set a couple of environment variables... they are requested to checkout/update/commit to svn so they already have something dofferent.

I do not agree with this.

At first, it is an unnecessary complication.

Secondly, working with source modifications using the binaries that will be officially distributed later, will assure that all things will work for end users, the same as they work for us (the library developers).

mrduck wrote: PS: which forum area should I post a request for help to write a printing procedure for hmg4 ?

Since it is referred to HMG 4 code you should do here, but, as I've warned to other users, most things in HMG.4 are yet under development and are subject to changes that could alter their behavior, so, perhaps is to early yet to create true applications with it.