MarkText 'portable'

[user1234]

In a recent post by @Zuzia, I came to know about this great Markdown editor (which I needed a lot)- MarkText. So following @mikewalsh's trend, I have made a (kinda) 'portable' for it (kinda because all configuration data is stored where ever the program wants them to).

Here is the link to it- https://github.com/lakshayrohila/marktext-portable.

As you might have seen, it does not include any binary right away. Instead, it installs the binary (AppImage) when needed. That's why on the first startup you may get a dialog box asking you to install binary. You may choose to download the binary at the same time or you may choose to download it later. Note that if you choose to download program's binary later, you will not be able to run MarkText. Might take nearly 100MBs for downloading the AppImage.

You can use the INSTALL and UNINSTALL scripts provided in the portable in order to do system-wide installation. NOTE THAT INSTALL AND UNINSTALL ONLY CREATES SYM-LINKS TO FEW OF THE COMPONENTS OF THE PORTABLE DIR. So never remove the portable dir even after you run INSTALL.

Also, note that currently the URL to check the latest version is given by me myself (located at /marktext-portable/DATA/.MARKTEXT_LAST_RELEASE in the github repo). I have also opened an issue on the original MarkText github repo, to provide a file for the same purpose. Until the issue is not processed, I'll regularly check for updates and update the version in my program whenever required.

Also, note that these sym-links are created after running INSTALL script-
1. LAUNCH -> /usr/bin/MarkText.
2. DATA/resources/marktext.desktop -> /usr/share/applications/
3. DATA/resources/marktext.png -> /usr/share/pixmaps/

Please read README.md for more information.

I'd also like to thank @Zuzia for mentioning and making us know about this great program, and @mikewalsh for inspiring me about portables and setting up an example (I referred to Google Chrome portable) of how to implement them (Some part of the code is copied 'as is' from the Google Chrome portable, so don't mind @mikewalsh... OK? (I didn't even read the Licensing of 'his' portable )).

Please test the portable and tell how it runs on your machine (It might not run on x86, i.e. 32-bit machine as I couldn't find any AppImage for the same in MarkText's Github Repo's Releases page).

Regards
User1234
(Fascinated by the beauty of this program.)

[mikewalsh]

@user1234 :-

Mm. Well, you won't find a 32-bit version anyway. This is Electron-based, and I haven't seen any 32-bit Electron-based apps for a few years now. The only 32-bit package I can see there is a zipped 32-bit build for Windoze.

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

With regard to making these portables totally self-contained, I'll let you in on a wee build secret. No point hoarding it, and keeping it to myself.

• Initially, I'll create the portable directory - suitably-named - along with a .DirIcon. I then place the app/AppImage/whatever it is in this directory, along with just a basic 'LAUNCH' script to get things going.

• On the first run - assuming it's successful - I then scan through the standard config locations to find where the app has placed its configuration directories/files. Having located them, I then create the portable's 'config' directory, and copy them across to here. Now it's time to start modifying the 'LAUNCH' script to add in the necessary clauses for checking to see if they exist, following by the usual delete and/or symlinking things from the portable to the 'expected' locations, together with the final lines to remove those sym-links again at close.

• Once this is all working, I then add the final touches; the 'DATA' directory that contains the pixmap icon & .desktop entry for the Menu entry, along with the MenuAdd/MenuRemove scripts themselves (with the appname variable suitably modified, of course). Don't forget to edit your desktop entry to point to the sym-linked entry in /usr/bin.

Bob's yr Uncle. Done..!

Hope that helps. Any clarification, ask away.

Mike.

[Zuzia]

Hi, i have my bionic also on usb then i try this portable version soon. 32bit version also can be great if some dey someone rebuild this apps. But probably i expect too much : ) Good markdown editor is rare toodey especialy Free. Then if i test more great apps from git hub or other linux distro i write here again, Great apps library is all what puppy linux need OS now is great if all apps will be great quality, that distro will be best forever : )

[mikeslr]

Just to note that currently the link on the OP is NOT to a downloadable package.

FWIW, you may want to examine the tar.gz here, https://www.forum.puppylinux.com/downlo ... p?id=11122 as an example of how MikeWalsh's system works.

[wiak]

As you might have seen, it does not include any binary right away. Instead, it installs the binary (AppImage) when needed. That's why, on first startup you may get a dialog box asking you to update. Do not refuse it as using it you'd be able to install the program's binary, which (of course) is required to run the program. Might take nearly 100MBs for downloading the AppImage.

Main problem of distros provided pre-built as isos rather than as a build script is that they very rapidly can become out of date. It is a lot of work continually building new ones.

Whilst I haven't myself been using sfs portable addon apps very much at all (relying instead mainly on package manager provided updates) it has been in my mind to build a small distro that totally relies on sfs-style or similar portable addons for its packaging system. Similar was done long back, by I think it was forum member taersh using a Puppy remaster he made.

So seems to me that a static portable App becomes stale, sometimes quickly, so instead it is best to provide a build system for a portable app that rebuilds to the latest AppImage version whenever you use it. In other words, basically like we do with build scripts for distro creation, the process for building any portable app should be scripted such that little or no further work becomes necessary to deliver a new version - just rebuild it.

Seems that is what you are basically doing with this one (though I don't know since I haven't tried it yet). Will try your portable (but also since I want to see what facilities this Markdown editor provides compared with say a small and simple markdown to html convertor, of which there are many).

But where is the download??? Or do you intend users to gitclone (or download zip) of all your scripts and run them in a certain order (from quick glance at your github files I'm presuming UPDATER first)?

EDIT: Okay, it worked for me to download your github site contents (I used gitclone) but simply downloading a zip copy to the directory where you wanted the marktext files stored would work. Then I ran ./UPDATER, which brought down the latest AppImage for MarkText, then I ran ./INSTALL to create appropriate symlinks such the MARKTEXT appears in my KLV-Airedale Accessories menu, and finally I ran ./LAUNCH and the application MARKTEXT launched. Basically seems to work and I am playing with it now.

The idea is good - you need to make the download and use process clearer for general users though. Yes, the marktext program works well via its menu as a WYSIWYG markdown editor - nice implementation overall of how to organise the portable app - good if similar were done for the likes of other such apps, such as for Chromium and other browsers and so on. I do really like your approach to installing/updating portable AppImages though.

Note that for using in KLV-Airedale, which is not a Puppy Linux distro or derivative per se, I needed to modify a couple of lines in UPDATER since KLV doesn't contain the, presumably Puppy specific, box_yesno or box_splash scripts/utilities - maybe you could make your 'AppImage build/creation implementor' somewhat more distro agnostic/universal by using something like gxmessage instead for these afterall very simple splash type notices - so easy to do that - otherwise it is a bit of a nuisance having to convert the simple scripts when not using Puppy Linux itself? Frankly, I've never understood why people developing simple utilities for Puppy Linux make them such that they only work on Puppy - usually they could be easily written in a general purpose any-distro sort of way using facilities available to most all Linux distros (gxmessage being installable in most all distros), which is much more universally useful of course. For example:

UPDATER

line 14:

Code: Select all

gxmessage -center -bg orange -title "yes_no" -buttons "No:1,Yes:0" "A new update of MarkText is found! Do you want to update?"

line 24:

Code: Select all

gxmessage -borderless -center -bg orange -timeout 10 "   DOWNLOAD FAILED!  Please try again later.....    "

Above is quick mod try - may need you to adjust somewhat according to what you need.

[williwaw]

I downloaded your zip, and UPDATER, INSTALL and LAUNCH seemed to run fine
the appimage itself partially runs with errors on EasyOS, but thats a different issue.

the desktop icon did not appear in the menu, and the png did not get associated with the .desktop link in /usr/share/applications, (but that may also be an EasyOs thing also)

[user1234]

Well @wiak, @mikeslr and @williwaw thanks for testing! I see that there are few doubts about how it works and how you need to download it. I am gonna make the README.md file today for the instructions. Well yesterday... I became lazy . Sorry for the inconvenience.

@wiak, no need to gitclone. Rather download ZIP file of the repo from github (I'll update the steps for it in the README). Also, what you need to run is just the LAUNCH script. Everytime it calls for the UPDATER script for any available update automatically, so no need to run UPDATER manually.

As you might have seen, it does not include any binary right away. Instead, it installs the binary (AppImage) when needed. That's why, on first startup you may get a dialog box asking you to update. Do not refuse it as using it you'd be able to install the program's binary, which (of course) is required to run the program. Might take nearly 100MBs for downloading the AppImage.

Note that for using in KLV-Airedale, which is not a Puppy Linux distro or derivative per se, I needed to modify a couple of lines in UPDATER since KLV doesn't contain the, presumably Puppy specific, box_yesno or box_splash scripts/utilities - maybe you could make your 'AppImage build/creation implementor' somewhat more distro agnostic/universal by using something like gxmessage instead for these afterall very simple splash type notices - so easy to do that - otherwise it is a bit of a nuisance having to convert the simple scripts when not using Puppy Linux itself? Frankly, I've never understood why people developing simple utilities for Puppy Linux make them such that they only work on Puppy - usually they could be easily written in a general purpose any-distro sort of way using facilities available to most all Linux distros (gxmessage being installable in most all distros), which is much more universally useful of course. For example:[/b]

UPDATER

line 14:

Code: Select all

gxmessage -center -bg orange -title "yes_no" -buttons "No:1,Yes:0" "A new update of MarkText is found! Do you want to update?"

line 24:

Code: Select all

gxmessage -borderless -center -bg orange -timeout 10 "   DOWNLOAD FAILED!  Please try again later.....    "

Above is quick mod try - may need you to adjust somewhat according to what you need.

Well, thanks for the same. I didn't know that box_yesno or box_splash scripts are not available for all puppies (Am kinda new to GUI with shell scripts). I'll use gxmessage from now onwards.

EDIT: Well I liked box_yesno and box_splash more than I liked gxmessage. So what I currently have done is a check to see if box_yesno and box_splash returned 127 (error code meaning that the executable couldn't run), and in case it returned 127 then use gxmessage (works fluently). You may be able to see the work in few hours/minutes when I push a new commit to github.

[wiak]

Well, thanks for the same. I didn't know that box_yesno or box_splash scripts are not available for all puppies (Am kinda new to GUI with shell scripts). I'll use gxmessage from now onwards.

They may be available on all actual Puppy Linux distros and their direct derivatives, but plenty distros discussed on this forum, such as the DebianDogs, which are not Puppy Linux at all. And KLV-Airedale doesn't contain these Puppy utils either though it could be made to I suppose, but other distros besides (the ones I otherwise use apart from KLV) certainly don't contain box_yesno and so on, but can install gxmessage since that is universally available to pretty much all Linux distros. I like your AppImage approach so I am keen to see it usable not only on Puppy since I don't want to have to develop alternatives.

I guess you better check if Puppy itself has gxmessage - a small addition to woof-CE if it didn't. EDIT: well I just looked in recent vupup and it did contain a binary called gxmessage, so I guess that is available via woof-CE - hope it is not just a cut-down special Puppy version; I haven't checked.

[user1234]

Added README.md (itself created with MarkText). Here is the link- https://github.com/lakshayrohila/markte ... /README.md. Will provide more information about using the portable.

These files have changed-
1. README.md (added)
2. UPDATER
3. .DirIcon (added)

You may copy the contents of these files directly from github to your local files if you already have downloaded the portable. It is recommended that you change to the newer version of LAUNCH.

Otherwise if you have newly downloaded the portable, then no need of any change.

Also note that these sym-links are created after running INSTALL script-
1. LAUNCH -> /usr/bin/MarkText.
2. DATA/resources/marktext.desktop -> /usr/share/applications/
3. DATA/resources/marktext.png -> /usr/share/pixmaps/

[user1234]

the desktop icon did not appear in the menu, and the png did not get associated with the .desktop link in /usr/share/applications, (but that may also be an EasyOs thing also)

Thanks for feedback! Can you explain more about the issue please, like where are .desktop and icons of applications located in EasyOs? The icon not being associated might be the problem due to this line of code-

Code: Select all

Icon=marktext.png

Try changing this to

Code: Select all

Icon=/usr/share/pixmaps/marktext.png

Please tell if this works.

[mikewalsh]

@user1234 :-

The other reason may be that if you want to use just the icon name, rather than using the full $PATH, you must NOT leave the extension (.png, .jpg, etc) in place. Only the name;

Code: Select all

Icon=marktext

.....ought to work. Otherwise, it interferes with the way in which the system searches recognised $PATHs for specific categories, and you end up with an icon name that that has ".png.png" on the end of it. This, of course, is not recognised.....hence, it doesn't show.

(See this example file from the ArchLinux wiki:- https://wiki.archlinux.org/title/Deskto ... le_example )

If using the full $PATH, your example as given is otherwise fine.

Mike.

[fredx181]

Note that for using in KLV-Airedale, which is not a Puppy Linux distro or derivative per se, I needed to modify a couple of lines in UPDATER since KLV doesn't contain the, presumably Puppy specific, box_yesno or box_splash scripts/utilities - maybe you could make your 'AppImage build/creation implementor' somewhat more distro agnostic/universal by using something like gxmessage instead for these afterall very simple splash type notices - so easy to do that - otherwise it is a bit of a nuisance having to convert the simple scripts when not using Puppy Linux itself?

I noticed that gxmessage is not installed by default in KLV-Airedale, perhaps @rockedge forgot ? (hint.... )

[rockedge]

@fredx181 That's weird, I did have gxmessage installed at some stage. I'll have to put it back in!

I use gxmessage in scripts that I can move between distro's so it should be in KLV-Airedale for sure.

After lunch I'll generate a new beta20 ISO with it installed.

[williwaw]

Try changing this to

Code: Select all

Icon=/usr/share/pixmaps/marktext.png

Please tell if this works.

yes, the association is now made.
I also needed to reboot. (there is a command for rebuilding the menus which I have forgotten and neglected)

[wiak]

@fredx181 That's weird, I did have gxmessage installed at some stage. I'll have to put it back in!

I use gxmessage in scripts that I can move between distro's so it should be in KLV-Airedale for sure.

After lunch I'll generate a new beta20 ISO with it installed.

Yes, I thought it was in it. The original 10gtkdialog/filemnt sfs I made needed it since my version of filemnt was modified to use gxmessage rather than the pup utils. When I tried the MarkText portable I believed I was in KLV-Airedale, but turns out I was in Zorin lite full install - I have them set up so identically I never know which I am in unless I glance at the wallpaper...

I just checked the KLV install I have and does seem to be missing gxmessage. Actually still has the filemnt in 10gtkdialogXXX that needs gxmessage - doesn't at a glance (just looking in the 07KLV...) that there is any other filemnt being used so pop-ups from gxmessage would be failing with filemnt use right now; I am sure that used to work so maybe left out in newer build?

[user1234]

I am adding a check if gxmessage is found or not. If not found, maybe use rxvt then?

Is rxvt present in KLV-Airedale @rockedge, EasyOS @BarryK and Fatdog @bigpup/@p310don and maybe other puppy distros?

[wiak]

I am adding a check if gxmessage is found or not. If not found, maybe use rxvt then?

Is rxvt present in KLV-Airedale @rockedge, EasyOS @BarryK and Fatdog @bigpup/@p310don and maybe other puppy distros?

No rxvt in KLV-Airedale - being xfce4 desktop, main terminal is xfce4-terminal, but also has xterm for simpler non-tabbed terminal.

No simple answer but to- choose something (such as gxmessage) that all distros 'could' install and have the program ask for its installation if not present I'd say. Lots of different potential terminal apps out there - that is not a good common ground choice unless your wrapper allowed for a case statement like use of whatever terminal is found on a system as an option to gxmessage. One thing for sure, if you standardize on a special Puppy notify utility/app then you definitely cut out usability on most all other distros but Puppy, and most distros do not have gtkdialog installed by default nor ever will have.

[wiak]

In a different script, for other purposes, I use something like the following to find which terminal the distro has:

Code: Select all

if [ $(command -v rxvt 2>/dev/null) ];then VTERMINAL="rxvt"
elif [ $(command -v xterm 2>/dev/null) ];then VTERMINAL="xterm"
elif [ $(command -v urxvt 2>/dev/null) ];then VTERMINAL="urxvt"
elif [ $(command -v aterm 2>/dev/null) ];then VTERMINAL="aterm"
elif [ $(command -v uxterm 2>/dev/null) ];then VTERMINAL="uxterm"
elif [ $(command -v mrxvt 2>/dev/null) ];then VTERMINAL="mrxvt"
elif [ $(command -v xfce4-terminal 2>/dev/null) ];then VTERMINAL="xfce4-terminal"
elif [ $(command -v lxterminal 2>/dev/null) ];then VTERMINAL="lxterminal"
fi
export VTERMINAL

but maybe better to just force users of that LAUNCH method to install gxmessage...

[user1234]

In a different script, for other purposes, I use something like the following to find which terminal the distro has:

Code: Select all

if [ $(command -v rxvt 2>/dev/null) ];then VTERMINAL="rxvt"
elif [ $(command -v xterm 2>/dev/null) ];then VTERMINAL="xterm"
elif [ $(command -v urxvt 2>/dev/null) ];then VTERMINAL="urxvt"
elif [ $(command -v aterm 2>/dev/null) ];then VTERMINAL="aterm"
elif [ $(command -v uxterm 2>/dev/null) ];then VTERMINAL="uxterm"
elif [ $(command -v mrxvt 2>/dev/null) ];then VTERMINAL="mrxvt"
elif [ $(command -v xfce4-terminal 2>/dev/null) ];then VTERMINAL="xfce4-terminal"
elif [ $(command -v lxterminal 2>/dev/null) ];then VTERMINAL="lxterminal"
fi
export VTERMINAL

but maybe better to just force users of that LAUNCH method to install gxmessage...

Well, that'd be better. But there is a problem. New versions of UPDATER script shows AppImage download progress using rxvt, i.e. run wget ini rxvt. Do you think all of these use -e as command line argument for running a command? And what should I call for running default terminal (in fossapup64 its defaultterminal command to run default terminal)? Otherwise forcing users to use only supported terminals will be the last option.

Maybe I should just install KLV-Airedale and EasyOS myself to check.

[wiak]

Maybe I should just install KLV-Airedale and EasyOS myself to check.

No idea about EasyOS - you would definitely have to check

You can't really rely on a distro assigning a defaultterminal - KLV-Airedale doesn't, but even if it did, others might now. I suppose you could just accept your LAUNCH script and so on limited to certain distros, but if you can make universal obviously better, but certainly you'd need to test whatever you hope for it to support - or rely on feedback from users here (often the best approach). Similarly you'd need to read the man pages for the terminal list if doing it that way or can't test directly if they support -e

[user1234]

Well, seems like there are large number of terminals out there providing different methods to execute a command from command line options, and a large number of desktop environments which provide different methods to execute the default terminal. This kind of un-united diversity makes the life of a programmer hard. Tired of searching about different methods to implement it (with no results), I am left forcing the user to install gxmessage (if /usr/lib/gtkdialog/box_yesno or /usr/lib/gtkdialog/box_splash are not present) and rxvt. Seems like not a big deal to be installed even if they are not present.

[mikewalsh]

@user1234 :-

One option could be to keep copies of those two scripts in the portable itself.

In the launch script, add a section which checks for the existence of those two files. If found, let the script continue; if not, first sym-link them over to the correct location, THEN continue.....

At close, add a line to delete the links again. That's the way I would handle it. Doubtless there's dozens of different approaches you could take, but I tend to find the K.I.S.S principle works best most of the time!

You DO tend to realise, after a while, that scripting is mostly like building with LEGO; aside from the application-specific bits, many sections & clauses can be re-used from other scripts (with modifications, of course).......certainly with relatively simple file-manipulation stuff.

Mike.

[williwaw]

Well, seems like there are large number of terminals out there providing different methods to execute a command from command line options, and a large number of desktop environments which provide different methods to execute the default terminal. This kind of un-united diversity makes the life of a programmer hard. Tired of searching about different methods to implement it (with no results), I am left forcing the user to install gxmessage (if /usr/lib/gtkdialog/box_yesno or /usr/lib/gtkdialog/box_splash are not present) and rxvt. Seems like not a big deal to be installed even if they are not present.

Isn't xterm more universal than most, or at least a symlink to a compatible replacement?

Easy uses Sakura and has xterm. Quite a few terminals take the -e argument but not as many will stay open with the -h argument, as some use -hold or require a certain order to the way multiple arguments are run in the script.

Generally speaking about downloads and many utilities I find in puppy et al.

I like the idea of some feed back during the download process, as some servers are quite slow and dloads of large files often fail on account of my connection which seems to get interrupted frequently. I prefer to use a dedicated download manager for larger downloads. Uget serves me well with Easy.

I can also understand the convenience to having an install script use wget in the background. That said, when I have to resort to downloading in a separate operation, the best I can hope for is to have the install script also recognize the presence of the most recent download and not call wget.

[rockedge]

You can't really rely on a distro assigning a defaultterminal - KLV-Airedale doesn't, but even if it did, others might not.

I have not added a defaultterminal script yet in KLV-Airedale, though there are 7 other /usr/local/bin/default<someapp> scripts mostly to be compatible with programs like the TAS screen shot application to ensure that the buttons work. I do use a defaultterminal script in KLV-Boxer that uses a jwm+Rox desktop instead of xfce4.

In KLV-Airedale it would be easy to add a /usr/local/bin/defaultterminal and then assign that script as a the terminal default system wide in the xfce4 settings.

[wiak]

I would suggest to just do your best to satisfy the most likely distros to use MarkText on this forum. I agree rxvt and xterm would be two good alternatives to cater for assuming the -e or whatever else you need work - maybe xfce4-terminal for a more complex terminal since xfce4 pretty popular nowadays, but not essential - anyone wanting to use your script should be able to get help on the forum to adjust it to work. gxmessage is a good target to encourage since Puppy utils such as box_yesno or whatever it is called, are only going to be found on Pups and I doubt most would want to add these otherwise (or logically even should), whereas gxmessage is pretty useful and universal anyway. It is a pity there is so little even simple standardisation in Linux creations - not even for small items like gxmessage - certainly makes development much trickier. It is messy to have to include binaries when simply wanting to script a good universal AppImage solution. Nevertheless MarkText is a good attempt and points to a better way (simple build script) to implement installation of portable apps more generally that will auto-update.

In existing portable app solutions on this forum, the portable apps suffer from the issue they soon become out-of-date so need regularly manually updated, which is inefficient and painful; at least with your pure scripted solution, once the likes of default required components are sorted out, such as maybe gxmessage, then all thereafter works fine without further future effort. That's why this build script method is so important overall.

[user1234]

@user1234 :-

One option could be to keep copies of those two scripts in the portable itself.

In the launch script, add a section which checks for the existence of those two files. If found, let the script continue; if not, first sym-link them over to the correct location, THEN continue.....

At close, add a line to delete the links again. That's the way I would handle it. Doubtless there's dozens of different approaches you could take, but I tend to find the K.I.S.S principle works best most of the time!

You DO tend to realise, after a while, that scripting is mostly like building with LEGO; aside from the application-specific bits, many sections & clauses can be re-used from other scripts (with modifications, of course).......certainly with relatively simple file-manipulation stuff.

Mike.

Thanks for the suggestion! But I feel like making the user themselves install these applications since they are not very big in size and can be useful a lot of times (at least gxmessage will be useful).

Well, seems like there are large number of terminals out there providing different methods to execute a command from command line options, and a large number of desktop environments which provide different methods to execute the default terminal. This kind of un-united diversity makes the life of a programmer hard. Tired of searching about different methods to implement it (with no results), I am left forcing the user to install gxmessage (if /usr/lib/gtkdialog/box_yesno or /usr/lib/gtkdialog/box_splash are not present) and rxvt. Seems like not a big deal to be installed even if they are not present.

Isn't xterm more universal than most, or at least a symlink to a compatible replacement?

Easy uses Sakura and has xterm. Quite a few terminals take the -e argument but not as many will stay open with the -h argument, as some use -hold or require a certain order to the way multiple arguments are run in the script.

Generally speaking about downloads and many utilities I find in puppy et al.

I like the idea of some feed back during the download process, as some servers are quite slow and dloads of large files often fail on account of my connection which seems to get interrupted frequently. I prefer to use a dedicated download manager for larger downloads. Uget serves me well with Easy.

I can also understand the convenience to having an install script use wget in the background. That said, when I have to resort to downloading in a separate operation, the best I can hope for is to have the install script also recognize the presence of the most recent download and not call wget.

Thanks for the suggestion! But sym-links to xterm are the problem (as I see it). For example, in fossapup xterm is sym-link to urxvt. Now urxvt uses -e for executing commands. Looking at xterm's manpage, I see that xterm also uses -e for executing commands. But what if the sym-link to xterm was of a terminal which didn't use -e for executing command? Very difficult to say if sym-links are made taking few things in consideration or not, just depends on the person who created them.

That's why I have mentioned them as requirements in the README.md and added some checks in the scripts to check if they are present on the user's computer.

[puppy_apprentice]

I myself all my AppImage apps have converted to SFS. So it was easily to add them to menu. AppImage app is placed in /opt/AppName/