[tjoff]

>There should be drop-down menus for all applications, whether text based or GUI based. And these menus should be able to incorporate system-native dialogs e.g choose a file, choose a font etc.

I see how that would easily break scripts. Not in theory no, but in practice. The instant developers gets a choice on this they will develop for their needs and break others.

It breaks what I as a user expects from a terminal and if such a terminal was launched today I don't believe anyone would use it. Not because the idea is bad but because the users of a terminal have a very confined idea of how the communication is supposed to work.

It absolutely must work the same over ssh on my phone or my fridge as on my workstation (regardless of OS). KISS.

Now that doesn't mean we can innovate or improve things, but it must be done without breaking expectations and it must be compatible with the mindset of today or I don't believe anyone will pick it up.

[setr]

Presumably it would be in the same fashion that file dialogs are generated; you defer the actual selection to some OS-provided library function, and just accept a standardized output (some FileObject construct). So the terminal would provide this file selector, based on context: a script would take it as the filename itself, the interactive shell would provide the file dialog, etc.

Terminal Programs are already outputting differently based on context (ie ls to a pipe vs screen), so supporting interactive and scripting is hardly a novel idea in the space; its just that the interactive support hasn't fundamentally improved in decades