Spatial file manager

[probonopd]

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.

[probonopd]

Also see https://www.asktog.com/columns/034OSX-FirstLook.html

[probonopd]

Possibly store the metadata for this using extended attributes?

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)

[probonopd]

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: helloSystem/Filer#23

I have started extending Filer for spatial mode support - helloSystem/Filer#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!

[probonopd]

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.

[probonopd]

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

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.

[probonopd]

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.

[probonopd]

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.