@pieper Are you suggesting that the effects no longer be in a ctkFlowLayout but rather a QGridLayout? If I manually expand the left side panel to be larger the effects would move to try and be on 1 row rather than multiple rows. If a QGridLayout, then on smaller screens the minimum size of the side panel would increase as it couldn’t change from say 8 effects across 2 rows to be say 4 effects across 4 rows.
Yes exactly. I don’t think it’s helpful for the effect buttons to jump around. If we just use the icons (no text) we can make multiple rows of a reasonable width. These could be generally grouped by similarity but I wouldn’t bother naming and labeling the groups since I agree with @muratmaga that the concept names aren’t exact, but rows of effects with somewhat similar behavior or interface could be helpful so people remember where to look for a type of operation.
Text looks nice and saves time for novices, but I agree that it may not worth the space it takes.
Flow layout saves space but not the saving is not that significant and forces users to scan through the complete icon list, so a static grid layout would probably work better.
We can allow users to configure both button label visibility and grid layout column count.
If we hide the Slicer logo at the top and put the Data probe in a dockable widget then probably we don’t need to scroll anymore.
If we need even more vertical space then we could add an option to show the toolbar on the side, using 1 or 2 columns.
I also like this idea, with the proviso that font size for these tooltips should a bit bigger than the rest. With my aging eyes, I find it quite difficult to read the contents of tooltips sometimes.
Yes, maybe not a tooltip with a delay, but a label below the rows of buttons that updates instantly as you mouse over the buttons. Similar in effect to the way the DataProbe updates as you mouse over segments.
I’ll post here again once I post another PR with the suggestions discussed on this thread.
Well here’s a first look for visual impressions. Actually using it can come soon after.
Thoughts on the “Segment Editor Effects” toolbar?
Does it work as a Toolbar? or should it instead be contained inside the Segment Editor module layout?
The allowed areas could be anywhere (Left, Top, Right, Bottom) with the default location being the left toolbar area. Should it be allowed anywhere including floatable?
Should it only be shown when the Segment Editor module is the selected module? It really depends on other functionality of the module.
For a smaller window size there is automatically an expand button to show the other toolbar buttons (Segment Editor effect buttons). It expands like the following to allow the selection of others and then the expand disappears when the mouse hovers away from it.
Regarding tooltip text size, currently it is the same size as other text in the module. If one is difficult to read the others will be difficult to read. Text size would then need to be magnified across the application. I assume this is already handled with the font size setting.
- If the Segment Editor Effects are in a toolbar the showing or hiding of text would seem to make sense paired to the current “Show text under icons in toolbar buttons” setting.
And of course the more old school method of the segment editor effects directly under the segment table and not movable.
Without being able to modify/change the active segment etc, I can’t see the Segment Editor toolbar being used on its own, at least not very effectively. To me, it feels like it just belongs inside the Editor.
I like that.
I liked what @pieper said about not being delayed tooltips. Would it be possible to bring a label immediately when I hover over (as oppose to waiting a little while before the tooltip shows up)?
In the module window, would it be possible to make the label of the active effect (Threshold in your screenshot) a bit more prominent (larger font or bold face or something).
Thanks again doing all this work!
Thank you, this looks promising.
The widget has to be self-contained (as it is included in many modules now) and we need to allow at least two columns (in the screenshot we already ran out of space with a single column). A simple frame with a grid layout containing QToolButtons should work. Number of columns (or maximum number of rows) could be user-configurable.
QToolBar is quite limited (single column only; dockable only if it is child of the main window, etc.) and if it was outside of the module’s GUI then showing/hiding/positioning would require a lot of extra management. So, I don’t think we can use QToolBar. We could easily make the position/orientation of the button grid user-configurable (horizontal/vertical orientation, left/right/top position), but probably this is not necessary.
Yes, it should only be shown when the corresponding qMRMLSegmentEditorWidget widget is visible. As I wrote above, this could become very complicated if the buttons are not in the widget’s layout.
If the effects are arranged vertically inside the Segment Editor layout should they be to the left of all current widgets in the layout? Would be to the left of help/acknowledgement, to the left of the segment table, to the left of effect options and to the left of masking options.
I guess if the effect buttons have to be within qMRMLSegmentEditorWidget, then they could only extend vertically in the region to the left of the (node selection + segment table + effect options + masking). It could not extend to the left of the acknowledgement group box area.
Exactly. Everything has to be inside the segment editor widget.
Here’s an image of the Segment Effects part of qMRMLSegmentEditorWidget with vertical orientation of effect groupbox. Effects fill into a QGridLayout instead of a ctkFlowlayout and fill in the grid in order from top to bottom utilizing 2 columns always. This is so effects at the beginning of the effect ordered list are at the top. Effects at the very end of the list are always near the bottom of the 2 columns. Also a reminder that since more things no longer need a scrollbar to see (masking options), this means the width of the left side bar area is a little bit wider to accommodate the 2 columns. This makes the decision to prioritize not having to scroll over trying to maintain a slightly smaller left side panel width.
If the window is small, you have to scroll down to see more effects, just like you would have to scroll to see more of the effects. I think this behavior is fine considering it is part of qMRMLSegmentEditorWidget object.
This would seem that the QGroupBox that currently has the title “Effects” should be changed to “Tools”. Should we begin referring to these as “Segment Editor Tools” to improve user understanding by using familiar terminology?
Is the effect groupbox resizable by the user (like making it single row, triple row etc)? If people have only the default segment editor tools, would the second row appear empty?
Otherwise this is looking better to me than our current UI.
The layout is filled in from the top to the bottom. So if there are fewer effects, there will be not as many rows instead of not as many columns.
For it to be resizeable and adjust dynamically like you are suggesting, it would need to be a ctkFlowLayout again instead of a QGridLayout.
@muratmaga The thing about resizing the effect groupbox that goes against some of the negatives talked about previous is that effect buttons would move location when this is resized. If effect buttons should be in the same location for familiarity then this dynamic resize/reorder would go against that idea. If you make it more columns or less columns, then you have to relearn where the expected location of the button is at.
Having a strict grid layout would make sure the buttons are always in the same place and you would scroll down if your screen size was too small to fit them all.
This is fine. I was just curious if the width of the groupbox was fixed, but now I understand it works exactly how it is right now, except vertically.
I guess for custom app purposes if you set only say 6 effects to be visible, then not sure if the 3 rows by 2 columns is still valid or if the user would then want 6 rows 1 column. So maybe adjustable as a setting for at least the custom app purposes. Though the custom app developer could probably change the layout to fit their purpose anyway rather than Slicer developers trying to guess what they might want in their custom app.
Regular unmodified Slicer would probably benefit with it always being a 2 column setup.
Thanks to all the efforts of @jamesobutler, the new Segment Editor layout is now ready - see more information (and provide any feedback and suggestions) in this topic: