[Lazarus] Gtk 1.2 fixes (again)

Tarnyko tarnyko at tarnyko.net
Thu Feb 17 13:23:40 CET 2022


 From memory, Windows 95 would be the target of such a version (98 already 
supports an early GTK+ 2.x). Is that your target? 

(just as denisgolovan said, I salute such an effort -as little as the market 
may be, and as long as it's doesn't delay/impede main stuff) 

Kostas Michalopoulos via lazarus writes: 

> On 2/13/22 23:41, Maxim Ganetsky via lazarus wrote:
>> But I still can't understand, why you put so much an effort into an 
>> ancient and obsolete widgetset.
> 
> I only spent 2-3 days, including getting Gtk 1.2 itself to compile and 
> tracking down a gdk_pixbuf version that was compatible with Gtk 1.x, it 
> wasn't that big of an effort. As to why, as i wrote in the comment in the 
> merge request, i was curious about the Gtk 1.2 state, noticed that it 
> didn't work and decided to fix it. I just simply like it when software 
> doesn't drop support for old stuff just because they are old. I am into 
> retrocomputing and various retrocomputing communities and i like being 
> able to use modern software in retro environments (if anything i'd like to 
> see what it'd take to bring back Win9x support to both FPC and Lazarus as 
> in a game i made for a gamejam a couple of years ago i had to use several 
> year old versions of FPC to make a Win9x version that would work with 
> graphics cards on my older computers - like 3dfx Voodoo - and couldn't 
> make the editor available for it because it wouldn't compile on the last 
> Lazarus that supported Win9x - at least i was able to use the latest FPC 
> for the DOS version, which is great). 
> 
> Beyond that, as i wrote in the merge request, MUI is even more "ancient" 
> and yet Lazarus added support for it recently. I do not see why it being 
> called obsolete by its original developers means that one couldn't work on 
> it if they want, it is open source after all, the entire point is having 
> the freedom to do things like that. 
> 
> Also i do not see why this is such an issue, the code is there and doesn't 
> bother anyone - it isn't like i as a user who mostly works with win32 and 
> gtk2 am bothered about the existence of 
> gtk3/gtk4/cocoa/carbon/mui/fpgui/customdrawn/whatever. The worst that 
> happens is that it takes a couple of MB of disk space in the source 
> checkout. 
> 
> > IMHO finishing fpGUI widgetset makes much more sense. 
> 
> AFAIK fpGUI hasn't seen a release in years now and i think the development 
> version has several incompatible changes, meaning that if anyone works on 
> it now they may have a Gtk2->Gtk3->Gtk4 situation where they'll need to go 
> and spend time getting the code base in a working state. TBH i am not a 
> fan of APIs that break themselves - i'd rather make a Motif backend (it is 
> technically still developed :-P and even theoretically an IEEE standard - 
> or, well, it was at some point) as its API has a stability that goes back 
> to the early 90s. While it'd be neat if there was support for it, it isn't 
> something i personally find interesting. 
> 
> Also why fpGUI specifically and not the custom drawn widgetset instead? It 
> does seem have some issues but at least this one seems to be 100% on 
> Lazarus instead of relying on an external project to remain working. 
> 
> Kostas
> -- 
> _______________________________________________
> lazarus mailing list
> lazarus at lists.lazarus-ide.org
> https://lists.lazarus-ide.org/listinfo/lazarus


More information about the lazarus mailing list