On Tuesday, February 1, 2022 at 11:48:46 AM UTC-5 T. Modes wrote:
> It is difficult to comment because you are often mixing things. Or as an > example you contradict yourself > > [email protected] schrieb am Dienstag, 1. Februar 2022 um 15:41:14 > UTC+1: > >> Hiding would only be temporary: other actions make the magnifier appear >> and "hiding" would not suppress that. > > and later > >> I want the new 'm' key operation to be the only thing that hides the >> magnifier. >> > Not a contradiction at all. I* was* saying 'm' would be the only thing that hides the magnifier, but would not be the only thing that brings the magnifier back once hidden. But since that suggestion does not seem to fit the needs of others, I will drop the idea that 'm' should be the only thing that hides the magnifier. I'll need more thought on how the things that hide the magnifier should interact with each other. I disagree: I like the feature that the magnifier disappear so I have a > better view on the whole neighbourhood of the cp. This makes it easier for > me the judge the cp. > Thanks for telling me in time that I can refine my plans (rather than do work I would later undo). That feature you like, is so inconvenient for others (I'm not alone on this one) that a setting is required and I will now sidetrack into creating that. I'm even fine with the default being the way you like it (though I suspect more users would prefer it my way). > > Please, one change - one changeset. Do not mix things in one changeset. > You can also send patches (diff files) for other people for testing. > It would be hard to split the changes for creating that setting (that I now understand I need, after previously hoping I wouldn't) from the changes I expected to make first, that now include applying that setting. It probably would be ugly to split that from the related magnifier settings that I would have done next if this change didn't need a setting. So I'm seem to be forced into the high side of the meaning of "one change", relative to what you maybe happy with for a first commit from someone you don't have experience with. I'll do my best to make it clean and to pull in as little as practical of the related planned changes. I'll use diff files if those are strongly preferred in this group. But all my professional experience in group software development tells me using public branches in a source code control system works a lot better than emailing diff files. I assume that anyone who could use a diff file could more easily get the full files from the branch and in rare cases that they couldn't use files from a branch, they could get the diff from the branch. -- 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/d7d9aa82-96ca-41ad-9acf-defc4a906531n%40googlegroups.com.
