Author Topic: WinAGI: feature request - batch mode  (Read 5819 times)

0 Members and 1 Guest are viewing this topic.

Offline ZvikaZ

WinAGI: feature request - batch mode
« on: February 12, 2021, 02:46:47 AM »
(is it the correct place for feature requests? do you prefer single thread for each feature request?)

It'd be great if it was possible to run WinAGI in batch mode - i.e., from the command line, without GUI (like 'gcc', or other compilers).

Motivation:
I've started work on Hebrew translation for PQ1. My previous project was Hebrew translation for SQ3. In that project, I've exported all textual resources to an excel file, uploaded it to Google Drive, and then shared it with a team of volunteers. The translation, and discussions, were done on Google Drive. Then I had scripts that downloaded everything from the drive, made required changes, [compiled everything with SciCompanion (*)], and created zip file ready for distribution.

(*) I've written [compiled] in brackets, because that step couldn't be done automatically, as SciCompanion doesn't have batch mode. Thus, this step needed manual intervention.

I plan similar flow for PQ1, and it'd be great if WinAGI could be run from a script, without GUI.

I assume that for the current version, it'd be quite difficult to achieve, but please take this into account for your new C# version design.



Offline AGKorson

Re: WinAGI: feature request - batch mode
« Reply #1 on: February 12, 2021, 03:48:24 PM »
This is probably the best place to make feature requests! Separate threads works for me, unless the requests are closely related.

Regarding batch mode, I can easily add command line switch options ( '/c' for a full compile; '/r' for rebuild VOL, '/d' for compile dirty logics) along with a wag file name that will run the compiler when WinAGI starts. Probably can't make it completely GUI free, as I'd have a lot of things to unhook from the compile functions. But I could make the GUI disappear immediately after running.

Would that work for you? Are there any other switches/functions you think you might need?

Offline Kawa

Re: WinAGI: feature request - batch mode
« Reply #2 on: February 12, 2021, 06:53:26 PM »
Probably can't make it completely GUI free, as I'd have a lot of things to unhook from the compile functions.
... suddenly I understand what's the big frikkin deal with recent, more "modern" UI development paradigms. I need a drink.

Offline AGKorson

Re: WinAGI: feature request - batch mode
« Reply #3 on: February 12, 2021, 10:00:20 PM »
Probably can't make it completely GUI free, as I'd have a lot of things to unhook from the compile functions.
... suddenly I understand what's the big frikkin deal with recent, more "modern" UI development paradigms. I need a drink.
I don't know how to read this. All I was saying is that the main functions for opening and compiling games currently provide feedback in the form of progress windows, status bars, and message boxes. I'd have to deal with all of these to go sans-GUI. It's not difficult, but it will take some time that I'd rather spend on something else.

Is that an example of a "modern" UI development paradigm? Why is that bad?

Offline Kawa

Re: WinAGI: feature request - batch mode
« Reply #4 on: February 13, 2021, 11:19:47 AM »
<lecture mode>

In classic Visual Basic and C# WinForms alike, you usually think in terms of "this is the user interface, when you click this button you run this event". "If the textbox has a selection, enable the Copy and Cut menu items". "Here's a window to create a new project, we actually do the creation thing when you click OK".

In the cut/copy example, imagine you have an Edit menu, toolbar, and a context menu. In your check to enable the cut/copy/paste commands you'd have to alter three separate controls for just the one operation. In the "new project" example, you can't run automated tests, or have a command line hook without either duplicating things or flashing the window on-screen.

With "modern" paradigms, the Cut menu item, toolbar button, and context item are each bound to the same single command, and you can just say "set the Cut command's availability to true if there's a selection". All three items automatically reflect that state, and they all execute the same code when clicked not because they have the same event handler, but because they have the same command. That's basically what WPF applications are like.

The "new project" thing could be done "better" in classic VB or WinForms by having a single "create new project" method/function that's not itself part of the "New Project" form but is called from that form. Or from the command line handler when it finds a "/new" argument. Or from an automated testing rig. Or gods forbid a Python binding. Either way there's a single piece of "create new project" code that all three entry points may use.

</lecture mode>

And I didn't understand the big frikkin deal until this week. Your comment on making it "completely GUI free" helped what I'd read before snap into place. So thank you for that.

Offline ZvikaZ

Re: WinAGI: feature request - batch mode
« Reply #5 on: February 13, 2021, 01:33:35 PM »
This is probably the best place to make feature requests! Separate threads works for me, unless the requests are closely related.

Regarding batch mode, I can easily add command line switch options ( '/c' for a full compile; '/r' for rebuild VOL, '/d' for compile dirty logics) along with a wag file name that will run the compiler when WinAGI starts. Probably can't make it completely GUI free, as I'd have a lot of things to unhook from the compile functions. But I could make the GUI disappear immediately after running.

Would that work for you? Are there any other switches/functions you think you might need?

Sounds great.
Maybe also an option to compile a single logic file?
On later phase, it might be nice to add also a possibility to "import Game" from command line.

Perhaps I will think of few more functions in the future...

Offline ZvikaZ

Re: WinAGI: feature request - batch mode
« Reply #6 on: February 13, 2021, 01:36:24 PM »
<lecture mode>

In classic Visual Basic and C# WinForms alike, you usually think in terms of "this is the user interface, when you click this button you run this event". "If the textbox has a selection, enable the Copy and Cut menu items". "Here's a window to create a new project, we actually do the creation thing when you click OK".

In the cut/copy example, imagine you have an Edit menu, toolbar, and a context menu. In your check to enable the cut/copy/paste commands you'd have to alter three separate controls for just the one operation. In the "new project" example, you can't run automated tests, or have a command line hook without either duplicating things or flashing the window on-screen.

With "modern" paradigms, the Cut menu item, toolbar button, and context item are each bound to the same single command, and you can just say "set the Cut command's availability to true if there's a selection". All three items automatically reflect that state, and they all execute the same code when clicked not because they have the same event handler, but because they have the same command. That's basically what WPF applications are like.

The "new project" thing could be done "better" in classic VB or WinForms by having a single "create new project" method/function that's not itself part of the "New Project" form but is called from that form. Or from the command line handler when it finds a "/new" argument. Or from an automated testing rig. Or gods forbid a Python binding. Either way there's a single piece of "create new project" code that all three entry points may use.

</lecture mode>

And I didn't understand the big frikkin deal until this week. Your comment on making it "completely GUI free" helped what I'd read before snap into place. So thank you for that.

I read once someone (forgot who...) that said that Windows programmers first build a GUI, and then implement its functionality; while Linux programmers first implement the functionality, and then (perhaps) attach it to GUI.
@Kawa, the two paradigms that you wrote seems "Windows" to me, while I think in "Linux" terms...

Offline Kawa

Re: WinAGI: feature request - batch mode
« Reply #7 on: February 13, 2021, 03:45:42 PM »
I read once someone (forgot who...) that said that Windows programmers first build a GUI, and then implement its functionality; while Linux programmers first implement the functionality, and then (perhaps) attach it to GUI.
@Kawa, the two paradigms that you wrote seems "Windows" to me, while I think in "Linux" terms...
You're not wrong, I guess.

Offline lskovlun

Re: WinAGI: feature request - batch mode
« Reply #8 on: February 13, 2021, 04:18:55 PM »
I read once someone (forgot who...) that said that Windows programmers first build a GUI, and then implement its functionality; while Linux programmers first implement the functionality, and then (perhaps) attach it to GUI.
@Kawa, the two paradigms that you wrote seems "Windows" to me, while I think in "Linux" terms...
You're not wrong, I guess.
And in DOS, both approaches are valid.

Offline Kawa

Re: WinAGI: feature request - batch mode
« Reply #9 on: February 14, 2021, 04:41:08 AM »
And in DOS, both approaches are valid.
To be fair, you don't generally have a GUI in DOS. Fun unrelated fact, QBASIC's user interface is written as if it runs on Windows, even though it's very much a DOS application. You figure out how that works... or how I know this.

Offline Collector

Re: WinAGI: feature request - batch mode
« Reply #10 on: February 14, 2021, 07:21:02 PM »
The "new project" thing could be done "better" in classic VB or WinForms by having a single "create new project" method/function that's not itself part of the "New Project" form but is called from that form.

That is how I have tended to write my programs for the past several years. Makes it easier and faster to write it just once in a separate class or at least separate method that can be called from whatever button click, menu selection, command line argument, etc.
KQII Remake Pic

Offline Kawa

Re: WinAGI: feature request - batch mode
« Reply #11 on: February 14, 2021, 07:42:28 PM »
Right? The event model just seems to invite making the "actually create project" code a part of the form like goto allegedly invites spaghetti.

So hey, good on you. I ought to get over it and learn to do similar.

Offline ZvikaZ

Re: WinAGI: feature request - batch mode
« Reply #12 on: February 15, 2021, 05:22:13 AM »
Thanks for the quick implementation of the new feature!

However, I'm not sure that I understand how to use it.

I've run
Code: [Select]
"C:\Program Files (x86)\WinAGI GDS\WinAGI.exe" /d "C:\Zvika\Games\Police Quest\AGI\PQ1.wag"

And WinAGI just opens, and closed, without anything happening.
How can I compile the dirty logic files?

(I have later opened the GUI, and compiled the dirty logic files from there, just to make sure that there were indeed file recognized as dirty)

Also, is it possible to write some log file, that I can check from the script what happened, what files compiled, which errors and warnings were issued?

Thanks



Offline AGKorson

Re: WinAGI: feature request - batch mode
« Reply #13 on: February 15, 2021, 01:52:38 PM »
It only gives you a message if it encounters an error. if you don't get any error message, then you know it compiled correctly.

This was the easiest way to implement the feature. Adding a logging feature would require more work than I currently have time for. I might take a look at it later, but I can't make any promises as to when.


Offline Collector

Re: WinAGI: feature request - batch mode
« Reply #14 on: February 15, 2021, 07:27:50 PM »
Possibly something to implement with your C# version, instead?
KQII Remake Pic


SMF 2.0.19 | SMF © 2021, Simple Machines
Simple Audio Video Embedder

Page created in 0.075 seconds with 22 queries.