[flixic]

An idea that anyone is free to take: JSON-definable UI for command-line apps. Define checkboxes for flags, inputs for arguments, buttons for commands and file pickers / droppable wells for file input. Allow some customization of layout of these elements. Have in-app "store" to download these JSON definitions, maybe even suggest them based on `which` output. Electron app, obviously.

[discordance]

That sounds like Gooey: https://github.com/chriskiehl/Gooey, which creates GUIs for Python cli apps.

Autogenerated based on the args, but configurable and the widgets and menus can be defined in JSON.

[flixic]

Gooey is a great northern star to follow, but this hypothetical app should work with any command-line app.

Idea would be to define UI structure that outputs (and executes) essentially a string (command) to run.

[cabalamat]

You have to define the behavour of your UI elements as well as their placement, at which point you're writing a program.

The best language to write a program in is a Turing-complete programming language specially designed for that task, not some cobbled together UI-definition language with ad hoc add-ons to processing.

[drran]

HTML is the only successful really cross-platform GUI system (text console, text-to-speak, Win, Mac, Lin, Android, iOS, Symbian, embedded, etc.) created so far.

[jonny_eh]

Indeed. Whenever someone suggests some kind of "UI" language, I just point to HTML/CSS. It's by no means perfect, but it's good enough and as ubiquitous as anything ever.

[_jal]

The best clothes are hand-tailored specifically to fit your body.

And yet, most people wear mass-produced clothes.

[NegativeLatency]

Well yes but to continue the metaphor almost nobody wears barrels

[HWR_14]

Mass produced clothes are significantly cheaper than barrels. Several orders of magnitude.

[goldenkey]

You have now been subscribed to Barrel Facts. Whiskey barrels are really expensive and the method to make certain types is passed down through generations. The tightness of the barrel and the type of wood are both considered as the wood will expand a bit from absorption of its contents. An amount of whiskey loss is accepted from evaporation of the contents through the porous wood of the barrel. A considerable expertise is necessary to create quality barrels. [1][2][3]

Each type of wood is used for aging different spirits. Oak is most common in whiskey and wine making. Sometimes the barrels are even smoked near a fire to impart a unique flavor into the alcohol that will be held in the barrel. A used barrel is very desirable and can go for higher prices on the open market than even a quality new barrel. This price parity is due to the unique flavor that can be impacted by using a used wine barrel for whiskey, used whiskey barrel for wine, or some other unique alternation of barrel contents.

Barrels that are hundreds of years old, and thick with aged bacteria are used for making traditional Japanese soy sauce. These special family heirloom barrels will be used for many generations before they are eventually retired. [4]

[1] https://youtu.be/ccoHCSKMf-E

[2] https://youtu.be/GE7QA1chUzw

[3] https://youtu.be/kaXvFw8ve_I

[4] https://youtu.be/1mc2g8Ue-hI

[flixic]

The way I look at this, the UI would be only to speed things up / simplify things a little bit. It wouldn't try to do full error validation before execution. It's the job of a command-line app to fail with an error if wrong combination of flags or inputs was provided, and the UI might display that error in a pretty generic way.

[hungryforcodes]

Everyone has different requirements. For many things, I'd take a quick JSON file configuration over having to write everything from scratch again and reinventing the wheel.

Like it or not, the whole low code movement is about this.

[cabalamat]

> I'd take a quick JSON file configuration

Let's say your GUI has several input boxes. You want to validate those boxes. You need something Turing-complete to do this, because if it isn't Turing complete and the tool is used by lots of people, someone's GUI will require it.

> the whole low code movement is about this

That's OK provided you accept that it limits what can be done.

[colejohnson66]

XML based UIs already exist with GtkBuilder and QtQuick(?). Although, your idea is more complex than that.

[jonny_eh]

HTML is a pretty good XML-like UI builder.

[ducktective]

I've been asking HN for this some time ago: https://news.ycombinator.com/item?id=27820141

Also see: https://news.ycombinator.com/item?id=28461133

[flixic]

It seems to me that a lot of these projects aim to deliver really "good" apps: native UI, table output, etc… Results are great, but the UI building complexity also becomes quite high.

I think that's the wrong goal. The goal should be really simple definitions and ok quality apps. Simple JSON (or XML, don't care).

    { control: checkbox, flag: c, label: "Compile" }

[zorr]

Not JSON, but related: Kaptain.

https://github.com/mviereck/kaptain

[flixic]

This is cool! Syntax might scare off many developers, I think one of the goals should be approachability, it should be super easy to transform your favorite command-line app into a GUI.

[slightwinder]

Why JSON? Just use a simplified subset of HTML and ignore styling+scripts for commandline. And for GUI/Web you can still offer the full HTML+CSS+Scripting-experience.

[flixic]

Can be XML as well, but I think HTML is too complex. The goal, for me, is simplicity.

    <section name="Options"><checkbox flag="c" label="Compile" /></section>

It shouldn't be a hassle at all to convert a man page to a UI that speeds up actions and avoids common errors.

Anyway, this idea is free, so feel free to take it and do whatever, even full HTML (:

[jonny_eh]

> HTML is too complex

The suggestion was a simplified subset of HTML.

[jhgb]

Sounds a bit like Sciter, then.

[slightwinder]

I don't see how yet another ui-definition-format will help to make things simpler. And what UI does a manpage need? Manpages are documents, they have no real ui.

[jjnoakes]

I think op meant covering a man page for a command into a gui for the command, not into a gui for the man page.

[platz]

i was surprised how close this gets https://sanana.kiev.ua/index.php/yad

[ape4]

Everything doesn't have to be JSON ;)

[cabalamat]

Agreed. The best format might be one specially defined for the job.

I built a GUI-builder ages ago (in Python, compiling to Python which calls Tkinter to build the GUI). Here's a sample of what the UI-definition language looked like: https://github.com/cabalamat/parrot/blob/master/simple2.par

[bavell]

Looks fine and dandy but could also be represented in JSON with not much effort and then you'd be using an interchange format understood by many tools instead of a bespoke language.

I'm definitely biased being a web dev but JSON is just so widely used and supported... seems ideal for small bits of config like this.

[bityard]

IMO, using JSON to specify a GUI would be a terrible idea. Its purpose is to serialize data for transport between disparate systems. JSON is verbose and writing anything decently complicated with it sounds like torture.

What you want for something like a GUI specification is a DSL designed for the task (e.g. QML), or a suitable general purpose language like HCL or YAML.

[cabalamat]

> JSON is verbose and writing anything decently complicated with it sounds like torture.

Except in comparison with XML :-)

[cabalamat]

> Looks fine and dandy but could also be represented in JSON with not much effort

Yes it could. But writing the UI descriptions would be harder in JSON than in my bespoke language.

My goal in writing the tool was to maker UI descriptions as easy to write as possible. If I hadn't cared about that I wouldn't simply continued to hard-code them in Tkinter.

> I'm definitely biased being a web dev but JSON is just so widely used and supported

JSON didn't exist when I originally wrote this. If i was doing it today, it's entirely possible I would use JSON as a data interchange format.

[cabalamat]

> But writing the UI descriptions would be harder in JSON than in my bespoke language.

For example, this:

    menu "File" {
        menuItem @New "New"
        menuItem @Open "Open..."
        menuItem @Save "Save"
        menuItem @SaveAs "Save as..."
        menuItem @Exit "Exit"
    }

Might become something like this:

    {'widget': 'menu', 'text': 'File', 'contents': [
            {'widget': 'menuItem', 'id': 'New', 'text': 'New'},
            {'widget': 'menuItem', 'id': 'Open', 'text': 'Open...'},
            {'widget': 'menuItem', 'id': 'Save', 'text': 'Save'},
            {'widget': 'menuItem', 'id': 'SaveAs', 'text': 'Save as...'},
            {'widget': 'menuItem', 'id': 'Exit', 'text': 'Exit'}
        ]
    }

Which would turn writing a UI from something that's a pleasure to something that's a chore. People who would deliberately write software that's a chore for others to use ought not IMO be writing software that will be used by other people.

[lbqjfw]

For native Mac apps, there is Platypus that does something similar: https://sveinbjorn.org/platypus

[smashah]

This would require some sort of open-api type spec but for CLIs. I like this idea. Good luck to anyone taking it up.

[MR4D]

So like a modern day VB3 but built on Electron. Would be nice to have!

[notRobot]

preferably not electron :)

[MR4D]

I get the hate for Electron, but to me, despite the issues, it's not going away.

I think a better approach is to figure out how to make Electron more performant in the various OSes.

I haven't gotten into the internals of Electron, so I'm not the one to reflect on the approach, but seeing some of the improvements that MSFT made with Edge over Chrome in memory usage gives me hope that this is achievable, even if it doesn't happen immediately.

Back in the 1990's we faced a similar thing, where web "apps" were ugly and slow, and not as powerful as the desktop apps that many corporations had developed in C++ or VB or Delphi. Today of course, the situation is much different, and we use web apps all the time. I really truly believe that Electron (or perhaps a successor - like how VS Code superseded Atom) will not go away, and in the future we will be much happier with it.

[HWR_14]

> back in the 1990's we faced a similar thing, where web "apps" were ugly and slow

And when's the last time you loaded an app with the Java VM on the desktop, unless it was Eclipse and you were about to use it to write more Java?

[genewitch]

Minecraft. q.e.d.

[HWR_14]

That's true. I forgot Minecraft. I now have two examples (Eclipse, Minecraft). Although Minecraft moved away from Java to native clients for consoles, mobile and even a Windows native version.