#253 wxCatapult: assorted general FR

(14:06:25) egp_1: Vampier_: promise... i mainly promised to maintain wxcatapult
(14:06:34) egp_1: Vampier_: no other promises
(14:07:52) Vampier_: egp_1: well that sucks
(14:08:01) egp_1: Vampier_: what sucks?
(14:08:08) Vampier_: I think we're all under the impression you are going to change catapult and make it better
(14:08:53) egp_1: Vampier_: I am myself under this impression =) I prefer slow coding esp. noting that I don't know C++ standards
(14:10:11) egp_1: I am studying that stuff
(14:10:17) egp_1: C++ standards
(14:10:22) egp_1: slowly
(14:10:29) Vampier_: well... then don't study catapult
(14:10:30) Vampier_: :D
(14:10:31) Vampier_: lol
(14:10:44) ***BiFi hopes this maintenance will include adding access to the newly added settings and other features since major updating has stopped
(14:11:01) egp_1: BiFi: sure
(14:11:43) egp_1: BiFi: that is planned. But first I need to fix existing bugs
(14:12:54) Vampier_: egp_1: the code needs an overhaul
(14:13:03) Vampier_: a serious overhaul
(14:13:18) Vampier_: wouter is already starting with this
(14:13:27) Vampier_: making it more up-to-standard
(14:13:27) egp_1: first, bugfixes. Then, the overhaul
(14:13:35) Vampier_: lol
(14:13:42) Vampier_: how about both at the same time?
(14:14:31) egp_1: Vampier_: that is unmanageable method
(14:14:38) egp_1: I prefer step by step
(14:15:42) egp_1: "At the same time" is uncontrollable. I fail to track all code leads in my memory.
(14:17:36) Vampier_: I think we should have 1) control module 2) communication model 3) GUI model
(14:18:03) Vampier_: one of the most important feature requests is probably for the disk manipulator
(14:18:13) Vampier_: creating harddisks
(14:18:17) Vampier_: filling harddisks
(14:18:21) Vampier_: etc etc
(14:18:58) egp_1: As in virtualbox, for example...
(14:19:36) Vampier_: no
(14:19:40) Vampier_: diskmanipulator
(14:19:47) Vampier_: openMSX already has it build in
(14:19:54) egp_1: yup, i forgot
(14:20:20) egp_1: I will file this log as a general FR
(14:21:28) egp_1: And file BiFi's hopes, too, there
(14:26:30) Vampier_: egp_1: https://www.youtube.com/watch?v=It-UE97uTFw
(14:26:31) Vampier_: check this
(14:27:28) BiFi: it's a good idea to have some graphical user interfacing for the diskmanipulator
(14:28:18) BiFi: from my old sources I noticed I had to add elements manually in 2 places which should be filled automatically: romtypes and pluggables
(14:30:37) Vampier_: the cheatfinder and color changer are not as cool
(14:30:44) Vampier_: but at the time they certainly where cool

[Anonymous]

Wouter writes:
If you're looking for additional work, then you can consider adding
support for new features in catapult. Since the time wxcatapult development stalled, openMSX itself has gained a bunch of new features. For example savestates and replays. But check the release notes (or commit log) for a full list. I don't know how to add all those features in catapult without cluttering the interface too much.

[Anonymous]

Wouter writes:

BTW2: Some more background info (very much over-simplified):

wxcatapult: GUI is very static, e.g.always shows 2 disk drives,
whether the actual
msx machine has 0, 1, 2 (or even more) diskdrives

qt-catapult: the GUI is much more dynamic: e.g. you select a msx machine without
disk-drives ->GUI won't show disk selection. You then insert a
disk-drive extension
-> GUI will dynamically add disk selection. Though because openmsx and catapult
run in a separate process and the communication between both is asynchronous,
this makes some (conceptually easy) things rather complex.

Manuel writes:

I really recommend you to try the Qt based Catapult. It gives a clear idea on what we actually intended for such a type of launcher.

You can run it with PyQt, under Linux it's easiest to try.

Code is here: https://sourceforge.net/p/openmsx/catapult/ci/master/tree/

Even if it' may not be the ideal GUI.

egp_: We could make it ideal.

The Qt based Catapult was an attempt to make it ideal :P
It uses communication with openMSX for everything, while the old wxCatapult only does this very limitedly and mostly relies on commandline arguments, including duplicating knowledge of openMSX in itself and having a very complex start up of openMSX.

egp_ writes:

Wouter writes:

BTW2: Some more background info (very much over-simplified):

wxcatapult: GUI is very static, e.g.always shows 2 disk drives,
whether the actual
msx machine has 0, 1, 2 (or even more) diskdrives

This could easily be a feature request. (1)

qt-catapult: the GUI is much more dynamic: e.g. you select a msx machine without
disk-drives ->GUI won't show disk selection. You then insert a
disk-drive extension
-> GUI will dynamically add disk selection.

This should be implemented within (1) above.

[Anonymous]

(low priority) currently all wxString parameters are passed by value,
in many cases it's better to instead pass 'const wxString&' parameters.