Just saw this comment for XnView by tripex. Thought this would be a better forum to discuss the topic instead of cluttering the entry with comments.



I don't really understand the logic behind this comment, so maybe we can work it out here.

We all know that file associations and shell extensions are not portable. So if you ask Irfanview to register file associations or shell extensions, it is assumed you are prepared to deal with the non-portability.

On the other hand, if you value portability a lot, then you should not ask Irfanview to register file associations or shell extensions. So what exactly is the problem? Are we asking the author of Irfanview to figure out a way to do file associations and shell extensions portably (which technically can't be done), or are we asking the author of Irfanview not to provide these functions (which might be useful to some users)?

I agree with Andy - quite often the question of relative paths is not essential. It is however a good indicator whether or not the application has been designed from the beginning to be truly portable ...

It can be annoying, though, when some of the settings write hard-coded paths - so even if you can carry the settings around, this is not necessarily of big use. I'm thinking of default directories, like for saving or opening etc ... As long as the core application works portable, however, I think there is no reason to take the predicate "portable away

Where I slightly disagree with Andy is that information about relative paths belongs to the comment section. I rarely open the comments, too often there's just useless comments there. In my opinion such info belongs to the synopsis, and if you're already considering new Boolean fields, relative path respect could be another such optional field.

Have a nice week-end all!
Chris

Is there any reasonable way to avoid this problem and keep using the MRU function? I don't think so, because when you work on f:\docs\work.doc the program usually don't know, that F: is the drive where the software is started from itself. It can pre-check, if it is possible to use relative paths, though I have the feeling this can create other fatalities. And even with relativeness paths/checks it will NEVER work on non relative MRU entries anyway.
But I admit I use the MRU seldem or never.

If I understand you right you discuss about the portability of applications that don't do a pre-check to use relative paths in the MRU?

OK, while I am at it, might as well add a new field to the database for this.



Well, cmmehl brought up the point that registry usage is not the only factor affecting portability, another possible factor is support for relative paths. My reply to him was that for some apps (eg. program launchers, MP3 players), it is clear-cut that relative path support is important for portability, but for other apps, it is less clear-cut. I brought up the example of MRU implementation in many apps, include OpenOffice, and argue that it is not clear-cut whether the usage of absolute paths in their MRU implementations detracts from their portability. Some people might actually be annoyed enough to call it non-portable, while others (like myself) couldn't care less.

cmmehl, regarding your comment about Save2ftp, the app indeed does not support relative paths (eg. ..\..\docs\*.*), but it does support absolute paths without drive letters (eg. \personal\docs\*.*), so that should do the trick for portable usage.

I have replied to someones comments. My intention wasn't starting a discussion about portability/stealth but giving info to him, because it seemed not clear to him, what you assume everybody knows. Have you removed my comment?



In my opinion that's not a good argue. According this logic you can also argue, the most CD burner, DVD ripper, overclocker, password hacker or system improving utilities at all are not working without installing a driver, hence they count as portable.



Personally I don't like this discretionary stuff. Some people care more some less about whatever so in my opinion it's the best to make it clear and not to assume too much.

You're right, Andrew, this does the trick, thx for that - quite a handy app. But a pain to configure with this syntax ... it's worse than maths to get to the right statement for the path of the item to back up

Would sure be easier if absolute relative paths were supported, or if there was a variable for the root.

Cheers
Chris

My apologies. I thought it was another discussion about portability of apps, which I tried to direct to this thread. I have added the comment back. It would be clearer if you indicate who you are directly your reply to (in this case, "ken").



Not sure I understand your statement. Could you please elaborate? If the proggie requires manual installation of driver, then it is not portable. But if the app installs a driver dynamically (and remove it upon exit), then it should be portable.



In that case, we can agree to disagree, and leave it at that. I would rather the site remains useful to me, rather than follow some black-and-white rule and choke all the life out of it.

I would have thought most people will find this syntax easier (since you just omit the drive letter). Relative path is a lot harder, since you must master the mental arithmetic of navigating the folder tree and converting them into relative path syntax!

Yep, you're right. Actually, the app can do both, relative and direct path without drive-letter. I had tried the first one first with its "mental arithmetic" >g< and that's what I had referred to.


Absolutely! And the site has proven to be useful not only to you, but to uncounted numbers of faithful users, too. I just love it

Cheers
Chris

OK, my mistake.



It's not only about drivers but everything that changes the host more dramatically than only the system MRU. I believe there are applications, that have to change the host to work properly regardless how much effort the author puts in to make it portable. You argue an mp3-player w/o a usable MRU would be useless, so you start to ALLOW these kind of applications special allowances. With exactly the same argument you could allow file associations, couldn't you? But they have a much more impact. And finally you allow anything, which is necessary for the purpose of an application. Obviously you wouldn't, because of your personal judgement of appropriateness. And that's the issue. Many people like me don't know your level which desides between thumb up or thump down. And because of this you will always encounter purist comments. You can delete them, you can ignore them, you can try to turn purists to free-lovers in discussions or you can specify your goals of the/your site clearer which would either leads to grading or a statement like this:



Grading is not necessarily choking.

Anyway, I will step back from the discussion because it seems there is nothing more to say for me.

CU
Andy

Portable means you can zip the folder on one machine, unzip it on another and it runs there without you setting a lot of stuff up.

Screw the rest

while i agree with most all of what you have posted, i am not sure i agree that file associations or for that matter shell extensions cannot be made portable. the real question to me at least, is do they need to be, and for my purposes they do not.

for example to make file extensions portable; on start up you need to save the current associations, install your new ones, and on shut down reinstall the original.

ok, but what if you can automate "the setting a lot of stuff up". i think alot of apps that are not considered portable here can be made portable without alot of effort ~ just MHO based on experience

you bet there is if you use a script to start the program, and another after the program has ended.