Thanks for the feedback (nice to know it is not entirely my personal unusual take on UIs).
More details on what problems you have (I assume not identical to mine) might help. You may give me more ideas on how to make it better for my own use and/or if I manage to fix my build I would be glad to provide a link to a built copy if you want, or if those in charge accept my changes, everyone might have them. If either of those ways can get a binary to you, I would probably fix anything easy to fix (in that area of the code) that you mention, even if it doesn't matter to me. So far I'm finding the source code unusually obvious and easy to fix (compared to other open source) while the build process has basically defeated me. So if I'm fixing anything, fixing more shouldn't be significantly harder. I would actually use what I can build now: an improved UI for control points in one build of hugin, with the need to switch to an official build to stitch. I only tried to build the hugin executable itself, not the other pieces. I copied the other executables from the official build and the failure (due to whatever build error) is in the hugin executable after the user clicks "stitch" but before hugin tells the external executable to start. I built in Windows with mingw64 (I hate the anti-optimization of the free version of Visual Studio and go to great lengths to avoid using it). I built in Ubuntu and installed the official hugin build for ubuntu, both right before switching to Fedora/KDE (on a different drive) for most of my Linux use. When I have the time, I'll likely redo in Fedora the hugin things I tried in Ubuntu. So if I solve my build mistakes I might have builds for Windows, Ubuntu and Fedora. Meanwhile I switch back to Ubuntu for hugin experiments, but generally prefer to use Windows for hugin. On Friday, January 21, 2022 at 3:18:27 PM UTC-5 [email protected] wrote: > I'm just an user. But I seem to have the same problems with Control Points > as you. > > > Am 21. Januar 2022 19:34:06 MEZ schrieb "[email protected]" < > [email protected]>: >> >> I want to make a bunch of changes to the control point dialog. >> Maybe this is just for my own use. But if those in control of the >> project think any of these are good ideas, I'd be happy to go to the extra >> effort to do these changes in a way that can go into the official version >> (I'll need a bit of guidance on that). >> >> For any of these, I'm asking first for what I misunderstood about the >> existing UI that makes the change unnecessary (how could I otherwise have >> avoided the problems I want to fix), and second for suggestions on >> how/where to make the change, and third for suggestions of a different >> feature I might add that would solve the same problem in a way other users >> would prefer: >> >> 1) Max resolution. 200% really isn't enough for me to place control >> points easily. I don't know what puts me or my photos or my large high res >> displays outside the usual range, but adding 400% and 800% choices is a >> trivial code change that will make the program easier for me to use. >> 2) Losing the magnifier. It always goes away at 200%, even though it >> magnifies enough to be helpful at 200% and can be made to usefully magnify >> even more. I found/understand the code that removes it for 200%. It also >> sometimes gets a timer and goes away by timer. I found but don't >> understand that code. I don't understand the intent of it going away by >> timer, nor the actual behavior (as a user, I can't predict which actions do >> or don't make the magnifier go away on a timer). I'm slow. I never want a >> timer taking the magnifier away. I do want to be able to actively get rid >> of the magnifier, see item 3. >> 3) More keyboard control. I don't have the dexterity to do as much with >> the mouse in that dialog as I assume others do. I have a lot of accidents, >> such as create a point when I intended to move one, then try to delete the >> new one, randomly deleting a distant one instead, then they renumber (see >> item 5) and I'm totally lost. Using the keyboard to move a point, I can >> never predict nor control which of the two will move (see item 4). I want >> keys to control which side is selected. Code exists that given a user >> provided position for one side of a control point will try to find the >> other side. I don't yet know where that code is, but I want to define a >> key to activate it (user places or moves a point then presses the key to >> switch sides, then the key to auto place the corresponding point). >> 4) Visible indicator of which side is selected. No clue what it should >> look like nor how to code it. Suggestions appreciated, but I'll figure it >> out myself if necessary. >> 5) Global stable numbering of points (as an option if this gets shared >> with others). I'm sick of losing track as points renumber. I want a gap >> left when I delete a point, that may be reused for a new point but won't be >> reassigned to a different point. I want the ability to place a control >> point on more than two images in multi-way overlap. So I should be able to >> switch the active list of points for a pair of images from their >> intersection to their union (and have some visible indicator of left vs. >> right vs. both) then select a point that is in just one of the two sides >> and right click selection and/or key to have the software guess where it >> goes in the other side. (I have enhancement ideas elsewhere that depend on >> points identified this way, but even without those enhancements, this would >> be a convenience feature for me). Advanced version of this would have the >> option to use the most recent optimize results to exclude point that are >> outside the geometry of the other side. >> >> I don't yet have a correct build of hugin either on Windows (mingw64) or >> on Linux. I struggled with both and never got cmake to believe the given >> location of dependencies either for hugin itself or for dependencies of >> dependencies when building those. I got past that in Linux with modest >> kludging and in Windows with massive kludging. I'll start a different >> thread on any of that if help is available. Current state on both >> systems: Most of hugin works including the whole control point dialog and >> the ability to save the project. But no way to make it stitch. On both >> systems I also have a binary install of hugin in a different place that can >> stitch (from the project saved from the version I built). So I can >> test/use control point changes without correcting build issues. But I'd >> like to fix the build issues. >> >> >> -- 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/9e1c3b0f-9253-4366-95bc-e05d1f42680bn%40googlegroups.com.
