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@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
--
_______________________________________________
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
