Menu
▾
▴
#47 remove (absolute?) path from address
I think it's really important to make it easy to move Frontier across
folders (directories) and machines. A huge barrier: the absolute file
path is included in the address of all ODBs except Frontier.root. I think
we should get rid of that.
I have no idea how easy or hard that is in the kernel, but once that is
done I think that most things will "just work" since the top-level items
in an open ODB are already global.
One huge caveat: since I got bit by this issue early on, I've always used
unique names at the top level of my root files, e.g. "foo.root" would
have a single top-level table named "foo", or "projects.root" would have
several top-level tables that I wanted to be global (much like all items
in "suites" are global). But, perhaps there are lots of existing ODBs
where that's not the case?
If so, perhaps it's important to have the filename and/or RELATIVE path
in the address? If RELATIVE path is much easier than no path, I think
that's a perfectly reasonable compromise. The hard part in moving
things around is the path ABOVE Frontier.root; I don't mind if the folder
structure beside and beneath has to be fixed to be fully portable.
One more thing to watch out for: it's sometimes useful to open 2
versions of a root file. Perhaps this again argues for RELATIVE path?
Though I would be content with filename and thus to make people
rename the file before opening a second root with the same filename.
It's a small price to pay for what I think is an uncommon use case.
Another: the Bookmark menu automatically opens the root file, i.e. it
makes use of the absolute path. There may be other code that has the
same assumption. FWIW, Bookmark is another example of the harm of
absolute paths: it means that Bookmarks aren't portable! This bit me
recently and was hard to track down.
An alternative that will get some of the benefit: upgrade many verbs
that expect an address to accept a string and coerce internally, e.g.
user.menus.menubar could be a string myRootTopLevel.myMenu rather
than an address @[path that might change].myRootTopLevel.myMenu
