It does me good to hear this discussion “firing on all cylindars”. Between links to a public domain visual language, discussion about rendering text-based shells obsolete with unique GUI properties of Haiku, file attributes for querying searches and using filters to narrow those searches or broaden searches by merging multiple query results, we’re getting bases covered. Maybe before too long I, myself, or someone else can file a pull request against the website to summarise these conclusions and discussions in an article on the Glass Elevator section.
I am beginning to think that the real haiku shell is just the whole OS, but it still needs work if it is going to replace bash with a GUI, however unique and beautiful the invention is
1 Like
Several articles on Glass Elevator refer to enhancements for the Tracker. Some are quite lengthy! In particular is the following article: One Desktop to Rule Them All
Now this would be cool. I too have my large music collection saved as MP3 files, where I created its own custom FileType ‘database:MusicDB’ and its default template. I have written queries to locate and display my results in the terminal–the queries work very fast (with indexes).
If ‘query’ command could incorporate database capabilities (e.g. WHERE clause structures) or new CLI commands similar to the Cypher language (i.e. MATCH) that could better leverage the BFS attribute paradigm. TrackerBase showed us the basic and extended capabilities of BFS. If Haiku had a simple query language that is specifically developed to ‘query’ the BFS data/attribute structures, it would replace complex query bash scripts to simplified query scripts.
The queries should also be able to display the results in various ways. I could define a query that groups songs by album, by artist, by record, by genre etc.
Let say I do a query grouping by artist, then the results would look like this:
Alanis Morissette/Track 1
Alanis Morissette/Track 2
Alanis Morissette/…
Beastie Boys/Track 1
Beastie Boys/Track 2
Beastie Boys/…
…
Same search but grouping by artist and album:
Alanis Morissette/Album 1/Track 1
Alanis Morissette/Album 1/Track 2
Alanis Morissette/Album 1/…
Beastie Boys/Album 1/Track 1
Beastie Boys/Album 1/Track 2
Beastie Boys/Album 1/…
…
Group by genre, artist and album:
Pop and Rock/Alanis Morissette/Album 1/Track 1
Pop and Rock/Alanis Morissette/Album 1/Track 2
Pop and Rock/Alanis Morissette/Album 1/…
Hip-Hop/Beastie Boys/Album 1/Track 1
Hip-Hop/Beastie Boys/Album 1/Track 2
Hip-Hop/Beastie Boys/Album 1/…
Queries needs to be visual, discoverable and self learning. That means when you start to use the query functionality you get visual feedback and help.
I see this as an extension to the current type-ahead filtering.
So, everything would start with reviewing and expanding BFS.
I think BFS2 would be the solution to all these problems.
I think BeFS, as it exists already, can do a lot more than we use it for!
1 Like
I have a really vague memory that someone wrote a command line tool to use SQL queries for BFS attributes a LONG time ago, around the time of Be Inc’s demise and the beginning of Haiku. Not sure if it supported WHERE clauses. And I have no idea where to find that or what was the name of the tool.
If it was a SQLite3 wrapper for Haiku, that would allow a lot of software to use BeFS that otherwise wouldn’t. One example is that Draken visual language editor I was hoping to adapt to Haiku which uses SQLite as its only file format internally.
Speaking of which, the Lua 5.2 backend I thought of adapting works already and several Lua versions are in HaikuPorts. I’d prefer to use the C++ backend for the editor itself but it currently uses Qt. Also, Luau wouldn’t be a hard port but I need to get familiar with Drakon first and foremost. Maybe I’ll just use the generators and rewrite the editor.
Re:Drakon’s SQLite File Format
After reviewing the documented schema of the file format of Drakon, I’ve discovered it’s geared toward the storage of the diagram format more than that of a code format. Fortunately, the generator can be written to export to any code-centric file format including another graphical language.
I’ll be ending the thought experiment of a graphical scripting engine in this thread now. It appears that it was partially a bust. My research now proceeds unto binary schemas for SQLite and version control operating on a common webserver.
1 Like
This is a modern take on a shell: Nushell. (cross platform - in rust) Its partly graphical, and has lots of contributors.
Nu draws inspiration from projects like PowerShell, functional programming languages, and modern CLI tools. Rather than thinking of files and data as raw streams of text, Nu looks at each input as something with structure. For example, when you list the contents of a directory what you get back is a table of rows, where each row represents an item in that directory. These values can be piped through a series of steps, in a series of commands called a ‘pipeline’.
3 Likes
But why would you want that? These applications can store their data in an sqlite database just fine. Why would you make them use thousands of empty files with attributes instead, resulting in slower performance and waste of disk space?
It’s been said that Haiku provides a cohesive experience compared to the likes of Linux which is piecemeal. If I need a mimetype for a SQLite3 based file format, how do I identify it?
Is SQLite3 completely necessary?
Could it be replaced by something else?
I’m thinking in that direction because it could easily be upgraded to allow collaboration online by putting the file manipulation onto a SQL based server, as was done for Drakon.
Collaboration tools coupled with replica sets of servers and in case of heavy loads, sharding of database repos, make for a better user experience if done right. It might even bypass the need for local version control tools. Thinking ahead, that doesn’t sound so great.
Maybe the best solution toward a cohesive scripting experience is to give the common tasks a graphical user interface. That way the staring at a blinking cursor as you try to remeber the name of a cryptic command syndrome will be remedied.
I like that.
Do you have any “mental prototypes” about it?
I was hoping to make a graphical programming and scripting engine but the one problem staring me in the face about it is that version control and file differencing is difficult in graphical languages.
Yes, but that does not mean “blindly use attributes for everything”. And especially attempting to fit an existing app that was designed and tested with sqlite to work with another quite different engine and storage seems like a bad idea.
If you are designing an application for Haiku, you can think about what is useful to expose to other apps as attributes, what is convenient to store there rather than in the file body, etc. But, you can’t take an app that was designed with a completely different model in mind, force it to store its data as attributes, and call it a day.
4 Likes
OK. What if I exported a file type and file type version as attributes in a file based on SQLite? Would the Haiku Filetypes utility be able to track it then?
Don’t know what the conversation drifted to, but replying to the original message: Would it be easier to just… use PowerShell and then load Haiku API .dlls and then interact with those objects?
1 Like