Seen the huge amount of options (--enable-lots-of-things) it would be nice a very small gui (maybe written in wxpython) with many checkbox with all the --enable-* and some radio button for the graphical libraries (X, wx, etc...)
It would be nice to have a cross-platform tool similar to QemuManager (see for reference: http://www.davereyn.co.uk/download.htm). The tool should have similar GUI capabilities and write .bocshrc to be used with Bochs.
The tool is not required to be part of Bochs binary, in fact it could be written on any language, for example on Java and this way to work on all platforms including cellphones. It will control bximage (to create new images) and write .bochsrc; the simulation thus could be run with double-click on .bochsrc in windows.
It also could have another advantage - current configurable GUI might be deprecated and cleaned from the code :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A bochsrc creation tool for Windows has been wriiten by Ben Lunt, but it's outdated now. The bximage/bxcommit stuff should be extended and moved into one binary. The configurable gui will never be deprecated since we always need the runtime configuration. Removing the start menu only doesn't make sense to me.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just install and run QemuManager and see how the GUI for configuring .bochsrc should look like. I don't know how to explain it exactly, just run and see.
It should be ... trivial for user ti use.
Might be you will be inspired to improve automatic .bochsrc generation menus as well.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The reason why third party GUI tools become obsolete is because it's always a catch up, then things get changed in bochs and the GUI breaks.
The problem is bochs itself.
It can be solved, but to solve this, bochs needs some sort of property tree anouncing provider that tells the GUI via a standardized messaging system what bochs can do and what modules it does offer to load and which module depends on which other module.
This messaging could be done as json text output with a version number for each specific item and a key value pair and information about allowed values. Plus a comment value in each language. The comment describes the specific key item.
And if a language is missing, there is a fallback to an English comment.
By doing so, the 3rd Party GUI program could first start and run bochs, then bochs starts it property tree announcing provider and sends via a json message to the GUI client what bochs does offer as key=value/options pairs. After that, it changes into a state for accepting new property queries.
Then the GUI can parse that versioned json message and generate a gui according to the information it got from bochs json message.
Then the GUI user can set up the available settings. The new settings which were set by the user then get sent to bochs again via a json message. Bochs interprets it and sets bochs in the requested state.
And if everything is done, the GUI can send a json message to run bochs with this state.
Because the GUI now knows what sort of key expects which kind of value, the GUI can draw checkboxes, radiobuttons and so on based on this information.
Plus a description what this feature does. Because the description is derived from the comment that was additionally sent by the json message from Bochs for each key=value item.
And the version for each module or item will make sure, that the GUI can be easily adapted to new changes.
This way, the GUI can stay easily consistent and up to date with bochs' development.
And the developers who write bochs will know what features and values a module or item does offer or accept and which dependency it requires.
With such a system in place, writing GUIs for bochs should become very easy and they won't become outdated so soon.
Because the message system is just a json message, a GUI could also be done as web frontend.
And the user could have different configurations for each kind of guest system he wants to setup.
What do you think about that?
Last edit: Oliver 2022-02-10
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It would be nice to have a cross-platform tool similar to QemuManager (see for reference: http://www.davereyn.co.uk/download.htm). The tool should have similar GUI capabilities and write .bocshrc to be used with Bochs.
The tool is not required to be part of Bochs binary, in fact it could be written on any language, for example on Java and this way to work on all platforms including cellphones. It will control bximage (to create new images) and write .bochsrc; the simulation thus could be run with double-click on .bochsrc in windows.
It also could have another advantage - current configurable GUI might be deprecated and cleaned from the code :)
A bochsrc creation tool for Windows has been wriiten by Ben Lunt, but it's outdated now. The bximage/bxcommit stuff should be extended and moved into one binary. The configurable gui will never be deprecated since we always need the runtime configuration. Removing the start menu only doesn't make sense to me.
Just install and run QemuManager and see how the GUI for configuring .bochsrc should look like. I don't know how to explain it exactly, just run and see.
It should be ... trivial for user ti use.
Might be you will be inspired to improve automatic .bochsrc generation menus as well.
The reason why third party GUI tools become obsolete is because it's always a catch up, then things get changed in bochs and the GUI breaks.
The problem is bochs itself.
It can be solved, but to solve this, bochs needs some sort of property tree anouncing provider that tells the GUI via a standardized messaging system what bochs can do and what modules it does offer to load and which module depends on which other module.
This messaging could be done as json text output with a version number for each specific item and a key value pair and information about allowed values. Plus a comment value in each language. The comment describes the specific key item.
And if a language is missing, there is a fallback to an English comment.
By doing so, the 3rd Party GUI program could first start and run bochs, then bochs starts it property tree announcing provider and sends via a json message to the GUI client what bochs does offer as key=value/options pairs. After that, it changes into a state for accepting new property queries.
Then the GUI can parse that versioned json message and generate a gui according to the information it got from bochs json message.
Then the GUI user can set up the available settings. The new settings which were set by the user then get sent to bochs again via a json message. Bochs interprets it and sets bochs in the requested state.
And if everything is done, the GUI can send a json message to run bochs with this state.
Because the GUI now knows what sort of key expects which kind of value, the GUI can draw checkboxes, radiobuttons and so on based on this information.
Plus a description what this feature does. Because the description is derived from the comment that was additionally sent by the json message from Bochs for each key=value item.
And the version for each module or item will make sure, that the GUI can be easily adapted to new changes.
This way, the GUI can stay easily consistent and up to date with bochs' development.
And the developers who write bochs will know what features and values a module or item does offer or accept and which dependency it requires.
With such a system in place, writing GUIs for bochs should become very easy and they won't become outdated so soon.
Because the message system is just a json message, a GUI could also be done as web frontend.
And the user could have different configurations for each kind of guest system he wants to setup.
What do you think about that?
Last edit: Oliver 2022-02-10