I cannot seem to adjust the width of the description field. Name field can be modified but not the description.
I would be good to bring back the old behavior
This is on windows 11 with 5.2.1
Actually I take it back. It is modifiable. But I have to grab from the right side, which wasn’t intuitive. Is there reason why the left one cannot be moved (as I hover over, cursor icon doesn’t change to indicate that width can be changed
In all software that I know of, you can adjust column width in a spreadsheet by drag-and-dropping the right side of the column. We cannot and should not change this.
I can see that there is a certain description column width range when the column sizes may change unexpectedly, but this is just due to that the name column is set to use all the available space and if you make description column narrower then it makes the name column wider.
We could turn off automatic expansion of description column, but then the table columns would not automatically use all available space.
The main issue that I see is that making description column very wide compresses the name column. I don’t know what a good solution for this would be. Resizing a column based on content would be extremely slow on large tables. Adding a button for “fit to contents” would further complicate the GUI.
I am not sure I described it correctly. The highlighted section is not movable. According to your description is the right correct place to resize the name column. The width of the name column can be adjust only by grabbing the handle on its left side (in other words the right hand of the visibility column). It just creates a weird dynamic. Try you will see…
Could you capture a video of your screen?
I never properly managed to use OSB, so apologies for the crappy video. But it shows the awkward adjustment behavior.
The ability to adjust the visibility column is a bug (easy to fix). Otherwise everything works normally. As I described above, the name column is configured to use up all unused space (and if you take space away then it is taken away from the name column). I agree that the end result can be somewhat unexpected (especially when you take away space from the name column), but it is all correct, consistent behavior, and I don’t see how we could change it without impacting appearance (having a blank space if columns don’t use all available space is ugly), performance (automatic fitting of size to content is extremely slow and does not solve all problems), usability (adding one more button to fit name column width to content would make the GUI even more cluttered). Often the issue is sidestepped by making the last column claim the remaining space, but we have the status column in the rightmost position and we also have two wide columns (name and description), so we cannot follow this pattern.
I respectfully disagree. Treating the total length of the name + description field is a fixed width and them adjusting their proportions is an awkward behavior, is completely different than what I am used to seeing before (in Markups) as well as any table oriented program like a spreadsheet. For me, for the behavior to be “normal”, name and description fields needs to be adjusted independently of each other as the user chooses. As a users that’s what I would expect when there is a visual vertical divider separating these columns.
The sizing rule is much simpler: the name columns takes up any unused space. Apparently, it is hard to figure this rule by using the system (even when explained), so probably it should be changed. However, I don’t see any simple solution, because the space is narrow, there are two potentially wide fields, and we always want to make the status column visible on the right.
You can experiment with the various options yourself:
tableWidget = findChild(None,name="activeMarkupTableWidget")
columnIndex = 3 # name column
sizeMode = qt.QHeaderView.Interactive # see options at https://doc.qt.io/qt-5/qheaderview.html#ResizeMode-enum
tableWidget.horizontalHeader().setSectionResizeMode(columnIndex, sizeMode)
Disabling stretching of name column makes sizing behavior easier to understand for users, but makes the status column disappear, as there is no column that would absorb various column width changes.
If the goal is to maximize space for name column, wouldn’t be easier to implement an option to hide the description field like RAS fields? So people who need to have long markup names can hide description and . maximize the width for name column?
You can already hide coordinates column (Coordinates → Hide), but it does not make a difference (space is still constrained).
Please experiment with column sizing options and see if you can find any combination that looks good to you.
For example, try this:
tableWidget = findChild(None,name="activeMarkupTableWidget")
tableWidget.horizontalHeader().setSectionResizeMode(3, qt.QHeaderView.Interactive)
tableWidget.horizontalHeader().setSectionResizeMode(4, qt.QHeaderView.Stretch)
For it to be like excel you would have an infinite number of columns and the width of the table would be infinitely sized. For filled columns to have any size width would mean likely supporting a horizontal scroll bar so not to increase the size of the widget container such as the module panel area.
The name column being given the unused space seems to be tied to the assumption that name will support longer text entries than the description field. The description is not pre-filled like the name field so by default it always has less text at 0 characters, but when description is actually used I think it would easily be longer than a given name. In my group’s work we have an instance of a cell defining Animal ID (like name) and then a button next to it to bring up a widget for all the extra details including a description/comment field which is a plain text field that can have the infinite space. This widget is ultimately closed but tied and saved with the data.
Based on @muratmaga’s usage in the original post, it doesn’t look like he’s using the name field as a real meaningful name. One of the names is “mca” which is actually an abbreviation of a name. My guess is the content in the “description” field is closer to a meaningful name, but it is not put in the “name” field because showing the name in the 3D slice views would clutter the visibility. However it would help if there was a way to abbreviate the name in the viewers or some other method to resolve the issue of meaningful names that are long but are not actually a full description of the name.
I am also not sure what “name” implies in this context. I always interpreted that field to be a “label”, as its contents is what’s shown in viewers. A label can be a fully qualified name, or an abbreviation, or databaseID. So perhaps name is not really the right term to use. Regardless, description is usually a lot more verbose than what name field can convey. Here is a typical craniometric landmak names and their description, as an example.
I may not want to use a label like Opistocranion because of its length and possibility of occluding things around it in 3D. Also a landmark/point may not have a name, but simply an anatomical description (e.g., the anteriormost point on the nasal bone in the dorsal view). So it is very common practice to have a few letter (3-5) abbreviations, if not simply using numbers…
going back to the original post:
This is what I see when I load my landmark template.
This is what happens when I choose to hide coordinates
As a user my expectation at this point is to use the divider at the right hand side of the Name column to adjust the spacing, which i don’t think anyone can argue that is a unreasonable expectation. And I can’t do it. Because it is not grabbable (if that’s a word).
I can eventually get it to look like what I expect by dragging the right hand divider of Description field to the right. That’s a completely weird and unexpected behavior that I never saw in any program before. This is what I am trying to get fixed.
I understand the concerns about the space, and I don’t want to make an already very busy with more scrollbars etc. So here are my suggestions:
- Leave everything as is, but implement the Name/Description divider to be adjustable. (this what I would prefer)
- I am not sure what the original justification was to maximize viewable space of Name field at the expense of Descrption. if the assumption is that description is not often use, whereas Name is always used, then I would suggest implementing on option to hide it (right click on the column name and choose hide) to maximize. That behavior can be applied to R/A/S fields as well (as opposed to hiding it from coordinates dropdown).
I would not like to defend our even discuss the current behavior, because a simple operation such as resizing a column must be obvious and should not raise any questions.
Let’s move on and try to find a behavior that is obvious for everyone.
@muratmaga Have you tried the code snippet that I provided above? It configures the behavior that you expect but have other issues (unused space looks ugly and status column may be not be visible without scrolling). Maybe you can tune the behavior that it makes sense for you but does not have these other problems.
Sorry, i didn’t see your response. I am away now, but i will try later tonight.
If the length results in it occluding the 3D view, I was suggesting that maybe this is the problem that can be addressed for this workflow. A good name should be used.
If there are times that there is no such name and only a description, then leaving name completely empty and hiding the name column would seem valid. It would be a list of descriptions where each description has no name, otherwise there would be a general accepted name for its meaning recognized around the world.
In a new Slicer session, this is what I get without the snippet (I hid R/A/S)
With the snippet, I can now slide the Description column towards name to benefit from extra space. This is the behavior I want to see implemented.
Re-enabling the R/A/S fields slightly alter the space arrangement, but can easily be modified by rearranging the column width. I did not notice any strange or invisible columns.
However, I did notice that the divider between Description and R columns exhibit the same symptom (not grabbable). So I still would have expected that it should be movable.
On a different note, the information that pops up when the user hovers over the table is somewhat useless (or rather very limited use to an early user ). It’s exactly the same information for every row. instead, for overflowing text like these (indicated by …) it might be more meaningful to display the full text of the description field (if the user’s mouse is on description column) or the name (if they are on the name column).
Finally, if you are going to implement hide/unhide columns (in general not just for R/A/S), the right click context menu of the table would be more natural place than the coordinates dropbox.
Let’s go back and keep experimenting with the column sizing options using the code snippet.
If you don’t want to make the description column take up all the unused space (but manually=interactively adjust its size), you can do this:
tableWidget = findChild(None,name="activeMarkupTableWidget")
tableWidget.horizontalHeader().setSectionResizeMode(3, qt.QHeaderView.Interactive)
tableWidget.horizontalHeader().setSectionResizeMode(4, qt.QHeaderView.Interactive)
This makes the column sizing behavior simpler, but also much worse, as the status column immediately becomes visible (you need to scroll to make it visible) when you make either name or description column wider. When description column is set to be Stretch (take up unused space) then you only lost the status column when you made the name column very wide.
Overall, I think disabling manual sizing of the description column is a very small price to pay and if it is the last variable-size column then it does not surprise users. If we make R, A, S columns interactively resizable then users again may be surprised to see the description column losing width when R, A, S columns are widened.
Please check these sizing modes to see if it fulfills all your needs and feels intuitive. You can try if setting R, A, S columns to Fixed improves things (but then of course we may need to accept truncation of coordinate values).
tableWidget = findChild(None,name="activeMarkupTableWidget")
tableWidget.horizontalHeader().setSectionResizeMode(0, qt.QHeaderView.Fixed) # selected
tableWidget.horizontalHeader().setSectionResizeMode(1, qt.QHeaderView.Fixed) # locked
tableWidget.horizontalHeader().setSectionResizeMode(2, qt.QHeaderView.Fixed) # visible
tableWidget.horizontalHeader().setSectionResizeMode(3, qt.QHeaderView.Interactive) # name
tableWidget.horizontalHeader().setSectionResizeMode(4, qt.QHeaderView.Stretch) # description
tableWidget.horizontalHeader().setSectionResizeMode(5, qt.QHeaderView.Interactive) # R
tableWidget.horizontalHeader().setSectionResizeMode(6, qt.QHeaderView.Interactive) # A
tableWidget.horizontalHeader().setSectionResizeMode(7, qt.QHeaderView.Interactive) # S
tableWidget.horizontalHeader().setSectionResizeMode(8, qt.QHeaderView.Fixed) # status
Moving the status column before the variable-sized columns (right before name column?) might help, too, as it is not a big issue if description or coordinate value columns gets hidden (require scrolling to become fully visible). Unfortunately, there is no way to change the column order using Python scripting, so you cannot try it easily.
I still like the first snippet behavior above. These options here either change the overall width of the table (I end up with blank space on right hand side of status columns, or columns go beyond displayed are), or create very awkward behaviors (like multiple column widths changing at simultaeously to adjust proportions).
I think word table behavior is what I am expecting for name/description columns. Everything else can be fixed width as far as I am concerned. So it will be this:
tableWidget = findChild(None,name="activeMarkupTableWidget")
tableWidget.horizontalHeader().setSectionResizeMode(0, qt.QHeaderView.Fixed) # selected
tableWidget.horizontalHeader().setSectionResizeMode(1, qt.QHeaderView.Fixed) # locked
tableWidget.horizontalHeader().setSectionResizeMode(2, qt.QHeaderView.Fixed) # visible
tableWidget.horizontalHeader().setSectionResizeMode(3, qt.QHeaderView.Interactive) # name
tableWidget.horizontalHeader().setSectionResizeMode(4, qt.QHeaderView.Stretch) # description
tableWidget.horizontalHeader().setSectionResizeMode(5, qt.QHeaderView.Fixed) # R
tableWidget.horizontalHeader().setSectionResizeMode(6, qt.QHeaderView.Fixed) # A
tableWidget.horizontalHeader().setSectionResizeMode(7, qt.QHeaderView.Fixed) # S
tableWidget.horizontalHeader().setSectionResizeMode(8, qt.QHeaderView.Fixed) # status
What I don’t understand and don’t like that QT allows being able to accidentally push things beyond visible area, even with this settings. Can that be fixed? I.e the rightmost column never moves out of sight and the whole width of the table is fixed (to the size of the module panel)
There are conflicting requirements (we want to allow users to resize columns, some columns to take up space, but also make sure columns can show some information without truncation, etc.). Qt has tons of sizing policies at many levels to resolve these conflicts, but in the end it is not possible to make every automatic conflict resolution work that fulfills everybody’s needs.
We can always implement custom mechanisms (e.g., inject additional constraints or make automatic adjustments when a user finished some manual adjustment) but these take a lot of time to develop and maintain and usually leads to bugs in some environments and unusual, unexpected behavior.
Maybe you are not concerned about the coordinates display right now, but you may need to be able to see accurate coordinate values (5-6 digits) when you work on something else in the future and then you would be bothered by the fixed RAS column widths.
Maybe moving the position status column to the left side and freeze the first few columns (selected, locked, visible, position status) would help?
We need to make the control point list widget reusable (now it is hardwired into the Markups module widget) for many reasons. If we do that then the widget could be shown in the view layout (similarly to the table view) with much more space. That could also help with reducing the irresolvable size constraints.