http://imagej.273.s1.nabble.com/Ctrl-Shift-keys-and-arrow-keys-tp5022996p5023033.html
Thanks for the ibus suggestion, that was it. Since the only application
et.al. I woner what was randomly turning this feature on. At least I
> Hi Fred,
>
> a web search for "shift-e fedora" tells that this is a Fedora issue
> related to some feature meant for inserting emojis.
>
> See, e.g.,
>
https://emacs.stackexchange.com/questions/29266/ctrlshifte-key-conflict-in-fedora>
> You can try to solve it by typing on the command line
> ibus-setup
> and changing that key binding.
>
>
> ---
> > Is there a way to move a really small roi with the mouse?
>
> Not that I am aware of, apart from zooming in so you can grab it between
> the handles for resizing.
> Shifting small rois with the arrow keys works, but it is useful for
> short distances only.
>
> One could think about a modifier key for this, but alt, ctrl and shift
> have already other functions:
> shift, alt: add/subtract polygon points, shift for keeping it
> horizontal/vertical or square/circle, ctrl keeps the center fixed.
> For lines, shift-alt keeps the length and forces horizontal/vertical,
> and you can even use ctrl-shift-alt to keep the length and rotate it to
> a horizontal/vertical position around the center.
> The windows key ('meta') is not available on Macs, I fear, the same is
> true for the 'Alt-gr' key (also absent on US windows keyboards) and also
> the middle mouse button is not available everywhere.
>
> Michael
> ________________________________________________________________
> On 03.03.20 06:05,
[hidden email] wrote:
> > Greetings Michael,
> >
> > A couple of updates. Screenshot attached. The added tab moves to the
> > current window. ESC causes the tab to disappear but does not
> discontinue
> > this mode. Also when the dialog poped up to request the timeout for
> > capturing the screen, the text field had a funny looking e in it and I
> > could not change the field value until I hit ESC.
> >
> > For #2, when not in said #2 bug mode, shift-up/down acts as ±.
> > Shift-left/right frame++/frame--. ctrl-left/right
> roi.width++/roi.width--
> > although ctrl-up/down act as ± and not roi.height++/roi.height--.
> >
> > Bonus question/request: Is there a way to move a really small roi with
> > the mouse. Generally you grab the boarder or grab while the cursor is
> > totally with the roi. But, alas, with really small roi(s) these don't
> > work.
> >
> > Thanks,
> >
> > Fred
> >
> > On Mon, March 2, 2020 1:23 pm, Fred Damen wrote:
> >> Greetings Michael,
> >>
> >> In a short example: When trying to restore any roi in a image
> window, with
> >> the cursor in the image window I hit Ctrl-Shift-e and the roi is not
> >> restored but I see...
> >>
> >> +--------------+
> >> | title |
> >> +--------------+
> >> | |
> >> | |
> >> | |
> >> | |
> >> | |
> >> +-+ |
> >> |e| |
> >> +-+--------------+
> >>
> >> Any Ctrl-Shift-(letter) causes the same results. Ctrl-(letter) or
> >> Shift-(letter) works fine. Using the main window menu item that
> >> corresponds to the key sequence always works. This does not happen
> with
> >> any other applications that I have. So there is something that is
> paying
> >> attention to my key stokes while using ImageJ. ImageJ is the only Java
> >> program that I am using. I have upgraded and / or restarted ImageJ
> many
> >> times and it still happens. I have yet to figure out what I do to put
> it
> >> into this mode, or what is guaranteed to take it out of this mode.
> >>
> >> For #2 below: This is independent from #1 and happens randomly on
> >> different systems. I use the arrow keys to move roi(s), (mostly a
> point
> >> roi), around in an image window. Some times I will do something else
> in
> >> ImageJ and then go back to moving the roi around and the left/right
> work
> >> as expected, but the up/down act like ±. As this happens randomly and
> >> infrequently I have not tracked it down to a specific cause(s). It
> seems
> >> as though a key handler is changing its interpretation of these keys
> for
> >> some reason. That reason seems to get reset to normal after a
> >> genericdialog is presented.
> >>
> >> --------
> >> [BTW, I did not understand your other post on CTRL-SHIFT under Fedora;
> >> is this about using the text tool on an image? Can you supply a
> >> screenshot to explain (Plugins>Utilities>Capture Delayed)? Replies in
> >> that thread, please]
> >>
> >> Michael
> >> -------
> >>
> >> Thanks,
> >>
> >> Fred
> >>
> >>
> >> On Sun, March 1, 2020 12:34 am, Fred Damen wrote:
> >>> Greetings,
> >>>
> >>> I have two separate issues with key combinations.
> >>>
> >>> 1) After upgrading to Fedora 31 and a somewhat recent version of
> ImageJ,
> >>> I
> >>> startted noticing that the Ctrl-Shift keys commands stop working
> and the
> >>> letter key was being drawn in a tiny tab just outside the lower left
> >>> corner of the window. This randomly start happening, then after a
> while,
> >>> stop happening, I have yet to figure out the triggering event(s).
> Using
> >>> just the Ctrl OR shift modifier does not seem to be involved.
> Although I
> >>> do not suspect that this is a ImageJ issue per se, but this is the
> only
> >>> place that I have seen this. Does anyone have any insight as to what
> >>> this
> >>> is and how to disable it?
> >>>
> >>> 2) At some random point in ImageWindow(s) the up and down arrow keys
> >>> will
> >>> perform the equivalent of the the + and - keys. The left and right
> >>> arrow
> >>> keys are not affected. Causing a popup menu to appear seems to remap
> >>> the
> >>> up and down arrow keys back to moving an Roi around.
> >>>
> >>> Thanks in advance,
> >>>
> >>> Fred
> >>>
> >>> --
> >>> ImageJ mailing list:
http://imagej.nih.gov/ij/list.html> >>>
> >>
> >> --
> >> ImageJ mailing list:
http://imagej.nih.gov/ij/list.html> >>
>
> --
> ImageJ mailing list:
http://imagej.nih.gov/ij/list.html>