GTKDialog - problems with GCC-14 - fix anybody?

[peebee]

GCC-14 introduces much stricter error checking than earlier versions.

There are problems building GTKDialog with GCC-14:
https://github.com/puppylinux-woof-CE/g ... issues/160

The code base is ancient . Thunor did what he could and he certainly was a fine programmer, but he's been awol for years. Unfortunately, none of the big distros (apart from pclinuxos - a mandrake fork - and we all know what happened to mandrake) ever picked up on it.

Without a few fine software engineers I'm afraid that gtkdialog is on it's last legs.

Anybody up to the challenge of updating the GTKDialog software for the future?? I know some people already think it's dead but the Puppy community has such a lot invested in GTKDialog apps it seems worth trying to prolong it's life if possible.

[dimkr]

https://github.com/puppylinux-woof-CE/g ... g/pull/163 should fix this.

However, gtkdialog is only one old and unmaintained package that fails to build with GCC 14 (for legitimate reasons, passing int * to a function that expects a size_t * is a real C sin and testimony to the code quality of gtkdialog) - I had to fix multiple packages (see https://github.com/vanilla-dpup/woof-CE ... 2024-08-12).

(gtkdialog is out of my dpup builds, so this is a one time thing. I'm not going to bother with gtkdialog again, and I'm definitely not going to maintain it.)

[rockedge]

My son is a computer engineer and software engineer/programmer so I asked him if he could perhaps take a look at gtkdialog to access the work needed to do an overhaul. It is a big maybe but for now @dimkr has helped tremendously and made the adjustments needed in gtkdialog to have the source compile successfully with gcc 14.

I have at the max gcc 13 at the moment and both a gtk3 and gtk2 version built successfully using KLV and the Void Linux development tools.

a major thank you goes out to @dimkr for the time and effort fixing it despite moving forward and away from gtkdialog.

[peebee]

Thanks @dimkr

[Clarity]

1. Which replacement, 'supported by worldwide linux development', is a good replacement delivering similar GUI needs?
   .

2. Is there a similar utility that exist in the QT6 arena similar to this GTK utility?

Curious

[wiak]

Con Te Partirò

[BarryK]

Con Te Partirò

Ha ha, I had to translate that:

I will leave with you

Ditto.

Note, it is possible to turn off all of the gcc-14 "improvements". peebee posted a link on github, that shows the new errors can be turned back into warnings:

https://gcc.gnu.org/gcc-14/porting_to.html

[peebee]

Note, it is possible to turn off all of the gcc-14 "improvements". peebee posted a link on github, that shows the new errors can be turned back into warnings:

https://gcc.gnu.org/gcc-14/porting_to.html

gtkdialog would not build on Debian Trixie gcc14 even with the -fpermissive gcc switch - interestingly it would build on the Slackware Current gcc14!!

[dimkr]

Maybe it's because you're doing a 32 bit Slackware build and a 64 bit Debian build? You'll get more warnings and errors in a 64 bit build because the size of a pointer and the size of an int are different, making 64 builds more likely to fail.

(I think this new GCC behavior is great, it catches many pointer type mismatches that eventually lead to corruption or overflows)

[wiak]

Con Te Partirò

Ha ha, I had to translate that:

I will leave with you

Ditto.

Well... that's a fair alternative per translation to my intended meaning, and I will definitely leave that fix gtkdialog effort with whoever wants to do it.
However, we have benefited greatly over the years from old gtkdialog, albeit with occasional blood, sweat and tears, but I feel it is now fondly, somewhat nostalgically:

One parting thought is that the original gtkdialog source code by Pere László was very much simpler (a single source code file as far as I remember, but I've lost my copy so not sure), albeit nothing like as functional as the Thunor extended variant. That earlier, around version 0.7.x of 2007, was what we once used and maybe there is more chance of resuscitating that one, by I take the thought back even as I speak it...

[peebee]

Maybe it's because you're doing a 32 bit Slackware build and a 64 bit Debian build? You'll get more warnings and errors in a 64 bit build because the size of a pointer and the size of an int are different, making 64 builds more likely to fail.

(I think this new GCC behavior is great, it catches many pointer type mismatches that eventually lead to corruption or overflows)

No both 64-bit