.directory documentation

Help
1

@meven

Is there a documentation for the .directory file?

1 Like
2
3

What sort of documentation are you after?

What is wrong with the spec?

4

Documentation for .directory contents.

1 Like
5

OK… what line of a random .directory file made your spidey senses shiver and prompted this question?

6

I’m more curious about the lines not there. Some questions:

  1. The list of possible layouts? Grid, thumbnails, lists, detailed lists, etc.
  2. The standard for description, tags, icons
  3. Is Comment= the right way to set a description for the file?

What extensions does Dolphin support? Are there standards for such extensions?

X-GNOME-Keywords
X-GNOME-Url
X-GNOME-View
7

1 ) nothing to do with XDG - The spec -

 The basic format of the desktop entry file requires that there 
 be a group header named `Desktop Entry`. There may be other 
 groups present in the file

- that only specifies stuff under [Desktop Entry] - anything under [Dolphin] is, well, dolphin’s. (As is everything in the dolphinrc file which is also applicable)

2 ) steady on…
a)   description? Where is that field?

b)   tags (and other properties on the file Details tab in dolphin) are nothing to do with .directory files - they are xattrs. Use

 getfattr -d --  FILENAME

to view them.

c)   icons? there can be only one for one .directory file. Nevertheless, it is quite clearly documented in the document you say documents nothing.

3 ) Comment= (if we are once again talking about the .directory file which we had steered away from…), if present, manifests as Type in dolphin properties for the folder, “pushing” Folder into a Content: field. Also shown in status bar.

A no numbered question, any reason?

https://github.com/KDE/dolphin/blob/master/src/settings/dolphin_directoryviewpropertysettings.kcfg

Standards? In the standards, obvs…

https://specifications.freedesktop.org/desktop-entry-spec/latest/extending.html

 

Y-ES-exactly
8

Nope, no documentation, for dolphin the source of truth is:

But it does not tell you all the values possible and there is more subtleties in cpp code:

Why do you need that?

9

Description? Where is that field?

Description for the contents of the directory. Not implemented by all file managers (which is why I’m looking for a standard), but can usually be viewed in file properties.

Tags are nothing to do with .directory files

What if it’s desirable to have them so? Xattrs are limited in many ways and are not as reliable as plain text files. Many programs just ignore them, not to mention backing them up between different filesystems.

quite clearly documented in the document you say documents nothing.

The document is useful.

Why do you need that?

  1. A standard would be nice to have compatibility between different file
    managers.
  2. I wanna know which file managers support which features.
  3. .directory ideas is an interesting one to have a sort of “modeline magic”
    when traversing special directories. I wanna know what the spec is so that I implement them in some shell scripts I have.
10

OK… Before you posted

did you bother to see if the Comment or Name fields (documented in that document) did what you seek when placed in the file - their specification is in the spec - if file managers choose to use them for other purposes (as already mentioned above, and a further example given below), that is for them…

What file managers choose to do outside of the spec is not a standard - that is for them to decide on; as long as it does not contradict the spec, then meh.

Edit: para removed - No longer work for directories :frowning:

you are asking a lot of questions that have been answered in the (now) “useful” document - be it by plain english or the absence of it. (hint - mentioned = in the standard; not mentioned = not in the standard)

1 ) Sounds like you have some work to do…

2 ) You have the answer for Dolphin… Better start a new thread for konqueror, gnome files, thundar, PC ManFM, …

3 ) your best bet would probably be to set up an inotify script that watches for certain files (in said directories) being scanned by dolphin, and then using that to trigger your, erm, “modeline magic”

Alternatively you could poll dbus -query IsUrlOpen for the paths - (file:///home/avidseeker/....)

11

We aim to have some compatibility between Dolphin and KDE File widgets (open save dialog) and other file views but beyond that won’t happen.
Feature set are very different filemanager to another and how settings are saved.

Standards are needed when third party applications need to interact with DE, and filemanagers are considered as applications part of DE.

Be warned .directory files shouldn’t considered stable, your scripts might break anytime without warning. For instance, they will disappear soon-ish when I finish https://invent.kde.org/system/dolphin/-/merge_requests/573
(but their data will be in filesystem metadata).
Dolphin already has a feature to set view settings recursively.

I told you most of what you’d need, but the question would be to what your script would do? Do you really need to script this?

For instance, we already have feature request to adapt the view based on the content (all photos → turn on preview in icon view…).

1 Like
12

What your script would do? Do you really need to script this?

E.g: a function alias for ls that reads .directory to see if directory is a gallery of pictures, in which case it uses a program like lsix. It can also be used to inform ls of
whether to show hidden files or not.

adapt the view based on the content

Interesting, my script might be better done through a heuristic like that, then.