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

[Jenny]

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

--- Comment #12 from Jenny <Jennyba1 at protonmail.com> ---
(In reply to Méven Car from comment #11)
> (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
> 

The arguments from the main Linux kernel maintainer are normal. 

The report here is about practical experience and you will see why your tip
with Krusader always remains individual.

> > 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

I have read the report and it just shows that it is always individual. Creation
date is displayed for example by Dolphin, but not by alleged pure-power tool,
like Krusader.

> > > > 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.

Maybe you have another idea for a name?

If not I suggest a new name "Last metadata change" it is more accurate and
should be sufficient.


> > > 
> > > 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.

You can't know that, many things become more popular through recommendations
from friends or through review videos etc., but it still remains individual.
For me it doesn't matter if it's popular or exactly like other dozens of
options in KDE Plasma that are probably not more popular than change time
(ctime).

> > 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.


Why doesn't Krusader show the creation date as the default configuration?

But normal users have rather created a report for Dolphin, because of creation
date than for Krusader.

Later it was added only in Dolphin. It was made only because users created a
report because of missing this feature. Exactly what I do for change time.
> > > > 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.

It's nice that you want to help me, but the Krusader is not a pure power tool.
It's just a tool like any other, it remains individual, nothing more, nothing
less.

I tested it with the current realease version (2.7.2) and the latest master
version. It does not provide all the timestamps for the list view column and
Properties. It is missing the creation date (Created).

In Dolphin, the Created date is displayed by default under Properties and as an
option users can add it manually for the list view column. I don't like the GUI
of Krusader and this twin panel view. In Dolphin it is much more elegantly
solved and you can do something like this twin panel view with split view for
example. Dolphin has a sidebar where I can quickly access my external hard
drive and has many other things, like an icon for the "Desktop" folder and the
operation is much more elegant for me. This is a pure-power-usability tool ;)

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