Conversation about the GUI for scripts.

About writing shell scripts and making the most of your shell
Forum rules
Topics in this forum are automatically closed 6 months after creation.
Locked
1000
Level 6
Level 6
Posts: 1040
Joined: Wed Jul 29, 2020 2:14 am

Conversation about the GUI for scripts.

Post by 1000 »

Termy wrote: Fri Jul 09, 2021 11:50 am
AndyMH wrote: Fri Jul 09, 2021 5:56 am And there is yad, does the same as zenity but more.
I can barely stomach working with GTK in PERL, but I think I'd rather use that than faff about with YAD or Zenity! I'm trying right now to get something usable out of YAD, but it's not my idea of a good time. Working with dialog(1) and whiptail(1) seems to be similarly clunky, but a bit easier to handle. YMMV, of course. I'm pretty stuck in my terminal ways. :lol:

Fun fact: YAD is a fork of Zenity.
I noticed that these programs have some limitations in GUI development.
For example:

- Yad for Bash
In Yad I can create icons in tray / systray,
but I don't seen terminal or graphic editor in Yad.

- Gtkdialog for Bash ( removed from Debian )
Allows us to create terminal but I don't seen icons in tray or graphic editor.
Gtkdialog is maybe similar to Glade for C++ or HTML.

In Mandriva / Mandrake Linux ( now it's dead ) I seen Perl scripts with own GUI they looked nice.
But I don't understand Perl and GUI.

In probably on Open Mandriva I seen Perl scripts and GUI in HTML.
They probably created their own browser and they use it to display windows.

The idea using web browser is certainly not new, although it may not always be popular.

Elektronjs for JavaScript use Chromium web browser to show GUI from HTML and CSS.
Neutralinojs is similar but I don't know what it use.

If you write programs
and you wish to do nothing in code for 20 years
and you wish the code was safe,
so which language will be better for creating a GUI ?

Bash scripts are working very long.
What else ?

From my own experience I see problems in applications GTK , Python, Qt.
( However GTK2 has been supported for quite a long time, now I see GTK4 https://blog.gtk.org/2020/12/16/gtk-4-0/ )
In newer versions, something remains abandoned, unsupported, and stops working.
Last edited by LockBot on Wed Dec 28, 2022 7:16 am, edited 1 time in total.
Reason: Topic automatically closed 6 months after creation. New replies are no longer allowed.
User avatar
xenopeek
Level 25
Level 25
Posts: 29614
Joined: Wed Jul 06, 2011 3:58 am

Re: Conversation about the GUI for scripts.

Post by xenopeek »

1000 wrote: Fri Jul 30, 2021 9:09 amIf you write programs
and you wish to do nothing in code for 20 years
and you wish the code was safe,
so which language will be better for creating a GUI ?
You want to do nothing to your GUI code for 20 years and still have it work after that time? I think that's not realistic.

But, RedHat give 12 years support on their OS releases so if you'd run RedHat that and stay with a (new) release that gets you 60% there :o Beyond that I think on a 20 year horizon there will be OS, GUI and programming language changes, if not hardware changes, that necessitate migrating your GUI program to keep it running. Running an older OS in a virtual machine, or packaging your program as an AppImage or similar (with all — by then obsoleted — libraries it needs included with it so that it can run) or maybe some kind of emulator (think DOSBox, which runs GUI programs from 40 years ago just fine) may in 20 years time still let you run software you wrote today.

I had need for a nice looking question dialog in a bash script I wrote, with configurable buttons. I tried several of the alternatives you mentioned but they either couldn't do what I needed or (I think) their dialogs looked real dated and don't fit with a modern desktop. I gave up on those tools. I rewrote the entire script in Python and wrote a wrapper function to show a GTK3 message dialog. If at some point I need to convert that to GTK4 or swap the GTK code out for something else, I only need to modify that one wrapper function. But with each Python release there may be changes that impact your code so even this approach is not a guarantee you can forgo doing routine maintenance on your code.

<side note>
This is the second bash script I recently found need to rewrite in Python. The other was basically a data conversion script that I needed to convert hundreds of files. It was slow in bash. I figured all the external commands used, all the piped commands — forks are expensive on Linux and each of those is at least one fork, so that adds up. I rewrote it in Python, needing no external commands or pipes and that made the script at least 40 times faster! Anyway, I'll still use bash for shorter scripts and prototyping but I'll be using Python henceforth for my larger scripts.
</side note>
Image
1000
Level 6
Level 6
Posts: 1040
Joined: Wed Jul 29, 2020 2:14 am

Re: Conversation about the GUI for scripts.

Post by 1000 »

Curio about pypy for python scripts.
Video: Tsoding Daily - "Python is Too Slow"
https://www.youtube.com/watch?v=Dc_dVBrOshE

Edited.
For bash we can try avoid external commands (usually this is not possible),
and if they are, we can try to use LC_ALL=C
But you are generally right.
User avatar
Termy
Level 12
Level 12
Posts: 4248
Joined: Mon Sep 04, 2017 8:49 pm
Location: UK
Contact:

Re: Conversation about the GUI for scripts.

Post by Termy »

Using Tk with Python and PERL is pretty easy, so there is that, but it's pretty ugly in Linux and doesn't adhere to your themes at all, or at least not that I've seen. I agree with Xeno: abandoning your program for 20 years will likely lead to so many problems, because a lot can change in that amount of time, regardless of the toolkit, language, or program.
I'm also Terminalforlife on GitHub.
Locked

Return to “Scripts & Bash”