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

[robert rozee]

has anyone experimented with Ardour's YTK (https://git.ardour.org/ardour/ardour/src/branch/master/libs/tk) as a replacement for GTK2?

according to google's AI:

"Stripped Features: YTK is a "stripped-down" version of GTK2, meaning it excludes many components of the original toolkit that Ardour does not use, further reducing its size compared to a standard system GTK installation.

Static Linking: In most official Ardour bundles, YTK is linked directly into the application, meaning you don't need to manage it as a separate, space-consuming "package" on your system."

this leaves me thinking that it may be possible to have YTK statically linked into a Lazarus/FPC application. if the result was an ELF binary that was, say, 5mb larger then this would for most folks be an acceptable compromise.

alternatively, for applications distributed within an installer YTK could be handled as either a dependency, or packaged alongside the the main application.


comments? worth looking into further?


cheers,
rob   :-)

[marcov]

Why don't you try, and report back ?

[valdir.marcos]

...

btw: i started another thread titled "could Ardour's YTK be used as a GTK2 replacement?" (https://forum.lazarus.freepascal.org/index.php/topic,73590.0.html), but only MarcoV posted to it - and that was not a very useful posting. while i'm not in a position to kick off such a project (integrating YTK into Lazarus as another widget set option) myself, it does seem like something worth exploring. no, not writing code! exploring in the sense of gaining some idea of how much bulk it would add to an ELF binary, to what degree YTK retains function calls that the LCL would need - and what needed function calls are missing, and the extent of modification to the LCL that would be needed. being able to (via existing GTK2 support along with incorporating YTK source) would add another string to Lazarus' bow going forward.


cheers,
rob   :-)

I am trying and dealing with some errors and without a running binary so far.

[robert rozee]

[...] I am trying and dealing with some errors and without a running binary so far.

have you been able to produce any binary yet? even if not runnable, it can yield useful information - such as by how much the size of the binary is increased when YTK is incorporated.


cheers,
rob   :-)

[valdir.marcos]

[...] I am trying and dealing with some errors and without a running binary so far.

have you been able to produce any binary yet? even if not runnable, it can yield useful information - such as by how much the size of the binary is increased when YTK is incorporated.

cheers,
rob   :-)

Nope. Not so far.

[dbannon]

this leaves me thinking that it may be possible to have YTK statically linked into a Lazarus/FPC application. if the result was an ELF binary that was, say, 5mb larger then this would for most folks be an acceptable compromise.

From memory, a gtk2 install requires about 200Meg.

Davo

[robert rozee]

From memory, a gtk2 install requires about 200Meg.

well, hopefully we will find out how large the added footprint of YTK is in the not too distant future - if it is indeed 200mb that is a problem; if it is 5mb then we are onto a winner.


cheers,
rob   :-)

[Thaddy]

It is nowhere near 5 and depending on distribution and cpu between 150 and 220. (It compares to a Windows install)
But note that that includes a lot of "unnecessary" tooling that an advanced user may remove: there are distro's that are GTK2 based and under 75.

Anyway, that solution is not mainstream so worthless in the sense you can not apply that to a default distribution.

[robert rozee]

It is nowhere near 5 and depending on distribution and cpu between 150 and 220. (It compares to a Windows install)
But note that that includes a lot of "unnecessary" tooling that an advanced user may remove: there are distro's that are GTK2 based and under 75.

Anyway, that solution is not mainstream so worthless in the sense you can not apply that to a default distribution.

hi Thaddy, i am afraid that you are talking rubbish.

the current Ardour downloader is a 75mb .run file. so that gives us an 'upper limit' to start with. one this is unpacked there appear to be a couple of YTK libraries of size 4.3mb (ytklib.so.2) and 3.9mb (libytkmm.so.2), giving a total of 8.2mb. there are also a few much smaller libraries, and one much larger library that seems to be the bulk of the main applications functionality (of which we have no interest in).

we need to wait a moment and see what valdir.marcos comes up with for a reliable estimate - even a non-functional ELF binary will reveal some idea of size and dependencies. speculation before then is unreliable.


cheers,
rob   :-)

[dbannon]

When Thaddy talks its sometimes rude, sometimes unpleasant. Never rubbish !

I have wasted most of a day trying to get a gtk2 version of my app as an AppImage. Because, Robert, that is what you want. An AppImage is built by examining your ready to run binary and gathering together "all" the required libraries, compressing them up and adding code to extract, as required, at run time. It (obviously) gets the libraries from the system its built on, it does not use the libraries from the machine it runs on. It does have to use local infrastructure sooner or later of course.

My version, here, bundles some 257 libraries including the xcb set and, as I understand it, the gtk2 set. Sadly, it does not work ! Seems the linuxdeploy people do not put a high priority on gtk2 ! But useful to see what it is trying to build. The AppDir is where all the libraries are assembled before compression so, while we know it is incomplete, its an indication of the size of a statically linked binary.

Code: Bash  [Select][+][-]

1. dbannon@dell:~/AppImageGtk2/tomboy-ng/tomboy-ng_0.42b-1$ ls -l tomboy-ng-x86_64.AppImage
2. -rwxr-xr-x 1 dbannon dbannon 27429368 Mar  9 12:53 tomboy-ng-x86_64.AppImage
3. dbannon@dell:~/AppImageGtk2/tomboy-ng/tomboy-ng_0.42b-1$ du -hs ../AppDir/
4. 94M     ../AppDir/

Remember, this is for my app, it obviously uses only a subset of GTK2, a general purpose library, to cater for all Lazarus apps would be a lot bigger. The AppImage itself is smaller due to compression, proving, to me, beyond all doubt its a better solution than static linking ! Still a dopey solution, but I make Qt5/6 AppImages available and they do get some downloads.

Davo
 



 

[AmatCoder]

@Davo:
I have the necessary infrastructure to make GTK2/3 static builds (and I was bored) so I built your app to test.

I can give you some numbers:

• GTK2 (symbols stripped) -> 25.92M
• GTK2 (symbols stripped / compress with UPX) -> 7.57M
• GTK3 (symbols stripped) -> 31.64M
• GTK3 (symbols stripped / compress with UPX) -> 9.14M

My version, here, bundles some 257 libraries including the xcb set and, as I understand it, the gtk2 set.

Although the number of libraries depends on the distribution, 257 seems excessive. I use about ~50 for GTK2 and ~60 for GTK3.

When I get more time I will build a Qt6 version to compare.

[robert rozee]

I have the necessary infrastructure to make GTK2/3 static builds (and I was bored) [...]

are you by any chance able to give a (detailed) description on how to do this?


cheers,
rob   :-)

[robert rozee]

[...] I have wasted most of a day trying to get a gtk2 version of my app as an AppImage. Because, Robert, that is what you want [...]

one of the greater sins in life is telling people what they want   

however, your efforts do provide another useful data point: 27429368, which i presume is 27mb. this result represents an upper limit, as it will no doubt include a whole load of other stuff that is of no interest. for instance, X11 does not need to be included, unless GTK2 and X11 are (god forbid) bound together at specific version number pairings.


cheers,
rob   :-)

[fifr]

For those who are interested: I managed to compile and link Lazarus against ytk. This does not mean that the result works (it crashes), but this is expected as I had to remove some unsupported code (without a proper replacement). However, the whole experiment was to see if ytk can be used in principle and how much work would have to be done. In case you want to try yourself, here's what I did:

• extract the ztk, ydk, ydk-pixbuf, ytk from Ardour's source tree (see the attached ytk.tar.gz). I added some hand-crafted makefiles that compile everything to static libraries (Ardour uses waf as build system, which I do not know, and using simple makefiles was easier). Note that other libraries like glib, gio, gobject, pango, cairo ... are still linked dynamically.
• remove some unsupported functions from the fpc package (see the attached fpc-ytk.patch). I used the 3.2.2 release of fpc
• remove some unsupported functions from Lazarus/LCL (see the attached lazarus-ytk.patch) and link against the static libs
• compile the patched fpc and use it to compile Lazarus like
  make bigide LCL_PLATFORM=gtk2 PP=/path/to/patched/fpc OTHERLIBDIR=/path/to/ytk/static/libs
  

This worked on my machine (void-linux, x86_64).

Note that number of changes/removals is not too bad. Most of them are related to functions that are deprecated in gtk2 anyway (e.g. gtk_clist_* gtk_pixmap_* gtk_list_* etc) and those deprecated functions have been removed from ytk. So probably these places could be updated without too much effort (maybe take some code from gtk3 or use proper replacements).

But as I said, Lazarus compiles and starts but crashes right after the start (probably due to some of my changes). Nevertheless, it seems that using ytk instead of gtk is indeed possible with some reasonable effort.

And if you like numbers: here are the binary sizes of a stripped lazarus executable on my system with gtk2 (dynamically linked) and ytk (statically linked):

• gtk2: 41.4 MB
• ytk: 45.5 MB

Here are the ytk-sources including my makefiles. They are too large to be attached to this post: https://limewire.com/d/NhcP6#T0SnfydlLc

[Fred vS]

@fifr:  WOW, You are a game-changer.