Am 08.06.21 um 19:17 schrieb T. Modes:
kfj schrieb am Dienstag, 8. Juni 2021 um 18:50:42 UTC+2:
It's likely that a windows system doesn't have
associations for some of these extensions (especially .pto, .lux and
.exr), in which case the doubleclick should even work without the
dialog.
If Hugin installer is used, it register the pto files with Hugin.
I would appreciate if you would keep this association intact instead of
unconditional overwrite it.
It doesn't. I think simply overwriting existing associations is no
longer possible with windows 10 - especially unconditional overwrites
simply aren't allowed anymore.
It was my impression that on Windows 10 a new association with an
extension results in a dialog when a file with this extension is next
doubleclicked, and the dialog offers the user to choose a new
association as the standard or keep the old one. Only if the association
was *not present previously*, the new program will open a file with this
extension when it's doubleclicked *without an intervening dialog*. When
I tested the installer, I saw this behaviour on my windows 10 pro 20H2
install. Did you actually test the installer and observe a different
behaviour? What system are you using?
My intention is to have this bahaviour: if the .pto extension is already
assigned (like, to hugin), and lux is installed afterwards, the first
doubleclick on a .pto after the installation of lux should result in a
dialog which offers the user to keep this association or change it to
another candidate. After the choice is made, the next time someone
doubleclicks on a .pto, it's opened with the application the user has
selected. I think this is perfectly reasonable. Other Windows users,
please comment.
Thomas, you're good with windows. Why don't you help lux along? It would
be easy for you the help make the installer do precisely the right
thing, you know about stuff like the registry, which is alien to me as a
linux person. I've published the .iss script on bitbucket, and if you
find fault with it, why don't you change it? You can send in a patch,
and I'll consider it - and so can everyone else. The file is in the
scripts section:
https://bitbucket.org/kfj/pv/src/master/scripts/lux_setup.iss
If you have a better idea for an installer, you're also very welcome. I
did consider nullsoft, because I could use cpack's NSIS module, it's
only that Frederico came up with the inno setup idea, and it's an
independent project, I liked the script-driven approach, so I went along
with the suggestion. I do in fact prefer my own 'bundles' which are
stickware and require no installation, but you know how windows users are...
Try lux - it's really a very nice program! You don't have to use it for
stitching or exposure fusion or focus stacking or deghosting - all the
synoptic work is optional. Primarily it's an image and panorama
*viewer*. It makes an ideal companion for hugin, but it's new technology
makes it hard to give stuff back to hugin and panotools. I'm not trying
to take anything away from the hugin project - it's just that I don't
get much help or feedback from the hugin project, so I go ahead best as
I can. I tried to get the people on hugin-ptx interested in my program,
even when it was in it's early stages of development. My postings were
usually quickly shot down with something someone did not like about it,
then the threads died down and my effort was ignored for another year or
two until I tried again. What was I supposed to do but carry on
developing as I saw fit? I'd much rather have someone else doing the
windows builds and installers, but even though Frederico started the
.iss for inno setup, it's ended up with me again to make it run okay. I
bet you know how it is if one has to do just about everything.
Here's the code for the .pto association in the .iss script:
Root: HKA; Subkey: "Software\Classes\.pto\OpenWithProgids"; ValueType:
string; ValueName: "{#MyAppName}.pto"; ValueData: ""; Flags:
uninsdeletevalue
Root: HKA; Subkey: "Software\Classes\{#MyAppName}.pto"; ValueType:
string; ValueName: ""; ValueData: "Lux Panorama Viewer"; Flags:
uninsdeletekey
Root: HKA; Subkey: "Software\Classes\{#MyAppName}.pto\DefaultIcon";
ValueType: string; ValueName: ""; ValueData: "{app}\{#MyAppIconName},0"
Root: HKA; Subkey:
"Software\Classes\{#MyAppName}.pto\shell\open\command"; ValueType:
string; ValueName: ""; ValueData: """{app}\{#MyAppExeName}"" ""%1"""
Root: HKA; Subkey:
"Software\Classes\Applications\{#MyAppExeName}\SupportedTypes";
ValueType: string; ValueName: ".pto"; ValueData: ""
Note the OpenWithProgids registry entry: if I understand this correctly,
it has a list of several applications which can handle the extension.
This is different from the old code, where one could simply overwrite
the relevant registry key(s) to force a new association. I think the new
mode is a compromise: it allows programs to register their extensions to
be immediately effective (like .lux, or .pto when it's not been
associated previously) and still protects existing associations by *only
offering the choice to change* when the extension was already associated.
Kay
--
A list of frequently asked questions is available at:
http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/hugin-ptx/07e89707-11fc-4774-ad07-d9b64837919f%40yahoo.com.
