I wanted to ask everybody a quick question about file associations. At first, I was planning on having each app only list associations for what it associates itself with locally or what can be associated within the app itself (if it has a 'register filetypes' function internally), as that seems to best duplicate the functionality you get from a local app. Audacity is the perfect example because, even though it supports WAVs, MP3s, etc, the only file type it associates itself with is AUP since that is its own filetype (and you'd be unlikely to want Audacity to come up by default for the others).
Some devs have been submitting apps with all filetypes they can handle associated. For example, fre:ac Portable. The local version doesn't register anything via the installer or via the app. But it can handle quite a few (aac,aif,aiff,aifc,bonk,voc,flac,mp1,mp2,mp3,m4a,m4b,mp4,ogg,au,snd,wav,cda,wma,vqf).
I'm inclined to go with my first instinct (1st method) because it better approximates what local apps do. And because it will be less work for the platform to do on startup to handle specific associations. Interested folks can, of course, add additional associations as they'd like, but for defaults, I'm thinking we do the simpler approach.
Thoughts?
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
the idea behind file associations and reasons for it I would go with your idea of associating the program specific ones and allow users to choose others they may want.
“Be who you are and say what you feel because those who mind don't matter and those who matter don't mind.” Dr. Seuss
I agree, an app shouldn't associate where it isn't appropriate, although if a local install of an app doesn't associate with a filetype that definitely should be associated (eg if Audacity didn't associate with AUP), we should include it too.
Eg. I think LibreOffice should associate with .odt, .ods etc. but shouldn't automatically associate with .doc, .xls. Code editors should not associate with the majority of filetypes they can open/edit/syntax highlight etc.
LibreOffice should associated with doc, xls, rtf, etc as that is its primary purpose. And when you double-click on them, you want them to open.
As for code editors, I'm debating still. I may stick to what they associate via installer and app as well.
Sometimes, the impossible can become possible, if you're awesome!
Just to be 100% sure about what the associations mean, I am assuming that:
Am I correct in this? Or are associations created by individual apps active even when not running, but the platform is?
Either way I would argue against adding the extra associations to LO.
While that is it's primary purpose, I can foresee people who would want to open .doc, .xls etc still in a local copy of MS Office, while opening .od? in LO.
I would prefer if obvious and definite associations (LO with .od?) should be assigned by the platform, but anything further (LO with doc, xls, rtf) should be user assigned only. It just doesn't seem logical to me to override the system's file associations in this regard unless the user wants it that way.
Most code editors I honestly don't think would associate with individual file types, except for associations similar to Visual Studio with .suo and .sln files, so going with base app associations is probably safest there.
All associations occur within the platform, whether general ones as part of the spec or specific ones as part of an app. Almost everyone will want their portable app to open docs/xls on a given machine that you don't (as it is likely to have an outdated version of MS Office or none at all). Keep in mind that users will be given a choice of what to do when first opening something a given associated file (use the portable app, use the local app, etc).
Sometimes, the impossible can become possible, if you're awesome!
I was also assuming that Platform associations would just automatically open in the defined PortableApp like system associations, but if given the option on first run, I think that is fine.
>Keep in mind that users will be given a choice of what to do when first opening something a given associated file (use the portable app, use the local app, etc).
Otto Sykora
Basel, Switzerland
Sorry, it looks like I misunderstood the file associations.
There's no misunderstanding. At least not on your end. It was never specified or spelled out. That's why I figured I'd start a discussion about it. We can always switch from one to another later as the overall plan. As well as make calls on an app by app basis.
Sometimes, the impossible can become possible, if you're awesome!
Personally, I'd like my portable apps to behave as similar as possible to the original app. As in audacity's case, since the installer only associates itself with the .aup files, I would expect only those to be associated in the portable app.
Likewise if I never installed audacity locally, but I installed the portable one, and I see that all these file extensions are associated, I would expect them to be associated in the installed version, too, and if I were unaware of the way file associations (will) work, I might consider it a bug and cause problems for the original devs of audacity, wondering why I can't associate my files, and that its buggy and what-not.
Hence, I think the first method is most appropriate.
Is it possible to have configurable file associations? For example, LibreOffice is associated by default with .odt, but not with .doc. However, on Windows, one might decide to associated .doc files with LibreOffice if, for example, one doesn't have Microsoft Word around. Could the same possibility exist in the Portable world?
Another request/suggestion. There are applications I like to have as PortableApps for use on "foreign" computers. However, when at home, I prefer to use the installed application, because it tends to work faster than the portable version. LibreOffice and Gimp are such examples.
In other cases, such as Thunderbird and Firefox, I prefer to use the portable version at all times so I don't have synchronization problems.
So how would the association work? Could some of it be deactivated in PortableApps so that associations on the host computers take precedence?
Michel Gagnon
Montréal (Québec, Canada)
or it also needs to be completely disabled.
When I have the usb stick in the computer, which is most of the time, I would find it very disturbing to have to close the platform or get the stick out before able to work with some .doc for example. As under normal work I would expect the resident ms office will open and only when there is nothing else, I can open libre and work from there.
And as my files are in most cases stored in usb stick where also portable apps are, automatic opening of libre will be very bad idea.
If there would be a fixed and permanent automatic file association, this would mean I need two different stick with me, one with the apps on it and other with the files only. The one with the apps would have to be removed most of the time as it would disable any standard work.
But the stick with the apps also has my mail client on it , therefore any permanent file associations will make portable apps almost unusable.
Otto Sykora
Basel, Switzerland
Hey guys, there's no need to keep guessing how it's going to work. Just wait until the first test version is available. The point of this thread was just to get a feel for the difference between the two approaches I mentioned in the main topic.
When you have the platform running and click on something that a portable app can open, it'll ask you what to do. You can open it with the portable app of your choice or have the local machine handle it. And you can have it remember your choice (or ask you next time, too, if you'd like). Then you can manually adjust that all later within the Options window. And you will be able to disable file associations with a couple clicks as well. There are no plans as of yet to have 'profiles' of associations on a per-computer basis, but that may be explored later. There's no need to argue the merits of it now.
Sometimes, the impossible can become possible, if you're awesome!
Are you releasing a test version soon?
I made this half-pony, half-monkey monster to please you.
I would rather not see an answer to this, but rather just have a nice product once it is done. (not that the two are mutually exclusive)
It seems that most times a estimate/date is given, something comes up, and the target is missed. This has only served to frustrate a number of users.
I think we can all agree that John an Co. have created an amazing product! When the next iteration comes along, I am sure it too will be great.
JM2C
It amazes me that on the internet you can be anything you want, and yet so many people still choose to be idiots.