revisiting YAD

[Anonymous]

somebuddy mentioned:
Yad is too limited, so I have been looking at learning python.

I had implored antiX to stick with an older, decidedly less featureful, version of yad because the subsequent versions dropped gtk2. Also, certain upstream sources also (via compile-time option) support, and thereby depend on, webkit.

Checking the status quo this week, I noted that the debian source package is still watch(ing) the old (migrated to github year ago) yad sourceforge repo. Debian builds it using gtk3, which I (personally) would choose to avoid.

“Step” of puppylinux//FatDog64 maintains the most up-to-date “suitable for gtk2” version of yad.

I’ve packaged a yad v0.42.1 gtk2 build and have begun testing its use on antiX 19 (64bit, virtualbox guest).
6.9MB memory footprint, according to ps_mem.py (vs 9.1MB seen in 64bit antix 17 for v0.38.2)
So far, no bugs nor regressions noticed.

a long-ish changelog entry details the changes/fixes compared to prior versions as well as the (my) rationale for the chosen, minimal, build-time options
https://gitlab.com/skidoo/yad/-/blob/master/debian/changelog

a debfile for 64bit systems is available for interested betatesters:
https://gitlab.com/skidoo/yad/-/blob/master/yad_0.42.1+gtk2-buster~ski_amd64.deb

[Member Xecure]

Helpful

Up

0

::

A few questions (please don’t take it as an atack, I am just interested in knowing).
Did you remove the extra functions because they used more RAM/CPU even if those function (html, using webkit to render html menus, glib gio etc) are not being called or is it only to remove extra dependencies? Could the functions still be added but not work except if the recommended packages are installed? I don’t know how difficult this is, so please forgive my ignorance.

Will it work also if gtk2 is removed (and gtk3 is present) or is it only for gtk2 libraries? This is important because the programs built would only run in antiX 17 and 19, but when bullseye comes will it still work in antiX 21? I don’t want to create something I have to remake again in a few months.

Anyways, I will download and try it. I hope the memory leak problem with gtk notebook tabs is fixed (each new tab would add 10-20 MBs on previous version).

Compared to gtkdialog, yad is very very very limited in how it looks, but it is much easier to use. I was hoping python would be better and more flexible in UI design, even if it used a bit more RAM.

Thanks for your efforts, skidoo.

antiX Live system enthusiast.
General Live Boot Parameters for antiX.

[Anonymous]

Helpful

Up

0

::

> a long-ish changelog entry details [..] the (my) rationale for the chosen, minimal, build-time options

Skim this 30line excerpt from the changelog, then lemme know what questions still remain

  * this build disables: html, gio, spell, sourceview
      (NOTE: THESE WERE UNSEEN/UNUSED THROUGHOUT antiX SCRIPTS WHICH WERE
             CRAFTED FOR USE WITH THE EARLIER 0.38.2 VERSION)
    and entirely removes: icon-browser (an ancillary "show all stock gtk icons" program)
  
  * Note: Although this build omits sourceview support, its library might be present
    on user systems anyhow, installed as a dependency of cherrytree, meld, pluma, et al.
    (In other words, it would not necessarily represent a "new" dependent pkg.)

    sourceview, if enabled would provide "syntax highlighting, for content
    dislayed in yad textinfo pane".  Who maintains the per-programming-language
    highlighting templates? Presumably, whomever is maintaining the upstream
    gtksourceview package. I have chosen to leave this option disabled, until
    or unless someone presents a relevant use case.

    spellchecker, would provide support for the (identical) component used by
    firefox and myriad gtk-driven applications. It's shared library is probably
    already installed on many end users' systems, but would add to the runtime memory
    footprint of a yad instance if no other app currently currently has that library loaded.

    enabling gio ~~ "gLib input/output stack" would bring many additional dependencies.
    I have chosen to disable this option. None of the apps preinstalled in antiX 19 utilize gio;
    if webkit is enabled for yad (or is installed with some other app) that scenario would pull in
    gio as a dependency. FWIW, "support for gio" was added to yad several years ago, but the
    yad program does not expose the ability to leverage many (if any) of it features.
    Example: "I have two windows open, editing the same document.
              WindowA can detect when the content has been edited in WindowB..."

   "enable-html" is the option which drags in dependence on webkit. It would provide 
   the (not!) lovely ability to develop, and foist upon users, "bare-naked"
   (no browser privacy addons) mini web-enabled applications. For extra fun,
   users can be coerced to launch these minibrowser processes with sudo permissions.

  * The revised manpage omits any mention of features related to
    html, gio, spell, and sourceview. It also strives to avoid presenting
    "if gtk3 THIS, else THAT", "only if gtk2, does not work for gtk3"
    (IOW: nixed the confusing, conditional, and often contrary explanations)

To build against “gtk3”, you can simply change 2 (to 3) in the debian/rules file.
Also, if interested, you can see here configure.ac how the build mechanism ingests the compile-time options.

“gtk3” (in quotation marks) because it has presented a sh*tfest of continual tail-chasing.
Developers faced breakage when 3.20 brought backward-breaking changes for programs which had target 3.16 or 3.02 (or whatever). Again when 3.22 introduced a fresh bunch of breakage and/or quirks. Lather rinse repeat…

You can dig in the code, or ask Step and/or v1cont which “minor version of” gtk3 has been targeted/tested.
You might inquire: “Which minor version of gtk3 will be present in bullseye when that suite becomes debian stable”

> I hope the memory leak problem with gtk notebook tabs is fixed

But, but… that bug resides in the underlying toolkit, beyond the purvue of yad (or other app developer) to fix. I haven’t tracked it recently, so don’t know whether it has been fixed nor whether the fixed can be (or has been, in some distro’s package) backported. IIRC, the relevant upstream bugtracker is git.freedesktop.org

[Member Xecure]

Helpful

Up

0

::

Sorry for my post. I wasn’t thinking properly. I read the changelog before posting. For some reason I wasn’t thinking clearly. Anything I do in yad should work even if the yad version changes to one only supporting gtk3. I must have been confused as the additions to this version of yad weren’t what I was expecting and I was pesimistic.

Anonymous wrote:

> I hope the memory leak problem with gtk notebook tabs is fixed

But, but… that bug resides in the underlying toolkit, beyond the purvue of yad (or other app developer) to fix.

When you say “the toolkit”, is this the gtk2 toolkit or something else? gtkdialog + 10 notebook tabs uses about the same as yad with only 2 notebook tabs (or maybe even with yad not using tabs). No memory leak there. I was hoping that the yad developer would find the reason and patch it, but i couldn’t find it in the changelog.

antiX Live system enthusiast.
General Live Boot Parameters for antiX.

[Member ex_Koo]

Helpful

Up

0

::

I don’t use yad any more. Rofi fills my needs these days, especially version 1.60 so good rofi has come a long way.

[Anonymous]

Helpful

Up

0

::

toolkit: https://en.wikipedia.org/wiki/List_of_widget_toolkits

> gtkdialog (using gtk2) + 10 notebook tabs uses about the same as yad (using gtk3) with only 2 notebook tabs

Yup.

$ which yad
/usr/local/bin/yad

$ file /usr/local/bin/yad | cut -d’,’ -f 1
/usr/local/bin/yad: Bourne-Again shell script

$ cat /usr/local/bin/yad
#!/bin/bash
/usr/bin/yad “$@” 2>/dev/null

$ ldd /usr/bin/yad | grep gtk | cut -d’ ‘ -f 1
libgtk-3.so.0

_______________________________

$ which gtkdialog
/usr/bin/gtkdialog

$ file /usr/bin/gtkdialog | cut -d’,’ -f 1
/usr/bin/gtkdialog: ELF 64-bit LSB executable

$ ldd /usr/bin/gtkdialog | grep gtk | cut -d’ ‘ -f 1
libgtk-x11-2.0.so.0

^———– couldn’t use a codebox, WORDFENCE triggered by the forward-slash usr

[Member Xecure]

Helpful

Up

0

::

Anonymous wrote:

libgtk-3.so.0

Thanks for the explanation.This is probably one of the reasons LXDE dev switcht to QT.
We may have to start studying how to package appimages instead xD.

antiX Live system enthusiast.
General Live Boot Parameters for antiX.

[Author]

Posts