https://bugs.kde.org/show_bug.cgi?id=447394
Nikita Melnichenko <nikita+...@melnichenko.name> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Status|REPORTED |CONFIRMED
--- Comment #3 from Nikita Melnichenko <nikita+...@melnichenko.name> ---
(In reply to Toni Asensi Esteve from comment #2)
> If someone follows the development of Krusader he/she can see that there's a
> commit "New tabs start in the current folder and can be inserted next to the
> current tab or at the end", with its merge request.
>
> As it's already explained in the aforementioned merge request :
>
> The aforementioned programs (Konsole, Double Commander, Total Commander or
> Dolphin) do that, so people who use those programs are used to the fact that
> when they open a new tab, it starts from the same folder that they were
> using. When trying Krusader, they do not expect that new tabs start from the
> home folder.
>
This assumption is not confirmed by any user study and not considering active
users that got used to the new tab opening in the home dir. For example, for me
it's not the case, please read comment #1.
> If the user is working on a folder, it's more frequent that the next action
> is going to be done in that folder or near it (a subdirectory, upper
> directory, etc.) instead of in the home folder. Anyway, going to the home
> folder is easy with a hotkey (Alt+Home) or using a Krusader button that can
> be enabled.
>
It's not more frequent for me, it's the opposite. I use Duplicate Tab (via
shortcut) when I need a copy. Using two actions as you suggest is far from
convenient and opening a new tab is a frequent operation.
> That change is not a regression since is a design decision, intentional,
> approved and Krusader developers, people who use the git version, and users
> of e.g. the [PPA of Rik
> Mills](https://launchpad.net/~rikmills/+archive/ubuntu/experimental/
> +packages) have been using that for more than a year.
>
I understand it's intentional and I disagree with this intent. :)
In fact, the change was not approved per our dev process. See for yourself:
https://invent.kde.org/utilities/krusader/-/merge_requests/50. One of the devs
other than the author needs to approve. There is no tag change. There is no
GitLab approval. Not even a comment that somebody tested it. You might have
interpreted thumbs up from Yuri as an approval, however it does not count.
Thumbs up means the user likes the proposal. It doesn't mean the change is
reviewed or approved. In any case, with all the respect to Yuri, Yuri's role is
to support the documentation, he's not acting as a developer in this project
per his own choice. In the same time, this was not a simple code change. It had
to be reviewed by the devs - Dave or me. I just want to make it clear regarding
approval status for this and future changes. It's ok to change the dev process
if you don't like it, but we should have a discussion and come to an agreement
first.
As for git version users, yes, some people use this version, however it doesn't
mean they like it. I know a person (not me) who reverted this change as they
don't like it but want to enjoy other fixes. I use a snapshot version with the
change for several months as an experiment whether I'd like it in a long run.
So far, I don't. It often feels like tripping over a stone during a smooth
walk.
Actually, I think we need to ask krusader user group and check who would like
to see it changed in the new release without an option to go back and who'll
miss it.
And there is definitely an inconsistency in the menu as I mentioned in comment
#1:
> Besides this, popup menu looks wrong now - there are two options "New Tab"
> and "Duplicate Current Tab",
> which do the same thing (shortcut actions have the same issue). Users will
> definitely consider this a bug.
> Moreover, the icon for the "New Tab" in popup is the same as on the New Tab
> button in the tab toolbar,
> which gives the idea that it should open a fresh tab.
And regarding the status.
> Now that we are at it: removing the "CONFIRMED" status since the same one
> that opens a report can not be the one that confirms it, as we already know
> (otherwise, all would be "CONFIRMED" bugs).
There are two ways to have a bug confirmed:
1. Multiple users report the same issue - then it's auto-confirmed.
2. A dev checks the bug and may confirm it.
This is the second case.
--
You are receiving this mail because:
You are watching all bug changes.
