The mess in /root/.config/rox.sourceforge.net/OpenWith

[LazY Puppy]

Hi.

I'm currently working on a script to translate all the files in /root/.config/rox.sourceforge.net/OpenWith (the Rox right-click-options) to a specified language (here: DE, specified at boot up). It is easy to setup for the use of any different language than DE as I'm using associative arrays to solve this. So all what needs to be done would be to translate the names/elements of the associative array.

But the content of /root/.config/rox.sourceforge.net/OpenWith is such a mess, that it seems to be impossible to get all the files translated.

Usually in /root/.config/rox.sourceforge.net/OpenWith there are symbolic links either to a .desktop file in /usr/share/applications or symbolic links to a roxapp directory in /usr/local/apps.

As longs as there are only such targets used for the symbolic links, the script is working pretty well.

But some puppy builders (or is it made by Woof CE scripts?) add different basic content to /root/.config/rox.sourceforge.net/OpenWith and some of this don't use symbolic links targeted as mentioned above.

Example File: /root/.config/rox.sourceforge.net/OpenWith/mkplaylist - which is not a symbolic link but it is a renamed .desktop file instead.

[Desktop Entry]
Type=Application
Name=MakePlaylist
Exec=mkplaylist
Icon=mini-audiovol
Categories=AudioVideo;
MimeType=application/vnd.ms-asf;application/vnd.rn-realmedia;application/x-annodex;application/x-mplayer2;application/x-quicktimeplayer;application/x-shockwave-flash;application/x-dvi;video/ogg;video/mpeg;video/x-mpeg;video/mp4;video/anim;video/x-anim;video/mkv;video/mng;video/x-mng;video/msvideo;video/quicktime;video/x-quicktime;video/x-flic;video/x-flv;video/x-ms-asf;video/x-ms-asf-plugin;video/x-ms-wax;video/x-ms-wmv;video/x-ms-wvx;video/x-msvideo;

Then there is a second file: /root/.config/rox.sourceforge.net/OpenWith/.inode_directory/mkplaylist which is a symbolic link. This symbolic link is neither targeted to a .desktop file in /usr/share/applications nor to a roxapp directory in /usr/local/apps.

It is targeted to /root/.config/rox.sourceforge.net/OpenWith/mkplaylist.

As long as those files remain un-renamed everything will work well. But after executing my script to translate the files in /root/.config/rox.sourceforge.net/OpenWith the symbolic link /root/.config/rox.sourceforge.net/OpenWith/.inode_directory/mkplaylist which is then renamed to /root/.config/rox.sourceforge.net/OpenWith/.inode_directory/Abspielliste erstellen won't work anymore as it is still targeted to /root/.config/rox.sourceforge.net/OpenWith/mkplaylist which is then also renamed to /root/.config/rox.sourceforge.net/OpenWith/Abspielliste erstellen.

So the only options I do have on this issue is: to remove both of them files or to let them remain in EN.

Question to the Woof CE Community / Puppy Builders: is there any chance to get Puppy following a straight path to use only symbolic links either to .desktop files in /usr/share/applications and/or to use symbolic links to roxapp directories in /usr/local/apps?

[zigbert]

mkplaylist is a part of ffconvert
http://murga-linux.com/puppy/viewtopic. ... 1330451470

[musher0]

@Lazy_Puppy:

It's not so much the mess at /root/.config/rox.sourceforge.net/OpenWith
as it is the mess in the *.desktop entries at /usr/share/applications.

/root/.config/rox.sourceforge.net/OpenWith contains only symlinks and
perhaps the odd script file.

I'll second you on your request, but please be aware that this is much
bigger than Puppy: these *.desktop files come from the developers
themselves: all kinds of developers writing all sorts of programs, some
companies, some individuals; some logical, some illogical. There actually
is a standard for the *.desktop files. A standard that nobody cares to
respect too much.

We at Puppy could intercept these weird *.desktop files with a view to
make them as consistent as possible, but as I said, this is BIG: a top-
notch and very serious Linux "authority" cannot get all developers to
comply with the standard.

On the illogical side, the ones I prefer are the *.desktop file where the
dev thinks that the generic name is the same as his own application's
name!!! This was hot discussion in the Middle Ages, the famous quarrel
about Universals versus Particulars!! Yes, in the Middle Ages. Ahh, 600
hundred years ago, and mankind is still illogical !!! My medieval
friend Ockham must be hurting in his grave.

Let's not forget that our very own BK has invented some categories to
suit Puppy. Even he is outside the standard sometimes.

The problem you mention is not going away for the foreseeable future,
so we better be prepared to laugh at it!

BFN.

[MochiMoppel]

Usually in /root/.config/rox.sourceforge.net/OpenWith there are symbolic links either to a .desktop file in /usr/share/applications or symbolic links to a roxapp directory in /usr/local/apps.

As longs as there are only such targets used for the symbolic links, the script is working pretty well.

But some puppy builders (or is it made by Woof CE scripts?) add different basic content to /root/.config/rox.sourceforge.net/OpenWith and some of this don't use symbolic links targeted as mentioned above.

What the directory /root/.config/rox.sourceforge.net/OpenWith "usually" contains in Puppies is one thing, what directory /root/.config/rox.sourceforge.net/SendTo (yes, Rox needs SentTo, doesn't care for OpenWith !) is designed for and what it should and can contain is a different thing. There is absolutely no need to link .desktop files. The SendTo directory can contain symlinks to any program. It can contain symlinks to directories and it even can contain executable files. Maybe you should make your script more flexible.

[disciple]

What is this .inode_directory though? I think I knew once, but I can't remember.

[MochiMoppel]

A subdirectory of SentTo. Links in this directory will appear in the Rox context menu when you select a single directory (= MIME type inode/directory).

[musher0]

@MochiMoppei:

As I understand it, the confusion originated in Lazy_Puppy's statement.
There's nothing to translate in directory
/root/.config/rox.sourceforge.net/OpenWith: it's all symlinks and perhaps
the odd bash script.

IMO, if he really wants to set things straight before doing his translation,
he has to work with the often erratic contents of the *.desktop files in
/usr/share/applications first. (And yes, I'm repeating myself!)

BFN

[disciple]

Translations should go upstream in the .desktop files (Although perhaps they get stripped out in Puppy?), so you shouldn't be scripting translation of their contents downstream at Puppy.

[disciple]

On the illogical side, the ones I prefer are the *.desktop file where the dev thinks that the generic name is the same as his own application's name!!!

Are you complaining about the way the "desktop environments" like to just call their programs by the generic name? Or are you saying people actually put something like "gnumeric" in as the "generic name"?

[MochiMoppel]

@MochiMoppei:

As I understand it, the confusion originated in Lazy_Puppy's statement.
There's nothing to translate in directory
/root/.config/rox.sourceforge.net/OpenWith: it's all symlinks and perhaps
the odd bash script.

I understand that everything (i.e. all names of symlinks) have to be translated. He can get translation strings from the .desktop files or has to provide them manually, but in case of his mkplaylist example renaming files would not be enough when links point to other (to be renamed) links or files within the SendTo directory. This would require to change the link target, not just the name of the link. I think "mess" is the proper word for what he describes, but on the other hand I think that this is a rare case. I can't see this in Slacko 5.6 and I've never seen a similar case.

Edit: I see now that the mess started with Slacko5.7 . One more reason not to upgrade
This doesn't mean that the old Slacko5.6 and the brandnew tahrpup6 are sane. Why on earth are there 2 menu items, "FFConvert" and "ffconvert", both pointing to ffconvert.desktop? Will be fun for RSH to translate them both to the same name.

[musher0]

Well, no.

First, he has to enter that directory with a good vacuum to remove
the doubles. Then, he'll be ok!

As well, send a "heads-up" to don570, who created many of those symlinks,
to make him aware of the doubles.

BFN.

[LazY Puppy]

It's not so much the mess at /root/.config/rox.sourceforge.net/OpenWith
as it is the mess in the *.desktop entries at /usr/share/applications.

Yes I know this. But this is another mess and I had done my own mess already on this, as I had also invented some new menu categories for LazY Puppy. But that's another story why I did so.

What the directory /root/.config/rox.sourceforge.net/OpenWith "usually" contains in Puppies is one thing, what directory /root/.config/rox.sourceforge.net/SendTo (yes, Rox needs SentTo, doesn't care for OpenWith !) is designed for and what it should and can contain is a different thing.

Directory SendTo is a symbolic link to directory OpenWith in all of my puppies. Usually I do refer to a directory of a path instead to a symbolic link of a path. Just wasn't aware of SendTo being the mean part. Though, it should not make any difference if /root/.config/rox.sourceforge.net/OpenWith is used as the path instead of /root/.config/rox.sourceforge.net/SendTo, no?

There is absolutely no need to link .desktop files. The SendTo directory can contain symlinks to any program. It can contain symlinks to directories and it even can contain executable files. Maybe you should make your script more flexible.

Yes, I had already seen scripts and roxapp directories placed somewhere in /root/.config/rox.sourceforge.net/OpenWith. But that were also rare cases, so I assumed symbolic links to .desktop files in /usr/share/applications and/or symbolic links to roxapp directories in /usr/local/apps would be some standard and anything else would be an un-needed exception of this.

Though, to make my script a little more flexible is only needed for those mentioned rare cases of symbolic links in /root/.config/rox.sourceforge.net/OpenWith targeted to files in /root/.config/rox.sourceforge.net/OpenWith.

Doubles like "FFConvert" and "ffconvert" should not cause any problems so far.

Ok, so as zigbert has pointed out -at least for the mkplaylist (renamed) .desktop file- this is not a puppy issue or Woof CE issue in general.

As I understand it, the confusion originated in Lazy_Puppy's statement.
There's nothing to translate in directory
/root/.config/rox.sourceforge.net/OpenWith: it's all symlinks and perhaps
the odd bash script.

Ok, I should have made this more clear as I'm using 'translate' similar to 'rename' because after doing the translation, all file names/symbolic links are renamed/translated to DE. Which sometimes includes an addition to the file name (e.g.: EN = audacity, DE = Audacity Mehrspur-Musikstudio).

These additions to the file name is priority No. 1. Priority No.2 is the need to have the first character of file names like audacity in upper case like Audacity. This depends on the German grammatical use of file names like audacity. We do call this "Eigenname" and those "Eigennamen" has to start with an upper case character generally. Otherwise it looks/views like it was translated by a person completely unable to use German grammatical rules.

Translations should go upstream in the .desktop files (Although perhaps they get stripped out in Puppy?), so you shouldn't be scripting translation of their contents downstream at Puppy.

The rox right-click menu will not show contents of a .desktop file. Doesn't matter if sym-linked or true file is placed into /root/.config/rox.sourceforge.net/OpenWith. It will show only the file name of the file/symbolic link placed somewhere into /root/.config/rox.sourceforge.net/OpenWith. If the mkplaylist.desktop would not have been renamed it would show up as mkplaylist.desktop in the rox right-click menus.

I understand that everything (i.e. all names of symlinks) have to be translated. He can get translation strings from the .desktop files or has to provide them manually, but in case of his mkplaylist example renaming files would not be enough when links point to other (to be renamed) links or files within the SendTo directory. This would require to change the link target, not just the name of the link.

That's it!

Edit:

File /root/.config/rox.sourceforge.net/OpenWith/ffinfo is similar to /root/.config/rox.sourceforge.net/OpenWith/mkplaylist - I assume this is also caused by ffconvert.

Doubles like "FFConvert" and "ffconvert" actually does not cause any problems. After translation there is only one symbolic link: FFConvert Mediakonverter.

[don570]

As well, send a "heads-up" to don570, who created many of those symlinks,
to make him aware of the doubles.

I am well aware of "doubles" that is why I warn people to use my
right click utility only on Barry's distros and Slacko distro.
I don't want to support other distros because it's too much work.

____________________________________________________

Regarding inode directory ---> Partitions and directories have
entirely different right clicks. You can check this by doing the right click with your
mouse on the icons.

_______________________________________________

The most recent distros by Barryk allow the SendTo folder to be used
as well. SendTo folder is a link to OpenWith folder

___________________________________________________

[disciple]

The rox right-click menu will not show contents of a .desktop file.

Ah. So why are .desktop files being used instead of just symlinks to the executables?

[LazY Puppy]

The rox right-click menu will not show contents of a .desktop file.

Ah. So why are .desktop files being used instead of just symlinks to the executables?

Using .desktop files or symbolic links to these files will show the program icon in right-click menu. Equal to symbolic links to roxapp directories.

Symbolic links to the executable will not show the program icon - instead the binary or script icon is used as one can see in /bin or /sbin etc.pp.

Probably I'm not the only one who prefers to see the program icon.

[technosaurus]

Double Post

[technosaurus]

The problem is that puppy actually provides stripped .desktop files instead of using the prepackaged ones provided upstream. Just as an example, Abiword has many translations in their desktop file, but Puppy replaces it. This is fine for a lot of users, but I have been advocating for an NLS.sfs for a long time that would contain the full desktop files and all of the stripped translations. ...Actually a pet with an install script that only installs the requested language(s) might be a better solution.

I actually went through a lot of effort to localize jwm menus (in my jwm-tools) only to be crippled by the same thing. Another thing in woof-CE that could use localization is /usr/share/desktop-directories, but the standard is really too vague on the directories portion of the spec and Puppy uses a lot of non-standard categories as well, so that may need further discussion.

FWIW, the ROX-Filer that we used has pretty much stopped development and there are forks on github that have made some improvements in this area IIRC

[disciple]

FWIW, the ROX-Filer that we used has pretty much stopped development and there are forks on github that have made some improvements in this area IIRC

Except aren't you saying I was right when I first asked the question, and Rox doesn't actually need improvements - Puppy just needs to ship the .desktop files from upstream...

[disciple]

FWIW, the ROX-Filer that we used has pretty much stopped development and there are forks on github that have made some improvements in this area IIRC

Except aren't you saying I was right when I first asked the question, and Rox doesn't actually need improvements - Puppy just needs to ship the .desktop files from upstream...

Oh, I think I interpreted "this area" too narrowly...

[technosaurus]

FWIW, the ROX-Filer that we used has pretty much stopped development and there are forks on github that have made some improvements in this area IIRC

Except aren't you saying I was right when I first asked the question, and Rox doesn't actually need improvements - Puppy just needs to ship the .desktop files from upstream...

Oh, I think I interpreted "this area" too narrowly...

As far as reading the desktop files, ROX uses an old version of XDG tools
but nothing major has changed.

As far as "open with", see some of the cool improvements @
https://github.com/dtomas/rox-filer/commits/master

Just the fact that it has a clipboard manager is worth switching to it, but it also appears to iterate over desktop files in */applications/ to help select an appropriate app