[dolphin] [Bug 431666] Provide list view column and properties for change time (ctime)

Méven Car bugzilla_noreply at kde.org
Mon Jan 18 10:22:33 GMT 2021


https://bugs.kde.org/show_bug.cgi?id=431666

--- Comment #11 from Méven Car <meven29 at gmail.com> ---
(In reply to Jenny from comment #10)
> (In reply to Méven Car from comment #9)
> > (In reply to Jenny from comment #8)
> > > (In reply to Elvis Angelaccio from comment #7)
> > > > If you know what the ctime is you problably also know how to read it from a
> > > > terminal. IMHO exposing it in the dolphin UI would result in added
> > > > complexity for 99% of regular users without actual benefits.
> > > 
> > > I understand your reasoning, but whether there are benefits for the user or
> > > not is only secondary and individual.
> > 
> > Well in fact no, everything features and details must be based on real user
> > use case and needs. 
> > 
> 
> It is very unlikely that the KDE developers know which features are really
> wanted by the users or not. How would you know exactly, you would have to
> have a tracking function built into every element of every KDE application
> in KDE Plasma and the users would not know about it and would be spied on
> which feature they activate the most with the mouse or keyboard. So there is
> no privacy in KDE. There is a good reason why there is such report page like
> this.
> 
> Joking aside, I just want to show that it is always individual. I have
> already said that I like the philosophy of KDE and KDE Plasma is generally
> known for being versatile configurable etc.
> 

"Simple by default, powerful when needed" sure but that does not mean we will
any feature requested.
There is nice argument by Greg Kroah-Hartman(one of the main Linux kernel
maintainer) that explains this :
https://youtu.be/CUifDVMHUXw?t=120

> It is very unlikely that the KDE developers know which features are really
> wanted by the users or not.

Sure, we use the best of of own abilities, starting with our own common senses
(three devs who are also users did not see value in this feature here)
and then information available : rare are filemanagers that supports this and
rare are the requests to implement it, rare are the users that know about it
and this feature is not even possible on proprietary OS (which are references
for users).

You can contrast this with the creation date feature that was requested long
before it was even possible on Linux:
https://bugs.kde.org/show_bug.cgi?id=286689

> > > A stat command in the terminal for every file and folder is time consuming
> > > and not practical.
> > 
> > What is your use case ? How would you use the change time in your workflow ?
> > 
> 
> I have already said when change time (ctime) is updated and these are the
> use cases.
> 
> > One command can fetch this for multiple files at once, for instance `/bin/ls
> > -l -c`.
> > 
> Integrating it directly into Dolphin (GUI) has other reasons you can use
> other functions at the same time.
> 
> > Adding the change status time to the properties dialog might make sense
> > (this is not part of dolphin), and maybe to the information panel since it
> > could be hidden by default easily.
> > 
> > In the views we would need a strong enough argument this is needed for at
> > least more than an individual user.
> > 
> > Any feature big or small adds visual clutter and potentially confusion to
> > users, work to developers, translators and documentation writers, bug
> > triagers...
> > 
> The idea with the floating window and an integrated wiki was just a
> suggestion. I think it is enough to just take another name instead of
> "Changed" just take "Last permissions change".

That's the potential confusion starting right here : "Last permissions change"
is not even accurate.
The ctime is just exposing more technical details to the user since you almost
need to understand filesystems or know about inodes to understand the notion.

> > 
> > There might be a reason others have not implemented it....
> 
> You know I'm talking about Dolphin and not other file managers on Linux, why
> the others don't add it could also be a simple reason because they have
> different philosophy than KDE with their many possibilities to configure. It
> could also be because there are few Linux users in general worldwide or 

> the users don't know about this feature

Well you said it. Most users don't know about it and so can't need it.

> and maybe if add it by default there are those who like it.

We gladly improve people workflow with default configuration, but we need to
see the value for it, we don't add features simply to teach users.

> > > Additionally Dolphin would be the first Linux file manager (GUI) that
> > > supports all timestamps like the stat command.

In fact, krusader supports it, so dolphin wouldn't even be the first KDE-App
filemanager to support it.

It shows the philosophy difference between krusader and dolphin : pure-power
versus power+usability.
Since krusader can help with your workflow, I encourage you to try it.

I wish I don't hurt your feelings or the expectation you have on the community.
I hope you can see our arguments are reasonable.
We of course would reconsider should the majority of people's opinions
expressed change.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


More information about the kfm-devel mailing list