Ready for land.
See commits.
Details
Details
- Reviewers
martinkostolny - Group Reviewers
Krusader - Commits
- R167:cc9333193c1e: Merge branch 'my-job_start_state'
Diff Detail
Diff Detail
- Repository
- R167 Krusader
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Comment Actions
I like it, thanks! The start mode enum makes the code more understandable.
Problem: Jobs created with "F2 Queue" are not started in queue (if queue mode is off)
I may be wrong but I believe this can be resolved by storing the startMode in the KrJob itself and then rely on it in JobMan::slotTerminated(KrJob *krJob) method.
Comment Actions
This look nice, almost perfect :)).
Please see my comment inside JobMan::slotTerminated method.
I can see we probably still misunderstand each other a little, so I try to write down several use-cases I believe we are trying to achieve:
- I want only one job at a time -> turn on queue mode ...OK
- I want to pile up one or more jobs but start them later -> turn on queue mode and keep pressing F2 ...OK
- I want everything in parallel -> queue mode off ...OK
- I want everything in parallel, but for some chosen jobs I want to start them paused and run them manually later ,,,OK (personally I think this will hardly be used)
- I want everything in parallel, but for some chosen jobs I want to start performing them one by one (e.g. copying to remote server)
- this could be achieved by:
- a) always starting queued job when last running job finished, regardless of queueMode (see my code comment above)
- b) or better keeping 2 "_jobs" collections instead of one, where the second one (e.g. "_queuedJobs") would contain only tasks to run one by one (to virtually mimic previous QueueManager) -> this would of course complicate the code a bit
- this could be achieved by:
Admittedly the fifth use-case is what I was used to before. But if I'm the only one, I definitely don't want to stand in your way and I'm open to new ways of managing such use cases! :)
| krusader/JobMan/jobman.cpp | ||
|---|---|---|
| 327–328 | If you remove _queueMode from the conditional, I'll be totally happy with this whole patch! | |
Comment Actions
- Dialogs: merged "delay" checkbox with "reverser queue" button in copy/move dialogs
- JobMan: improved coding style and documentation
- JobMan: run next job not started yet even if queue mode is off
Comment Actions
Ok, coming back to this. I needed some time to re-think it.
You're right, with the current F2 options this is the best way now and there is no direct misbehaviour.
It makes not much sense if only we two discuss this. And until a release with the new job manager is published we probably won't get more opinions.
It could also endlessly be extended: with two lists (like you said) or even more user created queues + a dialog for creating/saving/renaming queues + categories (running/paused/finished/...) for each queue; end so on...
With this last change I consider this "good enough" for now and we can wait until somebody complains:)
Comment Actions
This is perfect, thanks!
It makes not much sense if only we two discuss this.
I was thinking the same thing. :)
It could also endlessly be extended (...)
With this last change I consider this "good enough" for now and we can wait until somebody complains:)
Agreed, lets see what the "world" says.