Create a Simple GUI To Run Scripts From?

ghosty999

Member
Joined
Oct 18, 2022
Messages
59
Reaction score
34
Credits
550
This is probably another n00b question.... but I'm setting up a few Linux systems for non-techy users. I'd like them to have a GUI app with 3 buttons that runs different .sh files/scripts.

I've had a look at Gnome Builder etc and seems too involved for what I need. I like some of the PiApps GUI based apps like "All Is Well" which has a simple GUI for n00bs to do updates and clear caches. Basically I need a glorified "Right click and run .sh file"

What's the easiest way to do this? Thanks :)
 


My personal preference for doing this kind of stuff is YAD - Yet Another Dialog - forked off from the Zenity project some years ago. It does take a wee bit of practice.....but, once mastered, lets you produce all kinds of GUIs.

One of the best tutorials is that written by Smokey01.....a long-standing member of the 'Puppy' Linux community, latterly on the 'FatDog' team, and a retired Aussie firefighter. Which can be found here:-


....and is hosted from Smokey's own server, which has been providing storage space for various Puppy devs for many years.

-----------------------------------------------

The project's home page is based at SourceForge:-


....along with source code tarballs - it's really easy to build! - examples, its own Wiki, etc. You should be able to install it through your distro's package manager, if not already installed.

(Although gtk-dialog has existed for this purpose for many years, it's awkward to script, requiring a good understanding of XML markup language.....which is a pain to use. I prefer YAD, because it's easier to grasp the basics of...)

I've thrown together a number of small utilities for Puppy over the years. Here's a few of the GUIs, created with YAD:-

Screenshot-171.png


Screenshot-169.png


Screenshot-178.png


Screenshot-216.png


Screenshot-282.png


Screenshot-141.png


All created with YAD.....and just shows what's possible, if you put your mind to it.

A number of my utilities have a right-click menu, accessible from an icon in the 'notification area', but I don't, unfortunately, know how you would integrate a YAD-based rt-clk command into a GTK-based file-menu. It's not something I've ever tried. Although YAD can make use of the full range of GTK 'stock' icons that most distros come with by default, I think that's the extent of the cross-scripting that's possible....


Mike. ;)
 
Last edited:
@ghosty999 :-

Creating GUIs is definitely a bit of an 'art-form'. You need to decide how you want your GUI laid-out, then figure out how to achieve that with the thousand-and-one available commands.....many of which will only do what you want IF written in a specific order.

I have a number of 'work-areas' set-up on a secondary data drive, and that's where I experiment with all this kind of stuff. It's 'do-able', certainly. You just need a good supply of patience, and to be prepared to keep trying different things as you develop your script.

And remember to 'save' as you go. Frequently!

--------------------------------------

To give you some pointers, here's the Bash script for the first one I showed you above, the manual T.R.I.M facility for SSDs:-

Bash:
#!/bin/sh
#
#GUI for TRIM4SSD-portable...
#
HERE="$(dirname "$(readlink -f "$0")")"
#
yad --center --window-icon=$HERE/DATA/Icons/SSD.png --title="TRIM4SSD utility v1.5" --form --width=400 --text="                SSD TRIM utility (use weekly)
 ------------------------------------------------
        Mount filesystem FIRST using button
            below (unmount when finished)" \
--image="$HERE/DATA/Icons/SSD.png" \
--field=" ~~~~~ TRIM  NOW ~~~~~ ":fbtn "$HERE/DATA/fstrim.sh" \
--button="Mount":$HERE/DATA/cb_mount.sh --button="Unmount":$HERE/DATA/cb_umount.sh --button="About":$HERE/DATA/about.sh --button="QUIT!/$HERE/DATA/Icons/cancel-icon.png":1 --buttons-layout=right

I may have been using Linux for almost 10 years, but I still like my GUIs. I got very used to using them in various versions of Windows - before I said enough was enough! - and since I make these utilities available for other Puppy users to share, I take the view that you can't go wrong with a GUI.....and most people can use one.

And I won't release anything with a GUI until I'm satisfied it works properly. I'm a fussy bugger at the best of times!



Mike. ;)
 
Last edited:
Thanks for your help! There are many dependencies like:
No package 'gtk+-2.0' found
No package 'gtk+-unix-print-2.0'
that I don't have. Is it a process of installing all of them one by one before compiling YAD?

Is there no simpler way to create a 3 button GUI to run simple scripts? Will others also require to install these dependencies to run the app?

Sorry for any noob questions!
 
@ghosty999 :-

Whoops! My bad...

I'm perhaps leading you up the garden path here, to some extent. I've become so used to the fact that all Puppies come with YAD pre-installed, and have done as far back as ever I can remember. But more to the point, we've largely stuck with GTK-2.0, since it ensures a fair degree of "backwards compatibility" for so many Puppy apps/utilities.

Mainstream distros have been using GTK-3.0 for several years, and I believe GNOME are now working with GTK-4.0. GTK-2.0 is considered to be a "legacy" framework these days, and is not recommended by anyone......it's the old "newest is best, safest & most secure" way of thinking.

I have no idea if a GTK-3.0 version of YAD would even work the same; I know some of us have tried it, and the results have been alarmingly different to what we've come to expect. Nothing seems to work the way it should.....

But to answer your question, yes; if a GUI has been built with YAD, then YAD must be on all other machines that want to use it. It's why most developers tend to stick with GTK-dialog, because it's a standard, across-the-board framework included in all distros OOTB. I just don't like its awkward scripting requirements.

So; apologies for leading you "astray". Probably best to just ignore my 'ramblings'... :oops:


Mike. :(
 
Last edited:
@ghosty999 - bit of brainstorming here.

1. Is it a dealbreaker here to not have a GUI, but as an alternative have 3 (size adjustable) desktop icons that users can press, which run the contents of the scripts?

I am thinking in terms of creating 3 .desktop files that sit beneath the icons, and we can help with the content and syntax.

2. Is it the same distro for each user, and if so, which distro, version and DE (desktop environment - eg GNOME, Cinnamon and so forth)?

Cheers

Wiz
 
@ghosty999 :-

So; apologies for leading you "astray". Probably best to just ignore my 'ramblings'... :oops:

Mike. :(
Not at all! I actually learnt stuff in the process so it was fun to play around.

@ghosty999 - bit of brainstorming here.

1. Is it a dealbreaker here to not have a GUI, but as an alternative have 3 (size adjustable) desktop icons that users can press, which run the contents of the scripts?

I am thinking in terms of creating 3 .desktop files that sit beneath the icons, and we can help with the content and syntax.

2. Is it the same distro for each user, and if so, which distro, version and DE (desktop environment - eg GNOME, Cinnamon and so forth)?

Cheers

Wiz
1. Previously I used to do this. I set up things like redshift to be turned on and off with desktop icons. However I was hoping I could make a portable GUI app to put on various linux distros I can keep on a USB stick.

2. It's mainly Debian based (Mint, PopOS, Debian based Raspberry PI OS). I use a GUI app on the Pi4 called "All Is Well" which is exactly what I'm looking for. Install from PiApps and it allows elderly users to update their Pi4 and software.

Thanks for your help.
 
Last edited:
Would creating .desktop launchers for your scripts be a viable solution?
That way, you could get your scripts to appear in the systems main application menu, or main application launcher.

All you'd have to do is put your scripts into somewhere on $PATH, like /usr/share/bin.
Then you create your .desktop launchers in /usr/share/applications.

And a typical .desktop launcher for a terminal based script/application would look something like this:
Code:
[Desktop Entry]
Name=Your script
GenericName=set-up something
Comment=setup script for something useful
Icon=utilities-terminal
Type=Application
Categories=System;
Exec=/usr/local/bin/yourscript
Terminal=true

In the above, we've set up a .desktop file to launch a script at /usr/local/bin/yourscript
The name that appears with the Icon in the menu will be "Your Script" as per the Name field.

The GenericName and Comment fields are a short description of the script/program being launched. The text in the Comment field is usually used as popup/tooltip text when you hover your mouse over the icon.

I've set Icon to be utilities-terminal, which is a common, default, system icon used for terminal based applications. If you want to use another Icon, you could create one of your own, or use another icon that is installed on the system. But you also need to be aware that for icons in lossey formats (.bmp, .tiff, .png, .jpg) - you should provide the icon in sizes ranging from 16x16, up to 256x256, or 512x512, in order to ensure your icon will be drawn at whatever size the user has specified in their system settings/preferences. Alternatively, create your icon as a .svg, which is a lossless, infinitely scalable format. That way, you only have to create the one icon at any size and it can be scaled up, or down by the system as required.

Type has been set to Application - kinda speaks for itself.
Categories is where you specify the menu categories that your script belongs in.
I've specified System, so it will appear in the menu/launcher alongside other system tools, like your process monitor etc. You might want to put it into Settings, or somewhere else. I'll add some links to the official freedesktop documentation for the .desktop format below, so you can see all of the available categories.

Exec is where you specify the script, or executable that the .desktop file will be launching.
In this case, it executes a fictional program at /usr/local/bin/yourscript.
You should substitute yourscript with the name of one of your scripts that you copied to /usr/local/bin/.
NOTE: As the path to the executable/script is on the systems $PATH (/usr/local/bin/ is in $PATH) - we could have just put:
Exec=yourscript - but it doesn't hurt to specify the full path.

Terminal is a boolean variable that tells the system whether or not the application is a terminal application. In this case it is, so we've set it to true. This will cause a default, system terminal window to be opened and your script will be ran inside it.

With your scripts in /usr/local/bin and a .desktop launcher like the above one for each of your scripts in /usr/share/applications/ - you should be able to just open up your systems menu (if you're using a desktop/wm with a traditional, cascading menu system), or go to your systems launcher (if using something launcher based, like Gnome3, or Unity) and you should see desktop icons for your scripts in the main system menu. It might be a better option than trying to create a GUI script with buttons.

And don't let my huge wall of text put you off. This is REALLY simple to do. Literally copy your scripts to a location that is on $PATH, create a .desktop launcher for each script in /usr/share/applications, which will run those scripts. Then your users should be able to run your scripts by finding them in the appropriate category of their systems menu system and clicking on their icons.
And optionally - you might want to create a custom, (ideally .svg) icon and specify the path to that icon in the .desktop file. Again, whether you use the same icon for all of them, or use a different icon for each script is completely up to you.

Full documentation for freedesktop.org's .desktop format can be found here:

You can see what other fields are available in the .desktop format on this page:

You can also see the various application categories that are available in freedesktop.org's menu specification here:
Specifically on these pages:

Finally, I'm aware that many users here on Linux.org are from foreign countries, with English as a second language. So I feel it's worth mentioning that if you're using a non-english locale, you can add translations for specific locales by adding the locale-name in square brackets at the end of the field-names, alongside the translated text.
e.g.
For German:
Code:
Name[de]={German translation}
GenericName[de]={German translation}
Comment[de]={German translation}
Where {German translation} should be the actual translated text for the corresponding english field.
e.g.
Name[de]=Deine Skript or something - IDK?! I used to be quite fluent in German 25-30 years ago. But I can barely remember a word nowadays, ha ha!

Either way - the basic syntax for adding localised/translated fields to .desktop files is:
{FieldName}[{locale}]={translated/locallised text}.

So if you and/or your users are using any non-english locales, that's how to add translations for different languages/locales to your .desktop files. Even if you're from an English speaking country - you may have users on your systems who prefer to have things running in their native languages. So again, if this is a consideration - you can set up your .desktop launchers to support users who use other languages.

And even your scripts are not using any kind of translation - your launchers will at least be more friendly towards any foreign users you might have using your systems.

EDIT:
One minor caveat to using .desktop launchers to launch terminal-based scripts/applications is - if the script is something that does not run interactively (i.e .does not require any user input) and doesn't take very long to run - users will click on the icon and will just see a flash as a terminal window appears, the program/script runs and then the terminal quickly disappears. So they may not know whether or not the program/script completed sucessfully, or if it even ran at all. They might just see a blur.

One way around this is to make the following change to the Exec field:
Code:
Exec=/usr/local/bin/yourscript; read -p "Press any key to continue..." -n1 -s

That should pop up the systems default terminal, run your script and then prompt the user to press any key to continue. Upon pressing any key, the terminal window will disappear.

Or alternatively, you could leave the Exec field as it was
e.g. Exec=/usr/local/bin/yourscript
And add the read -p command to the end of each of your scripts instead.
Either way, you may need some way of pausing things, to allow the users to see the status of the script and dismiss the terminal window when they're ready.

Again, sorry for the wall of text. But this may be another valid way of solving your problem.

One last thing. You can do exactly the same thing with personally created programs/scripts too.
If you have a bunch of scripts, or executable programs in a personal bin directory in your home directory (e.g. ~/bin) and you've added your personal bin directory to $PATH in ~/.profile, you can add .desktop launchers to ~/.local/share/applications, which will allow you to access your own personal scripts/programs from your desktop (or window manager)'s main menu/launcher as if they were "first-class"/system-wide applicatons. But those applications will only be available to your user, NOT to other users.

Which can be handy if you're administering a multi-user system. You can add custom scripts and programs for all other users to use by installing them system wide, using the methods initially described (executables/scripts in $PATH and .desktop launchers in /usr/share/applications/).

And you can add your own personal, custom applications/tools for yourself via executables/scripts in your personal bin directory and .desktop launchers in ~/.local/share/applications/.
 
Last edited:
Why compile? If it's a Debian based system, then you can install YAD with:
Code:
sudo apt install yad
Here a couple of links you might find useful:
Thanks for the info! I had to compile some dependencies like gettext and a few others that the YAD installation requested... well that's what I thought I had to do as the downloads where .tar.gz files. I always thought it was a case of unpacking, then ./configure, make, make install in terminal? This may be showing my noob card haha.

Would creating .desktop launchers for your scripts be a viable solution?

And don't let my huge wall of text put you off.
This is super useful! I will try this tonight and report back. I've copied and pasted your post into a text to speech service which is reading it back to me! I find it often easier that way.
 
I always thought it was a case of unpacking, then ./configure, make, make install in terminal? This may be showing my noob card haha.
It used to be, like in the 90s :) Nowadays you can install pretty much everything without having to compile anything yourself.
 
This is super useful! I will try this tonight and report back. I've copied and pasted your post into a text to speech service which is reading it back to me! I find it often easier that way.
No worries. I tend to go into a LOT of detail when explaining things here. Sometimes unnecessary detail.
Sorry if it's a bit of an information overload. I just try to be as thorough as I can.
I've made some minor edits to the post since initially posting it BTW.
 
It used to be, like in the 90s :) Nowadays you can install pretty much everything without having to compile anything yourself.
How would I go about installing dependencies like intltool-0.51.0.tar.gz and gettext-0.21.1.tar.gz without using ./Configure method? Again... I'm a little n00by haha
 
No worries. I tend to go into a LOT of detail when explaining things here. Sometimes unnecessary detail.
Sorry if it's a bit of an information overload. I just try to be as thorough as I can.
I've made some minor edits to the post since initially posting it BTW.
I actually enjoy the detail haha! Means I have less excuses to ask follow up questions :p
 
Would creating .desktop launchers for your scripts be a viable solution?
That way, you could get your scripts to appear in the systems main application menu, or main application launcher.
Am I doing something wrong here? Created my .sh file and placed it at usr/local/bin as an executable file. Then create .desktop file?

Screenshot from 2023-03-30 21-46-17.png
 
How would I go about installing dependencies like intltool-0.51.0.tar.gz and gettext-0.21.1.tar.gz without using ./Configure method? Again... I'm a little n00by haha
Again, if it's a Debian based distro/OS, the package manager apt will take care of all it by you. So, if you launch a terminal and run
Code:
sudo apt install yad
apt will download and install all dependencies, as long as they're available on the repos, of course.
Code:
tolkem@neon:~$ sudo apt install yad
[sudo] password for tolkem:
Reading package list... Done
Creating dependency tree... Done
Reading status information... Done
Starting pkgProblemResolver with broken count: 0
Starting 2 pkgProblemResolver with broken count: 0
done
The following NEW packages will be installed:
   yad
0 updated, 1 new to install, 0 to remove and 0 not updated.
You need to download 184 kB of files.
An additional 592 kB of disk space will be used after this operation.
Des:1 http://archive.ubuntu.com/ubuntu jammy/universe amd64 yad amd64 0.40.0-1build1 [184 kB]
Downloaded 184 kB in 1s (205 kB/s)
Selecting the previously unselected yad package.
(Reading the database... 359838 currently installed files or directories.)
Preparing to unpack .../yad_0.40.0-1build1_amd64.deb ...
Unpacking yad (0.40.0-1build1)...
Configuring yad (0.40.0-1build1)...
Processing triggers for desktop-file-utils (0.26-1ubuntu3)...
Rendering triggers for hicolor-icon-theme (0.17-2)...
Processing triggers for man-db (2.10.2-1)...
Not building database; man-db/auto-update is not 'true'.
Processing triggers for mailcap (3.70+nmu1ubuntu1) ...
tolkem@neon:~$

And then
1680211407823.png
 
@ghosty999 sometimes that check execute function in the GUI (don't know why) does not work as expected.

1. cd into /usr/local/bin and run

Code:
ls -al

Your script file should have something like

Code:
-rwxrwxr--

at the beginning. If it does not

Code:
sudo chmod 774 CALLUM_UPDATE-SCRIPT

and run the ls command again.

2. Does your script have the shebang at the start of it as first line? That is

Code:
#!/bin/bash

If it does, then linux should be able to operate from it. If not, it will need to be renamed with a

.sh

at the end, note the dot

Though I am not sure with .desktop files if that still applies, Jas will know more.

What Jas was telling you is what I began with at #7, but he explains it a lot better.

Cheers

Wizard
 

Members online


Top