Auto resize the columns on qview's Advanced Tracking Tool
Moderate - The columns in the Qview table are set to autoresize on default. If the user wishes to resize the column they must click the column header of the desired column to make it interactable. They can then resize it from there.
The columns are toggle-able, click it to make it resizable or click again to make it autoresize based on content.
It would be nice to have the Advanced Tracking Tool columns auto resize according to the length of the longest value in that column (including the column header).
#4 Updated by Adam Goins 4 months ago
- Status changed from In Progress to Resolved
- Impact updated (diff)
The column width can be resized automatically by setting the section resize mode of the horizontal header of the parent table.
The following two lines of code were added to TableMainWindow to set the sectionResizeMode of the table upon creation.
The setStretchLastSection(true) will stretch the last column to fit the remaining length of it's viewport so there's no unnecessary empty space to the right of the last column.
This can be removed if that empty space is desired to remain.
#5 Updated by Tammy Becker 4 months ago
- Status changed from Resolved to Feedback
The behavior of the column size automatically adjusting to the width of the reported sample, line, pixel dn, lat, lon is a nice improvement. But, the inability to manually expand or decrease the width of the columns is concerning. A good behavior is to have this automatic adjustment, but then allow the user to modify the width of the columns and qview retain the manual widths throughout the qview session and after exiting qview and restarting...is this possible?
The last column adjusting with the width of the size of the main Advance Tracking Tool viewport (the main window needs to be expanded by default) is somewhat a funky behavior. The Track mosaic serial number is not consistently left-justified, with a number of beginning characters not displayed, but this exists in the public release version also, so might be a separate ticket.
An example image with a tracking band is /work/projects/cassini/CDAP-Enceladus/Enceladus_Delivery/BaseMap/Enceladus_NPole30N_100m_HPF_wTrk.cub
It would be good if the original reporter checked out this fix; as well as a few other users to determine if this is the desired behavior (Makayla, Lynn, Ken E., for example)
A few more users to weigh on this modification the better.
#6 Updated by Lynn Weller 4 months ago
I agree with Tammy that the auto-resize on the column is a nice feature to have, but not being able to resize the columns after the fact is a problem. Not being able to do so completely eliminates any customization on the users part, and quite frankly, if I have a lot of columns open and many displaying values that go out to the 14th decimal place, I'm going to want to be able to make those fields smaller otherwise I will have table that extends across multiple screens.
A good behavior is to have this automatic adjustment, but then allow the user to modify the width of the columns and qview retain the manual widths throughout the qview session and after exiting qview and restarting...is this possible?
This is a good idea and I would to see something like this implemented.
#7 Updated by Adam Goins 4 months ago
I have a rough solution generated and in the work area under /work/projects/isis/latest/m05142_v2 that affords the ability for the user to change the size of the column by clicking on the column the user wishes to resize and then resizing it. (click the column header).
This resizing will be persistent as the other columns update.
This solution isn't the final solution, i'd like to make it so that the user doesn't have to click the column before it allows the user to resize it but the resize ability to removed implicitly from the qtable when we make it autoresize.
Currently I'm having it set all columns to autoresize until a user clicks the column they wish to resize. At that point that column is set to be interactive and allows persistent resizing.
Let me know if a solution like this is probable as I work out how to make it so that the users doesn't have to click a column before resizing.
#8 Updated by Lynn Weller 4 months ago
The v2 is better, but nothing is saved after the fact, so every time I open tracking I have to reset the size the size of the column that I tweaked before. In my case, the last column (which is Notes in my case) will always have to be reset if I care to use it.
Maybe we ought to be talking about about a user config file that saves things and not just focus on this one thing. There are a lot of columns to choose from and if you want to see values for anything beyond the default columns, you have to reselect those every single time. Why can't this information be saved. It seems the overall width of the tracking tool table is recalled from one session to the next if I make a change, but nothing more. So we only remember window size but nothing else?
/home/lweller/.Isis/qview has a number of .config files but it's not clear all aspects of Advanced Tracking.config are being (there is also something named advancedTrackTool.config that is very old that is also in my directory). What do we know about what this was meant to do?
I don't mean to derail things, but there is more to the tracking insufficiencies than just the column size.
#9 Updated by Adam Goins 4 months ago
The advancedtracktool config file is used by the AdvancedTrackingTool to track if the help menu on startup is needed, and the Advanced Tracking.config is used for the table generated inside of the TableMainWindow to keep track of preferences for each item in that table.
I added another setting to that preference file that keeps track of the Columns of the AdvancedTrackingTool
Columns will load by default to autoresize based on content. You can toggle the autoresizability of it by clicking on the header of the column you wish to resize and then resize it (When a column is set to autoresize, QT makes it unresizable implicitly so we have to click on the column we want to resize to make it interactable).
If you resize a column, the column is then set to be interactable and the size can be changed from there.
Clicking a column that's set to autoresize will set it to interactable.
Clicking a column that's set to interactable will set it to autoresize.
You can toggle these options and whatever changes you make will be saved.
Whatever state the column is in gets saved to the Advanced Tracking.config located in $HOME/.Isis/qview.
Changes are persistent such that an interactable column of X width will maintain that width through new instance of qview.
Changes are found in the same location of /work/projects/isis/latest/m05142_v2 and have been built on prog24 for user testing and feedback.
Please let me know if this is what we are going for.
#10 Updated by Lynn Weller 4 months ago
Strange things are happening.
I tried to resize the Notes column (last one), but it doesn't stay. After resizing, I clicked on another column and Notes goes back to its original size.
After this I added a few more columns to view, then I went back to attempting to resize Notes and things flashed and jumped and a number of columns simply disappeared even though they are still highlighted in the list.
Then when I unselected one of the disappeared columns and selected again, it and the other disappeared columns reappeared. I tried to resize any column after this and they were all locked down.
Closed qview, opened images and tried again. This time when I tried to resize Notes, it seemed to work, until I added unseen columns then it undid my changes.
Closed qview, opened images and tracking and none of the new columns I added were there.
#13 Updated by Lynn Weller 4 months ago
- Status changed from Resolved to Feedback
The strange behavior I last experienced is gone, but none of my column selections or resizings are being recalled after I have exited qview and relaunched.
I tried again after deleting ~.Isis/qview and got similar results. This is where things stood back at comment #8 (at least that is the number on my end). Sorry.
Have you asked Makala to test? She is the original poster and should be more involved.
#14 Updated by Adam Goins 4 months ago
Makayla I'm pinging you on this one (Added you as a watcher). The column resizing is persistent through my test runs.
Here's my process:
setisisroot to this location.
ran qview, opened AdvancedTrackTool.
Made a couple columns interactable (by clicking the column header, they are autoresize by default).
Resized a couple columns.
relaunched qview, open advanced track tool -- the resized columns maintained their previous size and the autoresized columns maintain the autoresizability.
Can you run through this and see if the column sizes are persistent for you?
#16 Updated by Adam Goins 2 months ago
- Status changed from Feedback to Resolved
- Impact updated (diff)
It looks like this issue was called because the CloseEvent of TableMainWindow calls writeSettings() but the destructor doesn't, so if you closed the Table window it would write the settings but if you closed qview directly these settings would never be written.
I've adjusted TableMainWindow destructor to call WriteSettings() so that the settings will be saved.
Please let me know if this works!