Since the limitations of Yad are quite restricting for some things that I cobble together, I decided to look for alternatives and ( since GTK is getting less and less attractive each consecutive version) preferrably Qt or the like. And I found something
It is more flexible than yad and gives output âwhile runningâ instead of âon exitâ which makes it suitable for a much wider range of applications.
Here is an example for a frontend that I cobbled together in bash and it works like a dream
Iâve used yad and zenity quite a bit and have no problems with them. From your screenshot, I canât tell what kind of dialog is being thrown. It would seem you are embedding a YouTube video, but why do you need a dialog for that? Where are the controls (buttons) and options?
For simple things it is enough, but the layout you see in my example can not be done in Yad.
Nor can it do any intermediate output without exiting first (which can be quite inconvenient)
I streched the possibilities of yad to the limit when I made a kind of âshoppinglistâ app. It ended up with two minor inconveniences that I could not work around because of this.
Do you remember the graphical youtube-downloader frontend that we used to have in Ubuntu MATE some years ago ?
AFAIK it was Wimpy who made that in python.
Since itâs no longer available, I thought that I could have a go at it just to see if it was possible in âdialogboxâ (also tried in yad but making a reasonable practical layout was impossible)
The options are right in front of you, there will be some more.
Controls are not needed, itâs not a mediaplayer
As you say, unfortunate that you canât have a same dialog use intermediate outputs. Given that it is Qt-based, coming out of the KDE crowd, itâs possible that they will address that âshortcomingâ relatively quickly, once it has been pointed out!
I will definitely give that a spin! Thank you very much for bringing that to our attention!
Oh no, sorry, I explained it not clearly: Yad is the one that doesnât do intermediate outputs, but dialogbox does !
So, I can create a script in bash, driven by the output of dialogbox, which in turn is again driven by the script: a perfect eventloop and quite simple to create
root@OasisMega1:/opt/dialogbox-1.0# qmake -qt=qt4 -makefile qmake: could not exec '/usr/lib/x86_64-linux-gnu/qt4/bin/qmake': No such file or directory root@OasisMega1:/opt/dialogbox-1.0#
Would you have insights as to why that error and how to fix?
Can I simply âtransplantâ the qmake from qt5 install into the qt4 file tree (or symlink to the qt5 file)?
qtchooser is âELFâ so no opportunity for âtweakingâ!
Errlog from qt5 attempt:
In file included from dialogbox.cpp:21:
dialogbox.hpp:154:26: error: invalid use of incomplete type âclass QDialogâ
154 | class DialogBox : public QDialog
| ^~~~~~~
In file included from /usr/include/x86_64-linux-gnu/qt5/QtGui/qevent.h:44,
from /usr/include/x86_64-linux-gnu/qt5/QtGui/qtextlayout.h:49,
from /usr/include/x86_64-linux-gnu/qt5/QtGui/qabstracttextdocumentlayout.h:45,
from /usr/include/x86_64-linux-gnu/qt5/QtGui/QtGui:5,
from dialogbox.hpp:24,
from dialogbox.cpp:21:
/usr/include/x86_64-linux-gnu/qt5/QtGui/qwindowdefs.h:55:7: note: forward declaration of âclass QDialogâ
55 | class QDialog;
| ^~~~~~~
In file included from dialogbox.cpp:21:
dialogbox.hpp:206:24: error: âQTabWidgetâ has not been declared
206 | void ClearTabs(QTabWidget*);
| ^~~~~~~~~~
dialogbox.hpp:217:9: error: âQLayoutâ does not name a type; did you mean âQTextLayoutâ?
217 | QLayout* FindLayout(QWidget* widget);
| ^~~~~~~
| QTextLayout
dialogbox.hpp:219:44: error: âQLayoutâ has not been declared
219 | bool IsLayoutOnPage(QWidget* page, QLayout* layout);
| ^~~~~~~
dialogbox.hpp:221:54: error: âQLayoutâ has not been declared
221 | bool IsLayoutOnContainer(QWidget* container, QLayout* layout);
| ^~~~~~~
dialogbox.hpp:238:34: error: âQListWidgetItemâ has not been declared
238 | void ListboxItemSelected(QListWidgetItem*);
| ^~~~~~~~~~~~~~~
dialogbox.hpp:245:9: error: âQPushButtonâ does not name a type
245 | QPushButton* default_pb;
| ^~~~~~~~~~~
I've thought about that, but the flaws of python are a bit of a roadblock.
highly unstable language (think python 2 vs python 3)
highly unstable implementation (every minor version update breaks half of the applications on this planet)
extremely bad in multiprocessing ( and therefore bad at IPC )
What I wrote 5 years ago should still run now or in 5 years time without even looking at it. I wrote a serverapplication 12 years ago in bash that still runs to this day. It survived several OS upgrades without even looking at it.
Try that with python.
So yeah, I would sooner chooce for Tk/Tcl than Tkinter, Tcl is at least stable
But then, Tcl would then just be a translation layer between bash and Tk and I first would have to learn Tcl from scratch, so I rather search for a solution without an intermediate layer.
If I have to go with an intermediate layer then I would use WxWidgets which has a GUI Designer and a code generator. I've used that several years ago to create a EQ frontend for MPV:
I agree wholeheartedly, which is why, contrary to much of what I see, I have spent more time on Bash scripting, however inelegant at times, than trying to create (and repeatedly fix) compiled languages.
Sure, it may be deemed limited and ânicheâ by some, but for what I chose to apply myself to, those were essentially âmainstreamâ to me!
bash is always my first go-to when Iâm trying to automate a task. Most of my scripts donât need âprettying up,â but sometimes I like to add something, maybe in the way of feedback. Linux gives us all sorts of tools, like the simple one-line notify-send that simply pop up a notification dialog.
When you combine bash (or zsh, csh, or any of the various shells) with other built-ins, like sed, awkand similar utility programs, one can build quite a library of local, custom jobs.
Donât forget that programs like bashtop and htop also exist, further proving that thereâs an awful lot that can be done without having to learn a new language.
Also, as a distant historical reference, while he was working at Hydro-Quebec back in the 1980s, my now-deceased older brother (for his Doctoral thesis) had used shell scripts (plugged into databases and real-time controls) on a Unix box as the logic of an adaptive âexpert-systemâ controlling Hydro-Quebec power station transmission voltage to ensure the amount of power being generated was responsive to demand, without overloading the transmission âbreakersâ (I may have the wrong term there), and adjusting those controls simultaneously on 3 parallel transmission loops, ensuring stable transmission from James Bay to New England states.
At the time, he conjectured that Unix and Bourne Shell together offered a clear seed resource to creating Artificial Intelligence!