@extrowerk@Null@PulkoMandy
Just as I was starting to wonder what the interactive part of the shell should act like, this wondetful exchange takes place! It seems that my scripting engine start was exactly that: just the start!
Filtering down a query based on the result of a find should definitely be graphical! My opinion of drag-and-drop is more file-transfer oriented than the pipe proposal, however. I’ve had problems with intermittency of mouse buttons in the past, making dragging difficult.
The existing Tracker find window should be able to drill-down according to the directory tree memberships: “in child directory of…” should be a type of filter that selects its directory with a pop-up requester.
I think the “do one thing” doesn’t really hold true anymore, especially with many gnu tools beeing overloaded with arguments to do just one more thing : )
Unix and Linux are created using 100’s if not thousands of different components, most developed separately. That creates the fragmented mess that is Unix and Linux and it extends to open source software in general. Again, it is by design to ensure that the open source movement wastes as much resources as possible. And waste resources they do. If an individual component gets too popular and leads to a unified and cohesive experience, it will be sabotaged from within via infiltration, like GNOME.
I’m all for extending the capabilities of the Haiku terminal in a way that makes it cohesive and easy to use. The Unix way should be used as an example of how not to do things.
This is not intuitive, period.
Shell scripting is a mess and it is by design. I think Haiku should support it, but not encourage it or use it in any way by default. Instead a cohesive, intuitive and native scripting language that is fully integrated with the Haiku API should be used, and it should be able to be compiled. All tools included with Haiku should be written in C++.
As a side note I cannot understand why Python is so popular. It is a fragmented mess.
In designing a visual interface to pipe programs together, the main problem is how to implement the message containing the useful information visually. XML could be the solution, but it is not much more friendly to use than raw output/input.
Filetypes as a solution requires a file builder and a file interpreter. XML would make this simpler for script-based interaction. Commando appears (though I have never used it) to stream a program message output into the user’s hands, but then the task is how to coerce the information into the next piped program.
Still, this all is hardly visual or user friendly. How can we transcend this piping issue? Design an entirely new OS? Automator on MacOS is probably the best example of that. Maybe Adobe’s record action environment is even better.
If a program can be likened to a Building, and piping is sending information from building to building, then what is the information? Is it a person walking from one building to another? In this case we may think AI is the answer/solution.
But seriously, what about a car going from garage to garage? Is that likened to a filetype? Perhaps the answer/solution may be found outdoors. What is in the sixth dimension outdoors? Besides people…
Sending commands and receiving the results via text is an antiquated technology that remains from when teletypewriters was used as interfaces to computers. It is not an intuitive way of working with computers, especially when commands are combined as in @ArDrakho’s example. It should be left to history.
A step up is the use of formatted terminal applications with form fields, like the IBM 3270. It is menu and field driven and very intuitive to use. The 3270 is especially intuitive to use with a terminal keyboard. Anybody that has used a 3270 knows what I am talking about.
All applications should be able to be used without a mouse in the same smooth and natural way as a 3270 terminal. The same goes for the whole operating system. That is why I have tried to push for unification of keyboard shortcuts in Haiku that is currently a mess. Again, try using a 3270 terminal and you will understand why.
TLDR: Keyboard driven interactive terminal applications should be used instead of text commands.
It’s already possible to cache a query from Tracker’s “find” function as is. Adding filters and merges to those queries should be possible already… but aren’t.
I’ve never used an IBM 3270 but I am a fan of visual interactivity. Perhaps the Web, with all its forms and backend technology has the answer…
HTML 5 introduced semantic tags. Perhaps if we write the output from one program semantically, and the interpretation of semantics as the input, we could lose most of the filetype.
I guess we would just need a configuration genie to give the user a chance to say what is going to happen.
Forget about pipes. It is broken by design. Data should be stored in containers (variables) for later use. That mimics a natural workflow, like doing a calculation and writing down its result for later use.
The problem with other interactive solutions like the web, ncurses or simple GUI applications is the lack of an intuitive and standardized way of interacting with it using a mouse and keyboard. My example of 3270 is because it is a pure joy to use with a terminal keyboard, mouse not even needed.
The Unix way is using individual non-standardized text commands stringed together creating a fragmented, non-intuitive user experience while IBM created a standardized, intuitive and cohesive application based experience using terminal applications that was menu- and field driven.
If we had a query-file format stored in the Tracker config directory, couldn’t we apply the same filter technique to the text filters as well? The Head, Tail, Tee, Grep and so on could be grouped as text-utils commands and applied from a unified filter user-interface.
I’m with you there… A configuration genie could do away with unix pipes, provide a graphical interface to work with terms… provided application designers archive their messages into a semantic vocabulary established by the Haiku system… but still provide a pipe-like idiom.
With semantic input and output in messages sent from program to program, it is merely a task to provide matching of terms. The rest could be an API for configuring the User/Artist’s intent.
Let me give an example of how I would like to be able to use queries in Haiku.
I have an extensive music collection that I have ripped to my computer. I like to simply drop every track I have in my music players playlist. We are talking tens of thousands of tracks. From here I would like to filter out what to play from those tens of thousands of tracks. Maybe I would like to filter out by artist, by genre, by album, by path, by search criteria, or any combination thereof. I would like to be able to save these queries for future use. I would also like to be able to interact with predefined quueries. For example I could have a predefined query for artist where I have to input the search criteria for artist (like “moby”). That would give me anything with the artist Moby. But if I would like to listen to a particular album I would have to also query for an album. So that means two queries. And maybe I would like to only listen to the first CD of a multiple-CD album, I need to be able to query for that too, or an individual song from a particular album (I might have multiple variants of the same song with the same name). Since we all have different use cases, this needs to be fully user defined as not to be dependent on built-in support.
This means I would like to be able to quickly query my whole music library in a intuitive way using predefined queries that can be combined. This should be supported in Tracker but also be implemented by third party applications, like music players. If you have ever used WinAmp’s “Jump to file” plugin you know what I am talking about. My suggested functionality would be much more powerful.
It needs to be 100% keyboard driven, mouse only optional.
An example of workflow could be:
Press + for a search filter (will exclude anything that do not match filter)
Type art and tab to select “artist” (is predefined in some way)
Type “moby” enter to apply, esc to abort.
This creates a filter that filters out anything that does not contain the artist Moby.
This would create a psuedo query of “any track that contains the string moby as artist”. The query is run on a query that locates all tracks on the computer.
In the UI it could be displayed like (added search for the album Play) +filetype:flac+artist:moby+album:play
Tracker Find is most likely the starting point for any graphical/visual scripting, by providing a file type on the system. Narrowing the list with filters would be helpful and important, but this can be done with attributes AFAIK… perhaps not with cached queries
The rsason I thought a query filetype would be handy was that between the Haiku-specific scripting engine and the extensions to Tracker, there might not be much reason to have a shell in the first place.
Well, one thing that is lacking is for programs to communicate with each other. That is one thing I want to see in Haiku R2. Drag ‘n drop is a good start!
Drag ‘n drop query on slideshow. Cover art can’t be included as extended attribute. No cover art slideshow that way. Could be cool to have cover art in Tracker.
I came from the pre-GUI world of computing where CLI is very comfortable–be it UNIX, Linux, or DOS (MSDOS, Amiga DOS, etc.). With the CLI shell (whatever it be), I expect to control the entire IT universe from the commandline–even with today’s GUI OS’es (like I do today professionally)–in headless mode (i.e. no GUI–just CLI mode). CLI will always be CLI…but it can and should should interact with GUI objects at this low-level.
Piping is an easy concept of directing data/output traffic to other processes; hence, as in my example from earlier, under your new ideas, the “pipe” would represent a “StyledEdit process connector” that accepts a data flow from the find command (or any data source) where it starts StyledEdit and it accepts the data, formats the data, saves the data to a file as specified, then closes StyledEdit; returns to CLI prompt and reports “0”.
It is this “StyledEdit process connector” that you guys are talking about how to design and implement. This would be an example of PulkoMandy stated earlier:
I think Be Inc had automation in mind cohesively in the way they architected BeOS. The one piece we haven’t talked about yet, aside from queries, attributes, drag n drop & file types… is replicants!
How can we export just one gear of an application to be the source of configuration for automation…pipe that and send it to Filer
From some research I did… a replicant view is entirely its own, and doesn’t have to be the same as one visible in its parent application. So, a replicant could really be that “gear”.
It seems that my scripting engine start was exactly that: just the start!