Debian removes FPC/Lazarus

[inky]

440bx, there are already two pascal widgetsets available in lazarus.

one is fpgui. it is a separate project, but lazarus has an lcl code to use it instead of gtk or qt: https://wiki.lazarus.freepascal.org/Roadmap

readme in lcl/interfaces/fpgui describes how to use it with lazarus: copy its src directory to this lcl/interfaces/fpgui then in Project Options -> Compiler Options -> Additions and Overrides, choose LCLWidgetType: fpgui, and fpGUIPlatform: x11.

right now that lcl code is abandoned and doesn't work: https://github.com/graemeg/fpGUI/issues/142

other effort is customdrawn backend, we even were able to generate android lcl apps with it. but it is also in bad state and android is not possible anymore, because probably, we have no funding, no resources, not enough people who would deal with it.

i say 'we' as community, i am not a part of fpc or lazarus team. see the roadmap linked.

then there's a third, already mentioned pascal toolkit: msegui, but that perhaps would be even harder to wrap for lazarus lcl and no effort was made so far https://wiki.freepascal.org/MSEide%2BMSEgui#But_what_about_Lazarus?

delphi with their firemonkey widgets made something like customdrawn or fpgui but that actually works. they don't draw on x11 or win32 but get an opengl window from the os and draw on it. since it is possible to get opengl on anything, they can draw on android or ios as well. but i am not of course blaming anyone, delphi has lots of resources and is a proprietary commercial and very expensive project, and lazarus is driven by volounteers. still even delphi used fpc to compile to arm at some point.

unfortunately x11 is also not written in stone: gtk5 dropped support for x11 and some corps allegedly force the transition from x11 to wayland.
i personally dont see myself switching, and i even started on wrapping a WINGs widgetset to use it from pascal, to not depend on gtk. though probably instead i had to try to fix the linked lcl issue or use / contribute to fpgui or mseide.

[dbannon]

My concern would be that an X11 widget set isn't what the Lazarus project is supposed to be about.  IOW, if a new/better X11 widget set is necessary for one reason or another, it should be a separate project that isn't necessarily associated with Lazarus, IOW, it should be "general", not perceived to be Lazarus specific.

OK, a new general Widget set ? That means, something of the scale of gtk2, gtk3, Qt6 or Qt6 (win32, Cocoa)?  Because thats what they are, general widget sets. How will one more widget set solve the problem ?  It will still need to be migrated to Wayland, as gtk3, Qt5 and Qt6 were (gtk2 being dropped by the wayside) and would still need the massive commitment to develop and maintain.

Matters little whether its a new, stand alone widget set or a new layer on top of Lazarus, its still a massive task to build and maintain.  And it does not 'look' native to many end user's chagrin.

Davo

[Ericounet]

Gtk2 is outdated (even if it works fine).

Maybe it's time to "upgrade" to Gtk4?

[robert rozee]

[...] it does not 'look' native to many end user's chagrin.

maybe that is just the price that has to be paid.


cheers,
rob   :-)

[ron.dunn]

There are only two Linux desktops worthy of official support - GTK and QT. Anything else is a sideshow. Interesting, well-meaning, but completely out of date and irrelevant.

Of those two desktops, QT is sullied by licensing and distribution issues.

That really leaves GTK as the most strategic target. And since it also happens to be the most widely supported across distributions, and by user count, that's where FPC and Lazarus should focus.

[440bx]

Just in case, I'll clarify that I've been following this thread strictly driven by curiosity and, the post
https://forum.lazarus.freepascal.org/index.php/topic,73405.msg577383.html#msg577383
seemed to suggest a Lazarus specific widget set would have been (would be ?) a better solution in the long run than the current situation.  That further peeked my curiosity.

The really crucial thing I want to get at is, I do not have enough knowledge about Linux and the widget set situation in Linux to emit an opinion of any kind about the current situation.

My participation is strictly to satisfy my curiosity and hopefully get a clearer picture than the one I have now (which is very foggy to say the least.)

[Thaddy]

Just in case:

Also don't fall into the GTK3 trap because that is also legacy.
For new debvelopment use GTK4, although GTK3 is currently still supported.
See https://gtk.org

A choice for gtk -> gtk3 is like running backwards and should not even be considered.

[vfclists]

How about Skia ie something based on its  Skia4delphi/ variant?

https://wiki.freepascal.org/Skia


Is it the kind of toolkit capable of building a widget around, like MSEGui or FPGui?

[marcov]

How about Skia ie something based on its  Skia4delphi/ variant?

https://wiki.freepascal.org/Skia


Is it the kind of toolkit capable of building a widget around, like MSEGui or FPGui?

Please keep MSEGui or FPGui to the split off thread.

But I assume so, specially for fpgui, which seems designed to be owner drawn with minimal requirements. Same for the Lazarus ownerdrawn widgetset, if you are willing to work on that.

[Thaddy]

How about Skia ie something based on its  Skia4delphi/ variant?

Note the focus is about what Linux distributions offer as mainstream widgetsets (GTKx, Qtx) and underlying window compositors (X, Wayland).
Focus on that: MAINSTREAM plz.

There is no point in choosing anything else but mainstream technology for default releases.

[vfclists]

How about Skia ie something based on its  Skia4delphi/ variant?

https://wiki.freepascal.org/Skia


Is it the kind of toolkit capable of building a widget around, like MSEGui or FPGui?

Please keep MSEGui or FPGui to the split off thread.

But I assume so, specially for fpgui, which seems designed to be owner drawn with minimal requirements. Same for the Lazarus ownerdrawn widgetset, if you are willing to work on that.

I'm not speaking about MSEGui or FPGui as such, but whether if the Lazarus IDE was based on some custom graphics widgetset, a library like Skia would be a good option if it has all the necessary primitives, and will automatically work on all its supported platforms.

[robert rozee]

Please keep MSEGui or FPGui to the split off thread

Note the focus is about what Linux distributions offer as mainstream widgetsets (GTKx, Qtx) and underlying window compositors (X, Wayland). Focus on that: MAINSTREAM

as i pointed out earlier: we have one dead widget set (GTK2/3/etc), one legally toxic widget set (Qt5/6/etc), and a few obscure dribs-and-drabs that according to some don't even compile.

neither of the two choices that we are 'allowed' to discuss (GTKx and Qtx) appear to be viable options going forward. in particular, it looks like there have been concerns about the implications of Qt's licensing model for quite some time - a summary from google reads:

• "Whether Qt’s licensing has "poisoned" the Linux desktop is a subject of ongoing debate within the free software community, characterized more by developer anxiety and strategic maneuvering than immediate destruction of the ecosystem. While Qt is undeniably one of the best toolkits for creating native-looking Linux applications (particularly within KDE), its dual-licensing model and past attempts to restrict Long Term Support (LTS) releases have created tension [...]
  
  
• In 2020, The Qt Company considered limiting new LTS releases to paid customers for the first 12 months. This was seen as a threat to the open-source community, prompting worries that free software would be stuck with buggy, older versions of the toolkit [...]
  
  
• The Qt legal restrictions have not "poisoned" the Linux desktop, but they have introduced a layer of fear and uncertainty [...] For most, Qt remains a powerful, and free option, but the licensing structure means developers must be cautious about how they use it, particularly if they intend to build commercial [software]"

the above leaves me feeling that, at best, Qt should only ever be regarded as a '2nd option' made available as a backup to something else - be that GTK2/3/etc, MSEGui, FPGui or some other direct-to-X11 system.


cheers,
rob   :-)

[marcov]

I'm not speaking about MSEGui or FPGui as such, but whether if the Lazarus IDE was based on some custom graphics widgetset, a library like Skia would be a good option if it has all the necessary primitives, and will automatically work on all its supported platforms.

It would still be non native controls. The controls don't change with the system skin or HiDPI settings, and often don't support OS specific non visual user experience like keyboard (tabbing, system level accelerator keys) and mouse navigation. Everything has to be hand added, and to be frank, that rarely happens, and user acceptance is low.  The only benefit seems to be their low dependencies. But that could be a lot better if applications wouldn't have to be rewritten, and they would implement the LCL, hence the mention of the customdrawn widgetset.

Since it would be good to have a custom drawn as stopgap for new systems and other unforeseeable cases. But rewriting often is a bridge too far. If you are interested you could develop another one based on SKIA. Good luck.

I however don't think this thread really isn't a good example of such unforeseeable case, as there is QT, and even GTK3 on the horizon.

[inky]

perhaps ytk way indeed should be researched?
https://www.phoronix.com/forums/forum/software/desktop-linux/1559516-ardour-digital-audio-workstation-drops-gtk-option-in-favor-of-its-ytk-fork

ardour supports it.

maybe it is an easiest way today to replace gtk2 with ytk?

[marcov]

as i pointed out earlier: we have one dead widget set (GTK2/3/etc), one legally toxic widget set (Qt5/6/etc), and a few obscure dribs-and-drabs that according to some don't even compile.

The problem with the Toxic designation is that is the hardline GNU interpretation of the GPL, that is not commonly shared.  Granted, I can't identify the old clause that was in the GPL2 iirc for delivered with OS libraries any more in the GPL3. A clause that defanged the toxic bit (as you would use the QT delivered with the OS and its package systems). But that might just because I only superficially looked, and not really deep into the matter any more.

I even used QT4 heavily in the PowerPC OS X era, before the emergence of the COCOA widgetset and the deprecation of PPC macs.

neither of the two choices that we are 'allowed' to discuss (GTKx and Qtx) appear to be viable options going forward. in particular, it looks like there have been concerns about the implications of Qt's licensing model for quite some time - a summary from google reads:

• "Whether Qt’s licensing has "poisoned" the Linux desktop is a subject of ongoing debate within the free software community, characterized more by developer anxiety and strategic maneuvering than immediate destruction of the ecosystem. While Qt is undeniably one of the best toolkits for creating native-looking Linux applications (particularly within KDE), its dual-licensing model and past attempts to restrict Long Term Support (LTS) releases have created tension [...]
  
  
• In 2020, The Qt Company considered limiting new LTS releases to paid customers for the first 12 months. This was seen as a threat to the open-source community, prompting worries that free software would be stuck with buggy, older versions of the toolkit [...]
  

If I read that paragraph, I see Threats, opinions, "debate" , Anxiety and other smokescreens arguments, but no hard statement from somebody that is not parroting the FSF that there is a problem.

• The Qt legal restrictions have not "poisoned" the Linux desktop, but they have introduced a layer of fear and uncertainty [...] For most, Qt remains a powerful, and free option, but the licensing structure means developers must be cautious about how they use it, particularly if they intend to build commercial [software]"

I get from that that nothing is eternal, but currently we are good to go. So IMHO no problem. If it fails switch to win32/64 and use Wine, that is the benefit of the LCL.

the above leaves me feeling that, at best, Qt should only ever be regarded as a '2nd option' made available as a backup to something else - be that GTK2/3/etc, MSEGui, FPGui or some other direct-to-X11 system.

MSEGUI to my best knowledge never attempted VCL/LCL compatibility, and has been an one man isolate for most of its time, with weirdness as own code style guides etc.

FPGUI tried working on a LCL widgetset but that stalled. Customdrawn widgetset also seems to have stalled. (which was a better principle IMHO than FPGUI, as it assumed to being the backend of an LCL/VCL interface implementation, rather than just a 3rd party standalone project recycled for that purpose).   These are all so far from maturity (compared to even what is there for GTK3) that they are not part of any sane schedule.

So that leaves GTK3 and QT5/6.

So seriously, without knowing your exact situation and requirements(e.g. if you deploy the Linux distro also and can circumvent the issues for a while), start with accepting that nothing is perfect or eternal on the make it up as you go OS that is Linux. Then I would switch to a QT for the time being, but try to start supporting GTK3 development as much as possible and keep wine as emergency backup solution.   

And if you are professional and Linux GUI deployment is mostly an hobby since only a real small percentage of your business, consider simply cutting it (well, that is almost the same as the wine option anyway)