-----------

There is many command line apps, which while is nice to use when creating batch scripts... is annoying to use for daily stuff. Especially when you haven't use such a program in a while, so you have to relearn how to craft the right command line commands/switches/filepaths (stuffing up a few times before getting it right).

I understand why most coders just frankly don't do GUI for these super useful tools. GUIs are bloody annoying to code.

E.g. diff-pdf is a command line program that accepts 2 pdf filepath, and compaires it visually. Very useful... except you have to hunt the filepath for both pdfs... not very fun in windows. So i created a basic python script that uses tkinter to bring up two file browser prompt to make life easier.

What I really would like to see, is some way to quickly write up a minimal gui for any command line programs.

START of E.G. E.G. E.G. E.G. E.G. E.G. E.G. E.G. E.G. E.G. E.G. E.G. E.G. E.G.

## About ##
All comment will actually be displayed to the user etc, and should be rendered in markdown, could perhaps store the entire helpfile like this

INTERFACE SPEC:
---------------------
option1 = select{
'a' : # this comment will explains what option a is on hover
'b' : # what this option does
'c' : # and what this option does as well
}
option2 = range: 4 --> 9 # Comments about this argument
file = filepathbrowser: '*.pdf' # Maybe comment that only .pdf is accepted

run <-- helloworld.exe [--option1] [--option2] ((file))

------------

result --> { # Could be regex matched perhaps
0 : # Program exited without error
-1 : # error somewhere....
"hello world" : # All good
}

END of E.G. E.G. E.G. E.G. E.G. E.G. E.G. E.G. E.G. E.G. E.G. E.G. E.G. E.G.

Where the above is rendered as a simple GUI, with two optional select and range arguments, as well as a mandatory filepath

The above is just a quick illustration of the concept, and is not how the coding should actually look like. If anything, I would envision it to be more like making a HTML page.

The idea is that this is both an 'instant GUI interface' as well as a 'help file', e.g. can have extra tabs that serves as documention for the commandline program.

In fact, if possible, the whole 'GUI helper code' should be as human readable to a non coder as possible.
-- mofosyne, Jul 26 2014

GUI FRONTEND SCRIPT FOR DIFF-PDF (guiDiffPDF) https://github.com/.../diff-pdf/issues/14
Just a quick python script to solve this minor but very annoying issue of no GUI frontend for diff-pdf [mofosyne, Jul 26 2014]

Learnable Programming http://worrydream.c...earnableProgramming
Points out why GUI are easier than text. (Hint: context) [mofosyne, Jul 26 2014]

Python - Common Gateway Integration https://docs.python.../2/library/cgi.html
All your GUIs are belong to us. [zen_tom, Jul 29 2014]

Half Baked Idea: Simple GUI format for command line http://www.reddit.c...t_for_command_line/
[mofosyne, Aug 03 2014]

sadly the Internet has swallowed any mention of
Soft & GUI CommandLine, which I developed for this purpose in 1991
-- theircompetitor, Jul 26 2014


Still got the copy somewhere to share? :S Maybe we can learn something from your effort.

How does it work? And if you would write it again, how would you do it differently?
-- mofosyne, Jul 26 2014


// except you have to hunt the filepath for both pdfs //

You do realize that the command windows in Windows support drag and drop. If you drag a file from an explorer window and drop it on the command window, the full path gets "typed" in for you.

Also look up tab completion, "quick edit mode", and practice use of F3 and F8. These can help make your usage of the command line much more efficient.

Although I admit that for many people they wouldn't use the command line often enough to remember the tricks to use it efficiently, so they are better off with a GUI.

I'll bun this idea because it allows people to have their GUI while allowing the program to still operate well from the command line for scripting and use by weirdos like me.
-- scad mientist, Jul 28 2014


Hmm, I've seen various libraries making it easy to extract arguments for the command line in standard formats. It seems like it would be fairly simple to expand such a library so that if there are no parameters specified at all, it would launch a window to collect file names and parameters. The library might need to be enhanced slightly to associate help text with each parameter. As an added bonus, it could auto-generate the command line associated with the current parameters specified in the GUI, that could be copied to a script.

Alternately (and maybe more related to your idea) a lot of command line apps use fairly common syntax for specification in the help text. It might not be much of a stretch to have a program that automatically calls the program with "/?" and "-h" (the two most common parameters to get full help text), and then parses the help text to auto- generate a GUI. Obviously it won't work on all programs, but if it became popular, people writing command line apps might more often adhere to the standards that would allow this program to work well.
-- scad mientist, Jul 28 2014


Ah, you got a very nice idea there 'scad mientist', I think its worth of a separate half bakery post.

However I would wonder how one would use it normally.

(1) Should perhaps all command line program when clicked in desktop, be opened with a GUI prompt (after having it's help file parsed)? (edit: actually I think that wont work)

(2) Or should it be a right click 'open as GUI'?

(3) Or should it be a separate 'special short cut' that goes "GUIConstructor CmdProgToUse.exe"

Perhaps the best approach would be to use (3) approach, but also allow for an optional GUIspec file like I showed in the description.

e.g. "GUIConstructor CmdProg.exe CmdProg.GUIspec"

As for why? Because the "-h" while useful, is often sparse to keep the filesize down. So a separate help documentation is often needed.
-- mofosyne, Jul 29 2014


It's pretty simple to support both options (2) and (3), and good to allow running programs this way without having to set them up, but also allowing quick double-click launching for frequently used programs.

I'm thinking, that the first time, an app is launched with a right-click. It would attempt to parse the help text and auto-generate the dialog. There would then need to be an extra configuration button in the corner that would allow customization (modifying the GUISpec, or some more GUI-like method). There could also be the option to create a quick-launch shortcut. If an app had previously been configured, right clicking and launching would automatically used the stored GUISpec.

I think the auto-parsing is an enhancement, not a replacement for your GUISpec. I'm guessing that best case it might work tolerably well on 50% of existing programs.

And of course you could create a library of GUISpec for popular apps, and app authors could release theirs with GUISpecs if they wanted.
-- scad mientist, Jul 29 2014


Would it be wise to centralized 'GUISpec' (as a fallback if there is no local GUISpec?) online?

If so, how do we ID which GUISpec to use with which program. Can I just use the filename?

(What I'm thinking, is a wiki that the GUIGenerator can read and grab any GUISpec that matches the file name of the program)
-- Akimbomidget, Jul 29 2014


Sorry, did I hear people talking about the “command line” and “Windows” in the same context? Windows has no command line.
-- ytk, Jul 29 2014


//I would envision it to be more like making a HTML page// See this I think is the resolution to the problem, right there. You can write python to read inputs and generate text output - so why not tweak it to read in HTLM POST inputs, and send the output into an html page format that can be presented by your web server. OK, so it means configuring a web-server but most computers/oses these days come with a mini apache up and running for free - or perhaps turn-onnable with not too much effort. Get python included into your cgi-bin and you'll be creating distributable GUIs before you know it. Handsome.
-- zen_tom, Jul 29 2014


If you have a centralized location for 4th party GUISpecs, be sure to watch out for malicious ones. Those would need to be keyed off of filename and a checksum or hash. If there's no exact match, allow the user to test using one with the same filename in cases there was a minor revision change that didn't change the parameters.
-- scad mientist, Jul 29 2014


[YTK] what are you talking about. A quick search seems to indicate that they have made a nominal effort to hide the command prompt in Windows 8, but it is still there. Or are you claiming that cmd.exe does not qualify as a "REAL" command prompt?
-- scad mientist, Jul 29 2014


Is it just me or does windows 8 seem eerily a lot like 3.1?
-- RayfordSteele, Jul 29 2014


//Is it just me or does windows 8 seem eerily a lot like 3.1?//

I don't think so, Windows 3.1 was a resounding success with lots of interest from the business community, so much so that Windows became the de-facto desktop environment across most of the world for pretty much an entire generation. Windows 8 is geared towards confusing your Gran.
-- zen_tom, Jul 29 2014


I am aware of the existence of CMD.EXE. I repeat: Windows has no command line.

CMD.EXE is a tool used to practice the skill of shouting monosyllabic grunts to a brain-damaged chimpanzee at the top of your lungs.
-- ytk, Jul 29 2014


//windows has no command line
Next thing you'll be saying that the computer is not inside the display.
-- pashute, Jul 29 2014


Additional benefits of this approach beyond Simple GUI.

By providing a standard way to define possible valid input, and outputs. This also provides an opportunity to create a visual environment, where you can chain different programs together in a visual manner (As the input and output are well defined). Think of it as an API of sort.
-- mofosyne, Aug 03 2014



random, halfbakery