The status change time is rarely useful for users and would mostly be confused with the regular modify time, thus it missing on purpose.

(In reply to Méven Car from comment #1)
> The status change time is rarely useful for users and would mostly be
> confused with the regular modify time, thus it missing on purpose.

A possibility to add it only as an option, so a manual option, for users who want to enable it for list view column and properties.

A confusion is excluded because the name "Changed" compared to "Modified" is completely different it shows that it is about a different timestamp.

From a user perspective, "changed" and "modified" are the same thing. Heck I'm an intermittent Dolphin developer myself and I don't even know what the differences are between these two. Can you tell me what the difference is?

(In reply to Nate Graham from comment #3)
> From a user perspective, "changed" and "modified" are the same thing. Heck
> I'm an intermittent Dolphin developer myself and I don't even know what the
> differences are between these two. Can you tell me what the difference is?

Change time (ctime) does not refer to changes made to the contents of a file or folder. Rather, it is the time when the metadata about the file or folder was changed. For example, changes to the permission updates change time (ctime) or simply rename the name of the file or folder.

Do you have any ideas for how we could present this to the user in a comprehensible way?

(In reply to Nate Graham from comment #5)
> Do you have any ideas for how we could present this to the user in a
> comprehensible way?

I think from UX point of view should be added directly in Properties a small arrow. When clicking on the arrow a floating window appears, in this floating window is a small wiki integrated, what the 4 timestamps mean exactly and some examples are also given, how it happens. This is then self-explanatory for the users or new users (newbie) who use KDE Plasma for the first time.

As a new name I would suggest not to use "Changed" but "Last permissions change".

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.

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

A stat command in the terminal for every file and folder is time consuming and not practical.

I use KDE Plasma because it has a different philosophy than the other desktop environments. It's configurable in many ways, scores with detail elements and still remains elegant in design.

An example with the detail elements is "Katie" the female mascot for KDE. :)
That was also the idea why I opened the report for Dolphin because of detail element. 

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

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

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

One command can fetch this for multiple files at once, for instance `/bin/ls -l -c`.

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

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

There might be a reason others have not implemented it....

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

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

> > Additionally Dolphin would be the first Linux file manager (GUI) that
> > supports all timestamps like the stat command.
> 
> 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 and maybe if add it by default there are those who like it.

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

(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 ;)

Let's step back from the argument at hand before we all get too entrenched in our points of view. :)

If this was implemented but made off-by-default--as it is for a lot of other properties you can turn on if you want--I don't think it would be a big deal. 99% of people would never have to see it at all.