This is a tiny change which would ensure that duplicated tab is never immediately locked. I believe this was not the intention to duplicate this kind of setting. I could be wrong of course :).
Details
- Reviewers
palant - Group Reviewers
Krusader - Commits
- R167:70bbac90cd0e: Duplicated tab should not be locked
Tested that duplicated locked or not-locked tab is never locked after duplication.
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.
Frankly, we explicitly tested that "locked" setting was being duplicated when this was implemented. I have no idea however what users' expectation here might be. I managed to understand what this feature does but not what it is good for. What are people using "Lock Tab" for?
For example me and a few friends of mine use it to keep some tabs in their locked path. When you select such locked tab and start browsing in it, you expect the tab to be duplicated and preserve the original selected tab. This is of course similar to selecting a tab, duplicating it and then browse. But with locked tab you can be sure you don't loose the tabs location. Of course it would be nice to have a visual difference between these two tab states (total commander appends * to such tab name) and a confirmation dialog whether I really want to close a locked tab. But I believe current state is good enough.
As for the explicit testing of locked settings, I didn't noticed this in-my-eyes-misbehaviour before, sorry for that. I only noticed that duplicated locked tab was actually duplicated twice, which you've fixed.
That said, I cannot think of any use-case when user wants 2 exact same locked tabs.
Fine with me, it sounds like duplicating locked state is indeed undesired with that use case.