Ctrl-Shift keys and arrow keys

[Fred Damen]

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

[Fred Damen]

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

[Fred Damen]

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

[Michael Schmid]

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

[Fred Damen]

Greetings Michael,

Thanks for the ibus suggestion, that was it.  Since the only application
that this seems to be happening in was ImageJ, I was suspecting Java,
et.al.  I woner what was randomly turning this feature on.  At least I
know how to turn it off.

Yeah, it would be nice if we could remap the mod-ified mouse buttons.

If the ctrl-left/right stretch the roi left/right, should the ctrl-up/down
stretch the roi up/down?

thanks,

Fred

On Thu, March 5, 2020 5:57 am, Michael Schmid wrote:

> 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
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Michael Schmid]

Hi Fred,

 > If the ctrl-left/right stretch the roi left/right, should the
 > ctrl-up/down stretch the roi up/down?

Ctrl-up/down zooms in/out.
You can use alt-left/right and alt-up/down to modify the ROI size at the
right and bottom side, respectively.

Concerning how to grab small ROIs with the mouse, changing the modifier
keys would not be obvious for the user. Maybe there is a solution to
have some minimum area that is not interpreted as ROI corner handle.
I'll think about it.


Michael
________________________________________________________________
On 08.03.20 20:18, Fred Damen wrote:

> Greetings Michael,
>
> Thanks for the ibus suggestion, that was it.  Since the only application
> that this seems to be happening in was ImageJ, I was suspecting Java,
> et.al.  I woner what was randomly turning this feature on.  At least I
> know how to turn it off.
>
> Yeah, it would be nice if we could remap the mod-ified mouse buttons.
>
> If the ctrl-left/right stretch the roi left/right, should the ctrl-up/down
> stretch the roi up/down?
>
> thanks,
>
> Fred
>
> On Thu, March 5, 2020 5:57 am, Michael Schmid wrote:
>> 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
>>
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html