could Ardour's YTK be used as a GTK2 replacement?

[JuhaManninen]

for exactly the same reason that the Ardour project does, of course.
https://ardour.org/

I found this:
 https://www.phoronix.com/news/Ardour-Removes-GTK-Option
I also doubt the final size is much smaller. However they seem to develop the lib further, adding features and fixing bugs which is a valid reason to fork a project.

[fifr]

The only significant change that I found (at least in the version that I looked at), besides removing a lot of deprecated stuff, was that they added support for touch events (and unnecessarily broke ABI compatibility when doing so, btw). Everything else was only renaming some files. Maybe I missed something, of course.

I only checked this for gtk, not gdk or gdk-pixbuf.

[robert rozee]

[...] Do you think there is a chance your YTK branch could be merged into Lazarus somewhat officially? [...]

technically, there is no reason why not. a there are still a few kinks to be resolved, and a good deal of testing would be required, but after that it should be possible to have it integrated into the Lazarus IDE in just the same way as GTK2, Qt5, and the others are; YTK being one more option that sits beside a list of other widget-set options.

practically, i could see there being a great deal of push-back. in particular, some folks have raised concerns about incompatible licensing of the GTK2 source code on which YTK is based, although my personal view is that this concern could be resolved with relative ease. other folks seem to object to YTK posing a threat to the development of support for GTK3. yet other folks see dangers associated with effectively working directly with X11.


cheers,
rob   :-)

[PascalDragon]

Important note for anyone wanting to use either GTK or YTK with static linking: both are licensed as LGPL, which means that you are not allowed to distribute a proprietary application cause the LGPL only allows dynamic linking for proprietary code.

[Fred vS]

Important note for anyone wanting to use either GTK or YTK with static linking: both are licensed as LGPL, which means that you are not allowed to distribute a proprietary application cause the LGPL only allows dynamic linking for proprietary code.

Not true, to be legal for LGPL v2.1:

Facilitate Relinking: This is the "static linking requirement." You must provide your application's private static library (.a or .lib) so that a user can combine your code with their own modified version of YTK to create a new executable.


Specifically, in your source create a directory containing the static .a ytk libraries you use AND the link to the original ytk source code + fifr-ytk source code.

[Fred vS]

Specifically, in your source create a directory containing the static .a ytk libraries you use AND the link to the original ytk source code + fifr-ytk source code.

And for static linking of .a libraries stored in your source directory, use the excellent Guva tip.

[PascalDragon]

Important note for anyone wanting to use either GTK or YTK with static linking: both are licensed as LGPL, which means that you are not allowed to distribute a proprietary application cause the LGPL only allows dynamic linking for proprietary code.

Not true, to be legal for LGPL v2.1:

That's why I wrote “distribute” which means as-is without any linking required by the user.

[Fred vS]

Important note for anyone wanting to use either GTK or YTK with static linking: both are licensed as LGPL, which means that you are not allowed to distribute a proprietary application cause the LGPL only allows dynamic linking for proprietary code.

Not true, to be legal for LGPL v2.1:

That's why I wrote “distribute” which means as-is without any linking required by the user.

Okay, you're nitpicking as usual.

Your best AI friend say:

In short, in your distribution's readme.txt file, providing the link to the ytk static .a libraries + the link to the ytk source code (GitHub) + the link to your application (GitHub) is perfectly compliant with the LGPL license.

The core goal of the LGPL (Lesser General Public License) is User Freedom.
Unlike the standard GPL, which requires your entire app to be open source, the LGPL allows you to keep your app's logic private—on one condition: the user must never be "trapped" with the version of the library you provided.
The license is designed to ensure two specific freedoms:
-    The Right to Fix/Update: If a security bug is found in GTK or YTK, a user must be able to fix that bug in the library and "inject" it into your application without needing your permission or your help.
-   The Right to Audit: A user has the right to see exactly how the open-source library is being used and to modify it to see how those changes affect the program.

Why Static Linking is Tricky

    With Dynamic Linking (.dll / .so): The user just replaces the library file on their hard drive. Easy.
    With Static Linking (.exe): The library is "baked into" your application. The user can't replace it unless you provide the source code or object files so they can "re-bake" (re-link) the executable themselves.

In short: The LGPL exists to make sure the library remains "free" and "replaceable," even if the application using it is not.
Since you are providing your app's source code on GitHub, you are giving the user the ultimate "key" to exercise these freedoms.

To Resume (The "Static Linking" Rule):
If your app is...   Must share App Source?   Must share Library Source?   Must share Object Files?
                        GPL     YES                                            YES                                  No (Source is enough)
                        LGPL     NO                                            YES                                  YES

as-is without any linking required by the user.

The application you distribute only needs to be "relinked" if the user wants to use other ytk libraries.

[robert rozee]

the reality is that, in the case of FPC + Lazarus, the source code is freely available, and the end user can rebuild both FPC and Lazarus IDE from this widely available source code. there is ABSOLUTELY NO REASON why YTK should not be distributed as a part of the Lazarus package as downloadable from SourceForge, with YTK provided in the IDE as a selectable build mode.

the question then becomes: what of a non-open-source application that a user of Lazarus wishes to create? this can be addresses as:
what someone uses Lazarus to create is no business of the Lazarus developers. the 'beef' over the nature of said user-created application is entirely between the creator and and any 'offended' party.

if a user of Lazarus chooses to use it to create an application that violates the LGPL, not our problem. just as if a user of Lazarus chooses to use it to create an application that enables the commission of some crime, not our problem.

likewise, the Ford Motor Company is not responsible if someone uses a Ford Motor Vehicle to commit a bank robbery, a murder, or to deliver WMDs.


we should be concentrating our efforts not on creating straw man arguments, but on figuring out how to get YTK fully integrated into the Lazarus IDE as a widget-set option available for users to select.

the solution created by fifr still needs a little more work:
- currently it works by being the 'default' option in the Lazarus IDE. it needs to be changed to a non-default, user selectable option called something like "YTK/X11 direct". just like GTK3 and Qt5 currently are.
- it really should not need a modified version of FPC.
- the process of creating the four .a files should be separated out. while the source code for YTK needs to remain available, it does not need to be distributed with the Lazarus IDE. just distributing the four .a files with the IDE should suffice.


we are tantalizingly close to having a slot-in turnkey solution that can be presented to the Lazarus developers!


cheers,
rob   :-)

[Fred vS]

To developers of Lazarus: seize this fantastic opportunity; it's a wonderful new string to your bow.

Add the YTK widget to your toolkit.

Tested with LazPaint, the result is perfect (+3 MB vs. GTK2).

Code: Pascal  [Select][+][-]

1. $ readelf -d lazpaint | grep -i "needed"
2.  0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
3.  0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
4.  0x0000000000000001 (NEEDED)             Shared library: [libX11.so.6]
5.  0x0000000000000001 (NEEDED)             Shared library: [libglib-2.0.so.0]
6.  0x0000000000000001 (NEEDED)             Shared library: [libgobject-2.0.so.0]
7.  0x0000000000000001 (NEEDED)             Shared library: [libpng16.so.16]
8.  0x0000000000000001 (NEEDED)             Shared library: [libpangocairo-1.0.so.0]
9.  0x0000000000000001 (NEEDED)             Shared library: [libcairo.so.2]
10.  0x0000000000000001 (NEEDED)             Shared library: [libgio-2.0.so.0]
11.  0x0000000000000001 (NEEDED)             Shared library: [libpangoft2-1.0.so.0]
12.  0x0000000000000001 (NEEDED)             Shared library: [libpango-1.0.so.0]
13.  0x0000000000000001 (NEEDED)             Shared library: [libharfbuzz.so.0]
14.  0x0000000000000001 (NEEDED)             Shared library: [libfontconfig.so.1]
15.  0x0000000000000001 (NEEDED)             Shared library: [libfreetype.so.6]
16.  0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
17.  0x0000000000000001 (NEEDED)             Shared library: [libXext.so.6]
18.  0x0000000000000001 (NEEDED)             Shared library: [libXrender.so.1]
19.  0x0000000000000001 (NEEDED)             Shared library: [libXinerama.so.1]
20.  0x0000000000000001 (NEEDED)             Shared library: [libgthread-2.0.so.0]
21.  0x0000000000000001 (NEEDED)             Shared library: [libgmodule-2.0.so.0]
22.  0x0000000000000001 (NEEDED)             Shared library: [libatk-1.0.so.0]
23.  0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

[robert rozee]

hi Fred,
    it looks like everyone else has left the discussion   

i feel the best way forward is to create a patch to one of the existing releases of Lazarus for Linux, as posted on SourceForge. my preference would be to use the .deb packages of version 3.6 as it has been out for a while now without any major problems; it would be hopeless to try to work with the GitLab sources as these represent a moving target.

step 1:
we need to figure out how to create a new "LCLWidgetType" entry (see attached screenshot) for Project -> Project Options -> Compiler Options -> Additions and Overrides, calling it something like "YTK/X11". this differs from what fifr has done, where he has just repurposed the existing "GTK2" option.

step 2:
next step is to figure out how to differentiate between "GTK2" and "YTK/X11". i presume that at the moment fifr's changes are just edits to various pieces of the LCL source code related to GTK2. at the least we need an extra flag to indicate YTK has been selected for building, and conditionally compile either the (original) GTK2 segments or fifr's (new) YTK segments, depending upon this YTK flag.

or do we go down the more complicated route of creating a complete second set of routines, so we have an "original" GTK2 set of routines, and alongside this a "new" GTK2 (renamed as YTK) set. this path will likely involve a whole load more work, but be less of a kludge.

step 3:
examine what changes fifr has made to FPC. are these necessary? can they be achieved by instead making changes to only Lazarus code? ideally it would be nice to not need to make any changes to FPC.


once the above 3 steps are completed, we should have a version of the Lazarus IDE that can still build ELF binaries for GTK2, but can also build ELF binaries for a new target called YTK/X11.

and, more importantly, we can bundle this all up as a relatively small patch (plus the four .a files) that anyone can use by:

a. downloading the original three .deb packages from SourceForge for Lazarus 3.6 (or whatever other version we pick), and install them as normal. then,

b. run a patch program we supply that goes through and patches the Lazarus IDE's source and the LCL source to support YTK/X11, then,

c. rebuild the Lazarus IDE and LCL.


alas, i have absolutely no idea how to do most of this! i'm really hoping that fifr may be able to offer some pointers in massaging his code into the needed form, and indeed that perhaps valdir.marcos or zeljko may even chip in - in particular with the steps needed to add in a new "LCLWidgetType" entry in the Lazarus IDE.


cheers,
rob   :-)

[Thaddy]

You are running behind, maybe mislead by the The Register publication (what @dbannon explained to some extend)
Current focus is GTK3, with Qt6 (NOT 5!!) already Wayland proof as far is Wayland is, well, Wayland and a moving target on top of that:features that are in are frozen, but new API's are added).

Do you really think a niche solution contributes to a real solution?

[fifr]

Just to make a few things clear: ytk was only an exercise for me. I do not really see any value, mainly, because it's the latest gtk2 minus some removed deprecated/unused functions. You can just compile and statically link against the latest gtk2 as well.

I did not make any changes to fpc but only to the gtk2 package that is shipped with fpc. And I only removed deprecated functions that are not available in ytk and would lead to linking failures. And of course I changed the (hard coded) dynamic linking to static linking.

It is probably possible to either compile a static version of gtk2 or a dynamic version and link to it with some rpath flags (so there is no need to install the lib globally in the system).

As long as there is no real development/maintenance of ytk as a separate product, I do not see any advantage in using ytk instead of gtk2. In my opinion it would be wasted time.

That said, please note that I'm a happy Wayland user. It works pretty well for me and my use cases (and often better than x11).

[Fred vS]

Just to make a few things clear: ytk was only an exercise for me. I do not really see any value, mainly, because it's the latest gtk2 minus some removed deprecated/unused functions. You can just compile and statically link against the latest gtk2 as well.

I did not make any changes to fpc but only to the gtk2 package that is shipped with fpc. And I only removed deprecated functions that are not available in ytk and would lead to linking failures. And of course I changed the (hard coded) dynamic linking to static linking.

It is probably possible to either compile a static version of gtk2 or a dynamic version and link to it with some rpath flags (so there is no need to install the lib globally in the system).

As long as there is no real development/maintenance of ytk as a separate product, I do not see any advantage in using ytk instead of gtk2. In my opinion it would be wasted time.

That said, please note that I'm a happy Wayland user. It works pretty well for me and my use cases (and often better than x11).

Hello fifr.

First of all, a huge thank you for your work. I find it excellent and it perfectly meets my needs.

You demonstrate how to use a static library, and it works wonderfully.

Of course, we can now use GTK2 libraries, but with your YTK libraries, all the dependencies are lighter.

I tested it with complex applications, like LazPaint, and I didn't encounter any problems. The binary is only 3 MB larger with static libraries.

I was also able to use the dynamic (.so) files of your fpc-ytk libraries.

Wayland certainly has its advantages, but for X11, GTK2/LCL is excellent and stable, without FPC-specific dependencies or licensing issues like with Qt.

In any case, I don't want your work to be lost; it could be useful to others.

So I've done a release of your fantastic work: https://github.com/fredvs/lazfpc4ytk/releases .

Of course, I would have preferred that the Lazarus developers adopt your YTK solution.

Have fun.

Fre;D

[Thaddy]

I really appreciate such efforts, but it is not a long term solution: be warned you are spending effort which may become obsolete very soon.
Stick to what needs to be done:GTK3(+) or Qt6 as default.