Mudlet: Labels as a draggable handle breaks if the mouse passes over the minimap.

[xekon]

Brief summary of issue / Description of requested feature:

I am using and have somewhat extended Jor'Mox Drag and Drop GUI Framework: https://forums.mudlet.org/viewtopic.php?p=44735

Labels as a draggable handle breaks if the mouse passes over the minimap, the issue is very obvious when you try to shrink the map window by dragging the handle toward the maps direction.

The only way to resize in that direction is very carefully and very slowly. This really threw me for a loop at first, I had no idea what was going on. The handful of people I have shard the UI with had the same complaint and thought something was broken. I am not sure what the cause of this phenomenon is or how difficult it will be to fix.

Steps to reproduce the issue / Reasons for adding feature:

1. Install Jor'Mox GUI Frame or here is a testing script that can be easily imported with some defaults for testing:

testing.zip

here is an even lighter simpler one with all defaults:
testing_simple.zip

1. Try to resize in the direciton of the map.

[xekon]

Just want to add to this that Jor'mox is not experiencing this issue under OSx, so I will need to try with an unmodified version of his addon/different OS, and see what the culprit is.

I tested on a completely blank profile with an unmodified copy of Jor'Mox framework and get the same result:
testing.zip

[bduza]

Can confirm it occurs in Windows 10.

Additionally, if the map is a tab and a different tab is selected, it does not occur.
Remember that GUIframe (I believe this is correct) only uses :show() to make the selected tab's container visible, and does not use :hide() on the other tabs.

So while the map isn't visible, it is still there, underneath, but the bug only occurs when the map is actually visible. Which may or may not be useful information.

[xekon]

Can confirm it occurs in Windows 10.

Additionally, if the map is a tab and a different tab is selected, it does not occur.
Remember that GUIframe (I believe this is correct) only uses :show() to make the selected tab's container visible, and does not use :hide() on the other tabs.

So while the map isn't visible, it is still there, underneath, but the bug only occurs when the map is actually visible. Which may or may not be useful information.

Thanks for testing! I am on Ubuntu 18.10 KDE, it also occurs on windows 8.1. I am starting to wonder if OSx is the only immune Operating System or if there is another reason that this bug does not occur for Jor'Mox and the OS is just a coincidence.

[SlySven]

Does it depend on how long it takes to redraw the map? Non-release versions (which are slower) will display an approximate measure of how long the T2DMap::paintEvent() took to do most of it's work - if it gets to be a big problem we might be able to reset the updatesEnabled flag for the mapper widget whilst it is being resized...

[xekon]

Does it depend on how long it takes to redraw the map? Non-release versions (which are _slower_) will display an approximate measure of how long the T2DMap::paintEvent() took to do _most_ of it's work - if it gets to be a big problem we _might_ be able to reset the updatesEnabled flag for the mapper widget whilst it is being resized...

SlySven how would I view or see this infromation, and also how would I determine if the redraw time is the culprit or not? in my second example testing_simple.zip thats a blank profile and the mapper does not even have any rooms in it yet and it still occurs.