Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature] wxCatapult: assorted general FR [sf#253] #5

Open
openMSX-import opened this issue Jun 24, 2015 · 3 comments
Open

[Feature] wxCatapult: assorted general FR [sf#253] #5

openMSX-import opened this issue Jun 24, 2015 · 3 comments

Comments

@openMSX-import
Copy link

Reported by joxy on 2013-08-02 06:32 UTC
(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

@openMSX-import
Copy link
Author

Commented by joxy on 2013-08-02 06:50 UTC
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.

@openMSX-import
Copy link
Author

Commented by joxy on 2013-08-02 07:14 UTC
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.

@openMSX-import
Copy link
Author

Commented by joxy on 2013-08-02 10:21 UTC
(low priority) currently all wxString parameters are passed by value,
in many cases it's better to instead pass 'const wxString&' parameters.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant