New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
M multi selection list widget #2477
Conversation
…n with nestable=true allows the parent label to be hovered over instead of clicked to open the children flyout labels.
…=true allows the parent label to be hovered over instead of clicked to open the children flyout labels.
seems I had some commit issues that did not resolve, this should fix it.
Try to Trigger another Appveyor build.
… name shown in tooltip on mouse hover.
Hey there! Thanks for helping Mudlet improve. 🌟 You can directly test the changes here:
No need to install anything - just unzip and run. |
@@ -410,7 +410,7 @@ end | |||
--- Internal function when a parent nest element is clicked | |||
--- to lay out the nested elements within | |||
-- @param label The name of the label to use | |||
function doNestClick(label) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes to this file are nothing to do with this PR - I suspect you did not start your work at the correct point in the repository - are they from other changes that have not been merged into the development branch at this time?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, its because my initial commit was done on the "development" branch, before I realized i should have made a unique branch per pull request. Now this new branch "multiselectionlistwidget" was created prior to the other pull request being merged. Needless to say I will be carefull that changes go into their own branches from now on. I am still new to using github.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well if the other PR goes in without any further changes you will get away with it because Git will (normally) silently fast-forward over a change that gets merged in from a different commit - so, since the change was already done it will disappear from the set of changes in this PR - but if the other one has to be changed than this PR will start reporting the difference as a conflict and require the code here to be made to have the same changes (you would have to merge the revised development` branch into your local copy of this branch/PR and then push the merged version out to your repo...) 🤓
@@ -5019,11 +5019,9 @@ void T2DMap::resizeMultiSelectionWidget() | |||
{ | |||
int newWidth; | |||
if (mIsSelectionUsingNames) { | |||
if (width() <= 300) { // 0 - 300 => 0 - 200 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The original code allowed for a smooth size adjustment based on the overall width of the mapper so that it scaled proportionally over the following ranges:
mapper width | selection widget width if names ARE shown | selection widget width if names are NOT shown |
---|---|---|
up to 300 | two thirds of width (so 0 to 200) | two thirds of width (so 0 to 200) and I think I have that slightly wrong so it should only scale up to 120...! |
300 to 600 | one thirds of width + 100 (so 200 to 300) | 120 |
600 or more | one thirds of width + 100 (so 300) | 120 |
The new code just snaps between two fixed widths of 300 - IF THE NAMES ARE SHOWN:
mapper width | selection widget width if names ARE shown | selection widget width if names are NOT shown |
---|---|---|
up to 300 | 160 | two thirds of width (so 0 to 200) |
300 to 600 | 160 | 120 |
600 to 999 | 160 | 120 |
999 or more | 300 | 120 |
If you are going to shrink the width I would urge you to tweak things so there are not snap changes in widths as that is even more annoying (IMHO) in that a slight adjustment in width will produce a sudden change...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how often do people adjust the width of their map while having a multiple rooms selected. In my UI I set my container sizes and my mapper never gets its width adjusted.... honestly I felt that 160 pixels was already a little wider than I liked.
It really is a struggle to move rooms while mapping when your mapper is about 600 pixels wide and the popup list is 300 (half of your visible mapper.)
I will try to think of another solution, but I just got done mapping 20+ areas with the new setting of 160 wide and it was sooooooo much easier to get things done.
maybe at the very extreme end of the width it can start to RAMP up quickly. (will experiment with this when I get home.)
such as:
mapper width | selection widget width if names ARE shown | selection widget width if names are NOT shown |
---|---|---|
up to 300 | 160 | two thirds of width (so 0 to 200) |
300 to 800 | 160 | 120 |
800 to 820 | 180 | 120 |
820 to 840 | 200 | 120 |
840 to 860 | 220 | 120 |
860 to 880 | 240 | 120 |
880 to 900 | 260 | 120 |
900 to 920 | 280 | 120 |
920 to 940 | 300 | 120 |
940+ | 300 | 120 |
Brief overview of PR changes/additions
This makes the popup list widget for multiple selected rooms more compact when the size of the mapper is less than 999pixels wide, going from 300 pixels wide to 160. This makes working with the mapper much easier.
Motivation for adding to Mudlet
Mapping areas and being infuriated while trying to move rooms around while that popup list is visible.