[XForms] Pre-release xforms-1.2.5pre1

[Jens Thoms Toerring]

Hi everyone,

it's quite a bit of time since the last stable version but
I was rather busy with a number of other projects (as you all
know there comes a time when you have to make sure that you can
pay the next rent and also have some spare change for food;-) I
now have a new pre-release for the stable branch that hopefully
addresses all (or at least most of) the patches I received and
bugs reported from the last year - lots of thanks to everyone
involved!

You can download it from

http://download.savannah.gnu.org/releases/xforms/xforms-1.2.5pre1.tar.gz

There are also versions compressed with bzip2 and xz (the last one
resulting in the smallest file).

Since I am not 100% sure if I managed to address all problems I'd
like to ask you if your patches or the bugs you told me about
actually are included or fixed. And if there are some bugs I'm
not aware of yet please let me know!

Please note that this is a patch release for the stable version
only, the changes haven't been included in the UTF-8/True Type
development version yet - I hadn't enough time to deal with that
yet (and I'm not sure when I'll be able to get around to that).

Best regards, Jens
--
\ Jens Thoms Toerring ________ j...@toerring.de
\_______________________________ http://toerring.de

[Serge Bromow]

Hello fellow Xformser's, (That's a mouth full)

Well, I tested the latest release and so far so swimmingly.

The only additions I made were to the forms.h file as follows;

*extern void fli_set_form_icon_data(FL_FORM * form, char *data[]); ,*

required to declare set pixmap from file on iconify.

And for backwards compatibility I added;

*#define fl_set_form_icon_data(a, b) fli_set_form_icon_data(a, b)*

I'll remove the later once I locate all instances of the old naming
convention.

I understand why*'fli_set_form_icon_data*' is not declared in forms.h
since it is an internal routine but I would think others could benefit
from it. Perhaps it's time for this routine to come out of the closet?
lol...

Thanks Jens,

Serge

[Jens Thoms Toerring]

Hello Serge,

On Tue, Feb 23, 2016 at 07:32:08PM -0500, Serge Bromow wrote:
> Well, I tested the latest release and so far so swimmingly.

That's good to hear!

> The only additions I made were to the forms.h file as follows;
>
> *extern void fli_set_form_icon_data(FL_FORM * form, char *data[]); ,*
>
> required to declare set pixmap from file on iconify.
>
> And for backwards compatibility I added;
>
> *#define fl_set_form_icon_data(a, b) fli_set_form_icon_data(a, b)*
>
> I'll remove the later once I locate all instances of the old naming
> convention.
>
> I understand why*'fli_set_form_icon_data*' is not declared in
> forms.h since it is an internal routine but I would think others
> could benefit from it. Perhaps it's time for this routine to come
> out of the closet? lol...

Once upon a time (before I started messing things up;-) this
function was defined as fl_set_from_icon_data(). But there
were a lot of functions with names starting with 'fl_' and
declared in forms.h, which obviously were of no interest except
for internal use and which also weren't documented. Thus I
renamed all functions (or at least all I noticed) that were
not documented to names starting with 'fli_' and moved their
declarations from forms.h to flinternals.h (which is only used
when building the library). fl_set_form_icon_data() was one of
them.

But as it seems to be a useful function I'll put it back into
the stuff exported from the library and write some documenta-
tion for it. So it's coming back out of the closet;-)

[Michal Szymanski]

Hi,

I have found a strange configure problem on Fedora 22 (32bit).
The check for the Xpm library version apparently fails, saying

checking for X11/xpm.h... yes
checking xpm header version... ./configure: line 13418: fg: no job control
.

and then, in the summary:

== Version . of the Xpm library is a bit old.
If you experience strange crashes with xforms, try to upgrade
to at least version 4.7 (aka 3.4g).
If you have installed a newer version of the library, check whether
you have an old xpm.h header file in your include path.

I do have the latest libXpm version 3.5.11 and its "devel" companion.

regards, Michal.

--
Michal Szymanski (msz at astrouw dot edu dot pl)
Warsaw University Observatory, Warszawa, POLAND

[Jens Thoms Toerring]

Hi Michal,

On Sat, Mar 26, 2016 at 07:21:39PM +0100, Michal Szymanski wrote:
> I have found a strange configure problem on Fedora 22 (32bit).
> The check for the Xpm library version apparently fails, saying
>
> checking for X11/xpm.h... yes
> checking xpm header version... ./configure: line 13418: fg: no job control
> .

I'm rather puzzled where the "fg: no job control" bit is coming
from since there's no invocation of 'fg' anywhere in the
configure script (or at least I haven't found one). And all
I've got at line 13418 is

sed -e 's/^"%%%"\(.*\)"%%%"/\1/' -e 's/ //g'`

> and then, in the summary:
>
> == Version . of the Xpm library is a bit old.
> If you experience strange crashes with xforms, try to upgrade
> to at least version 4.7 (aka 3.4g).
> If you have installed a newer version of the library, check whether
> you have an old xpm.h header file in your include path.
>
> I do have the latest libXpm version 3.5.11 and its "devel" companion.

I haven't found any explanation for this and on my system this
doesn't happen with what looks like the same version of libXpm
installed.

Since, as far as I can see, the configure script checks for
the version of libXpm available on the system by looking at
the xpm.h header file it might be interesting to compare your
version with the one I have. Could you send me your version of
that file?

[Paul]

I am pleased to see that xforms1.2.5.pre1 fixes a problem I
just found in the fdesign version 'Exp 1.39' installed by

apt-get install libforms-bin

under 64-bit Ubuntu 14.04 LTS.

On 64 bit, fdesign 1.39 complains of 'Wrong file type' when
opening an existing .fd file.

The same .fd file opens fine with the 32 bit fdesign 1.39.

I just compiled fdesign from xforms1.2.5.pre1 on 64-bit and it
doesn't have this problem.

The package in Ubuntu's repository is probably quite old now
and ino doubt this bug was long ago fixed.

--
Paul Nicholson
--