To be honest, I have my problems with this.

When queueMode is false, copy dialog has "F2 Queue" button which adds a paused job. This job is automatically run when all other running jobs are finished.
When queueMode is true, copy dialog has "F2 In Parallel" button which starts the job immediately.

If I see this right, the behavior is exactly the same as if you would enable/disable the "queue mode" before creating the job. So there is now not only the "default" queue mode but also a button to overwrite the behavior for each job.
I think this makes it more complicated as it has to be.
Some other points:

• you would also have to include this description e.g. as tooltip. Because, as i said, it is really complicated now.
• "F2 in parallel" doesn't do anything different if no jobs are currently running
• instead of

When queueMode is false, copy dialog has "F2 Queue" button which adds a paused job. This job is automatically run when all other running jobs are finished.

this is less ambiguous:

When queueMode is false, copy dialog has "F2 Queue" button which starts a job immediately if no jobs are running. Otherwise the job is queued for later execution when all other running jobs are finished

• and

So technically I've also removed the possibility to add a paused job that has to be unpaused manually

not only that. It is impossible to create a paused job now if no other jobs are currently running. I think this was the main point of the old queue manager.

and see below

If I see this right, the behavior is exactly the same as if you would enable/disable the "queue mode" before creating the job.

Yes, this is exactly what I intended. And I agree I'd have to add a tooltip. But I don't think it is complicated. It simply allows user to selectively choose to run new job in the other mode. I'll explain the intention later.

"F2 in parallel" doesn't do anything different if no jobs are currently running

That's true. Maybe it should be renamed to "F2 Run Immediately"?

this is less ambiguous

Yes, this is better, thanks!

It is impossible to create a paused job now if no other jobs are currently running. I think this was the main point of the old queue manager.

Yes, you are right about the impossibility to create the paused job. And maybe it can have some use-cases so I should add the checkbox back?

But I politely disagree about the point of the old queue manager. I can miss something and be wrong of course. Anyway I cannot find a way to add a paused job to the old queue manager - F2 always adds and runs new job if there is not an already running one.

I also believe that now the past behaviour of F5 + (enter or F2) button is on par with the new JobMan (queueMode=false) combined with this diff. The same behaviour has Double Commander and Total Commander. This is why I think it is not over-complicated but rather expected functionality. And since Krusader now have a bonus queueMode feature, there is a possibility to do the opposite with "F2 Run Immediately".

As I said, if You still feel, the diff is more hurting than beneficial, lets dump it and keep the code simpler:).

bool isQueueMode = _queueMode != reverseQueueMode;

Thanks a lot, how stupid of me!

_manuallyPaused = _job && _job->isSuspended();

Nice, I'll commit this. :)

"F2 in parallel" doesn't do anything different if no jobs are currently running

That's true. Maybe it should be renamed to "F2 Run Immediately"?

Yes, that's good. But now I realize it's the same for "F2 Queue":
"F2 Queue" doesn't do anything different if no jobs are currently running. That's another reason why it could potentially be confusing for users.

It is impossible to create a paused job now if no other jobs are currently running. I think this was the main point of the old queue manager.

Yes, you are right about the impossibility to create the paused job. And maybe it can have some use-cases so I should add the checkbox back?

Yes, please. Now that its there, i see a real purpose for the checkbox.
(And can you please rename the "queueBox" to "pauseBox", etc...? Thanks.)

But I politely disagree about the point of the old queue manager. I can miss something and be wrong of course. Anyway I cannot find a way to add a paused job to the old queue manager - F2 always adds and runs new job if there is not an already running one.

The queue manager can be started/paused manually. And if paused, added jobs are simply not run. There was even the timer for specifying at which time to start the queue. So I'm pretty sure this was a common use case.
(The timer is missing now and I'm unsure if there is still anybody out there who would use this. No feedback so far...)

I also believe that now the past behaviour of F5 + (enter or F2) button is on par with the new JobMan (queueMode=false) combined with this diff. The same behaviour has Double Commander and Total Commander. This is why I think it is not over-complicated but rather expected functionality. And since Krusader now have a bonus queueMode feature, there is a possibility to do the opposite with "F2 Run Immediately".

Ok, then. I personally don't see the need. But if there are no regressions and just an additional button (that was there before my rework!), nothing speaks against it.

As I said, if You still feel, the diff is more hurting than beneficial, lets dump it and keep the code simpler:).

No, that's not it. We should always come to an agreement were everybody is satisfied. And the code is fine.

There is one problem I just noticed now for a special use:

1. activate QueueMode
2. create several jobs -> first is started all others are pending
3. deactivate QueueMode

Expected result: first job finishes, all others should stay paused

Actual result: first job finishes, next one is started, and so on... The QueueMode behavior continues.

I have no solution yet, but will propose other changes. Stay tuned...

Actually that was intentional :). You started the jobs in queue mode, that's remembered, so they are performed in queue regardless of changed queueMode option. And it should work vice versa.

But You are right, it could be confusing. Maybe this behaviour should only be applied if you "forced" job to queue by pressing F2 with queueMode turned off.

So my proposal:

• start jobs in queue mode, then turn off queue mode -> not started jobs will stay paused
• start jobs in parallel mode with F2 (forced queue mode) -> these jobs are started sequentially no matter what

If we agree on that, I think I can adjust the code :).

I'm sorry but I really think this is way too complicated now. We have 4 variables which have influence on the job behaviour:

<QueueMode: "on" OR "off"> X <reverse QueueMode: "true" OR "false"> X <startDelayed (aka Paused): "true" OR "false"> X < jobsAreRunning(): "true" OR "false">

That makes 16 - 4 = 12 different cases (because reverse QueueMode cannot be "true" if startDelayed is "true". And this is really not understandable for an average user.

We have to think about another approach here which makes this usable...

Agreed. I'm also not happy about the complexity. Now I realize, that reversing the mode is not such a good idea. So I'd at least remove F2 In Parallel option - this probably won't have much uses. I'd only be happy if F2 Queue was there when queueMode is off (in matter of additional feature to the original JobMan experience).

I'll add a comment to Your new code proposal D3611 momentarily.