PFGW 3.8.3 (with gwnum v28.7) Released - Page 33

paulunderwood · 2019-03-23, 06:15

Not having a GUI would teach people who did not already know to use CLI how to do so.

a1call · 2019-03-23, 13:49

Not using GUI. Running multiple instances from batch files works very well.
I work on Windows though. That is much more convenient than virtual boxes of Ubuntu.

rogue · 2019-03-23, 14:20

Quote:

Originally Posted by paulunderwood

Not having a GUI would teach people who did not already know to use CLI how to do so.

I honestly can't tell if you are being sarcastic. My query was sincere. I used to use the GUI, but haven't done so in years and I have no data on how people use the software. Removing the GUI components would be far easier then building a new GUI from a different tech stack. The pfgw code base that I inherited is a complete mess and writing a new GUI will likely require a lot of refactoring of the existing code.

It might be feasible to write something in Java that hides the command line input and output. That would be portable to other platforms and would not be linked with the pfgw executable. It would just need to reside in the same folder as pfgw. That would probably be easier to maintain, but I don't know how easy it would be.

Thoughts?

Puzzle-Peter · 2019-03-23, 19:59

Ich have used the GUI in the past, but I am just as happy using the command line. Which is what I am doing exclusively nowadays. Starting several instances from scripts is just much more convenient. So ditch the GUI If it makes your work easier. Speaking of it - thanks for all the work you are putting into this.

henryzz · 2019-03-23, 20:22

It strikes me that it might be easier to have a completely separate gui that calls the program itself. A language that easily does forms could be used such as c#.

paulunderwood · 2019-03-23, 21:10

Quote:

Originally Posted by rogue

I honestly can't tell if you are being sarcastic. My query was sincere. I used to use the GUI, but haven't done so in years and I have no data on how people use the software. Removing the GUI components would be far easier then building a new GUI from a different tech stack. The pfgw code base that I inherited is a complete mess and writing a new GUI will likely require a lot of refactoring of the existing code.

It might be feasible to write something in Java that hides the command line input and output. That would be portable to other platforms and would not be linked with the pfgw executable. It would just need to reside in the same folder as pfgw. That would probably be easier to maintain, but I don't know how easy it would be.

Thoughts?

Having a Java GUI with all the switches available would be cool. (I don't know how to program Java.)

Gui-less PFGW for people who use the current GUI, would an easier lesson than the transition from Chris Nash's PrimeForm to the Woltman library based one i.e PFGW. A slight modification to the documentation to say "use ./pfgw64 in front of the switches" described in the pfgwdoc.txt file should allow you to drop the GUI (unless some does the Java wrapper) and to concentrate on some of the more important development.

Prime95 · 2019-03-24, 00:19

If you build a new PFGW please do not release until 29.7 is ready.

rogue · 2019-03-24, 00:56

Quote:

Originally Posted by Prime95

If you build a new PFGW please do not release until 29.7 is ready.

It will be a while since I have to migrate the solution and rebuild the projects. I'll be in Calgary for two weeks during April and not being home should give me more time to work on it. The next release will not have a GUI as that will take even more time for me to get that done.

BotXXX · 2019-03-25, 19:31

I actually use the GUI (on Windows), however can use the CLI with the same easiness. So for me dropping the GUI is no problem, i will switch to CLI.

That said, I would refrain from putting (too much or any?) effort in building a Java GUI. At least on Windows systems Java (either old legacy Sun or Oracle or OpenJDK version) is frowned upon. It is not a popular framework on machines where there is no requirement by the "main" software running on the machine. I am not sure how popular Java is on Linux/Mac/BSD servers where people would be running their applications. To require a JRE just to run one GUI is overkill in most cases. And maybe not worth the effort to invest in building the GUI while (most) people will use the CLI anyway.

Super for the continued efforts on maintaining the code!

rogue · 2019-03-27, 20:51

The good news is that I figured out why VS 2017 wouldn't import the project. The bad news is that I have to make a number of changes to address differences between the two versions of the compiler.

rogue · 2019-03-28, 14:22

I have been able to work thru the compiler issues, but neither the command line or GUI version link. These issues are proving much more difficult to resolve because many seem to be driven by the compiler options I've used and if I change those, I get completely different errors that are just as difficult to resolve.

2019-03-23, 13:49	#354
a1call "Rashid Naimi" Oct 2015 Remote to Here/There 3×5×137 Posts	Not using GUI. Running multiple instances from batch files works very well. I work on Windows though. That is much more convenient than virtual boxes of Ubuntu. Last fiddled with by a1call on 2019-03-23 at 13:53

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
A possible bug in LLR/PFGW while using GWNUM (no bug in P95)	Batalov	Software	77	2015-04-14 09:01
PFGW 3.2.0 has been Released	rogue	Software	94	2010-09-14 21:39
PFGW 3.2.3 has been Released	rogue	Software	10	2009-10-28 07:07
PFGW 3.2.2 has been Released	rogue	Software	20	2009-08-23 12:14
PFGW 3.2.1 has been released	rogue	Software	5	2009-08-10 01:43

2019-03-23, 06:15	#353
paulunderwood Sep 2002 Database er0rr 111010011011₂ Posts	Not having a GUI would teach people who did not already know to use CLI how to do so.

2019-03-23, 19:59	#356
Puzzle-Peter Jun 2009 2AC₁₆ Posts	Ich have used the GUI in the past, but I am just as happy using the command line. Which is what I am doing exclusively nowadays. Starting several instances from scripts is just much more convenient. So ditch the GUI If it makes your work easier. Speaking of it - thanks for all the work you are putting into this.

2019-03-23, 20:22	#357
henryzz Just call me Henry "David" Sep 2007 Cambridge (GMT/BST) 2³×3×5×7² Posts	It strikes me that it might be easier to have a completely separate gui that calls the program itself. A language that easily does forms could be used such as c#.

2019-03-24, 00:19	#359
Prime95 P90 years forever! Aug 2002 Yeehaw, FL 2·53·71 Posts	If you build a new PFGW please do not release until 29.7 is ready.

2019-03-25, 19:31	#361
BotXXX Aug 2003 Europe 302₈ Posts	I actually use the GUI (on Windows), however can use the CLI with the same easiness. So for me dropping the GUI is no problem, i will switch to CLI. That said, I would refrain from putting (too much or any?) effort in building a Java GUI. At least on Windows systems Java (either old legacy Sun or Oracle or OpenJDK version) is frowned upon. It is not a popular framework on machines where there is no requirement by the "main" software running on the machine. I am not sure how popular Java is on Linux/Mac/BSD servers where people would be running their applications. To require a JRE just to run one GUI is overkill in most cases. And maybe not worth the effort to invest in building the GUI while (most) people will use the CLI anyway. Super for the continued efforts on maintaining the code!

2019-03-27, 20:51	#362
rogue "Mark" Apr 2003 Between here and the 11×577 Posts	The good news is that I figured out why VS 2017 wouldn't import the project. The bad news is that I have to make a number of changes to address differences between the two versions of the compiler.

2019-03-28, 14:22	#363
rogue "Mark" Apr 2003 Between here and the 18CB₁₆ Posts	I have been able to work thru the compiler issues, but neither the command line or GUI version link. These issues are proving much more difficult to resolve because many seem to be driven by the compiler options I've used and if I change those, I get completely different errors that are just as difficult to resolve.