Using table navigation commands in focus mode flips Windows screen orientation


Louise Pfau
 

Hi.  I just discovered by accident that if you use the NVDA table navigation commands while in focus mode such as the list of messages in the Gmail standard view, the screen orientation flips.  I just checked the archive for the Windows Access with screen readers list, and it looks like there's a conflict between the windows flip screen orientation commands and the NVDA table navigation commands.  I won't cross-post the message.  I know JAWS uses the same table navigation commands, so JAWS users would have the same problem.  Since I use NVDA to navigate the Internet, I figured this observation would be appropriate to this list.  I'm using NVDA 2021.3.1 with Windows 10.  I don't know the exact version, since I'm accessing the interface remotely at the moment.

Louise


Chris Mullins
 

Hi

Yes, this is a long-standing situation, I’m totally blind so it doesn’t make a difference to me as NVDA carries on regardless but my wife will say “your screen is sideways” etc.  You can alwas” do NVDA+f2 for pass through followed by Control+Alt+UpArrow to put it into normal landscape orientation.

 

 

Cheers

Chris

Sent from Mail for Windows

 

From: Louise Pfau
Sent: 07 January 2022 22:28
To: nvda@nvda.groups.io
Subject: [nvda] Using table navigation commands in focus mode flips Windows screen orientation

 

Hi.  I just discovered by accident that if you use the NVDA table navigation commands while in focus mode such as the list of messages in the Gmail standard view, the screen orientation flips.  I just checked the archive for the Windows Access with screen readers list, and it looks like there's a conflict between the windows flip screen orientation commands and the NVDA table navigation commands.  I won't cross-post the message.  I know JAWS uses the same table navigation commands, so JAWS users would have the same problem.  Since I use NVDA to navigate the Internet, I figured this observation would be appropriate to this list.  I'm using NVDA 2021.3.1 with Windows 10.  I don't know the exact version, since I'm accessing the interface remotely at the moment.

Louise

 


Gene
 

I would think that if you are in browse mode, NVDA intercepts the commands and they never reach the display adapter.  So it shouldn’t matter as long as you use the commands in browse mode.
 
Gene

-----Original Message-----
Sent: Friday, January 07, 2022 4:28 PM
Subject: [nvda] Using table navigation commands in focus mode flips Windows screen orientation
 
Hi.  I just discovered by accident that if you use the NVDA table navigation commands while in focus mode such as the list of messages in the Gmail standard view, the screen orientation flips.  I just checked the archive for the Windows Access with screen readers list, and it looks like there's a conflict between the windows flip screen orientation commands and the NVDA table navigation commands.  I won't cross-post the message.  I know JAWS uses the same table navigation commands, so JAWS users would have the same problem.  Since I use NVDA to navigate the Internet, I figured this observation would be appropriate to this list.  I'm using NVDA 2021.3.1 with Windows 10.  I don't know the exact version, since I'm accessing the interface remotely at the moment.

Louise


 

The hierarchy of command key processing in any operating system will be:

1. Operating system itself.  Windows in this case.
2. Accessibility Software.
3. Application Software.

And as soon as one of the above has processed a command, that's where it stops.  The next member of the command processing bucket brigade is not passed "the bucket."

I'm guessing that the command that changes screen orientation is not a toggle, or else NVDA should never have access to that keystroke.  My guess is that it's strictly a "flip sideways" command that only gets processed by Windows (for the display adapter/driver) if the screen is not already in the flipped state.  If it is, it will then not be processed and continue down the chain.

Just curious, but what's the exact sequence to make this happen?  I'd love to try it out myself for the fun of it .

I am confused as to why one would have to use the NVDA pass-through command to make the correction since if CTRL + ALT + Up Arrow is a OS level command it should never be handed to NVDA to begin with.

On my laptop, without any screen reader running, CTRL + ALT + Left/Right/Up/Down Arrow has no effect.
--

Brian - Windows 10, 64-Bit, Version 21H2, Build 19044  

The instinctive need to be the member of a closely-knit group fighting for common ideals may grow so strong that it becomes inessential what these ideals are.

       ~ Konrad Lorenz (1903-1989)

 


Gene
 

I’ve seen the probloem discussed now and then in the past.  I would imagine it is a command certain display adapters use, but I don’t know which ones.
 
I seem to think it is a common command in Dell computers.  I have a vague memory of that from seeing it discussed years ago.
 
Gene

-----Original Message-----
Sent: Friday, January 07, 2022 4:52 PM
Subject: Re: [nvda] Using table navigation commands in focus mode flips Windows screen orientation
 
The hierarchy of command key processing in any operating system will be:

1. Operating system itself.  Windows in this case.
2. Accessibility Software.
3. Application Software.

And as soon as one of the above has processed a command, that's where it stops.  The next member of the command processing bucket brigade is not passed "the bucket."

I'm guessing that the command that changes screen orientation is not a toggle, or else NVDA should never have access to that keystroke.  My guess is that it's strictly a "flip sideways" command that only gets processed by Windows (for the display adapter/driver) if the screen is not already in the flipped state.  If it is, it will then not be processed and continue down the chain.

Just curious, but what's the exact sequence to make this happen?  I'd love to try it out myself for the fun of it .

I am confused as to why one would have to use the NVDA pass-through command to make the correction since if CTRL + ALT + Up Arrow is a OS level command it should never be handed to NVDA to begin with.

On my laptop, without any screen reader running, CTRL + ALT + Left/Right/Up/Down Arrow has no effect.
--

Brian - Windows 10, 64-Bit, Version 21H2, Build 19044  

The instinctive need to be the member of a closely-knit group fighting for common ideals may grow so strong that it becomes inessential what these ideals are.

       ~ Konrad Lorenz (1903-1989)

 


Rui Fontes
 

Sorry, but that order is incorrect...


Screen readers intercept keystrokes before they get to the operative system...


Between apps and operative system, I don't know the order...


If you are not in focus mode, the keystroke is intercepted by NVDA and nevers get to the operative system, so the screen orientation is not fliped.

In focus mode, those commands do not apply to NVDA, so they are passed to the operative system.


Rui Fontes



Às 22:52 de 07/01/2022, Brian Vogel escreveu:

The hierarchy of command key processing in any operating system will be:

1. Operating system itself.  Windows in this case.
2. Accessibility Software.
3. Application Software.

And as soon as one of the above has processed a command, that's where it stops.  The next member of the command processing bucket brigade is not passed "the bucket."

I'm guessing that the command that changes screen orientation is not a toggle, or else NVDA should never have access to that keystroke.  My guess is that it's strictly a "flip sideways" command that only gets processed by Windows (for the display adapter/driver) if the screen is not already in the flipped state.  If it is, it will then not be processed and continue down the chain.

Just curious, but what's the exact sequence to make this happen?  I'd love to try it out myself for the fun of it .

I am confused as to why one would have to use the NVDA pass-through command to make the correction since if CTRL + ALT + Up Arrow is a OS level command it should never be handed to NVDA to begin with.

On my laptop, without any screen reader running, CTRL + ALT + Left/Right/Up/Down Arrow has no effect.
--

Brian - Windows 10, 64-Bit, Version 21H2, Build 19044  

The instinctive need to be the member of a closely-knit group fighting for common ideals may grow so strong that it becomes inessential what these ideals are.

       ~ Konrad Lorenz (1903-1989)

 


Chris Mullins
 

Hi

I’m not sure this hierarchy is correct. the NVDA passthrough command exists so that you can pass a NVDA command through without it being processed by NVDA.  Control+alt+LeftRightUpDown arrows all alter screen orientation but if you issue one and you are in a document but not in a table, NVDA says “not in a table” and it is in that situation you use passthrough followed by the appropriate command to affect the screen orientation.intercepted ,

 

Cheers

Chris

 

Sent from Mail for Windows

 

From: Brian Vogel
Sent: 07 January 2022 22:52
To: nvda@nvda.groups.io
Subject: Re: [nvda] Using table navigation commands in focus mode flips Windows screen orientation

 

The hierarchy of command key processing in any operating system will be:

1. Operating system itself.  Windows in this case.
2. Accessibility Software.
3. Application Software.

And as soon as one of the above has processed a command, that's where it stops.  The next member of the command processing bucket brigade is not passed "the bucket."

I'm guessing that the command that changes screen orientation is not a toggle, or else NVDA should never have access to that keystroke.  My guess is that it's strictly a "flip sideways" command that only gets processed by Windows (for the display adapter/driver) if the screen is not already in the flipped state.  If it is, it will then not be processed and continue down the chain.

Just curious, but what's the exact sequence to make this happen?  I'd love to try it out myself for the fun of it .

I am confused as to why one would have to use the NVDA pass-through command to make the correction since if CTRL + ALT + Up Arrow is a OS level command it should never be handed to NVDA to begin with.

On my laptop, without any screen reader running, CTRL + ALT + Left/Right/Up/Down Arrow has no effect.
--

Brian - Windows 10, 64-Bit, Version 21H2, Build 19044  

The instinctive need to be the member of a closely-knit group fighting for common ideals may grow so strong that it becomes inessential what these ideals are.

       ~ Konrad Lorenz (1903-1989)

 

 


Gene
 

Its an interesting question.  In browse mode, for example, many commands are intercepted by the screen-reader and they don't go further.  But what happens in other instances.  When you down arrow in Notepad or a word processor, two things have to happen, the down arrow action has to be carried out in the program and the screen-reader has to know to announce the next line.  So the command is causing two actions, moving the cursor to the next line and telling the screen-reader to announce that line.  So what is the order in a case like that? 


If I use the key pass through command in an editor, I move by line but nothing is announced.  But how does NVDA know when to speak, that is, to announce the line you move to.  It would seem the command causes the cursor to move to the next line and then the screen-reader is told to announce that line.  I suspect that both Brian and others are correct, depending on the context.


Gene

On 1/7/2022 5:47 PM, Chris Mullins wrote:

Hi

I’m not sure this hierarchy is correct. the NVDA passthrough command exists so that you can pass a NVDA command through without it being processed by NVDA.  Control+alt+LeftRightUpDown arrows all alter screen orientation but if you issue one and you are in a document but not in a table, NVDA says “not in a table” and it is in that situation you use passthrough followed by the appropriate command to affect the screen orientation.intercepted ,

 

Cheers

Chris

 

Sent from Mail for Windows

 

From: Brian Vogel
Sent: 07 January 2022 22:52
To: nvda@nvda.groups.io
Subject: Re: [nvda] Using table navigation commands in focus mode flips Windows screen orientation

 

The hierarchy of command key processing in any operating system will be:

1. Operating system itself.  Windows in this case.
2. Accessibility Software.
3. Application Software.

And as soon as one of the above has processed a command, that's where it stops.  The next member of the command processing bucket brigade is not passed "the bucket."

I'm guessing that the command that changes screen orientation is not a toggle, or else NVDA should never have access to that keystroke.  My guess is that it's strictly a "flip sideways" command that only gets processed by Windows (for the display adapter/driver) if the screen is not already in the flipped state.  If it is, it will then not be processed and continue down the chain.

Just curious, but what's the exact sequence to make this happen?  I'd love to try it out myself for the fun of it .

I am confused as to why one would have to use the NVDA pass-through command to make the correction since if CTRL + ALT + Up Arrow is a OS level command it should never be handed to NVDA to begin with.

On my laptop, without any screen reader running, CTRL + ALT + Left/Right/Up/Down Arrow has no effect.
--

Brian - Windows 10, 64-Bit, Version 21H2, Build 19044  

The instinctive need to be the member of a closely-knit group fighting for common ideals may grow so strong that it becomes inessential what these ideals are.

       ~ Konrad Lorenz (1903-1989)

 

 


 

On Fri, Jan 7, 2022 at 06:47 PM, Chris Mullins wrote:
I’m not sure this hierarchy is correct.
-
This is one of those things where the following observation applies:

A sensible person realizes that all principles that can be expressed in a statement of finite length are oversimplified.

    ~ Robert Heppe


Getting into how the exception flows are handled once you are within a given layer can get very, very difficult to follow indeed.

There is a reason why things like CTRL+C, ALT+S, and similar stay the same across hundreds of programs, and that's because these commands are, for all practical intents and purposes, handled by system calls to the OS, not any given application (or accessibility) program.

But once you are inside a given application, things can be set up such that it can use a keyboard shortcut that's used by many other programs that is not an "OS level function."  You don't escape from an application except by deliberately doing so, so once you're in the screen reader and application zone, you're somewhat cut off from the OS, but not entirely.

It may be easier to think of it as a set of nested circles where each is a zone, and anything contained inside a zone is subject to the thing that surrounds it and where the thing that surrounds it takes priority.  That is seen very clearly in NVDA and other screen readers, and is why the pass through command is necessary.  If NVDA (or another screen reader) uses a keystoke sequence command, and the application it accesses also uses that same sequence, it will never get to the application until you have hit the pass-through command to let the screen reader know that it should ignore the next command issued and just pass it through to the underlying/inside it's zone application program.

It's an oversimplification, but there are commands that never make it to a screen reader.  The easiest one I can think of off the top of my head is CTRL + ALT + Delete.  This is always handled by Windows, no matter what else is running, and whether there is a screen reader is running or not.  And it is not passed through to either the screen reader nor any application after it is processed.

The operating system always has "first dibs."  But there are a limited number of keyboard shortcuts that the OS processes directly, as opposed to having system calls handing control to it.  The vast majority of keyboard shortcuts are handled either by accessibility software or the applications being accessed by same.  But those same shortcuts were "seen" by Windows, and it's already made the determination "it's not mine to process" before the screen reader or application ever gets its hands on it.
--

Brian - Windows 10, 64-Bit, Version 21H2, Build 19044  

The instinctive need to be the member of a closely-knit group fighting for common ideals may grow so strong that it becomes inessential what these ideals are.

       ~ Konrad Lorenz (1903-1989)

 


Gene
 

I just found out something very interesting.  When using the pass next key through command before down arrowing in Notepad, nothing is spoken when I down arrow and I move to the next line.  When I use the pass through command in a list of folders and files, what I move to is spoken.
 
I wondered if the difference in behavior had to do with something being highlighted.  Evidently not.  When I use the pass through command and control down arrow in a list, the item I move to is still spoken even though it isn’t highlighted. 
 
Gene

-----Original Message-----
Sent: Friday, January 07, 2022 6:04 PM
Subject: Re: [nvda] Using table navigation commands in focus mode flips Windows screen orientation
 
On Fri, Jan 7, 2022 at 06:47 PM, Chris Mullins wrote:
I’m not sure this hierarchy is correct.
-
This is one of those things where the following observation applies:

A sensible person realizes that all principles that can be expressed in a statement of finite length are oversimplified.

    ~ Robert Heppe


Getting into how the exception flows are handled once you are within a given layer can get very, very difficult to follow indeed.

There is a reason why things like CTRL+C, ALT+S, and similar stay the same across hundreds of programs, and that's because these commands are, for all practical intents and purposes, handled by system calls to the OS, not any given application (or accessibility) program.

But once you are inside a given application, things can be set up such that it can use a keyboard shortcut that's used by many other programs that is not an "OS level function."  You don't escape from an application except by deliberately doing so, so once you're in the screen reader and application zone, you're somewhat cut off from the OS, but not entirely.

It may be easier to think of it as a set of nested circles where each is a zone, and anything contained inside a zone is subject to the thing that surrounds it and where the thing that surrounds it takes priority.  That is seen very clearly in NVDA and other screen readers, and is why the pass through command is necessary.  If NVDA (or another screen reader) uses a keystoke sequence command, and the application it accesses also uses that same sequence, it will never get to the application until you have hit the pass-through command to let the screen reader know that it should ignore the next command issued and just pass it through to the underlying/inside it's zone application program.

It's an oversimplification, but there are commands that never make it to a screen reader.  The easiest one I can think of off the top of my head is CTRL + ALT + Delete.  This is always handled by Windows, no matter what else is running, and whether there is a screen reader is running or not.  And it is not passed through to either the screen reader nor any application after it is processed.

The operating system always has "first dibs."  But there are a limited number of keyboard shortcuts that the OS processes directly, as opposed to having system calls handing control to it.  The vast majority of keyboard shortcuts are handled either by accessibility software or the applications being accessed by same.  But those same shortcuts were "seen" by Windows, and it's already made the determination "it's not mine to process" before the screen reader or application ever gets its hands on it.
--

Brian - Windows 10, 64-Bit, Version 21H2, Build 19044  

The instinctive need to be the member of a closely-knit group fighting for common ideals may grow so strong that it becomes inessential what these ideals are.

       ~ Konrad Lorenz (1903-1989)

 


 

Hi all,

First, to answer the original question, Control+Alt+arrow keys is typically used by Intel display drivers to set screen orientation. I believe you can turn off a setting in Intel graphics utility to prevent this in the future.

To answer the subsequent discussion: the picture described by Gene is a simplified version of what is actually happening. In fact, it is a bit more complicated, but it goes something like this:

There is a family of features and commands specifically designed to work with edit fields, collectively grouped under "editable text". Editable text support consists of:

  1. A way to detect text ranges inside an edit field. Through a concept called text infos, NVDA can ask the app or accessibility API for the text of a control. For edit fields, it includes the text content, and if defined, the label (name) of the edit field. For simplicity, text infos in edit fields will deal with field content (internally, NVDA sees it as value of the control; ask me offlist as to why this is the case as it requires explaining accessibility API properties, something well beyond the scope of this list).
  2. A way to determine where the cursor (caret) is at, along with cursor movement commands. Cursor movement commands, in turn, rely on a concept of "movement unit" such as character, word, line, sentence, or paragraph.
  3. The actual cursor movement gestures such as arrow keys.
  4. Customizations for specific edit fields such as ones requiring screen scraping, different accessibility API's, and in an extreme case, browse mode documents. Browse mode documents is quite a complicated case because NVDA must obtain the entire web document (some developers call this "eating or swallowing the document") to present something that is navigable and presentable.

To use Gene's example, here is what NVDA does when you press down arrow key from Notepad:

  1. NVDA first determines the source of the just performed command. If located on an edit field (like this case), NVDA knows that down arrow key is assigned to cursor movement command, so it invokes line movement script. The source of this script is not the application itself, but rather, the control that NVDA recognizes as an edit field. I may come back to the "magic" behind it upon request.
  2. From the line movement script, a helper function is invoked whose job is to coordinate caret movement and new position announcement if possible. One of the parameters of this helper function is the movement unit, and since down arrow moves to the next line, the movement unit will be set to "line". The gesture (down arrow) is also pased in.
  3. The helper function tries to locate where the caret is at. This involves locating the text info associated with the open Notepad document and getting the caret posistion if possible.
  4. If the caret could not be located, down arrow is "pressed" by NVDA and the helper function ends, and so does the down arrow command behavior. How a screen reader can "press" keyboard keys is beyond the scope of this thread, but suffice to say that this technique is employed in several add-ons.
  5. By now the helper function knows where the caret is (NVDA calls this "bookmark"), so down arrow key is "pressed". This allows Notepad to update the cursor position.
  6. NVDA waits up to 10 milliseconds for the new caret position, and if the cursor did not move (when the timeout elapses), NVDA gives up.
  7. If NVDA determines that the caret did move, it announces the movement unit associated with the just performed movement command, which in our case is announcing the line where the caret is located.

Hope this helps.

Cheers,

Joseph


Gene
 

I'm not sure if I made clear in my previous message that I was presenting what seemed logical to me as to what is occurring.  I'll read your message again to see if I understand your description better.  It appears to me at this point that what I wrote is logical but not accurate because what is occurring is much more complex and my logical discussion didn't know about the complexity.


Gene

On 1/7/2022 8:50 PM, Joseph Lee wrote:

Hi all,

First, to answer the original question, Control+Alt+arrow keys is typically used by Intel display drivers to set screen orientation. I believe you can turn off a setting in Intel graphics utility to prevent this in the future.

To answer the subsequent discussion: the picture described by Gene is a simplified version of what is actually happening. In fact, it is a bit more complicated, but it goes something like this:

There is a family of features and commands specifically designed to work with edit fields, collectively grouped under "editable text". Editable text support consists of:

  1. A way to detect text ranges inside an edit field. Through a concept called text infos, NVDA can ask the app or accessibility API for the text of a control. For edit fields, it includes the text content, and if defined, the label (name) of the edit field. For simplicity, text infos in edit fields will deal with field content (internally, NVDA sees it as value of the control; ask me offlist as to why this is the case as it requires explaining accessibility API properties, something well beyond the scope of this list).
  2. A way to determine where the cursor (caret) is at, along with cursor movement commands. Cursor movement commands, in turn, rely on a concept of "movement unit" such as character, word, line, sentence, or paragraph.
  3. The actual cursor movement gestures such as arrow keys.
  4. Customizations for specific edit fields such as ones requiring screen scraping, different accessibility API's, and in an extreme case, browse mode documents. Browse mode documents is quite a complicated case because NVDA must obtain the entire web document (some developers call this "eating or swallowing the document") to present something that is navigable and presentable.

To use Gene's example, here is what NVDA does when you press down arrow key from Notepad:

  1. NVDA first determines the source of the just performed command. If located on an edit field (like this case), NVDA knows that down arrow key is assigned to cursor movement command, so it invokes line movement script. The source of this script is not the application itself, but rather, the control that NVDA recognizes as an edit field. I may come back to the "magic" behind it upon request.
  2. From the line movement script, a helper function is invoked whose job is to coordinate caret movement and new position announcement if possible. One of the parameters of this helper function is the movement unit, and since down arrow moves to the next line, the movement unit will be set to "line". The gesture (down arrow) is also pased in.
  3. The helper function tries to locate where the caret is at. This involves locating the text info associated with the open Notepad document and getting the caret posistion if possible.
  4. If the caret could not be located, down arrow is "pressed" by NVDA and the helper function ends, and so does the down arrow command behavior. How a screen reader can "press" keyboard keys is beyond the scope of this thread, but suffice to say that this technique is employed in several add-ons.
  5. By now the helper function knows where the caret is (NVDA calls this "bookmark"), so down arrow key is "pressed". This allows Notepad to update the cursor position.
  6. NVDA waits up to 10 milliseconds for the new caret position, and if the cursor did not move (when the timeout elapses), NVDA gives up.
  7. If NVDA determines that the caret did move, it announces the movement unit associated with the just performed movement command, which in our case is announcing the line where the caret is located.

Hope this helps.

Cheers,

Joseph


 

Hi Gene,

I think you did explain the high level overview much better than I did, so I guess our messages should be complementary.

Cheers,

Joseph


Gene
 

Thank you. 
 
Your message shows how much more complex what is going on is.  I’d like to understand more of what is occurring.  I’ll read your message again to see if I can get a better idea of the complex things that are occurring.
 
Gene
-----OOriginal message-----

From: Joseph Lee
Sent: Friday, January 07, 2022 9:23 PM
Subject: Re: [nvda] Using table navigation commands in focus mode flips Windows screen orientation
 

Hi Gene,

I think you did explain the high level overview much better than I did, so I guess our messages should be complementary.

Cheers,

Joseph


Louise Pfau
 

On Fri, Jan 7, 2022 at 03:52 PM, Brian Vogel wrote:
Just curious, but what's the exact sequence to make this happen?  I'd love to try it out myself for the fun of it .
Try using one of the table commands while focused on the address bar.  I got there by mistake.  Both my computer and the computer I'm using to check the archive use Intel drivers, which was mentioned in a later message as the cause.

Thanks,

Louise


Gene
 

Louise and all
It should work anywhere that you are not in browse mode and where a program isn’t using those commands.  I would expect it would cause this action in most places.  Of course, you would have to have a video display that uses the commands.
 
Gene

-----Original Message-----
Sent: Tuesday, January 11, 2022 3:52 PM
Subject: Re: [nvda] Using table navigation commands in focus mode flips Windows screen orientation
 
On Fri, Jan 7, 2022 at 03:52 PM, Brian Vogel wrote:
Just curious, but what's the exact sequence to make this happen?  I'd love to try it out myself for the fun of it .
Try using one of the table commands while focused on the address bar.  I got there by mistake.  Both my computer and the computer I'm using to check the archive use Intel drivers, which was mentioned in a later message as the cause.

Thanks,

Louise


 

On Tue, Jan 11, 2022 at 04:52 PM, Louise Pfau wrote:
Try using one of the table commands while focused on the address bar. 

-
Louise,

I'll have to give that a whirl when I'm using a machine with Intel graphics.  The one I'm using now, and using most often, has AMD Radeon R7 graphics and wouldn't have the same commands.

I just tried the CTRL + ALT + Left/Right/Up/Down arrow keys and nothing amiss occurs.  Well, one thing, NVDA started up when I hit CTRL + ALT + Right Arrow, but that's because I tweaked the desktop shortcut when playing with all this a few days ago.
 
--

Brian - Windows 10, 64-Bit, Version 21H2, Build 19044  

The instinctive need to be the member of a closely-knit group fighting for common ideals may grow so strong that it becomes inessential what these ideals are.

       ~ Konrad Lorenz (1903-1989)