Markdown processing in Dolphin from inode properties?

[rokejulianlockhart]

Summarily, I think that #Dolphin should support markdown processing in directory and file Comments and Names because I believe that it would allow some genuinely incredible innovation in file system management.

This is because novice users can use the basic text accentuation that they’re used to (*, **, and >, which Markdown was designed to improve) and have them automatically parsed by Markdown, Markdown support nowadays includes almost full pure HTML support.

Using the Comment property

which is currently sorely underused, would become genuinely viable, since I’d be able to store full notes in it – it’d be just pure text underneath, after all. Plonk the Kate KPart in there, or have inode comments open in the user’s default text editor, and now they’re a popular part of file management.

However, despite the existence of that filesystem-specific property, filenames in Linux are multiline. Nothing fundamental prevents this.

Features

Precedence

It allow non-technical users to want to highlight a file to not have to put ! or A before it (it would instead allow them to bold the filename)

Some more impressive features that are specifically relevant to file storage that I can see it add, however, would be:

#Tags for tag organization

If you’re a bit of an organizational perfectionist like myself, you will know that purely hierarchical organization doesn’t work at scale - search somewhat rectifies this, but it isn’t foolproof, especially for binary files like images.

This brings me onto my next part of this point - although tags are supported by most formats that really need them, it’s always as custom metadata. Just being in parseable XML doesn’t help someone comprehensively programmatically poll for consistent metadata.

This would! tagging would become cross-FS, and as simple as #tag. No need for advanced, finnicky solutions like

Organize your files and folders with tags | TagSpaces

which leave .json files around the filesystem, and don’t really automatically update when file operations are performed due to its client not being installable per se (so no index daemon).

Clickable links

No more need for .desktop (or, in my case, since I want cross-platform support, .html) link files on Linux - simply

[obfuscating text](link)

becomes enough, in filename itself!

shows how this can be used. I’ve currently a crude .TSV table in my FS, created using tabs between the first and last names of some people (don’t worry – these names aren’t confidential, I promise, nor are the URIs accessible in any manner). However, each entry into the table isn’t clickable currently. Managing this would be a million times easier if they were.

This wouldn’t impair usability, since the user can just go to the right of the filename to invoke the file.

---

I know, it’d be a fair bit of work. But I think that it’d put #Dolpin so many lightyears ahead in terms of usability for the average and advanced person that I really, really think that it’s worth considering.

It’s the whole reason I wanna learn Qt. If nobody else does, I’m gonna fork #Dolphin myself. XD

Thanks for reading this. I hope one day this becomes possible.

[anon69930177]

Let’s see if I understood you correctly. You want to write the extended file attributes of the file systems with some yet to be determined Markdown and this should be executed by KDE programs like Dolphin? Interesting. Let’s start with something very mundane. How do you envision protecting the extended attributes from being overwritten, where currently the attributes that e.g. Gwenview writes are deleted by gThumb, in such a way that neither program tells the user what is going on. I am curious about the solution.

[rokejulianlockhart]

@anon69930177

How do you envision protecting the extended attributes from being overwritten, where currently the attributes that e.g. Gwenview writes are deleted by gThumb, in such a way that neither program tells the user what is going on. I am curious about the solution.

Which attributes are you referring to? I’ve never had Comments overwritten. That seems like a separate isue, though.

@anon69930177

You want to write the extended file attributes of the file systems with some yet to be determined Markdown and this should be executed by KDE programs like Dolphin?

I don’t know what this means. I just want #Dolphin to be able to parse basic Markdown in file and directory name and (BTRFS) comment properties to reduce some bad practices.

Thanks for the interest.

[anon69930177]

Ok, @rokejulianlockhart, then apparently I didn’t understand you. Sometimes a picture montage of the result is helpful for clarification, kind of like the storyboard in film, especially if it’s a new idea. But you don’t have to convince me, I am only the walk-on here, who provides the one or other cue, you have to convince those who have to translate your thoughts into source code.

[felixernst]

Currently file comments are displayed as a simple text field e.g. in Gwenview which allows both modifying and viewing the comment. If we were to support a markdown view of this, we would have to separate the viewing presentation from the editing presentation.
Displaying the comment as markdown makes some sense in Dolphin’s information panel for example. There editing already opens a separate window.

So working on markdown support for file comments is a somewhat worthy goal IMO.

For file names it is a different story though IMO. You are saying that having e.g. clickable links as a file name “wouldn’t impair usability, since the user can just go to the right of the filename to invoke the file.” I don’t think this is true. For one, Dolphin still allows users to disable the full row clickable area in Dolphin’s details view mode settings. When enabled, they can’t click on the side of it to invoke the file.

Another basic functionality one would lose is inline renaming when using double-click mode. I am talking about the workflow (when using double-click to open) of clicking on the name of a file to start inline renaming. If we would parse the file name as markdown, clicking the name there would instead follow the link.

We also would introduce the inconsistency that for most files clicking the file name opens the file, while file names that contain markdown might instead open a link. But even if Dolphin had perfect support for this, other programs would have to follow suite and even then there are a number of other usability problems.

If you, for example, have a file “**boldFileName**” which would then be displayed as “boldFileName” by Dolphin, many users might not be able to correctly type the name of that file in the terminal because they wouldn’t know that the “**” make things bold. Similar aspects apply for link text, etc. as long as the user doesn’t know how to decode markdown in their minds.

Actually, some file systems themselves do not allow * to be used in file names: Filename - Wikipedia So we are already out of luck on some file systems no matter what we would want to support within KDE. We could never have complete markdown support.

All in all, file names really should only be used as identifiers of data.

About the tag functionality you might be interested to know that there is already a cross-desktop way to tag files. user.xdg.tags in the extended attributes is typically used for this AFAIK. This isn’t Dolphin-specific or anything and there is technically nothing stopping anyone from supporting this everywhere.

leave .json files around the filesystem, and don’t really automatically update when file operations are performed due to its client not being installable per se (so no index daemon).

There is no technical reason for this. However, even basic command line utilities still sometimes require extra input to preserve those extended attributes. The basic cp command needs an added -preserve argument for example. (cp(1) - Linux manual page)

KDE software is generally supposed to manage all of this correctly by default. You shouldn’t have to worry about preserving them while using KDE software. I haven’t done much testing on this myself however.

It’s the whole reason I wanna learn Qt.

I hope my above comment doesn’t discourage you from learning Qt and more programming anyway. ^^ The features you want could certainly be improved with work by you or other potential contributors.

If nobody else does, I’m gonna fork #Dolphin myself. XD

We are very collaborative and welcoming to contributors, so no hostile forking please.

[anon69930177]

@felixernst

Currently file comments are displayed as a simple text field e.g. in Gwenview which allows both modifying and viewing the comment. If we were to support a markdown view of this, we would have to separate the viewing presentation from the editing presentation.
Displaying the comment as markdown makes some sense in Dolphin’s information panel for example. There editing already opens a separate window. […]

We shouldn’t be afraid to dream big.

The text field in Gwenview and the comment column in Dolphin can be thought of as funnels through which data flows into the same containers, for simplicity’s sake and not to worry parts of the users. Thus, a unified interface for a Markdown editor is a natural choice. This interface is then accessed by the individual programs, as with a lib. So that the users can also accommodate as many sorted and unsorted lists, various link descriptions, colored and also bouncing text there, the entire text is compressed. An independent solution serves as the compressor, e.g. a program yet to be developed, if one does not want to fall back on existing ones, which transparently compresses the data from the user’s point of view and at the same time encrypts it to protect it from foreign eyes. Thus there are also no conflicts with other programs, which do not originate from KDE. This provides users with a kind of pretty diary for KDE.

For the file names, a hash sum offers itself as a solution to the problem. The users then think they are writing file names, but in fact it is hash sums that are used. Hash and “filename” are stored in a database. The advantages are manifold. The mentioned annoying limitations of the respective file systems that nobody knows anyway are omitted. The file names can have the length of an article and with Markdown the necessary text highlighting of the important places receive. In addition, files can be placed or moved by users anywhere because they can be located at any time via their hash in the database.

The possibilities that present themselves are unlimited and more varied than my brief sketch, limited for reasons of time, can conjure up.

[rokejulianlockhart]

@anon69930177

For the file names, a hash sum offers itself as a solution to the problem. The users then think they are writing file names, but in fact it is hash sums that are used.

If the hash sums are generated at creation and then unchanged, sure, but UUIDs would be better for that.

Unfortunately, what you’ve done is just reinvented inode identifiers, but for cross-platform usage – filenames need to be user/program(/non-FS) configurable in order to maintain compatibility with 100% of software, else how is a program to know how to refer to a specific file?

This is already done at the kernel and FS level, though, which is the best possible approach, since identifier management can only be performed by a central authority – the filesystem itself.

@felixernst

file comments are displayed as a simple text field, e.g. in Gwenview, which allows both modifying and viewing the comment. If we were to support a markdown view of this, we would have to separate the viewing presentation from the editing presentation.
Displaying the comment as Markdown makes some sense in Dolphin’s information panel, for example. There, editing already opens a separate window.

@anon69930177, this is the best approach.

However, like you, I ultimately disagree that we should prevent users rendering Markdown from the filename section, and instead warn them with small text in the separate edit form, or hiding rendering of filenames with Markdown behind a configuration toggle – after all, “Simple by default, powerful when needed.”

@felixernst

We are very collaborative and welcoming to contributors, so no hostile forking please.

Ya ultimately gotta fork to do a merge request, right? That’s all I meant – leave it on GitLab to allow anyone who wants to include it later to do so.

Is that considered hostile to an OSS project?

---

@felixernst

About the tag functionality you might be interested to know that there is already a cross-desktop way to tag files. user.xdg.tags in the extended attributes is typically used for this AFAIK. This isn’t Dolphin-specific or anything and there is technically nothing stopping anyone from supporting this everywhere.

@felixernst, does an equivalent exist for comments too? They seem safe when I transfer between BTRFS, but the moment that NTFS is involved they’re gone. That’s ultimately why I have to use filenames for comments (like most people do) rather than solely as unique identifiers.

The perfectionist in me wants nothing more than to never modify a filename past its creation time, never/rarely use directories (and instead use tags) but neither is possible currently.

[redstrate]

@rokejulianlockhart

However, like you, I ultimately disagree that we should prevent users rendering Markdown from the filename section, and instead warn them with small text in the separate edit form, or hiding rendering of filenames with Markdown behind a configuration toggle – after all, “Simple by default, powerful when needed.”

I disagree, if an option is off by default it severely hinders adoption of said feature and it’s probably a sign that it might be too esoteric. See “New off-by-default features” on the Community wiki

@rokejulianlockhart

They seem safe when I transfer between BTRFS, but the moment that NTFS is involved they’re gone.

I suspect whatever you’re using to mount NTFS on Linux doesn’t support extended file attributes, which is typically used to store that data. Or at least, support isn’t enabled by default…

[felixernst]

@rokejulianlockhart

@felixernst

We are very collaborative and welcoming to contributors, so no hostile forking please.

Ya ultimately gotta fork to do a merge request, right? That’s all I meant – leave it on GitLab to allow anyone who wants to include it later to do so.

Is that considered hostile to an OSS project?

I was mostly joking either way, but to answer your question: There is both collaborative forking and hostile forking, and I wasn’t sure from your wording which of the two you meant. Hostile forking would be to fork with the plan to create a competing/alternative project which typically weakens the position and quality of the original project at least in miniscule ways.

However, forking as you meant it is indeed the only way to create merge requests on KDE’s Gitlab instance if one doesn’t have a KDE developer account yet.

@rokejulianlockhart

@felixernst

About the tag functionality you might be interested to know that there is already a cross-desktop way to tag files. user.xdg.tags in the extended attributes is typically used for this AFAIK. This isn’t Dolphin-specific or anything and there is technically nothing stopping anyone from supporting this everywhere.

@felixernst, does an equivalent exist for comments too?

Yes! This is actually one of the few attributes that are mentioned on freedesktop.org (CommonExtendedAttributes): user.xdg.comment.

They seem safe when I transfer between BTRFS, but the moment that NTFS is involved they’re gone.

I agree with what redstrate wrote (“I suspect whatever you’re using to mount NTFS on Linux doesn’t support extended file attributes, which is typically used to store that data. Or at least, support isn’t enabled by default…”). NTFS does support those in theory, and KDE software should automatically preserve them in theory, too. If any of that doesn’t work, there is a bug somewhere.

That’s ultimately why I have to use filenames for comments (like most people do) rather than solely as unique identifiers.

The perfectionist in me wants nothing more than to never modify a filename past its creation time, never/rarely use directories (and instead use tags) but neither is possible currently.

Right, I don’t feel particularly comfortable using extended file attributes either at the moment because I know that some software will forget them or not handle them correctly between multiple file systems that I might come in contact with. It can be something extra to care about but who double-checks this whenever they move data? One needs to be very confident that this metadata is handled correctly by every software on the system. This is one of the topics where extra contributions (maybe even outside of KDE) are needed. I just checked and there is for example 435001 – Ark does not preserve user generated xattrs (extended attributes) when editing/updating/saving a .zip file (and other types of archives) which is one of those things that should never happen. We would need more people looking after this kind of stuff to improve confidence in this kind of data never getting lost.

[rokejulianlockhart]

Thanks for this, @redstrate, and especially @felixernst.

Consequently, I’d solely like to be able to render .md in the user.xdg.comment section. (We can teach new users to use it instead of the filename.) Would it be reasonable to file this at bugs.kde.org, now that we’ve fairly well discussed the actual scope of the request, and its feasibility?

[felixernst]

You are welcome!

Consequently, I’d solely like to be able to render .md in the user.xdg.comment section. (We can teach new users to use it instead of the filename.) Would it be reasonable to file this at bugs.kde.org

Certainly reasonable. Just be aware that we get a lot of bug reports, and that we don’t have close to enough contributors to implement everything that would be reasonable.

we’ve fairly well discussed the actual scope of the request, and its feasibility

I think so too. If anyone takes the time to implement it, they would have all the necessary information to make this a success.

[rokejulianlockhart]

Perhaps text/html is partially rendered?

<blockquote>

```eml
=?UTF-8?Q?Order=20#=20FP21000011529=20has=20been=20shipped?=
``` 

</blockquote>

leaves me with

which I now can’t edit, for the comment box editor itself seems to be rendering the <blockquote></blockquote> .html tags?!

[felixernst]

Yes, that seems a bit weird. Might be worth looking into.