JW library app on Windows behaves non-conform standard windows applications

[PaulvH]

Hi everyone,

 

I've noticed that the JW library app on Windows 10 is not conforming default windows behavior. When the JW library app main window is covered by another application (e.g. zoom) and you want to bring it to the top, clicking the part of the window that is visible may actually trigger the display of a video or image when you were accidentally clicking on a thumbnail area of one of the media files. I don't think this is correct behavior. Clicking on a window that is partly hidden by another application window should not activate a control on the application. It should just bring the application window to the top after which you can start using the controls. So, please, JW library app developers, if you read this, change this behavior to conform with standard windows behavior.

 

Brotherly love,

--Paul

[carlos]

30 minutes ago, PaulvH said:

So, please, JW library app developers, if you read this, change this behavior to conform with standard windows behavior.

Hi Paul! It's very unlikely that the developers of JW Library follow this topic. It would be better if you call the branch and contact the IT department, or send them your report by some other means.

[PaulvH]

Thanks Carlos...I will figure a way on how to reach them. I suspect the actual developers might be scattered around the world.

Verstuurd vanaf mijn SM-S901B met Tapatalk

[➕👇 ꓤꓱꓷꓠꓵ🎵Tone]

While I am not exactly sure if this is the workaround, you could try it:

 

https://github.com/AntonyCorbett/JwlMediaWin

 

Anthony Corbett is a brother who has written programs to make for smooth operation at the KH (as well as a beaut program to 'merge' all your personal notes on the JW library all.)

The above program fixes a process with media display which he describes as 'fragile'. I think this may address your problem.

[jayrtom]

Why do you say this is not a correct behaviour? I just clicked the button to answer to this post while the Edge (browser) window was behind another window which had the focus and the Edge window understood the click and the action of answering was done

 

Note: Edge is a microsoft app so it must comply with the correct windows behaviour...

 

Edited August 17, 2022 by jayrtom

[howudodat]

I suspect this behaviour changed about 5 years ago. I saw some complaints among some of the early previews. In order to scroll an unfocused window mouse events must be passed to the unfocused window.  it would be better if there was a setting allowing to click to activate then click to perform action, but I couldn't find one.  I tested and this behaviour happens with MS Paint, MS Word and several other MS applications, so it is a behaviour by design.

 

1 hour ago, jayrtom said:

Note: Edge is a microsoft app so it must comply with the correct windows behaviour...

I almost spit out my coffee laughing so hard to this comment.  Microsoft is notorious for not complying with their design guidelines

[PaulvH]

Windows scroll events are relatively harmless and sometimes you need the unfocused window to scroll to, for example, compare content. I can see why MS has introduced this behaviour. However, handling mouse click events should be different as it is potentially more dangerous. I can imagine a case where you accidentally hit a "Run" button  in the unfocused window to which it immediately responds with running an action. An action that you didn't intend to perform. I'm a bit rusty on running MS applications (I am a MacOS user), though I haven't seen this behaviour before. In the case of JW library app, you need to be extra careful where you click to gain focus to see all media content which I think is a nuisance.

[howudodat]

I agree it's a nuisance, sadly it's how windows behaves.

gnome behaves the same way

kde does too

windows server 2012 does as well

I have not tested on a mac, but I guess they do too

Edited August 17, 2022 by howudodat

[PaulvH]

I tried clicking the "Share" button in the unfocused Google Chrome browser and it only brought the browser window forward, where I had to click the "Share" button again to perform the actual action. On MacOS it depends pretty much on the application developers. Some do and some don't. For example, Apple Music starts playing when you click on "Play" even though the application doesn't have the focus. For, the JW lib app I would recommend to turn this behaviour off (or better make it configurable) as the impact of accidentally clicking a media thumbnail (i.e. it disrupts the meeting) is big.

[howudodat]

click through is very problematic and pretty much every operating system and desktop has it turned on.  whether or not click-through is needed or dangerous can be debated for days on end.  MacOS human interface guidelines recommend that a control with destructive action or difficult to undo should disable itself when focus is lost.  For "mobile" apps, this is less of an issue because every app is full screen.

 

Let's consider a couple of scenarios:

• The window is completely visible but not focused.  should controls be disabled?  should you have to click twice when you can clearly see the control?  I could see arguments both ways
• What is considered dangerous?  For example, the "home" button on a browser is generally not dangerous.  However if I have been filling an application for the past 45 minutes, and switch away to get some info and click to switch back, hitting home could be very bad.

In either situation creating a decision tree would significantly complicate the software and would slow the app down.

 

I can think of two ways a developer could fix this.

• Hook into very low level mouse event handling and ignore the event if the window doesn't have focus.  Hooking here is problematic and typically results in poor user experience.  (ie: how cell selection vs editing is handled in tables, which is probably the single most difficult part of any system's focus)
• When focus is lost, iterate all controls and disable them, re-enable them when focus is gained.  This would generate visual artifacts, and depending on the number of controls would result in spikes of resource consumption

A lot also depends on the framework that is used to develop the application.  An application built using a native SDK (Software Development Kit) would be more likely to be able to hook into low level events.  I dont know what JWL is currently built in.  Based upon the look and feel, I suspect a cross platform toolkit is being used.  This has the advantage of not needing multiple different teams of developers (MacOS, iOS, Android, Windows, UWP), but many such toolkits dont expose lower level events.  In either case, this would be a fairly large undertaking to get right.

 

Personally I dont like click through at all and feel it should be disabled at an OS level, or actually shouldn't even be the way the OS operates.  However that is not likely to change anytime soon.  I make it a habit to click on the title bar, or window borders so as not to accidentally perform an unwanted action.  Realistically, dont expect this behavior to change.

 

Edited August 18, 2022 by howudodat

[PaulvH]

Thanks for your elaborate response. I can discern a developer background 😉. Anyways, I agree with what you say. I don't like the 'click through' behaviour either, but I guess I just have to accept it. I need to instruct the media hosts to be very careful where they click the JW app window. Best to stay away from the content area. Thanks for your help and useful comments. --Paul