What I'm adding, and what I'm planning next...

[mwieder]

File associations on linux:

Here's what works for me

Create a file ~/.local/share/mime/packages/application-extension-oxtstack.xml

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<mime-info xmlns="http://www.freedesktop.org/standards/shared-mime-info">
 <mime-type type="application/x-extension-oxtstack">
  <comment>OpenXTalk Stack</comment>
  <glob pattern="*.oxtstack"/>
  <icon name="application-x-extension-oxtstack"/>
 </mime-type>
 <mime-type type="application/x-extension-oxtstack">
  <comment>legacy LC Stack</comment>
  <glob pattern="*.livecode"/>
  <icon name="application-x-extension-oxtstack"/>
 </mime-type>
  </mime-info>

If you want script files associated as well then add another mime type.
I prefer to keep them by default as text files, thus open with xed.

Then issue the command

Code: Select all

update-mime-database ~/.local/share/mime

Note that any open file browser windows won't reflect the change until they're relaunched.

[tperry2x]

File associations on linux:
Here's what works for me...

Thanks Mark, I really appreciate that info.
I'll test and build that into the file association checks for Linux in-stack, so that it works for every user.

On line 6:

Code: Select all

  <icon name="application-x-extension-oxtstack"/>

This is referencing an icon, which is in:
~/.local/share/icons/hicolor/scaleable/application-x-extension-oxtstack.svg

Just checking - Is that the right location?
I also tried with a PNG, rather than an SVG version.

I used the XML you quoted above, but I get some weirdness:

hmm.png (18.33 KiB) Viewed 2957 times

It sees 'oxtstack' and 'livecode' files as both "legacy LC Stack".

So, I changed the XML to:

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<mime-info xmlns="http://www.freedesktop.org/standards/shared-mime-info">
 <mime-type type="application/x-extension-oxtstack">
  <comment>OpenXTalk Stack</comment>
  <glob pattern="*.oxtstack"/>
  <icon name="application-x-extension-oxtstack"/>
 </mime-type>
 <mime-type type="application/x-extension-livecode">
  <comment>legacy LC Stack</comment>
  <glob pattern="*.livecode"/>
  <icon name="application-x-extension-livecode"/>
 </mime-type>
</mime-info>

(line 8 and 11, I put in application/x-extension-livecode instead)
I now get this:

hmm-2.png (17.74 KiB) Viewed 2957 times

It's closer, as it now differentiates between a 'Livecode' file and an 'oxtstack' correctly, but I thought it should read 'legacy LC Stack' on the 'livecode' file? - that's what the XML would suggest?

If you right click, or double-click the oxtstack files - they are associated with the "OpenXTalk Lite" program.

hmm-3.png (15.8 KiB) Viewed 2952 times

But, there's no icon associated with it.

I note, there's a file that has appeared called 'icons' in ~/.local/share/mime/ with the following content in:

application/x-extension-oxtstack:application-x-extension-oxtstack
application/x-extension-livecode:application-x-extension-livecode

[mwieder]

Interesting. I must have posted an earlier experiment instead of the real code. Try this:

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<mime-info xmlns="http://www.freedesktop.org/standards/shared-mime-info">
 <mime-type type="application/x-extension-oxtstack">
  <comment>OpenXTalk Stack</comment>
  <glob pattern="*.oxtstack"/>
  <icon name="application-x-executable"/>
 </mime-type>
 <mime-type type="application/x-extension-lcstack">
  <comment>legacy LC Stack</comment>
  <glob pattern="*.livecode"/>
  <icon name="application-x-executable"/>
 </mime-type>
</mime-info>

[tperry2x]

Interesting. I must have posted an earlier experiment instead of the real code. Try this:

It's certainly closer, so thank you. The file types show the right info under their description, however the icons have changed to a generic executable.

test-2.png (5.28 KiB) Viewed 2935 times

[tperry2x]

Ah, got it.
There's a lot more to it than first appears unfortunately. So, I made the process into a script:

example.png (75.86 KiB) Viewed 2928 times

Usage:

Code: Select all

./create_custom_mime_with_custom_menu_name.sh oxtstack application/x-oxtstack "OpenXTalk stack" './oxtlite-doc.png' /opt/openxtalk/openxtalk_x86_64/openxtalk.x86_64 ./oxtlite-app.png ./oxtlite-app.png "OpenXTalk Lite"
 

[mwieder]

Ah. Custom icons. Very nice.

[tperry2x]

A small change: it now properly puts the icon for the menus in the 'Development' or 'Programming' category (whichever you have).

menu.png (44.54 KiB) Viewed 2904 times

I can work this script into the installer, but also when the IDE checks for file associations in Linux (so a new user logging in, then opening OXT Lite will be prompted properly).

[mwieder]

One more thing. If you're installing into /opt for all users you'll want to put the xml file into

/usr/share/mime/packages/

instead of

~/.local/share/mime/packages/

[richmond62]

One more thing.

There will be an infinite chain of 'one more things' . . .

[tperry2x]

One more thing. If you're installing into /opt for all users you'll want to put the xml file into
/usr/share/mime/packages/
instead of
~/.local/share/mime/packages/

Can I query this?
According to this freedesktop.org page, which the conventions are followed by on most linux distros (and is what I'm targeting):

additions and removals applied from the mimeapps.list file in $XDG_CONFIG_HOME, $XDG_CONFIG_DIRS and $XDG_DATA_HOME will override all existing desktop files, but that an addition or removal of an association using /usr/share/applications/mimeapps.list for example, would be ignored if the desktop file of the named application was present in $XDG_DATA_HOME/applications.

In plain english, ~/.local/share/mime/packages/ takes priority over /usr/share/mime/packages/

[tperry2x]

Working well at the moment for multi-user and single-user Linux setups:

linux-associations.png (31.92 KiB) Viewed 2857 times

[mwieder]

True about the desktop priorities, but if you're going to install into /opt then OXT is available for all users, and I'd think that in that case you'd want the file associations for all users as well.

[tperry2x]

if you're going to install into /opt then OXT is available for all users, and I'd think that in that case you'd want the file associations for all users as well.

I was mulling this over earlier and giving it careful consideration.
On the face of it, yes - so they match.

However, I then thought about this scenario: what happens if someone installs OXT for all users (in /opt/ for example). Then subsequently users begin to login (perhaps it's a shared machine).* However, the admin of that computer doesn't want the link to that program to show up for all the users (perhaps some users have also requested they don't see it as they don't like a cluttered desktop or want minimal application menus).
If that shortcut was installed for all users, if the admin deletes it for the ones that don't want it - it'll delete it for every user. That was my issue I was pondering.
* the reason there's an asterisk: I have this situation where staff have access to a set of programs that are in hidden directories with obscure names. Having a shortcut that points to this, other users would work out the location of those folders and try meddling in things they shouldn't really be in.

The way I thought to solve that would be have an install for all users in /opt/ but then install the shortcut pointing to this program on a per-user basis. That way the control over it is more granular (it can be removed for specific users without affecting others), but it then does not require multiple installs of the same thing - meaning that someone might end up with a version that is out of date or has bugs that the user next to them on a different computer has fixed.

This is the way it works in MacOS (although, yes - I know you can have your own ~/Applications folder for a user-application basis), but generally - if someone installed BBedit for example, that sits in /Applications and is available to all users who login via launchpad.

I'm just pondering options currently.

[OpenXTalkPaul]

I didn't want it to seem like we are begging. (even if we are ) - but yes, needs to be a lot more noticeable and styled a bit more. It was just merely a proof of concept, as Paul could change this at the CSS level on the server.

Also, worth thinking about. Are we doing a gofundme / paypal whatever - how are people actually donating. Also, does Paul even want to be the recipient of these funds? Has he been asked & feels comfortable with that? Lots of questions, apologies if they've been answered elsewhere.

I would'nt be comfortable receiving the funds of any crowd-funding campaign for OpenXTalk, I just do not want that responsibility. I'm 100% for the idea of crowd-funding some goals, so long as whomever does manage the funds does so in a way that is very transparent, it should always be clear what funds will go where and for what exactly.

I believe there are a few crowd-funding platforms specifically designed with Free Open-Source Projects and Non-Profit Public-goods in mind. This site here looks like what I'm getting at: https://opencollective.com

Here's an interesting list here: https://www.oss.fund/tags/open-source-friendly/

I guess our current major goals would be getting the OXT Engine(S) updated, recompiled with a few minor changes in place on ALL current platforms, and one (or two) additional CPU architectures. Stretch goal of setup the Engines repo to update/replace and re-enable some sort of automated build process for the Engines.

[tperry2x]

Renamed 'Code' to 'Script' on the toolbar and in the title of script editor windows, so that it's consistent with the rest of the IDE.

code-to-script.png (61.91 KiB) Viewed 2202 times

Help > Check for updates (will take you to build '202407121402')
(I'll release v1.06 soon with all these updates since 1.05 bundled together).

[mwieder]

Ran the updater. All seems well but the build number is 202406010625.

[tperry2x]

There may be multiple updates.
202406232320, 202406271556, 202406281643, 202406291043, 202406291630 and (finally) 202407121402
Each one is incremental (click the 'what's changed' at the bottom left of the update window for a brief description).

Which is why I'm going to bundle all these up into a v1.06 version.
In future versions of the updater, I'll make them all apply one after the other - even though that gets a little trickier.

[mwieder]

Ah.

Unfortunately build 202406212252 broke the startup handler in the IDE.
So now I can't launch the IDE, can't do the rest of the updates, and can't go back.
I'll wait for the bundle.

[richmond62]

In the light of Mark's finding: no updates for me.

[tperry2x]

OMG, as they say