Release pnd_utils

[hmc]

Not understood yet.

http://pandorawiki.org/PXML#The_.3Cassociations.3E_element

says:

"(required) The command attribute on an association element specifies the command to be run; ..."

but the example reads:

<association name="Deinterlaced Bitmap Image" filetype="image/bmp" />

(I don't see the command there.)

Also: In the PXML file you can define what MIME types the PNDed applications handles, but where do you define the MIME types themselves? I.e. in normal Linux there is an XML file like this:






<mime-info xmlns="http://www.freedesktop.org/standards/shared-mime-info">
<mime-type type="application/notecase-plain">
<comment>NoteCase Pro document</comment>
<magic priority="80">
<match type="string" offset="1" value="!DOCTYPE NoteCase-File"/>
</magic>
<glob pattern="*.ncd"/>
</mime-type>
.....


 



Where is this info put for a PND?

Sorry for my lack of understanding. I may not see the wood for trees here..

 

[ssokolow]

When I look at that associations element documentation, my first impression is "If you need to create a .desktop file for each association rather than just bundling all the associations into the existing application .desktop file, you're doing it very wrong and no wonder nobody reported it as a bug that Thunar only offers up visible .desktop files for the association selector."

I've written quite a few .desktop files back when not all applications provided their own and I've yet to run across a situation where an application required custom commands for different mimetypes without each of those custom commands also being useful enough without arguments to get their own categorized menu entries.

Can someone elucidate what makes the Pandora firmware special enough to be an exception?

 

[skeezix]

Not understood yet.

http://pandorawiki.org/PXML#The_.3Cassociations.3E_element

says:

"(required) The command attribute on an association element specifies the command to be run; ..."

but the example reads:

<association name="Deinterlaced Bitmap Image" filetype="image/bmp" />

(I don't see the command there.)

Also: In the PXML file you can define what MIME types the PNDed applications handles, but where do you define the MIME types themselves? I.e. in normal Linux there is an XML file like this:






<mime-info xmlns="http://www.freedesktop.org/standards/shared-mime-info">
<mime-type type="application/notecase-plain">
<comment>NoteCase Pro document</comment>
<magic priority="80">
<match type="string" offset="1" value="!DOCTYPE NoteCase-File"/>
</magic>
<glob pattern="*.ncd"/>
</mime-type>
.....


 



Where is this info put for a PND?

Sorry for my lack of understanding. I may not see the wood for trees here..

There is an example right above that, but you're right, when I did a quick pass of that section the other night, I didn't update it again ( did a couple updates in a row, as the code was changing.) Sorry about that, I'll update it again

ex: <association name="myapp png loader" filetype"image/pnd" command="run.sh" arguments="%f"/>

Is the one right above it.

This is still 'stuff in flux' as we get a handle on it, so it is not comprehensive; adding a bit, to support existing mime-types .. so pnd apps can offer up to support image/png say, and should work.

The one note (which is in the documentation there) is the limit of 3 associations per pnd; I'm thinking I shoudl up that to to some larger number (like if say, someone ports Gimp, which probably supports 20 types or more ), but for now, gathering comments!

The elements in there are named after simialra ones in the main <exec> line, but if your'e really on top of your game you may notice I have not mentioned how these interplay; I'm on the fence. Right now, the cpu speed and so forth bits from <exec> are inherited by the <association> created .desktops, but it is tempting to make all the same options for <exec> available in <assoc> and thus be very clear. In practice, few actrualyl use any of those options, so I'm not sure it matters.

As to your note abotu creating new mimetypes entirely .. I have not gone that far yet. I've not looked up how (say) .deb's or the like  do that, or if it is done 'at all'. ie: There is a 'database' (xml file) in most linux distros (same with ours offhand, I think):


$HOME/.local/share/mime
/usr/local/share/mime
/usr/share/mime

I forget if its a single file per location, or multiple files (probably multiple), so could probably have PXML elements that emit new entries to new files there..

.. but our PXML specification never went that far (this update is to ratehr fill in and start discussion on PXML ideas we'd put togethdr 2 years ago or whatever, at least.)

Feel free to comment or make a recommendation

jeff

 

[skeezix]

When I look at that associations element documentation, my first impression is "If you need to create a .desktop file for each association rather than just bundling all the associations into the existing application .desktop file, you're doing it very wrong and no wonder nobody reported it as a bug that Thunar only offers up visible .desktop files for the association selector."

I've written quite a few .desktop files back when not all applications provided their own and I've yet to run across a situation where an application required custom commands for different mimetypes without each of those custom commands also being useful enough without arguments to get their own categorized menu entries.

Can someone elucidate what makes the Pandora firmware special enough to be an exception?

Its not as if the planned thing is breaking anything; ratehr, it is 'harmless extension'. ie: Why _not_ allow for different arguments per mimetype, rather than the same arguments for all mimetype mentality?

I had actually implemented it a couple days ago as per normal, but it was brought up that the PXML specification from before did support different args for the mimetypes, so we thought hey, why not, lets do it like that. (see the history of changes to the wiki recently

If you have a counter-example, let me know

ie: Theres no reason you can't just specify the same runtime and args for all the assoc's you include, we merely provide the option to do it differently.

jeff

 

[ptitSeb]

The one note (which is in the documentation there) is the limit of 3 associations per pnd; I'm thinking I shoudl up that to to some larger number (like if say, someone ports Gimp, which probably supports 20 types or more ), but for now, gathering comments!

Yes, 3 associations will be a little short. LibreOffice, for example, will need a bit more

I guess there will be an avalanche of updates when this function will be live. And to the benefit of end user !

 

[ssokolow]

If you have a counter-example, let me know

ie: Theres no reason you can't just specify the same runtime and args for all the assoc's you include, we merely provide the option to do it differently.

My launcher menu is as tall as the screen allows without scrolling and well-categorized and I had to write a lot of .ovr files to get it that way. Unhiding the Other category by adding content to it will be a major pain for me given how hard it already was to meaningfully crunch down my loadout to a number of categories that wouldn't scroll.

I could see you guys collapsing identical entries before generating .desktop files so that Other entries only appear if necessary, but if you don't support things like %f in the regular application exec args and make the "command" attribute optional, then you're inviting packagers to make a typo that fails the collapsing process but still works (like using "%f" or "%u" once where everything else uses "%F" or "%U") and then not notice that something appeared in Other.

I'd also argue that, for things which support a lot of mimetypes (like pretty much every non-game, non-browser I have such as Audacious Media Player, SMPlayer2, etc.), requiring that the command be re-specified for every association and then generating a forest of .desktop files as a result is a major design flaw.

Just for Audacious alone, I actively play audio tracks from the following containers/formats: MP3, Ogg, FLAC, AAC, SID, HSC, SPC (.sp[c0-9]), GYM, NSF/NSFE, GBS, ProTracker (.mod), ScreamTracker (.stm), ScreamTracker 3 (.s3m), FastTracker (.xm), ImpulseTracker (.it), Wave, Sun AU/SND, Creative VOC, WavPack (.wv), FLV-format YouTube dumps, MP4-format YouTube dumps, WebM-format YouTube dumps, and MIDI.

...not to mention the ones that I would play if the available build of Audacious supported them: PSF (OpenPSF plugin is so unoptimized it won't even play when my Rebirth-edition Pandora is overclocked) and Infogrames .dum files from Goblins 3 (UADE plugin not bundled with Audacious and possibly not even available anymore since UADE devs promised to intentionally break the UADE API if Audacious devs bundled the plugin in line with their Kernel-like approach to API consistency), for example.

 

[skeezix]

The number of .desktop entries shouldn't be a large concern (unless we have many thousands, which could slow down (say) xfce's parsing.) We should be able to sort out a method to hide them (if worst case being to stick them in some buried subcat :/) I think xfce's way of dealing with them is broken, but it is what it is. However, this implies still 2-3 desktops -- one for plain exec, one for optional info, and one for associations. ie: There is some pain due to xfce and pnd_run.sh, so sticking the "%f" into the "arguments" bit in exec doesn't work out really well, so we have to add them to the end a little specically. We could change the PXML to have an 'extr-arguments' bit in the main exec, which is always added at the end.. that was my thought mid last week.. but we're getting into kludge space :/

Anyway, I could try to filter down on command and args, and where they are the same, just include them in the .desktop perhaps (perhaps assuming they are sensibly ordered in PXML, so all adjacent lines with the same args/command can group). It would be clumsy to add more PXML to specify both kinds separately.

The limit of 3 is rather due to some clumsiness in the libpnd code that were introduced over a few peoples hands some time ago, and being consistent. If however it is a 'must change thing', then it may be the time to at least do it 'better' for this. Sounds like we absolutely need more than 3, so maybe I should be working that angle now, rather than monkeypatching later ..

hmrf.

edit: There is also a usage question .. I don't support mimetypes in minimenu at all (few if anyone uses the directory browsing component), so its xfce users mostly (or other custom launchers.) Do you play all these Audacious files by queueing from Thunar, or do you launch Audacious and queue them there? Or do you drag ang droip directories? ie: On a desktop its extremely vcommon to fire up Audacious, then drag ang driop a directory in, say. Or double click on a file and play it. But on Pandora, even with Audacious.. is that the norm or the exception? (either way, best to handle with some elegance..)

 

[skeezix]

oh.. how about this.....

We could perhaps expand the pxml spec, so that many mimetypes can be included in one assoc line; 3 lines max, but many in there

ex:

<association name="Audacious Associations" filetype"audio/mp3; audio/mod; audio/wav; audio/flac" command="run.sh" arguments="%f"/>

Something like that might solve most of the concerns?

jeff

 

[ssokolow]

edit: There is also a usage question .. I don't support mimetypes in minimenu at all (few if anyone uses the directory browsing component), so its xfce users mostly (or other custom launchers.) Do you play all these Audacious files by queueing from Thunar, or do you launch Audacious and queue them there? Or do you drag ang droip directories? ie: On a desktop its extremely vcommon to fire up Audacious, then drag ang driop a directory in, say. Or double click on a file and play it. But on Pandora, even with Audacious.. is that the norm or the exception? (either way, best to handle with some elegance..)

I press Enter, then curse when the "Open With" dialog opens to remind me that the Pandora isn't like the copy of LXDE on my desktop PC, then close it and launch Audacious, then use Audacious's internal file browser because the stylus doesn't drag well and it's easier to use the D-Pad to add files. (Using the nubs to double-click to work around the annoying "Enter on a directory adds it rather than descending" problem Audacious has but Thunar doesn't)

This happens every time I set my Pandora down for more than a few hours.

(The stylus is normally kept holstered and, even if I'm not using my fingernail as a stylus, the touchscreen doesn't work very well for dragging)

oh.. how about this.....

We could perhaps expand the pxml spec, so that many mimetypes can be included in one assoc line; 3 lines max, but many in there

ex:

<association name="Audacious Associations" filetype"audio/mp3; audio/mod; audio/wav; audio/flac" command="run.sh" arguments="%f"/>

Something like that might solve most of the concerns?

jeff

If you combine it with a mechanism for collapsing the association .desktop file into the regular launch one, it'd solve all my concerns. Is there any reason you couldn't make the command attribute optional and, if it's optional, interpret arguments as being in addition to whichever ones are provided by the normal launch command?

 

[skeezix]

That would imply adding "%f" (say) to the end of the exec argument, always, which may not be what the dev wants. (Further, you might want %U or %F or any number of other Freedesktop choices. So we want the choice explicit.)

It is tempting to let you stick %f into the Exec lines arguments, and then have the script filter it out, and if present, append it.. but then we have to catch all the freedesktop guys, and its not really a general solution.

If you put one <assoc> line and thus end up with 3 .desktops (exec plain, optional info, and that one assoc line) .. is that not a pragmatic solution?

(do note that the .desktop generation is rather 'internal'; we could change it in the future if the code gets cleaned up in such a way as to make it nice and pleasey say to work around this say. Theres nothing saying it has to stay that way.. it should be invisible to usage, other than the undesirable side effect of the extra menu item because xfce is stupid

(its possible this buglet in xfce has been repaired in a newer version as well, but thats out of scope for me to look at right now; its not relevent to current firmware (as opposed to .next) )

jeff

edit: The other thought in my head, was from last week, but its also clumsy .. allow an extraArgs bit in <exec>  which woudl always be put at the end of the pnd_run.sh invocation, and be taken as expanded by shell.. so xfce's %f expansion would work there. Then drop the 'arguments' and 'command' bit from the <assoc> lines, and we end up with how every other app does things.. no multiple eays to exec bits based on mimetype (they'd have to do that in the run-script.) ... choices choices.. and internally, libpnd would then just add up all the lines into one mimetype list for sticking into .desktop, and there would be no limit of 3, since there'd be just one per se.

 

[skeezix]

Discussing with notaz .. may just revert it all to the style was going for last week.. one .desktop with all the mimetypes in it, as per the 'edit' above.

 

[ssokolow]

That would imply adding "%f" (say) to the end of the exec argument, always, which may not be what the dev wants. (Further, you might want %U or %F or any number of other Freedesktop choices. So we want the choice explicit.)

It is tempting to let you stick %f into the Exec lines arguments, and then have the script filter it out, and if present, append it.. but then we have to catch all the freedesktop guys, and its not really a general solution.

If you put one <assoc> line and thus end up with 3 .desktops (exec plain, optional info, and that one assoc line) .. is that not a pragmatic solution?

(do note that the .desktop generation is rather 'internal'; we could change it in the future if the code gets cleaned up in such a way as to make it nice and pleasey say to work around this say. Theres nothing saying it has to stay that way.. it should be invisible to usage, other than the undesirable side effect of the extra menu item because xfce is stupid

(its possible this buglet in xfce has been repaired in a newer version as well, but thats out of scope for me to look at right now; its not relevent to current firmware (as opposed to .next) )

jeff

edit: The other thought in my head, was from last week, but its also clumsy .. allow an extraArgs bit in <exec>  which woudl always be put at the end of the pnd_run.sh invocation, and be taken as expanded by shell.. so xfce's %f expansion would work there. Then drop the 'arguments' and 'command' bit from the <assoc> lines, and we end up with how every other app does things.. no multiple eays to exec bits based on mimetype (they'd have to do that in the run-script.) ... choices choices.. and internally, libpnd would then just add up all the lines into one mimetype list for sticking into .desktop, and there would be no limit of 3, since there'd be just one per se.

What I'm suggesting wouldn't necessarily imply adding "%f" automatically.

I was suggesting making the "command" attribute for <assoc> optional and treating the "arguments" bit as your "extraArgs" if command wasn't provided. (I've been operating from the assumption that you wanted as little churn on the PXML spec as possible in case people had preemptively added <assoc> to their PNDs)

Yes, that would end up merging tokens like "%f" into the main .desktop file, but since the PND still has control over which token gets used and the Xfce launcher knows what to do with them, I don't see what the issue is.

As for having three .desktop files, my main problem is the user experience. I want the same kind of clean, elegant user experience as on desktop Linux and that requires having the mimetype associations attached to the main .desktop file. (If nothing else, manually adding an association not offered by the PND via the launcher browser dialog can only be implemented that way since users wouldn't intuitively recognize that they need to choose some special entry squirreled away in Other rather than just picking the launcher they're already familiar with.)

 

[skeezix]

okay, going to cut back to what I Was doing early..

Dropping 'command' and 'arguments' from the <assoc> lines, and then you can add the %f or %u or whatever to an extra-args bit in the <exec>. (ie: You can't have varying execution without multiple .desktops, which is why we did that. So you either have command/args in <assoc> or not at all,(

This will mean no extra .desktop emittance, and as many associations as you like (one line with many, or many lines.. they'll just cat catenated and stuck into the .desktop)

We lose the per-mimetype execution stuff, but thats okay, clever devs can handle it inside their run-script or application if they need to.

I'll update the code and docs soon. Thanks for your feedback; its all a work in motion anyway, so the important thing here is to get something foundational out, and see how it goes, and grow it if we need. So going minimal is okay, so long as we don't step down the wrong path if we can avoid it

jeff

edit:

I was suggesting making the "command" attribute for <assoc> optional and treating the "arguments" bit as your "extraArgs" if command wasn't provided. (I've been operating from the assumption that you wanted as little churn on the PXML spec as possible in case people had preemptively added <assoc> to their PNDs)

Yep, exactly so about PXML .. as you can see, even just a little thing like this is risky to someone .. so I try to minimize changes unless theres a really good and useful case.

This above we can't do.. ie: if theres >1 assoc line, then how would you handle the multiple arguments/commands? hence the simplication above.

(which we then steered into more complex, to try and fulfill what the original PXML spec had. But I have no concern over going simpler, and dropping the bits, since simpler is better

 

[skeezix]

Submitted codechange quick .. will do some more robust testing again tonight

Updated PXML documentation:

http://pandorawiki.org/PXML_specification#The_.3Cassociations.3E_element

See also the <exec> tag

In short..

- no more 3 item limit (internally, there is only 1 now, and just keeps appending to it)

- No extra .desktop files

- The main executable .desktop just has the full list of Mimetypes in it

- no variations of the exec .. all use the same exec

- new argument to Exec is "extraarguments", where you place the %f or %U or whatever (or any other arguments you wish to feed to the pnd, and let the shell see.) The normal 'arguments' element is still there, but it is quoted and the shell/desktop won't expand any of that stuff

Should satisfy everyone.

In short..

Add 0, 1, or more associations, and add the extraarguments to the exec line, and you're good; should take no time at all.

jeff

 

[ssokolow]

Updated PXML documentation:

http://pandorawiki.org/PXML_specification#The_.3Cassociations.3E_element

See also the <exec> tag

It looks good though, to be more accurate, the documentation should say that %u is a single URL and %U is multiple URLs, not that %U is "a url".

Also, probably a good idea to link to the exact section of the relevant specification:

http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#exec-variables

Finally, the example disagrees with the documentation on what the name attribute should contain. The documentation says it should contain a user-friendly action name which, ideally, includes the application name while the example shows it containing the filetype's name.

 

[skeezix]

Yep, my thoughts exactly; I have here some screaming babies, so added a couple more points, but to add links outside of the page need to find a password, and digging arund a forum right now is hard

skeetablet

Feel free to edit the documentation to improve it; more hands is better.. we have precious few

 

[hmc]

Hi Jeff,

ex: <association name="myapp png loader" filetype"image/pnd" command="run.sh" arguments="%f"/>

ah, okay, understood. 

The one note (which is in the documentation there) is the limit of 3 associations per pnd; I'm thinking I shoudl up that to to some larger number (like if say, someone ports Gimp, which probably supports 20 types or more ), but for now, gathering comments!

 NoteCase Pro would need 6 or 7 assiciations. So I vote for a limit of 8. ;-)

The elements in there are named after simialra ones in the main <exec> line, but if your'e really on top of your game you may notice I have not mentioned how these interplay; I'm on the fence. Right now, the cpu speed and so forth bits from <exec> are inherited by the <association> created .desktops, but it is tempting to make all the same options for <exec> available in <assoc> and thus be very clear. In practice, few actrualyl use any of those options, so I'm not sure it matters.

As to your note abotu creating new mimetypes entirely .. I have not gone that far yet. I've not looked up how (say) .deb's or the like  do that, or if it is done 'at all'. ie: There is a 'database' (xml file) in most linux distros (same with ours offhand, I think):


$HOME/.local/share/mime
/usr/local/share/mime
/usr/share/mime

I forget if its a single file per location, or multiple files (probably multiple), so could probably have PXML elements that emit new entries to new files there..

.. but our PXML specification never went that far (this update is to ratehr fill in and start discussion on PXML ideas we'd put togethdr 2 years ago or whatever, at least.)

Feel free to comment or make a recommendation

jeff

Yes, those are multiple files.

But I don't know the exact mechanism either.

It would be great, if a PND can simply put a new file with new MIME types there and then have those MIME types registered as long as the PND is mounted. 

Wait! The PND is not mounted at the time when the user doubleclicks a data file of the PNDed application! Okay, so this MIME type registration should be done ideally as soon as the PND is installed, i.e. as soon as it is available. pndlib will notice that there is a new PND. Would it be possible, to let pndlib have generate that MIME type definition file on the fly, once the PND is seen for the first time, and remove it again, if the PND is not found on a PND scan anymore?

That's actually the same mechanism as creation / removal of the .desktop files, I would guess.

However, I don't know, if for MIME type registration some additional command needds to be called, so that the XML files are parsed or registered.

 

[ssokolow]

Yep, my thoughts exactly; I have here some screaming babies, so added a couple more points, but to add links outside of the page need to find a password, and digging arund a forum right now is hard

skeetablet

Feel free to edit the documentation to improve it; more hands is better.. we have precious few

I've added the link and done what I could to improve the typesetting of the spec. Anything I noticed but couldn't fix, either due to lack of time or because the spec is self-contradictory and I need clarification is described in <!-- TODO: ... --> blocks that only appear while editing.

 

[skeezix]

I think dash should be okay in appdata; I don't see why not. We definately don't want special globbing characters like * or ? or \ or / or the like or "The result is undefined" .. but dash should be okay I'd imagine; why call that one out, instead of the more scary characters? Not sure who put that in

jeff

 

[hmc]

Just a reminder for my post above: 

If we now have support for file type associations, I guess we also need MIME type definitions. 

E.g. many of the file types LibreOffice uses are not known yet to the system. and thus they can't be associated, as far as I know. (Or can they? If so, how?)

What about a dedicated section in the PXML, that defines those needed MIME types with file extensions?

pndlib would put the corresponding new MIME type definition XML into the branch that's responsible for that and (If necessary) call the command needed to re-parse the MIME type definition files.

The question is: How does the system handle duplicate MIME type definitions? Should they be avoided? Don't they matter?