When selecting a certain line in the scheduler tab or in the capture tab, the GUI is synched with the selected row and displays the values of the selected job.
Additionally, a typo in the scheduler state has been corrected.
Details
Details
- Create a capture plan with multiple entries and select them with a mouse click or using the arrow keys. Check, that the correct values are displayed.
- Do the same for the scheduler.
Diff Detail
Diff Detail
- Repository
- R321 KStars
- Branch
- row_selection
- Lint
No Linters Available - Unit
No Unit Test Coverage - Build Status
Buildable 11417 Build 11435: arc lint + arc unit
Comment Actions
Capture module.
Functionality tested OK.
This is a change of UI behavior: now clicking once on a job does sync the left fields with the properties of the selected job, as mentioned in the changeset.
However, it makes the end-user think the job can be modified in-place, while there is actually no effect. Counter-however, the change makes adding a new instance of an existing job easier.
I will say the change makes the UI slightly better in terms of usability, but the ergonomy is still flawed.
I observe that arrow buttons are always enabled even if the selected row is first or last while scheduler has this proper (but not always), but this is completely minor. The code doing that should probably be refactored somewhere.
Scheduler module.
OK for the typo fix, obviously.
Got an assertion abort related to null lead time, that is fixed by D19393.
Functionality is OK, it's cool to press the mouse button and move through jobs with their properties immediately displayed.
However, it's possible to change the order of the schedule while the Scheduler is running.
As a result, the schedule is reevaluated immediately, and if the job that is running is moved, states are reset and Scheduler is lost.
As an example, the job that was slewing becomes idle and the Scheduler remains stuck in that situation.
I'll double-check what the current unpatched situation is.
Comment Actions
Good point, I will check enabling/disabling for capture and scheduler. At least I did not change anything intentionally, so I would expect it has been before. But nevertheless, let's clean it up here.
Comment Actions
Now the activation of buttons should prevent moving list entries when the scheduler is running. But in both the scheduler and in the capture module, enabling/disabling buttons is distributed. Should be cleaned up somewhen...
Comment Actions
Rebased on the current head. From my perspective, it is mature enough to be merged into master.
Comment Actions
Ouch, that's embarrassing to admit, but I simply forgot to test this case :(
I'm afraid, scheduler and capture take the values at least partially directly from the UI and not from the model.
Nevertheless, updating only in the idle case might be safe, but for the users it's confusing. Wouldn't it be better if we prevent to change the selection and make the UI fields readonly during execution?
Comment Actions
Now rows might only be selected when capture or scheduler are idle.
What I currently do not like: when the table is disabled, its colors are greyed out and not that good readable. Where may I change the widget layout?
Comment Actions
you can use setStyleSheet(...). There are some documentation online on using Qt Stylesheet for all various types of widgets in various states active/disabled..etc.
Comment Actions
Currently I am reluctant interfering directly since I am not really familiar with style sheets. I understand that it follows the CSS syntax, but I do not want to override a single place with fixed values.
But coming back to the problem changing the row when scheduler or capture are running. I think changing the row and updating the UI does not make it worse as it is currently, since all fields both in scheduler and capture are editable any way! I think this is not a good idea, but it should be issue to a separate diff.
My conclusion: let's take this diff without disabling the queue tables when running.
Comment Actions
I disagree with disabling the queue table. I think checking whether the scheduler is running when enabling or disabling the button that allows sorting, and duplicating the check in the function that does the actual sorting, is a better option.
Comment Actions
Active job selected, enabling/disabling queue tables removed.
@TallFurryMan: This is a misunderstanding, I did not touch enabling/disabling of the table buttons. This already works correctly and remains as it is.
Comment Actions
OK, but I checked for the reordering problem:
- It's possible to sort jobs while the Scheduler is running using the "Reset state and sort observations" button. That is not a regression, that is an existing bug.
- It's possible to reorder and reset jobs while the Scheduler is running using the "Reset state and force reevaluation" button. That is a regression in this differential.
Other than that, I'm fully OK with this change.
As a side note, I hope to come up with a new independent gadget that will refactor all these manipulations, and can be used for both Scheduler and Capture.
Comment Actions
As mentioned above, right, this is an existing problem, but this diff neither addresses it nor makes it worse. Should be fixed separately.
Comment Actions
OK, but I checked for the reordering problem:
- It's possible to sort jobs while the Scheduler is running using the "Reset state and sort observations" button. That is not a regression, that is an existing bug.
- It's possible to reorder and reset jobs while the Scheduler is running using the "Reset state and force reevaluation" button. That is a regression in this differential.
Eric, I cannot reproduce it. When I start the scheduler, all buttons on the top left side of the queue are deactivated.
Comment Actions
No more problem with reordering of jobs when the scheduler is running. The behavior is now coherent with the Capture module.
However, the end-user now has the same feedback when clicking (job characteristics are displayed) and double-clicking (job characteristics are edited).
But that's a better behavior I think (and it matches with the draft UI I'm preparing).