Fewer Excuses for making Text-only Programs

[VicVergil]

Text-only programs are easy to use. There's no excuse not to make a bit of effort to learn how to.
Let's say you have a command-line tool you want to run.

For example, CUE's RSEARCH.
According to its documentation, and trying to run it the wrong way, the usage is something like this:
RSEARCH filename text [min [max [inc]]]
Since min, max, inc are optional, we'll do without them, and then you have just one argument (text).

This tool analyses a text file and generates a table file.
Let's call it text.txt for this example. That's what filename is supposed to stand for.
To make things simple, we'll have it in the same folder as the tool.

Method 1: Learn how to use the Command Prompt

Press Windows+R, type cmd and confirm.
The scary black Command Prompt window will appear.
Type this: CD "C:\etc\caetera\Folder_Where_Tool_is" /D and press Enter.
You may not even have to do this step, just right-click on the folder where the tool is, while holding Shift, and the contextual menu will have "Open Command Prompt Here".

Now type the tool's name. For example here: RSEARCH.EXE
It's probably not the correct way to use it.
The tool's author will have some extensive help here usually about how to use it.
That's where I got the usage tips above from.

Now in the command prompt type this: RSEARCH text.txt
And that should be it. Really.

Method 2: Batch files
Open Notepad, and write this:

RSEARCH text.txt
pause

Save this text file with the extension bat in the same folder as the tool and the text file.

Now double-click that bat file. That's it.

Method 3: Console Compromise
A tool that can be downloaded from https://www.romhacking.net/utilities/1284/.
You get to use any command-line tool as a GUI tool, even though it's a bit pointless.
You pass the path for the application, and the arguments (here it's just filename).

Method 4: Drag-and-drop
If it's a simple tool, sometimes dragging the file to be converted on top of the tool's executable is enough. For example, the UNECM tool to decompress some PS1 scene releases.
Unfortunately, you'll miss any messages displayed by the process, errors or information, because it will close immediately whenever it's done. That's how it is with every modern day Windows OS. But sometimes this is good enough.

If there's a will, there's a way.

I used to hate command-line, but realized they're much more preferable to GUI tools, especially for operations that need to be repeated for hundreds of files (text insertion with Atlas for multiple files, with multiple insertion methods, or mass converting graphical files) and this would mean clicking hundreds of times on a button instead of copy-pasting a line in the batch file and running that once.

Making a GUI is extra work. You do realize that people making tools code them just enough for their personal use to do the job, and then share it if they feel like it? Sometimes it's not even a proper program, but a bmg script. If it's good enough to do the job, why bother adding a GUI that wouldn't be needed in many cases at best, and a hindrance at worst.

That said, there are some tools that could benefit from a GUI, like the aforementioned RSEARCH which is superior in every other way to monkeymoore but could use some GUI options to make copy-pasting text, writing Japanese text, and editing table files on the fly possible, as well as better logging for the search process. Same goes for many MTE dictionnary optimisation/generation tools. These kind of tools need that visual feedback.
On the other hand, conversion tools, compression tools (which you need the offset for the data to use anyways), etc... these definitely don't need the extra development time on just one simple yet time-consuming GUI with "Select File" and "Convert".
LunarIPS is one such GUI, but that was done to cater to the needs of the general consumer, and even that one has had its later versions move on from that GUI to just directly selecting the files.

[Jorpho]

So now that your problem has been revealed to be Lunar Compress, feel free to download the DLL version, wrap it around your GUI using Visual Studio and amuse us with how easy it will work out!

Heck, if making a GUI is so easy, one can just throw together some frontend that will execute the relevant shell commands using the command-line version.

[flame]

Method 1: Learn how to use the Command Prompt

Press Windows+R, type cmd and confirm.
The scary black Command Prompt window will appear.
Type this: CD "C:\etc\caetera\Folder_Where_Tool_is" /D and press Enter.
You may not even have to do this step, just right-click on the folder where the tool is, while holding Shift, and the contextual menu will have "Open Command Prompt Here".

Now type the tool's name. For example here: RSEARCH.EXE
It's probably not the correct way to use it.
The tool's author will have some extensive help here usually about how to use it.
That's where I got the usage tips above from.

Now in the command prompt type this: RSEARCH text.txt
And that should be it. Really.

GHANMI, really, people are having to:
1) Type xdelta -?, read what it says, understand what it means (difficult even for me) and then:
2) Type something like: xdelta.exe -9 -S djw -B 1812725760 -e -vfs "old.iso" "new.iso" "SERIAL_Old-CRC_to_New-CRC.xdelta3″

That's out of range of most people, hence xdelta UI tool (a GUI wrapper for xdelta)

A lot of tools are more simple than that and are perfectly usable on the command line for most people, but not that one.

[Disch]

Rules of thumb:

It should NOT be a console program if....

- It needs to prompt users for input    (command line args are not a prompt)
OR
- It, at any point, for any reason, pauses
OR
- It needs to draw graphics that are more complex than basic rectangular shapes

It's OKAY to be a console program if....

- It's a "take some file(s), so something with them, and exit" program
AND
- Its options are relatively simple and straightforward.

It SHOULD be a console program if...

- It's a "take some file(s), so something with them, and exit" program
AND
- Its options are extremely complicated


========================

The last two might seem backwards, but they make sense under the assumption that a complex program will have a separate program that will interface with it (see:  just about any compiler in existence).  You don't want an IDE and a Compiler to be the same program -- they should be separate.

On the other hand... something like a patcher can operate well as a commandline driven program, but since the GUI would basic, it could fall back to a GUI if no commandline args are given.



The entire advantage to console programs is they're fast, lightweight --- and most importantly, scriptable.  Someone should be able to make a script file that takes their ROM, make an xdelta patch from it, then zips it with a readme file -- so that task can be accomplished with a single keystroke.  You can't do that if the patcher forces you to use a GUI -- or if it pauses to prevent the console window from closing immediately after you use it.

[VicVergil]

GHANMI, really, people are having to:
1) Type xdelta -?, read what it says, understand what it means (difficult even for me) and then:
2) Type something like: xdelta.exe -9 -S djw -B 1812725760 -e -vfs "old.iso" "new.iso" "SERIAL_Old-CRC_to_New-CRC.xdelta3″

That's out of range of most people, hence xdelta UI tool (a GUI wrapper for xdelta)

A lot of tools are more simple than that and are perfectly usable on the command line for most people, but not that one.

That's one example of a tool that would benefit from a GUI (ideally not a wrapper, but included in the program proper like it's the case with its recent versions). For two reasons at the very least:

1 - the target audience:
Most people using this patch just want to
a) use a patch
b) on the original game, and then the tool does the rest.

LunarIPS is ideal in that regard, it associates all ips file extensions (and I think another tool does that for ips AND bps), so that you just double-click the patch, the tools asks you to find the original ROM is with the file explorer, then asks you where to save the new ROM. And that's it.
Something like that for xdelta could be all what's needed. Maybe just an error message for CRC mismatching written in a more helpful way ("This xdelta patch probably wasn't intended for this file. This patch was designed for [ROM name from optional comment field in xdelta/ips specifications]. Do you want to force patch the game anyways? (Not recommended)") and that's it. The more elaborate GUI could be useful for creating patches.

2 - the complicated arguments:
If arguments are so long, why not simply use a configuration file?
Like with Cartographer. You can edit that config file in Notepad and it would even have comments on what each parameter does, and recommended values.

Also, xdelta is both a tool to apply the patches and a tool to create them, and you choose between both with a parameter, further complicating the syntax.
Why not make TWO separate executables each with a much simpler syntax?

Ideally, the configuration file itself would be an optional argument, as the tool would use a specific config file by default.
If xdelta UI didn't exist, this way making an xdelta command line tool where you just drag and drop a folder (with the original ROM and the patch) onto xdelta would just generate the new ROM automatically.

[BlackDog61]

I love Starwin's answer!
GUI's are NOT easy to do in a right and useful way. If they are easy for you to do, you're probably not giving a damn about ergonomy.
I have all of my tools in command line EXCEPT the story editor, because I thought a graphical representation of the flow of dialog with character portraits, like it appears in game, would help the translator feel "inside" the story. For that tool, I knewthefile format by heart, and yet it took 50+ hours to get the GUI to do what it should the way it should. And there are still a lot of things that could / should be added (there's not even a search).
Of course you can go ahead saying I'm slow. But I care for my users  (well, 2 users in this case).
Bottom line: programin a cost-effective way, 'cause your time for the hobby is ata premium if you're contributing. Thus command lines most of the time, GUI's where absolutely needed. If you can't run it, you're probably not supposed to.

[KingMike]

Yep, most of my tools are made for my use. I don't want to spend a time making a GUI I don't really need, so I don't.
Although I add a prompt in my program for file and such instead of command line because I don't feel like writing the extra steps to parse the command file. Since again, I write them primarily for my own use.

If it's something I share, that's a bonus.
If you don't like how I share my personal work, then you're free to redo all the work on your own.

[Chronosplit]

Wait--OP wasn't pure sarcasm?

I was wondering that myself.

Mednafen?  Does that have a GUI yet?  I haven't used it in years -- mainly for this reason.

Using Mednafen cores in RetroArch/OpenEmu/probably every PCE emu for mobile counts, I guess.

I believe there are launchers for Mednafen itself now however.

[Klarth]

The excuse is time. Sure, a GUI for a commandline program that takes very few parameters and is a single step workflow (ie. no further input necessary) is typically easy enough. But in many cases, GUI dev could account for half (or more) of the total dev time. Plus, GUI dev is its own skill with yet another learning curve.

I could have made a fully-fledged GUI for Atlas, but the amount of time to make a worthwhile GUI could have easily dwarfed the dev time for program itself. Text insertion is something you do many, many times while fixing bugs and testing so most users would prefer just creating a .bat file or adding it to their build file. My audience is not first-time users with low technical knowledge. You need to read the manual to even get started.

Conversely, TileShop has a massive amount of GUI functionality necessary to make the editing process both seamless and accessible to non-technical users. The amount of GUI dev time is far more (and still growing) than what was required for the behind-the-scenes code that actually does the work. Stylistically, I still do wish I put the core functionality into its own isolated language and executed commands via the GUI instead of having the GUI coupled to core functionality. I might still do that, but time is always a huge factor for me.

[furrykef]

How would you use a GUI program in a shell script (batch file)?

And yes, you can make a GUI program that accepts arguments on the command prompt and try to get the best of both worlds, but now your program has two different user interfaces.

[pianohombre]

I don't see what all the big fuss is about. I never had much trouble creating GUI, at least in programs using C++ and Java. You can just drag and drop menu items in some of the more popular compilers. Sure, if it only does a few things no biggie, but I mean is it really that much extra work?

[hanhnn]

I don't see what all the big fuss is about. I never had much trouble creating GUI, at least in programs using C++ and Java. You can just drag and drop menu items in some of the more popular compilers. Sure, if it only does a few things no biggie, but I mean is it really that much extra work?

Most of the tools here are open source.
If you think it is an easy task, why not do it yourself and show it to us.

[pianohombre]

This post was more a rant & rave than a post about how I'm going to try and fix the rom-hacking archives.

[BlackDog61]

This post was more a rant & rave than a post about how I'm going to try and fix the rom-hacking archives.

that's the same as saying you could make it a useful topic, but you don't want to.