Tiny Core Linux
General TC => Programming & Scripting - Unofficial => Topic started by: GNUser on March 12, 2020, 10:49:53 AM
-
I wanted my GUI applications to open files using my preferred applications, but I didn't want to install the (overly complex) xdg-utils extension.
So I forked the linopen shell script (see https://wiki.archlinux.org/index.php/Default_applications), took out all the bashisms and GNUisms, and rebaptized it as tinyopen. (Rich helped with the most difficult step which was to find a workaround for BusyBox ps's missing "+" mark for foreground processes). All you need to use tinyopen instead of xdg-open is to put the script somewhere in your PATH and make xdg-open be a symlink to the script. Filetype associations are managed in ~/.config/tinyopenrc
https://github.com/bdantas/tinyopen
Some applications ignore xdg-open completely and, instead, they parse ~/.config/mimeapps.list (some older applications still look for this file in its old, deprecated location: ~/.local/share/applications/mimeapps.list). To satisfy these applications, manually create ~/.config/mimepps.list and make ~/.local/share/applications/mimeapps.list a symlink to it.
That's all there's to it :) Now you can manage all your filetype associations right in ~/.config by touching only two files:
1. ~/.config/tinyopenrc for applications that use xdg-open
2. ~/.config/mimeapps.list for applications that directly parse this file or its symlink at ~/.local/share/applications/mimeapps.list
-
Well, just like the deep breath of clear air, thanks a lot!
-
You're welcome, jazzbiker. I hope you find it useful.
Because TCL is so uncluttered, it has helped me understand many things that seemed hopelessly complicated before (such as filetype associations). TCL rocks.
-
I realized that I don't like having to manage two separate config files (~/.config/tinyopenrc for the set of applications that use xdg-open, ~/.config/mimeapps.list for the separate set of applications that use the XDG standard). I want to manage only ~/.config/tinyopenrc! ;D
So I created /usr/local/share/applications/xdg-open.desktop, which is trivial and looks like this:
[Desktop Entry]
Name=xdg-open
Exec=xdg-open
Icon=xdg-open
Type=Application
Categories=Utility;
Then I went here to get a list of all existing MIME types: https://www.iana.org/assignments/media-types/media-types.xhtml
With the complete list, I created a ~/.config/mimeapps.list that associates every existing MIME type with xdg-open.desktop.
My ~/.config/mimeapps.list is here: http://files.dantas.airpost.net/public/mimeapps.list
So there you go. Now I manage all my filetype associations in one place: ~/.config/tinyopenrc 8)
-
HI @GNUser
can you re-check link for http://files.dantas.airpost.net/public/mimeapps.list
going up one level I am none the wiser
http://files.dantas.airpost.net/public/
-
Hi, aus9. All you need (including mimeapps.list and a script that sets up everything for you) is here now:
https://github.com/bdantas/tinyopen
-
Please note that on TCL the mime-links script needs to be run at every boot (e.g., via a job in ~/.X.d/). Also, obviously, the mime directory needs to be somewhere with persistence (e.g., in /opt or /home) or added to your backup via .filetool.lst and filetool.sh -b.
-
sorry for the delay. Just downloaded it
Some questions if you do not mind?
1) Was this script originally designed for a prefix=/usr type distro?
2) If so, is that the reason why mime-links appears to want to link
tinyopen to /usr/bin/xdg-open? (and similar pathways)
and
sudo mkdir -p /usr/share/applications
When AFAIK, anyone running a WM or Gnome are likely already have
/usr/local/share/applications
3) AFAIK TC64 desktops are perm 644. Why do we need to change to 755?
chmod a+x $mime_dir/mimeapps-open.desktop
4) what am I supposed to define for "_TINYOPEN_CFGARG=" please?
I am sorry if this looks picky....but I need your script to fix up a mess caused by me running a certain package that breaks pristine state that re-creates .config/mimeapps.list
It is a web browser....and I prefer to keep it
I am hoping you will work out my issues and then you can submit a TCE if interested?
-
I am sorry if this looks picky....
No worries. I'm happy to help.
1) No, I designed the script for my personal use on TCL.
2) I did everything in a distro-agnostic way. /usr is a more common prefix than /usr/local, so that's why I chose /usr. But it honestly makes no difference--you can change every /usr in the tinycore "suite" to /usr/local if you prefer. The only important thing is that when you run which xdg-open in a terminal, the result you get is the link to tinyopen and not the "real" xdg-open (if it's installed).
Every mkdir in the script is there just to be safe. Because of the distro-agnostic nature of the script, I didn't want to make any assumptions.
3) If a .desktop file isn't marked executable, applications and desktop environments will ignore them. Try it and you'll see what I mean.
4) Nothing. You can leave it blank. I'll edit the script on github to clarify that.
Please go ahead and give it a try. It's hard to break a TCL system because rebooting performs a "factory reset" (plus customizations via bootcodes, onboot.lst, mydata.tgz, and startup jobs in /opt/boot*.sh and ~/.X.d/).
-
thanks spotted another one for you maybe?
_TINYOPEN_CFGRC="$HERE/tinyopenrc"
_TINYOPEN_CFGSYS="/etc/tinyopen.conf" # this does not have to exist (just $HOME/.config/tinyopenrc is sufficient))
It looks to me you are saying if someone has a system wide config, they could rename and place the rc file under etc/ as tinyopen.conf....CHECK
if not found....the home config rc file is at our pwd.....but above it appears to me you are suggesting that is
.config/
but I understand your README differently as you appear to say
1. Put the attached `mime` directory with its 4 files anywhere on your system
and that rc file unpacks to a dir called mime.
And sorry to be anal....that means it can not be .config but somewhere else?
-
Thanks for catching that. I went ahead and deleted the unused variables and misleading comments from the tinyopen script.
The tinyopen script and its config file should both be in the mime directory, as stated in the README.
There's nothing you need other than the mime directory (and its contents) and the mime-links script.
-
I went ahead with my usr/local pathways and testing in spacefm works really well. I know you have mentioned that web browsers and file manager "make up their own rules", so my web browser still complains on start up which I can live with.
Luckily I found a command to fix pcmanfm, from desktop-file-utils
update-desktop-database ~/.local/share/applications
sorry if I drift off topic but hope this helps TC members
-
my web browser still complains on start up which I can live with.
You shouldn't have to live with it if you don't like it :) Which web browser do you use? What is it complaining about?
If the complaint has something to do with filetype associations, a general fix might go something like this:
open the browser -> Edit -> Preferences -> Preferred Applications -> manually associate all filetypes with tinyopen
-
P.S. If there are an additional one or two users who would be interested in tinyopen as a TCL extension, I'd be happy to put one together. Just let me know.
-
I gave tinyopen another overhaul and submitted it as an extension for TCL11.x x86_64 (it's just a shell script, so it would work in other architectures as well).
Now it's dead simple to use:
1. Load the extension
2. Edit ~/.config/tinyopen.conf to your liking
PS: The extension works differently (more polished) than the tinyopen version on my GitHub page, so please disregard the documentation on GitHub. The documentation in the .info file is correct for the TCL extension.
PS2: I will attach the extension and .info file here for convenience. The only dependency is glib2.tcz.
-
thanks!!! ...
Well, just like the deep breath of clear air, thanks a lot!
+1
.. ftr the git hub link is mort
this is the current working url
https://gitlab.com/GNUser/tinyopen
perhaps this should/could be included in tinyopen.tcz.info
-
You're welcome, mocore. The latest version is 5.0 is available in the TCL13.1 x86_64 repository and has the correct (gitlab) url.