search

puppylinux-woof-CE / woof-CE

woof - the Puppy builder
GNU General Public License v2.0
399 stars 288 forks source link

Attempting to make rox-filer file association xdg-desktop compliant #1546

Closed rizalmart closed 5 years ago

rizalmart commented 5 years ago

We already know that rox filer has a unique file association management compared to Thunar, PCManFM, etc. It was non xdg-desktop compliant. This was very troublesome when installing pet packages or loading sfs modules where its file associations don't work well on rox and it requires manually associating every file type. Also recently, the Puppy Package Manager and sfs_load can now process xdg file associations.

I created an approach in order to make rox-filer xdg compliant so the file associations can be easily configured when when installing pet packages or loading sfs modules. It was now under pull request in woof-ce.

  1. Instead of creating a script in every mimetype in /root/Choices/MIME-types. Just only 5 scripts will do the job:

/root/Choices/MIME-types/audio /root/Choices/MIME-types/video /root/Choices/MIME-types/image /root/Choices/MIME-types/application /root/Choices/MIME-types/text

Those scripts will call the /usr/bin/rox-xdg-open script

  1. The rox-xdg-open script will just search for appropriate program associated with the file by searching at mimeapps.list and mimeinfo.cache. This is the hierarchy of search

/root/.local/share/applications/mimeapps.list /root/.local/share/applications/mimeinfo.cache /usr/share/applications/mimeapps.list /usr/share/applications/mimeinfo.cache /usr/local/share/applications/mimeapps.list /usr/local/share/applications/mimeinfo.cache

First program found win and will execute

  1. When a package was install/remove or load/unload sfs modules. It calls sync-rox-icons script to synchronize the rox file icon with mimetype icons in /usr/share/icons
wdlkmpx commented 5 years ago

https://github.com/puppylinux-woof-CE/woof-CE/pull/1545/files#diff-f989c51dabfbe4a00f3454faf973c91dR7

gvfs, that application is usually included when rox is replaced by a file manager from one of the known DE's. It's not included in any of the default builds.

rox has many capabilities just like pcmanfm, it can be tweaked to support extra stuff, but the amount of time and effort to do that is the problem.

I'm not exactly a rox user, but I do use it sometimes, and I can see a massive reaction to the proposed changes. Because rox doesn't support xdg, and I don't see it working that way.

I haven't read all the scripts, but rox is not designed to be xdg-compliant, but I guess a hack can be added, a "translation layer" that differs from the proposed changes.

I'm not sure how pcmanfm works, but it currently seems to support both mimeapps.list and mimeinfo.cache, and the priority goes to mimeapps.list. That's why my stuff works and mimeinfo.cache provides extra info that is used to add more menu items to the context menus and extra default apps when mimeapps.list doesn't provide any default app.

This pcmanfm stuff is currently only used in dpup stretch, I could not bother to make it global and then receive complaints, and it implements the default applications chooser (puppyapps (defaults-chooser), pmime (/etc/pmime.conf)).

rox doesn't work that way, people might want to add default apps and associations... which are scripts.

Currently rox reads stuff from:

I think another special directory could be added

This directory could be deleted and recreated by a special and simple script. With the lowest priority for rox, allowing people to use rox itself to create default applications and file associations that are not overridden.

Where a "translation" happens, that special script could read mimeapps.list and mimeinfo.cache and write to /etc/true-xdg/rox.sourceforge.net/.., that way a simple script could provide all the needed support for rox xdg:

This approach will require changes in rox itself (might be easy) and a simple script to translate mimeapps.list and mimeinfo.cache to something rox understands (update-desktop-database-rox).

I don't know much about rox and its code, these are just ideas, and I guess it could be the right approach, another approach is to rewrite many parts of rox. I personally think that pcmanfm is the ultimate file manager, above all other file managers, thunar is crap compared to pcmanfm.

rizalmart commented 5 years ago

if gvfs was not included then we need a script that determines the mimetype according to /usr/share/mime. I tried file command but it does not return the proper mimetype.

For now syncing rox icons was viable and mergeable to the woof

PCManFM is good but the problem was on networking. when connecting to a public shared folder on lan or public ftp. It still requires password even the it has no password

wdlkmpx commented 5 years ago

rox can determine the mimetype, that's why a "translation layer" to convert mimeapps.list and mimeinfo.cache to something that rox can understand makes more sense.

Speed is always important, optimizing this kind of code is a priority, so that conversion should be fast enough.

A simple script that reads both files and creates rox file associations. that's quite easy to do, but those generated files should be in a special directory that rox should read and use it as a last resort if everything else fails, this is where understanding how rox works comes into play.. yes understanding the source code.

rizalmart commented 5 years ago

I think we need to contact woodenshoe-wi for modifying the source code or I will try to send pull request on his rox-filer modifications

wdlkmpx commented 5 years ago

Well I have a clear idea of what can be done and how can be done, but there is code that I haven't read.

I see this: https://github.com/woodenshoe-wi/rox-filer/blob/master/ROX-Filer/src/choices.c#L106

I'll perform some tests to see if I can apply any of my ideas, this is quite simple and should be fast enough, changing defaultfilemanager

wdlkmpx commented 5 years ago

I just realized something that I don't remember seeing before.

rox seems to recognize some apps, but I don't see where they were added as file associations, mpv, gnome-mplayer, deadbeef, audacity

I'm checking the desktop files, it seems to be getting that info from the desktop files, but how

pmime also populates /etc/mailcap. rox is getting info from somewhere, but how

wdlkmpx commented 5 years ago

I have created the special script to "convert" mimeinfo.cache to rox stuff, it creates 1260+ files (scripts and directories) in 3 seconds, in a pentium4 pc. I think it's fast enough. The conversion or translation is accurate.

Now I have to read rox's source code to understand how it works.. or maybe the man page explains it?

However this rox version is xdg-compliant, I see stuff that just shouldn't be there, stuff that should appear only in pcmanfm: Screenshot Screenshot(1)

It's reading mimeinfo.cache, I don't how good it handles that info, but see the screenshots https://github.com/woodenshoe-wi/rox-filer/blob/master/ROX-Filer/src/menu.c#L1787

This is thanks to woodenshoe-wi for providing a usable version of rox and thanks to you for creating the update-desktop-database script.

wdlkmpx commented 5 years ago

Now we know that rox-woodenshoe is xdg-compliant, at least it's what I see.

If it fails to show something that pcmanfm does show, it's probably due to a bug in rox itself.

There's no need to add hacks or special scripts, it's time for those C programmers out there to improve rox itself.

rizalmart commented 5 years ago

@wdlkmpx thats nice. However based on source code. It reads mimeinfo.cache only. It needs to read mimeapps.list or defaults.list first to find the users preferred default program for the file. Also woodenshoe-wi must add another window for managing default apps for selected file by read and writing mimeapps.list

rizalmart commented 5 years ago

@wdlkmpx too bad that @woodenshoe-wi was very busy at this moment based on his reply on this github repo

wdlkmpx commented 5 years ago

Perhaps mimeapps.list is not as generic as mimeinfo.cache, which contains accurate data, in the rootfs-skeleton scripts that file is deleted and recreated with fresh info.

As I said before, I had issues with mimeinfo.cache, but a recent version of pcmanfm and dependencies handle it perfectly. The good thing about pcmanfm and the whole gtk lxde desktop, is that it compiles in old and new distros, so using the latest version is a must.

In dpup mimeapps.list contains valid and invalid apps, pcmanfm can determine if a desktop file contains a invalid Exec= and hide it on-the-fly. But I'm not sure how it works, there's a daemon, menu-cached, that probably monitors files and directories and determines stuff.

My pmime.conf stuff just adds a lot of default apps and file associations (.desktop, mimeapps.list), it also implements the defaults-chooser stuff.. Puppy has a long history of rewriting .desktop files with custom ones that lack MimeType=

This overrides the compat distro geany.desktop (this doesn't apply in zwn): https://github.com/puppylinux-woof-CE/woof-CE/blob/master/woof-code/packages-templates/geany_FIXUPHACK

The geany.petbuild does look good: https://github.com/puppylinux-woof-CE/petbuilds/blob/slacko_142/geany/geany.desktop#L84

But that custom geany.desktop should not exist. Scripts should only sed the desktop files to replace Categories=, sometimes Icon= and Name= .. nothing else.

By fixing that issue, mimeinfo.cache will produce something bigger and pcmanfm and rox will show more items in the 'Open with' menus.

There's a lot of work to do. And all of these changes require new ISOs.

wdlkmpx commented 5 years ago

I see the pull requests and I'm thinking. Hmm. Hmmm. Hmmmm. Hmmmmm.

This is what we know:

  1. rox identifies mimetypes
  2. rox can "run" .desktop files
  3. rox can understand mimeinfo.cache

I was not aware of 2. and 3. Well, I think I was partially aware of 2.

So there's no need to write complex routines to implement stuff, it's already implemented, and I think it's possible to tweak rox itself.

I've always thought that rox behavior should be altered.. just a bit. So that less hacks are needed. It's possible.

wdlkmpx commented 5 years ago

There is something going on.

When you open a file, rox also reads mimeapps.list, but apparently does not find the mimetype there.

I implemented the desired feature adding about 110 lines to run.c

I deleted the ROX file associations for audio/mp4 so I can test this stuff.

This is what I see when I open a .mp4 file:

# roxfiler /mnt/sda3/a.mp4 
/root/.local/share/applications/mimeapps.list
/usr/share/applications/mimeapps.list
/usr/local/share/applications/mimeapps.list
- /root/.local/share/applications/mimeinfo.cache
- /usr/share/applications/mimeinfo.cache
+++/usr/share/applications/ffconvert.desktop
- /usr/local/share/applications/mimeinfo.cache

As we can see rox reads mimeapps.list, I added the lines that start with '-' and '+++'

So with this change, rox now also looks in mimeinfo.cache (as a last resort) and opens the file with the first .desktop it finds.

In this case rox opens a.mp4 with the wrong application: ffconvert ... it's the first match.

wdlkmpx commented 5 years ago

Facts

When you open a file, rox

If that fails, rox

The mimeapps.list I use is created by pmime, it "implements" the .desktop part of puppyapps or defaults applications chooser

Opening a.mp4

# roxfiler /mnt/sda3/a.mp4 
/root/.local/share/applications/mimeapps.list
/usr/share/applications/mimeapps.list
** /usr/share/applications/defaultmediaplayer.desktop
GMLIB-Message: after init: position=0.000 length=0.000 start_time=0.000 run_time=0.000 volume=0.00 player=dead media=unknown uri=

As we can see it detected defaultmediaplayer.desktop

But for some reason that file was deleted, so it got ignored. So I had to restore it, and it works now.

ROX currently doesn't look in mimeinfo.cache to open a file with a "default application", I can produce a patch for that.

wdlkmpx commented 5 years ago

Now some philosophy.

Woofce uses the same rox version in all builds, it's called centralization. It's good and bad at the same time. Other rox versions are simply not supported.

What I see is a usable rox as it is now, in the past I had expressed an intense hatred and wanted to erase ROX from existence. I'm sure people remember my psychotic outbreaks. I still think most new users will find rox very strange, but usable.. the latest version used by woofce of course.

Now.. mimeinfo.cache: rox supports mimeinfo.cache for the File context menu (open with).

But it doesn't read mimeinfo.cache when you click on a file, and I can see why, it may open an inadequate program (ffconvert instead of gnome-mplayer).

I remember my brother had this problem years ago, he had to configure stuff to get proper apps to open certain file types. So automatic handling may annoy people in some cases.

wdlkmpx commented 5 years ago

See the referenced pull request. That makes rox itself behave dangerously close to rox-xdg-open.

wdlkmpx commented 5 years ago

PR https://github.com/woodenshoe-wi/rox-filer/pull/6 "finishes" the implementation of 'rox-xdg-open' within rox

Basically rox first checks if the file to be opened can be handled with its native file associations, otherwise xdg compliance applies..

woodenshoe-wi commented 5 years ago

But it doesn't read mimeinfo.cache when you click on a file, and I can see why, it may open an inadequate program (ffconvert instead of gnome-mplayer).

I was thinking that a completely automatic configuration couldn’t work for that reason. Maybe it could work if only one program was found, otherwise pop up a dialogue with all the options and ask the user to choose a default. I think that is how Other Operating Systems handle it.

Maybe we need to re-brand “rox-woodenshoe“ as “ROX-Classic” (because support for the older compilers in older distros is a requirement) and start incrementing the version number when new releases/pets are made.

I don’t want to become the de-facto maintainer of a “ROX-Classic” since I only have time to work on it four months of the year, but maybe a kind of unconventional decentralized approach could work? Whoever made the last changes would increment the version and make the pets. If anyone else wanted to make changes they would check the GitHub Network graph and make sure they merged any changes that were not a work in progress to their own fork before they started work.

I still have ideas about things I want to add or change in ROX, but I have the feeling that some people that know c programming might want to make changes when I don’t have time to work on it. Kind of ironic that someone who didn’t like ROX is now reading the code 😀 but one thing I noticed was that sometimes something almost works, and it is annoying because it isn’t working right, and you read the code and can tell what they were trying to do, and when you figure out how to make it work right you actually like the program more after it is fixed than before when it was buggy. It is definitely a lot easier to fix a few annoying bugs and implement a few missing features than writing something that complex from scratch.

wdlkmpx commented 5 years ago

I think it's "ROX-classic" because it simply does not use the latest glib/pango/cairo/whatever functions, because even old compilers compile that stuff, but errors occur when implicit declarations happen and no symbols are found.

Probably all rox versions are classic versions with the possible exception of jun's, as I was not able to compile it in precise years ago, even after fixing compatibility rox showed weird stuff. But if it's not a gtk3 app, it should probably compile in older distros... not so old of course.

That's why I kind of don't like glib. For the first pull request, I had a bit different code, using access() and a few other low level functions, but then saw the glib code a few lines above and then copied and pasted. Gtk apps rely too much on glib, or completely.

"rox-w" sounds about right. It could mean many things including woof, wiki.

The good thing about git repos and sites like github, is that you can share and/or delegate responsibilities until disagreements happen haha, just give me write access to your repo and I'll make a few changes.

This project offers many file associations by default (native rox file associations), so in this particular case, it might not be that bad to use a rox that can become automatic with some exotic stuff. I'll make pmime.conf more generic, to avoid surprises.

I'll also update the rox xdgmime stuff, but the problem is in freedesktop.xml, they just add weird stuff, but I think it gets fixed in later versions, so using the shared-mime-info pet pkg might be the right thing to do.

But after some thought, things may be reconsidered. Hmm. Hmmm...

wdlkmpx commented 5 years ago

This is off-topic but perhaps rizalmart can help fix/improve/rewrite a few gui apps.

This script can be improved: https://github.com/puppylinux-woof-CE/petbuilds/blob/generic/basic/pkgs/pure-ftpd/run-pureftpd

It can be converted to yad or gtkdialog, and include a few more options (i.e. directory to share). $HOME/.ftpd is probably hard-coded? Can be a symlink to the actual dir.

Etc, let me know if you need more challenges..

woodenshoe-wi commented 5 years ago

I had changed some code to match what was in the jun7 fork and was surprised that it failed to compile in slako 14.0 because with the old compiler you can’t declare a variable in the () part of a for loop. woodenshoe-wi/rox-filer@f6f1e5c So it is more than just what library versions are required.

As far as I know there wasn’t any active development on any forks other than jun7’s when I started working on ROX.

If you want to call it rox-w and keep it on your GitHub page or have it added to puppylinux-woof-CE that is fine too. I can also delete and re-fork the repo on my GitHub page so that it isn’t the root repo if you want.

I consider my GitHub page to be my personal page, not a suburb of woof-CE and I do not intend to give anyone write access to any repos there.

When Linus Torvalds wrote git, he specifically designed it so that it could be used in a decentralized manner. GitHub and apparently everyone else who wants to teach you how to use git will tell you all about these wonderful methods to organize and control projects in a centralized way. You talk about “share and/or delegate responsibilities until disagreements happen”, in a centralized project that is bound to happen pretty quickly.

I think I benefit from jun7’s fork because if I run into a problem I can look at how jun7 fixed it. In return, I try to make the improvements that I make available to jun7. This does not mean that I intend to include all the changes jun7 makes, or that I expect jun7 to include all of my changes.

The conventional wisdom is that splitting development of a project into two competing forks harms the project, and it is done only as a last resort after a big argument with a lot of bad feelings. I think the harm comes from the big argument and bad feelings, and if the project was intentionally decentralized from the beginning with each developer making their own decisions about which changes to include it might be able to benefit from a phenomenon called “collective intelligence”. https://en.wikipedia.org/wiki/Collective_intelligence This approach probably wouldn’t work with libraries, unless everyone agrees on a specific API, but starting with whichever fork you think is best and merging whatever changes you think have merit might have an advantage over letting a central group make all the decisions or arguing about everything.

There is a saying about too many cooks in the kitchen, https://knowyourphrase.com/too-many-cooks-in-the-kitchen and some of us are more comfortable working alone.

wdlkmpx commented 5 years ago

Well it can be forked to woof-CE. I'm not interested in implementing a lot of things, just want to address the issue raised by rizalmart.

But in the end, trying to keep the same level of support for the old distros is probably not a good idea.. at all.

I think many apps use for (int i=0;... I haven't tested but it's strange, it's about standards.. there are several standards, C99 allows that, I think. I'm certainly no C expert, I only look at C code when I have to fix something, last time I used it to create something was many months to code a C irc bot. I'm no C coder, but somehow I can understand it a bit even when I almost never use it

woodenshoe-wi commented 5 years ago

Since ROX-Filer is mostly older code, I don’t think it would be hard to keep supporting the old distros, just make sure you compile your new changes in an old distro to check, but you shouldn’t have trouble with the existing code.

It is the actively developed programs that are more problematic, all the new code has only been compiled with newer compilers, and people may be adding features that depend on newer libraries.

On a somewhat related note, this spring I was working on enhancing the icon auto placement functionality in ROX-Filer when I started having computer problems and didn’t finish thoroughly testing it. The changes are in the desktop-drive-icon branch, and as far as I know it is working correctly. I do have pets on the “Releases” tab of my ROX-Filer GitHub page, but they don’t have the latest bugfix so you may want to compile it yourself if you are using a single core machine. https://github.com/woodenshoe-wi/rox-filer/tree/desktop-drive-icons

I made the needed modifications to the woof scripts (frontend_rox_funcs and eventmanager) into a commit, but it is based on the version of woof-CE you used for your raspi build. That was the most recent build that I tested the changes in. https://github.com/woodenshoe-wi/woof-CE/commit/bc76e3fe78bbd8baae0970771602e31d0622e412 You might have to cherry pick it, because the raspi build was from the experimental branch. I don’t follow what is going on with the woof branches enough to know what happened to experimental.

I don’t know if you are interested in these changes, but I thought I would bring them up if you are planning to work on ROX-Filer.

wdlkmpx commented 5 years ago

I didn't know about those changes, I'll take a look and I'll try to merge them. I'll do my best to merge them. That certainly looks good.

But there are always side effects.

Making puppy very friendly with desktop files forces rox users to check and understand .desktop files and how xdg desktop works, many will not know why there are duplicate entries in the File-> menu

rox does understand mimeinfo.cache, but when that file is created rox will modify its behavior.

Commit https://github.com/puppylinux-woof-CE/woof-CE/commit/a360e835e9459f6a7f0481427d127c4f6d69e1d5 deletes all the UExtract rox file associations (not default app) because uextract includes a desktop file that list about 141 mimetypes.

rox users will not be pleased.

wdlkmpx commented 5 years ago

rox does something really remarkable when it reads the desktop files listed in mimeinfo.cache.

It displays icons without using globicons or the famous rox apps.. to do that it must search for the icon in the icon theme and hicolor and /usr/share/pixmaps probably?

It just means that all needed code to handle desktop files is already there.

Obviously the next philosophical, religious and metaphorical debate: desktop files (files) vs rox apps (directories)

Is guess it will always be taboo.

wdlkmpx commented 5 years ago

Long story short:

Side effects:

Possible outcome:

rizalmart commented 5 years ago

Is it only applicable on woodenshoe-wi build only? Or applicable to all rox filer builds?

wdlkmpx commented 5 years ago

I don't know. I guess it applies to woodenshoe-wi's and jun7's builds. That's why when testing stuff for woofce it must be in a recent woofce iso. Things change, and it can be good and bad.

As I said, we have to be careful, rox implements an alternate desktop to the xdg, I see that perhaps in other distros rox users are used to deal with .desktop files, but in puppy rox users usually only care about roxapps and native file associations. No xdg beyond mimetypes recognition.

Even though rox natively supports freedesktop this can lead to another flame war, because puppy rox users are not used to see stuff that everyone else sees..

woodenshoe-wi commented 5 years ago

The support for desktop files came from dtomas‘s fork. As far as I know it was never merged into jun7’s fork.

The desktop file support can be disabled with a checkbox in the “Menus” section of the Options dialogue.

I think I have a fix for the duplicate menu entries. I haven’t tested this much, but it seems to work: woodenshoe-wi/rox-filer@7457fc9

wdlkmpx commented 5 years ago

Yes that fixes the issue. rox-filer-17w is looking good

Sometimes even pcmanfm displays 2 duplicate entries (see notepad in the screenshot above), the patch even fixes that extra issue in rox-filer

wdlkmpx commented 5 years ago

Testing the half-automatic placement, I found it a bit confusing, and these seem to be some proper defaults Screenshot(4)

I see it changes some rox-filer options, pinboard_*_margin: /root/.config/rox.sourceforge.net/ROX-Filer/Options

I haven't tested with 20+ partitions, but I see it will no longer be incredibly slow after a few partitions.

So far the tests look good, the new eventmanager stuff is a bit confusing, but I guess it makes sense, it's changing some rox settings outside rox, and using already available options to make stuff faster.

I think $ICON_PLACE_START_GAP (/etc/eventmanager) is ignored

wdlkmpx commented 5 years ago

The current stuff in the rox-filer repo seems to be enough for the next release.

I'm reluctant to merge the patch for extending the automatic opening of files using mimeinfo.cache "as a last resort". Because we have to be careful, it could puncture the hull of a battle ship leaving thousands to drown at sea, because it's so sharp.

And currently I have no way of doing that, I accidentally deleted myself as a collaborator while I was playing with the settings in my tablet. I was half-awake. Hopefully that will be fixed soon

woodenshoe-wi commented 5 years ago

Because mimeapps.list and mimeinfo.cach are not ROX specific, maybe a stand-alone gtkdialogue/yad app that would make it easy for users to configure their mimeapps.list based on the entries in mimeinfo.cach would work better?

If the app could also open a file name given as an argument with the user’s choice of program, ROX would only need to be modified to call the helper script as a last resort, and the user would be able to choose between the available programs instead of a possible nonfunctional automatic pick.

wdlkmpx commented 5 years ago

Windows shows you a dialog with applications when there is no default app, so you can choose which app to run and/or set as default app.

In android ZArchiver follows the same logic.

In Linux, I've never seen pcmanfm showing a dialog like that, it only shows a dialog with all the recognized apps (by category) when you try to open a file that doesn't have file associations at all, otherwise it just runs one of the associated apps or maybe even the 1st match in mimeinfo.cache (need to verify this).

I guess what's already there is enough, no need to apply my 2 extra patches, unless a new configuration option is added, but I don't know how to do that.

I certainly don't have the latest pcmanfm version, maybe some big changes happened. But rox implements the risc os desktop or something, all the major linux DE's follow freedesktop, so when configuring freedesktop stuff, it will apply to all DE's.

woodenshoe-wi commented 5 years ago

ROX-Filer was originally part of a larger ROX-Desktop suite of apps. One of the apps was a MIME rule editor, and there still is a button labeled “Edit MIME rules” in the “Types” section of the ROX-Filer Options dialogue.

I think I once went through the hassle of getting the 0launch/0install stuff working to try out the MIME rule editor, but I wasn’t impressed and think something of equivalent functionality could be written with gtkdialogue or yad.

I do have a little time in the evenings now, and if someone is interested in writing a MIME rule editor I could see if I can change the way ROX handles the MIME rule editor to work the same way that the terminal editor can be configured.

If the MIME rule editor would also have the ability to open a file given as an argument with the user’s choice of application and optionally make it the default, most of the needed functionality could be implemented outside of ROX-Filer.

wdlkmpx commented 5 years ago

Something like this:

yad --icons --read-dir=/usr/share/applications --width=640 --height=480 --compact

(using yad 0.42.1 from the common32/64 repo)

Some sort of plugin. I see where the call to that plugin goes, it's where my patch to read mimeinfo.cache goes. Instead it should call a script that gives the user the choice to run or set an app as default.. using the desktop files specified in mimeinfo.cache.

It might not be that hard but it would be quite easy if yad --icons printed the .desktop file name when clicking on ok.

There is code in update-desktop-database (script) that can be reused for other purposes.

woodenshoe-wi commented 5 years ago

Here is something for a start, woodenshoe-wi/rox-filer@f7a93a6

But I couldn’t figure out how to guarantee that the file name is always passed as a single argument. ROX seems to always use sh -c to run things, and it seems to only pay attention to the first argument so I used g_strconcat to join the arguments using spaces. This means that if there is white space in the file name or path it gets broken up.

I don’t know if it would be easier to figure out how to pass the arguments directly or escape the file names, but it is past 2:00 in the morning here so I’m stopping.

woodenshoe-wi commented 5 years ago

I think I have it working correctly now. woodenshoe-wi/rox-filer@34f46e1

The file name is now quoted using g_shell_quote and I changed it to use %f and %m to pass the arguments instead of hard coding $1...

woodenshoe-wi commented 5 years ago

After further testing it was still incorrect, I had switched to passing the arguments directly AND quoted the file name.

This should fix it, woodenshoe-wi/rox-filer@eade08f

woodenshoe-wi commented 5 years ago

What is the current status?

Should I issue pull requests for
https://github.com/woodenshoe-wi/rox-filer/tree/fix-duplicate-sendto
and https://github.com/woodenshoe-wi/rox-filer/tree/run-action-helper

@wdlkmpx wrote:

And currently I have no way of doing that, I accidentally deleted myself as a collaborator while I was playing with the settings in my tablet. I was half-awake. Hopefully that will be fixed soon

Has this been fixed?

wdlkmpx commented 5 years ago

This is already merged: https://github.com/woodenshoe-wi/rox-filer/tree/fix-duplicate-sendto

I verified that I have write access by merging https://github.com/woodenshoe-wi/rox-filer/tree/run-action-helper

see https://github.com/puppylinux-woof-CE/rox-filer

I no longer can change settings and stuff, but I can push commits.

I'm yet to test the run-action-helper script and will provide feedback

woodenshoe-wi commented 5 years ago

Ok, now I see the ‘Fix duplicate "open with" menu entries’ commit. It was underneath some older commits.

I’m not familiar with yad, but I have a proof of concept script written in bash/gtkdialogue if anyone is interested.

wdlkmpx commented 5 years ago

Well, the yad --icons stuff is not customizable and doesn't print the desktop file, so I guess it's only to view icons. I'm not familiar with yad either, but it's easier to remember command line switches than html code.

Yes I'm interested, I'll test it and see it's enough or requires some improvements (this is when I can help)

woodenshoe-wi commented 5 years ago

You probably will want to modify it to store the desktop file name in the hidden tree view column instead of the Exec action so that it would be easier to set the default in mimeapps.list.

I couldn’t get gtkdialogue to show icons with absolute paths, but even an svg icon worked when it was in the default icon directory.

Yes, it will definitely need some improvements, but l’m hoping that it will be easier to make improvements to a script than in GTK C code as part of ROX-Filer.

It uses bash arrays to parse the Exec command arguments, and it seems to work with file names that have spaces and quotes.

#!/bin/bash

# Reads all desktop files in /usr/share/applications.
# Desktop file Icon entries with absolute paths are not supported.
# Desktop file Path and Terminal keys are not implemented,
# but probably could be.
# Implementation is not complete or standards compliant.

[ -z $GTKDIALOG ] && GTKDIALOG=gtkdialog

while [ "$1" != "" ]
do
    case $1 in
        -f|--file)
            shift
            filename=$1
            shift
            continue
            ;;
        -m|--mimetype)
            shift
            mimetype=$1
            shift
            continue
            ;;
        *)
            if [ -f "$1" ]; then
                filename=$1
                shift
                continue
            else
                echo "Unrecognized option $1"
                exit
            fi
            ;;
    esac
done

if [ ! -f "$filename" ]; then
    echo "${0}: $filename does not exist."
    exit
fi

shopt -s extglob
for one_file in /usr/share/applications/*.desktop
do
    desktop_name=""
    desktop_icon=""
    desktop_exec=""
    while read line
    do
        # Remove any [[:blank:]] characters before or after the =.
        if [ "${line}" != "${line#Name*([[:blank:]])=}" ]; then
            desktop_name=${line#Name*([[:blank:]])=}
            desktop_name=${desktop_name##*([[:blank:]])}
        elif [ "${line}" != "${line#Icon*([[:blank:]])=}" ]; then
            desktop_icon=${line#Icon*([[:blank:]])=}
            desktop_icon=${desktop_icon##*([[:blank:]])}
            # Remove icon extension.
            # xpm png and svg are supported, but not paths.
            desktop_icon=${desktop_icon%%.*}
        elif [ "${line}" != "${line#Exec*([[:blank:]])=}" ]; then
            desktop_exec=${line#Exec*([[:blank:]])=}
            desktop_exec=${desktop_exec##*([[:blank:]])}
        fi

    done < "${one_file}"

    if [ "$desktop_name" != "" -a "$desktop_exec" != "" ]; then
        ENTRY_LIST="${ENTRY_LIST}${desktop_icon}|${desktop_name}|${desktop_exec}
"
    fi
done
shopt -u extglob
export ENTRY_LIST

export MAIN_DIALOG='
<window>
    <vbox>
        <hbox>
            <frame Choose application to open file>
                <tree headers-visible="false" column-visible ="1|0" exported-column="1">
                    <variable>TREE</variable>
                    <height>300</height>
                    <width>200</width>
                    <label>0 | 1 </label>
                    <input icon-column="0">echo "$ENTRY_LIST"</input>
                </tree>
            </frame>
        </hbox>
        <hbox homogeneous="true">
            <button cancel></button>
            <button ok></button>
        </hbox>
    </vbox>
</window>
'

GTKDIALOG_RESULT="$($GTKDIALOG --program=MAIN_DIALOG)"

while read ONE_VAR
do
    case "$ONE_VAR" in
        EXIT*)
            if [ "${ONE_VAR%\"Cancel\"}" != "$ONE_VAR" ]; then
                exit
            elif [ "${ONE_VAR%\"OK\"}" != "$ONE_VAR" ]; then
                EXIT_OK="true"
            fi
            ;;
        TREE*)
            exec_command=${ONE_VAR#TREE=\"}
            exec_command=${exec_command%\"}
    esac
done <<< $(echo "$GTKDIALOG_RESULT")

if [ "$EXIT_OK" = "true" -a "$exec_command" != "" ]; then

    if [ "${exec_command}" != "${exec_command%\%f*}" ]; then
    # Support %f in desktop files.

        declare -a "exec_begin=(${exec_command%\%f*})"
        declare -a "exec_end=(${exec_command#*\%f})"

        exec "${exec_begin[@]}" "$filename" "${exec_end[@]}"

    elif [ "${exec_command}" != "${exec_command%\%F*}" ]; then
    # Support %F in desktop files.

        declare -a "exec_begin=(${exec_command%\%F*})"
        declare -a "exec_end=(${exec_command#*\%F})"

        exec "${exec_begin[@]}" "$filename" "${exec_end[@]}"

    else
    # Desktop files without %f or %F.

        declare -a "exec_array=(${exec_command})"
        exec "${exec_array[@]}" "$filename"
    fi

fi
wdlkmpx commented 5 years ago

Ok, I tested the script that's a good start, I can modify and use it in different ways.

Testing rox-filer with run-action-helper, I specified: /usr/local/apps/ROX-Filer/open-with-mimeinfo.sh

Now, that script is executed when I try to run a file with no rox default app (I removed it first).

And I see it doesn't get passed params. I was expecting perhaps: $1 mimetype and $2+ = file

This script will read mimeinfo.cache and probably mimeapps.list to provide a dialog with apps to open the file with.

It will optionally open the file ($2) with the selected desktop file info..

At that point rox-filer might just end the routine successfully and let the script show and do what it wants. This is just speculation, but that's how I expect things to work, that's my experience using other systems.

woodenshoe-wi commented 5 years ago

I tried to document the syntax in the tooltip,
https://github.com/puppylinux-woof-CE/rox-filer/blob/eade08fa8583d4985ae193e90be6fa685c88ceb2/ROX-Filer/Options.xml#L310

I think /usr/local/apps/ROX-Filer/open-with-mimeinfo.sh -m %m -f %f will give you the mime type and file name in a format that the script can handle.

If the script can optionally add an entry to mimeapps.list the next time ROX tries to open the file it can use the entry from mimeapps.list. The problem was that mimeinfo.cache is automatically generated and could have multiple entries that the user should get a chance to choose, that is where the script is useful.

wdlkmpx commented 5 years ago

Ok, I'll keep testing and the script will evolve.

But now I want to mention why pcmanfm ignored mimeapps.list and only read mimeinfo.cache in the past.

So I hit the bug again, somehow rox had defaultmediaplayer.desktop as the default app for video/mp4, and I had deleted it with rox, so when I clicked on a .mp4 file, ffconvert was launched, and I thought what the...

I restored the file and restarted X because pcmanfm would not recognize the change or something.

This time it happened because I added support for XDG_RUNTIME_DIR, a few rare apps complain or crash if that variable is missing.

But it took me a while to realize the pcmanfm bug was brought back to life.

So I was going crazy I even deleted mimeinfo.cache and mimeapps.list because after restarting X a few times pcmanfm just wouldn't start and gconf was crashing (/var/log/messages).

So I looked in /tmp/runtime-root and saw sockets. What if those sockets are not deleted and by restarting X I'm triggering a bad bug?

And yes, commit https://github.com/puppylinux-woof-CE/woof-CE/commit/a9e3a6eb808b7b7581b900ea1cc2a1bbc0131eba fixed the issue.