hello
hello copied to clipboard
helloSystem
Spatial file manager
The current https://github.com/helloSystem/Filer/ implementation is not spatial.
Spatial Interfaces are explained by John Siracusa at https://arstechnica.com/gadgets/2003/04/finder/2/
It would be nice if we could have a spacial file manager.
Were you thinking that Filer should be extended to have a spatial mode or having an alternative to Filer that is spatial? I don't think there's any existing project in Qt (Gnome 2 had spatial mode at one time - we don't want that)
Either way. One thing I don't like about Filer is that it still draws in some glib based components, and I was considering alternatives including DFilemanager but I could not get it to compile yet: https://github.com/helloSystem/Filer/issues/23
I have started extending Filer for spatial mode support - https://github.com/helloSystem/Filer/pull/35
I agree it would be nice not to have the glib components at all, but I think the current Filer is probably the best option still and for pragmatism it might be worth sticking with it and hope that eventually it can be refactored (well, libfm-qt)? I got DFilemanager to compile but there are more problems there.
Extended attributes looks viable - this is the next step in extending Filer. As a proof-of-concept from the command line:
HelloChris% setextattr user window.height 100 Documents
HelloChris% getextattr user window.height Documents
Documents 100
See https://www.freebsd.org/cgi/man.cgi?setextattr
I had some spare time (I'm on 'holiday' this week :) ) so I went ahead with the extended attribute implementation for window position and size (modified the same PR).
This implements spatial folder browsing, so obviously there's an outstanding task for storing icon position as well but I think this is good to start with?
~We might want to hide the sidebar and navigation controls when in spatial mode to provide a similar experience to Haiku's tracker or classic Mac finder.~ OK, I had a bit more time and sorted this out too :)
It would also be nice if the 'maximise' window button behaviour would do the same as tracker in this case (resize to the minimum size to fit all items without scrollbars). That's a different topic though, I guess!
Wow @moochris this is awesome! Thank you very much.
Let's think about a few more aspects of spatial navigation Maybe we should think about creating a spec for the metainformation needed to make a truly spatial file manager first, ideally in a way so that any file manager could implement the spec in a compatible way, e.g.,
- Window size in pixels at normal (no-HiDPI) resolution
- Window position on screen in a coordinate system
- Display mode (icons view, list view, Miller columns,...) and a definition of fallbacks (e.g., if Miller columns were set but the file manager does not have them, then use list view)
- Icon size for the window
- How icons are positioned (automatic/by type/sorted/manual...) and sort order
- Icon positions in a coordinate system for each icon
- Window background wallpaper (only in icon view)
- Custom icons for files and folders pasted by the user
- Tags/colors of files
- ... As for storing the information, we should think about consider
- Extended Attributes (advantage: no additional files cluttered around for storing this information)
- One hidden file per directory (advantage: survives archiving and copy operations even over the network, etc.)
- Possibly a combination of the two or something else.
We should investigate how other spatial file managers are doing this.
More food for thought from reviewer John Siracusa and Classic Mac UX auhtority Bruce "Tog" Tognazzini:
- https://arstechnica.com/gadgets/2003/04/finder/2/
- https://www.asktog.com/columns/034OSX-FirstLook.html
For me, the possibility to open new windows for each folder is just one (and probably the most controversial - hence Apple made it optional in Mac OS X) aspect. Other aspects should also be considered, such as remembering for each location in which mode (list/icons,...) it is displayed, where each icon is (in icon view mode), how things are sorted (in list view mode).
Yep I think a spec would be a good idea.
I started on a kind of structure for the names of the extended attributes in the initial implementation, but it probably won't scale to include the other fields.
I had thought of a few similar to what you have listed, but also another nice thing might be to reuse Haiku's HVIF format to store icons in extended attributes? (I'm sure you're aware of this, but https://www.haiku-os.org/articles/2006-11-13_why_haiku_vector_icons_are_so_small/ link anyway :smile: )
And yes storage is definitely a consideration - e.g. it would be nice if Nextcloud (or Dropbox or whatever) could synchronise the metadata. I quite like the extended attributes (seem to work well in this first attempt) but I guess if they are transparent to the user, then some other file based mechanism like dot files would be preferable.
I quite like the extended attributes (seem to work well in this first attempt) but I guess if they are transparent to the user, then some other file based mechanism like dot files would be preferable.
Let's have a look at where other systems are storing which kind of information; Haiku and the Mac are coming to mind immediately.
Speaking of Haiku:
Haiku Vector Icons
Yes, I know about them but since many applications don't have them I think we needd to support png and svg in any case.
An interesting post (albeit from a while ago now) on extended attributes:
https://www.lesbonscomptes.com/pages/extattrs.html
Hopefully some of those pitfalls have been solved in the meantime. I note that it mentions ROX using them, so worth adding that to the list of projects to investigate.
Possibly we need to consider a combination of extended attributes (for performance) and files (for robustness) (I think this is what Haiku is doing). In any case, the spatial information should travel with the folder, so that e.g., if someone accesses the same folder over the network the spatial information should be available to that user, too.
Need to keep in mind use cases like this one:
Here, whoever created that disk image
- Set the sidebar to disabled for that window
- Set a custom window wallpaper
- Set the size and location of the icons
...and all of it traveled along inside the disk image.
Possibly we need to consider a combination of extended attributes (for performance) and files (for robustness) (I think this is what Haiku is doing). In any case, the spatial information should travel with the folder, so that e.g., if someone accesses the same folder over the network the spatial information should be available to that user, too.
I think Haiku only uses attributes for Tracker - it's these here: https://git.haiku-os.org/haiku/tree/src/kits/tracker/Attributes.h
e.g. _trk/windframe
But yes I agree these things should be portable. For Haiku, for example, they modified zip and unzip to preserve attributes. We should look into whether other formats can preseve extended attributes already - e.g. tar already does.
Uh. I am not a huge fan of patching half the system. Maybe better use dot files in each directory. E.g, .extattr? When Filer sees such a file, it could read it and apply the extended attributes in the filesystem. Something along those lines (not fully thought through yet).
Yeah, OK, I think you're right.
We'll need a spec - doesn't have to be fully fleshed out, but if we can get a standard for naming to start with that would be good for modifying the spatial Filer PR (as a prototype).
All files/folders will need a dot file I think, rather than a just one for the directory or you have all sorts of management of what then becomes like a flat database.
e.g.:
/home/chris/projects
/home/chris/.extattr_projects
/home/chris/projects/document.odt
/home/chris/projects/.extattr_document.odt
The dot files can contain key value pairs for the attributes, although I'm not sure about the best format - possibly just key=value one per line?
It doesn't need to apply the extended attributes at all really, as the dot files will need to be kept up to date - may as well just use the dot files?
OK, I see the problem with that - the directory needs to contain its own dotfile or you'll lose it on archiving.
So:
/home/chris/projects
/home/chris/projects/.extattr
/home/chris/projects/document.odt
/home/chris/projects/.extattr_document.odt
Instead of having
/home/chris/projects/.extattr_document.odt
we could have that information in
/home/chris/projects/.extattr
as well. Only directories would need those files, the files could also describe the documents inside. When Filer sees the directory, it would apply its extattrs to the files inside.
People are gonna hate this if we have such files cluttered around in big numbers.
Actually, let's have a look at how .DS_Store files work. They are created by the Finder in some circumstances and seem to contain the metadata we are discussing here. The format is proprietary, but maybe we can deduce some of the "theory of operation".
- https://en.wikipedia.org/wiki/.DS_Store
- https://0day.work/parsing-the-ds_store-file-format/
- https://wiki.mozilla.org/DS_Store_File_Format
- http://search.cpan.org/~wiml/Mac-Finder-DSStore/DSStoreFormat.pod
- https://digi.ninja/projects/fdb.php
Our motto: Aim for making everything 10x as simple! But it cannot hurt to understand the "prior art" concepts first.
We might want to consider something like sqlite?
Sure. But we need to think about what to put where, so that it can travel along, e.g., in zip files and such. And we need to think about performance. The Wikipedia article has some good hints. (To interpret them liberally: By default do not store such files on network shares, and only save those files after a window was open for a certin number of seconds and the user changed its appearance - something like that)
Sure. But we need to think about what to put where, so that it can travel along, e.g., in zip files and such. And we need to think about performance. The Wikipedia article has some good hints.
I'm suggesting that the single .extattr file in the directory is an sqlite database, so it would persist with the zipped directory. But yes, not sure about performance.
Check this out!
https://ds-store.readthedocs.io/en/latest/
Manipulate Finder
.DS_Storefiles from Python. (...) This module allows programmatic access to and construction of .DS_Store files directly from Python, with no Mac OS X specific code involved.
Wouldn't it rock if we could use the same format even, given that someone seems to already have written the implementation?
Reading through the comments in the code of https://github.com/al45tair/ds_store/blob/master/ds_store/store.py alone is versy interesting, it gives some hints such as:
Works by manipulating the file on the disk---so this code will work with
.DS_Storefiles for very large directories.
I'd say let's play around with https://github.com/al45tair/ds_store a bit and in case we decide against using it we know at least why ;-)
Please let’s not use DS_Store, as a former macOS user it was a PITA for me, specially when doing development.
This means it will be very useful for the daily users, but very bad experience for the power users and developers.
On Sat, Feb 20, 2021, at 3:03 PM, probonopd wrote:
Check this out!
https://ds-store.readthedocs.io/en/latest/
Manipulate Finder
.DS_Storefiles from Python.Wouldn't it rock if we could use the same format even, given that someone seems to already have written the implementation?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/helloSystem/hello/issues/79#issuecomment-782607064, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABKXL3P5TT6XEZ5X37FO4LTS76JIVANCNFSM4VQPWWMQ.
The format seems to be documented here: https://metacpan.org/pod/distribution/Mac-Finder-DSStore/DSStoreFormat.pod
What were your gribes with .DS_Store fies? I am asking because I fear that some of them will be there with any such format.
At the very least, we should understand .DS_Store before we implement something new.
At the bare minimum, https://metacpan.org/pod/distribution/Mac-Finder-DSStore/DSStoreFormat.pod tells us conceptually which type of information we should consider to store. If we then find a much simpler way, all the better!