Am 10.06.21 um 19:18 schrieb T. Modes:
kfj schrieb am Mittwoch, 9. Juni 2021 um 09:04:59 UTC+2:
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.
Hugin registers 2 verbs for pto files: open and stitch.
I don't understand what you mean by 'registers 2 verbs', can you please
explain? what are 'verbs' in this context? And with what are they
registered?
I don't how this interacts with the OpenWithProgID. But this may be a
reasonable approach.
I think that the installer behaves like I intend (see above). Can you
please confirm that it does not unconditionally overwrite any existing
associations? If it does, something is wrong and I'll have to change it.
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
<https://bitbucket.org/kfj/pv/src/master/scripts/lux_setup.iss>
Sorry, but I don't have experience with this scripts. So I can't help here.
But it's easy! You can help, and it's no big deal. The section of the
script which deals with the extension associations merely modifies the
registry. For lux and the .pto extension, this is what happens:
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: ""
This is plain registry modification, to clarify, I'll 'decode' the first
line for you:
Root: HKA; Subkey: "Software\Classes\.pto\OpenWithProgids"; ValueType:
string; ValueName: "{#MyAppName}.pto"; ValueData: ""; Flags:
uninsdeletevalue
This means:
set HKA's subkey Software\Classes\.pto\OpenWithProgids to contain the
string "Lux Panorama Viewer.pto" and remove it when lux is uninstalled
And, to be less verbose: The second and third one merely register the
app name and icon for the association, the fourth one specifies how to
invoke the executable and the fifth one says that lux does support .pto
files.
So the five lines doing the extension association (as MS suggests it for
W10) are easy to understand: they make a few registry changes. AFAICT
the changes do not 'step on hugin's toes', and this is where you could
help: just look at the registry changes and give me your opinion.
I tested Lux again, but it does not match in my workflow.
Fair enough.
When opening a pto file it is slower and takes more memory than Hugins
preview. So I'm faster with Hugin.
That observation is correct. In order to provide smooth animation, lux
uses interpolators which take up a lot of memory and take time to build.
There are a few flags to lower memory consumption, but especially for
views taking in several images (like, from .pto files), memory
consumption and setup time can be high.
I tried to address your criticism that lux is unresponsive during
startup - now you get the splash screen and the status line tells you
what is loaded and built, and if you lose patience, you can press
'Escape' and it will stop and terminate after processing the current
partial image. So now you can interact (if drastically) and you aren't
confronted with an unresponsive program and a white screen during startup.
Let me remind you: you shouldn't really compare lux to hugin in that
respect: lux is primarily a panorama *viewer*. It has some capabilities
to deal with .pto files, but it really shines where you have a
ready-made panorama to display, like a single full spherical. I made it
to *look at* panoramas. That it can also make panoramas is a new
sideline, which you can simply ignore for now. So stitch your panorama
with hugin/nona/enblend, then *look at the result* with lux.
Lux has capabilites of nona and enfuse and enblend built-in, and to
provide all this capability in one application takes more resources than
hugin's approach of delegating most tasks to external programs: cpfind,
nona, enfuse, enblend, PTBatcher - and then leaving it to the user to
find a panorama viewer to look at the result.
Also I don't like the self written interface - but that's a matter of taste.
Again, fair enough. I think you refer to the GUI with it's three rows of
buttons. That is indeed not my favourite part either, it's more of a
gate-opener to the 'proper' way of using lux, which is with the keyboard
and with mouse gestures. You get hints to the keys and gestures by
right-click-holding the buttons. Navigation in the image is like QTVR,
so this should be intuitive. When it comes to stitching and fusing, my
GUI admittedly doesn't help much as it is.
Using a small hand-written immediate mode GUI has the advantage of
needing fewer dependencies and producing a smaller executable, but of
course it's hard to produce a user experience similar to what you get
from a well-made wxwidgets or Qt GUI. Internally, all actions are
relayed via small single-purpose functions, which could easily be
triggered from a different coordinating process.
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/903222e9-ef32-9d9d-6fad-e48c8c329c12%40yahoo.com.
