openmsx-devel

[openMSX-devel] Toolkit migration

[Maarten t. H. <ma...@tr...>]

Hi all,

Currently openMSX uses SDL 1.2 for platform abstraction and has an internal 
mini GUI toolkit for the OSD that is programmed from Tcl. This is not ideal 
though:
- the design of SDL 1.2 is limiting: no support for multiple windows, only 
exclusive fullscreen mode, no support for joystick hotplugging etc
- we don't want to reinvent the wheel by making a full GUI toolkit 
ourselves, but we do want to build more complex GUIs than the OSD toolkit is 
designed for


We tried to run the GUI in a separate process. This works (wxCatapult), but 
the integration is not very tight. It turns out the having the GUI run 
asynchronously, in a separate event loop from openMSX itself, leads to a lot 
of complexities. These complexities slowed down the development of the PyQt 
version of Catapult so much that we eventually gave up.

An example of these complexities: if the user attempts to move a slider and 
the GUI waits from an update from openMSX to change the current value, the 
latency of the movement will be noticable, leading to a poor user 
experience. But if the GUI updates the current value before openMSX has 
processed the change, the value for the slider within the GUI and within 
openMSX will be out of sync for a short time. Also it is then hard to 
distinguish updates that are the result of the GUI's own commands from 
updates that are the result of changes from another source (hotkeys, Tcl 
scripts, replays etc).


On the SDL front, SDL 2.0 was released and that is where all future 
development will be done. SDL 1.2 is a dead end.

We have been talking about this for years, but now the time has come to 
actually move away from SDL 1.2.


What will the new situation look like? I think there are a few different use 
cases for openMSX:

1. Gaming
Playing MSX games, not caring a lot how this is achieved as long as the 
games run.
Emulator features used include:
- save states
- reverse
- screenshots
- cheats
- autofire

2. TAS
Creating tool-assisted speedruns.
While technically gaming, it is quite different from normal gaming.

3. Power use
Running complex MSX setups with many extensions, harddisks, MIDI connections 
etc. The user cares for the particular MSX setup used, it might mimic the 
real MSX setup they had or wished they had.
Emulator features used include:
- selecting a particular MSX model
- selecting extensions
- creating a harddisk image and importing files to it

4. Development
Developing MSX software, in particular testing cross compiled code.
Emulator features used include:
- debugging features
- dir-as-disk

A use case I'd like to support in the future is to use openMSX as a plugin 
for a multi-emulator front-end such as OpenEmu or RetroArch. Since these 
front-ends don't have MSX specific knowledge, I think only the gaming use 
case can be supported there.


We also support different types of devices:

A. PC with mouse and keyboard
B. game consoles, PC with game controllers
C. touch screen devices

I think TAS recording, power use and development will mainly happen on PC 
with mouse and keyboard. However, I know for example Alex likes to run turbo 
R demos on an Android tablet, which I would classify as power use.


It might be useful to be able to compile openMSX for a particular use case. 
For example, to play games you don't need dir-as-disk, harddisk, MIDI etc. 
However, the cheats do depend on debugger functionality. I'm not sure if it 
would be feasible to actually compile openMSX without unnecessary features 
or wheter we should only leave out the UI for those features.

I think both Catapult and the openMSX Debugger would no longer be separate 
programs, but have their functionality integrated into openMSX itself. That 
functionality would be conditionally compiled, so that we wouldn't have to 
install a full featured debugger UI on a game console.


For rendering and scaling, OpenGL (ES) seems the obvious target. By "(ES)" I 
mean using the subset of GL features present in ES and have fragments of 
conditionally compiled code to cover the differences. The specs are moving 
in the direction of having GL ES as a proper subset of GL, but that is not 
the case yet.

We currently use GLEW for handling GL extensions, but GLEW doesn't support 
GL ES. A possible solution would be to switch to Epoxy:
  https://github.com/anholt/libepoxy

Do we want to keep software scaling support or switch to hardware scaling 
only? Is there a purpose for software scaling other than supporting systems 
without pixel shaders? Because that was important in the past, but nowadays 
even phones do pixel shaders. And as ultra-high resolution displays are 
getting more common, software scaling on a single CPU core cannot really 
keep up and I'm not sure if it's worth investing in multi-core CPU support 
when GPUs are better equipped for these kinds of workloads.


For the choice of the GUI toolkit, there is a preference for Qt 5. It 
integrates well with C++, it can handle different UI designs on top of the 
same engines (using QML), it is available on most platforms we support (*1) 
and it has good documentation. It is also already used in the openMSX 
Debugger.

(*1) Dingoo A320 would probably have too little memory for openMSX + Qt. It 
also doesn't have OpenGL ES support. However, the current openMSX release 
for Dingoo has all the necessary features, so I would be fine with ending 
Dingoo support in openMSX 0.11.0 and if necessary release bug fixes from the 
0.10.x branch.


One reason we didn't originally want to add a GUI toolkit in openMSX itself 
was that we were afraid the GUI code would get mixed with the emulation code 
and would make the code base unmaintainable. That is still a risk, so I 
would like to establish some architectural rules about how the GUI interacts 
with the rest of openMSX and also enforce these rules as part of the build 
or a static code check.

In particular, I'd like to avoid the situation we're in with SDL 1.2, where 
parts of openMSX depend on SDL while they really shouldn't. I have started 
an analysis of the dependencies and have already removed a few, but a lot 
more work will have to be done to push SDL out of the core of openMSX and 
into the edge.

An idea that appeals to me is to be able to compile openMSX against 
different toolkits. For example, a gaming-only build could use SDL 2.x, 
while a full featured build would use Qt. I don't know though what kind of 
impact that would have on the code: I wouldn't want to create an elaborate 
abstraction layer around the toolkits.


Currently openMSX uses Tcl for lots of things:
- commands entered on the OSD console
- user scripting and customization (hotkeys)
- the OSD UI
- feature implementation: cheat finder, debugger helpers etc

We could write Tcl wrappers so we can create Qt widgets. However, I think we 
would gain more by using QML, since that makes it much easier to adapt to 
different form factors. But in QML, JavaScript is the language of choice for 
scripting.

Which places where we currently use Tcl would be migrated to JavaScript? I 
think the OSD UI should be migrated (because of QML) and the commands 
entered on the OSD console should not (JavaScript syntax is not suitable). 
What about user scripting? Tcl would be easier for simple scripts, but 
JavaScript is more convenient for complex scripts. Maybe support both?

And does it make sense to keep a full Tcl interpreter or would it be 
sufficient to have a mini Tcl-like interpreter that could handle console 
commands but wouldn't do variables, procedures, tracing etc? We had 
something like that before Tcl was introduced. It only makes sense though if 
the functionality is very limited; we don't want to reimplement Tcl.

I must say that while I like Tcl as a language for simple scripts, I don't 
like it as a programming language. It is quite different from languages that 
I regularly use, so every time I have to write Tcl, I have to look up basic 
things. Also some things that are simple in other languages aren't simple in 
Tcl; look for example at the ugly things we needed to make navigation 
through long file lists in the OSD menu run quickly on slow CPUs (commits 
from July 2009). So I would be in favor of replacing Tcl for all use cases 
that go beyond simple scripting.


I think at this point we need two things:
- agree on what openMSX will look like (architecturally) at the end of this 
transition
- find concrete things to work on so we can move the code base forward

About the latter: I would like to have a working application for most of the 
migration, so I'd prefer to first do incremental changes that will simplify 
the toolkit switch, then switch without actually taking advantage of the 
toolkit yet and only in a final step start making changes to the UI. There 
could even be releases inbetween these steps.

I'd like to hear your opinions and insights on this.

Bye,
		Maarten

Re: [openMSX-devel] Toolkit migration

[GuyveR800 <guy...@xs...>]

So basically everything I've been lobbying for in openMSX, which you did 
not allow me to commit any patches for, not even in a separate GIT 
branch, which forced me to fork openMSX, is now the new plan?

You are horrible people. Good luck with your CLOSEDMSX project.

On 07/05/14 09:52, Maarten ter Huurne wrote:
> Hi all,
>
> Currently openMSX uses SDL 1.2 for platform abstraction and has an internal
> mini GUI toolkit for the OSD that is programmed from Tcl. This is not ideal
> though:
> - the design of SDL 1.2 is limiting: no support for multiple windows, only
> exclusive fullscreen mode, no support for joystick hotplugging etc
> - we don't want to reinvent the wheel by making a full GUI toolkit
> ourselves, but we do want to build more complex GUIs than the OSD toolkit is
> designed for
>
>
> We tried to run the GUI in a separate process. This works (wxCatapult), but
> the integration is not very tight. It turns out the having the GUI run
> asynchronously, in a separate event loop from openMSX itself, leads to a lot
> of complexities. These complexities slowed down the development of the PyQt
> version of Catapult so much that we eventually gave up.
>
> An example of these complexities: if the user attempts to move a slider and
> the GUI waits from an update from openMSX to change the current value, the
> latency of the movement will be noticable, leading to a poor user
> experience. But if the GUI updates the current value before openMSX has
> processed the change, the value for the slider within the GUI and within
> openMSX will be out of sync for a short time. Also it is then hard to
> distinguish updates that are the result of the GUI's own commands from
> updates that are the result of changes from another source (hotkeys, Tcl
> scripts, replays etc).
>
>
> On the SDL front, SDL 2.0 was released and that is where all future
> development will be done. SDL 1.2 is a dead end.
>
> We have been talking about this for years, but now the time has come to
> actually move away from SDL 1.2.
>
>
> What will the new situation look like? I think there are a few different use
> cases for openMSX:
>
> 1. Gaming
> Playing MSX games, not caring a lot how this is achieved as long as the
> games run.
> Emulator features used include:
> - save states
> - reverse
> - screenshots
> - cheats
> - autofire
>
> 2. TAS
> Creating tool-assisted speedruns.
> While technically gaming, it is quite different from normal gaming.
>
> 3. Power use
> Running complex MSX setups with many extensions, harddisks, MIDI connections
> etc. The user cares for the particular MSX setup used, it might mimic the
> real MSX setup they had or wished they had.
> Emulator features used include:
> - selecting a particular MSX model
> - selecting extensions
> - creating a harddisk image and importing files to it
>
> 4. Development
> Developing MSX software, in particular testing cross compiled code.
> Emulator features used include:
> - debugging features
> - dir-as-disk
>
> A use case I'd like to support in the future is to use openMSX as a plugin
> for a multi-emulator front-end such as OpenEmu or RetroArch. Since these
> front-ends don't have MSX specific knowledge, I think only the gaming use
> case can be supported there.
>
>
> We also support different types of devices:
>
> A. PC with mouse and keyboard
> B. game consoles, PC with game controllers
> C. touch screen devices
>
> I think TAS recording, power use and development will mainly happen on PC
> with mouse and keyboard. However, I know for example Alex likes to run turbo
> R demos on an Android tablet, which I would classify as power use.
>
>
> It might be useful to be able to compile openMSX for a particular use case.
> For example, to play games you don't need dir-as-disk, harddisk, MIDI etc.
> However, the cheats do depend on debugger functionality. I'm not sure if it
> would be feasible to actually compile openMSX without unnecessary features
> or wheter we should only leave out the UI for those features.
>
> I think both Catapult and the openMSX Debugger would no longer be separate
> programs, but have their functionality integrated into openMSX itself. That
> functionality would be conditionally compiled, so that we wouldn't have to
> install a full featured debugger UI on a game console.
>
>
> For rendering and scaling, OpenGL (ES) seems the obvious target. By "(ES)" I
> mean using the subset of GL features present in ES and have fragments of
> conditionally compiled code to cover the differences. The specs are moving
> in the direction of having GL ES as a proper subset of GL, but that is not
> the case yet.
>
> We currently use GLEW for handling GL extensions, but GLEW doesn't support
> GL ES. A possible solution would be to switch to Epoxy:
>    https://github.com/anholt/libepoxy
>
> Do we want to keep software scaling support or switch to hardware scaling
> only? Is there a purpose for software scaling other than supporting systems
> without pixel shaders? Because that was important in the past, but nowadays
> even phones do pixel shaders. And as ultra-high resolution displays are
> getting more common, software scaling on a single CPU core cannot really
> keep up and I'm not sure if it's worth investing in multi-core CPU support
> when GPUs are better equipped for these kinds of workloads.
>
>
> For the choice of the GUI toolkit, there is a preference for Qt 5. It
> integrates well with C++, it can handle different UI designs on top of the
> same engines (using QML), it is available on most platforms we support (*1)
> and it has good documentation. It is also already used in the openMSX
> Debugger.
>
> (*1) Dingoo A320 would probably have too little memory for openMSX + Qt. It
> also doesn't have OpenGL ES support. However, the current openMSX release
> for Dingoo has all the necessary features, so I would be fine with ending
> Dingoo support in openMSX 0.11.0 and if necessary release bug fixes from the
> 0.10.x branch.
>
>
> One reason we didn't originally want to add a GUI toolkit in openMSX itself
> was that we were afraid the GUI code would get mixed with the emulation code
> and would make the code base unmaintainable. That is still a risk, so I
> would like to establish some architectural rules about how the GUI interacts
> with the rest of openMSX and also enforce these rules as part of the build
> or a static code check.
>
> In particular, I'd like to avoid the situation we're in with SDL 1.2, where
> parts of openMSX depend on SDL while they really shouldn't. I have started
> an analysis of the dependencies and have already removed a few, but a lot
> more work will have to be done to push SDL out of the core of openMSX and
> into the edge.
>
> An idea that appeals to me is to be able to compile openMSX against
> different toolkits. For example, a gaming-only build could use SDL 2.x,
> while a full featured build would use Qt. I don't know though what kind of
> impact that would have on the code: I wouldn't want to create an elaborate
> abstraction layer around the toolkits.
>
>
> Currently openMSX uses Tcl for lots of things:
> - commands entered on the OSD console
> - user scripting and customization (hotkeys)
> - the OSD UI
> - feature implementation: cheat finder, debugger helpers etc
>
> We could write Tcl wrappers so we can create Qt widgets. However, I think we
> would gain more by using QML, since that makes it much easier to adapt to
> different form factors. But in QML, JavaScript is the language of choice for
> scripting.
>
> Which places where we currently use Tcl would be migrated to JavaScript? I
> think the OSD UI should be migrated (because of QML) and the commands
> entered on the OSD console should not (JavaScript syntax is not suitable).
> What about user scripting? Tcl would be easier for simple scripts, but
> JavaScript is more convenient for complex scripts. Maybe support both?
>
> And does it make sense to keep a full Tcl interpreter or would it be
> sufficient to have a mini Tcl-like interpreter that could handle console
> commands but wouldn't do variables, procedures, tracing etc? We had
> something like that before Tcl was introduced. It only makes sense though if
> the functionality is very limited; we don't want to reimplement Tcl.
>
> I must say that while I like Tcl as a language for simple scripts, I don't
> like it as a programming language. It is quite different from languages that
> I regularly use, so every time I have to write Tcl, I have to look up basic
> things. Also some things that are simple in other languages aren't simple in
> Tcl; look for example at the ugly things we needed to make navigation
> through long file lists in the OSD menu run quickly on slow CPUs (commits
> from July 2009). So I would be in favor of replacing Tcl for all use cases
> that go beyond simple scripting.
>
>
> I think at this point we need two things:
> - agree on what openMSX will look like (architecturally) at the end of this
> transition
> - find concrete things to work on so we can move the code base forward
>
> About the latter: I would like to have a working application for most of the
> migration, so I'd prefer to first do incremental changes that will simplify
> the toolkit switch, then switch without actually taking advantage of the
> toolkit yet and only in a final step start making changes to the UI. There
> could even be releases inbetween these steps.
>
> I'd like to hear your opinions and insights on this.
>
> Bye,
> 		Maarten
>
>
> ------------------------------------------------------------------------------
> Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
> • 3 signs your SCM is hindering your productivity
> • Requirements for releasing software faster
> • Expert tips and advice for migrating your SCM now
> http://p.sf.net/sfu/perforce
> _______________________________________________
> openMSX-devel mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openmsx-devel
>

Re: [openMSX-devel] Toolkit migration

[Albert B. <bi...@ms...>]

On 7-5-2014 9:52, Maarten ter Huurne wrote:
>
> For rendering and scaling, OpenGL (ES) seems the obvious target. By "(ES)" I
> mean using the subset of GL features present in ES and have fragments of
> conditionally compiled code to cover the differences. The specs are moving
> in the direction of having GL ES as a proper subset of GL, but that is not
> the case yet.
>
> We currently use GLEW for handling GL extensions, but GLEW doesn't support
> GL ES. A possible solution would be to switch to Epoxy:
>    https://github.com/anholt/libepoxy
>

 From GLEW to Epoxy... Interesting change of glue type.


-- 
GreeTz, BiFi

Visit my Home Page at www.bifi.msxnet.org
mail me at: bi...@ms...
FTP: ftp.bifi.msxnet.org

Re: [openMSX-devel] Toolkit migration

[Alex W. <ale...@sc...>]

Hi,

What I would like to have is that we can have more native like GUIs for
the different platforms.

For example, for Android, it would be good if we can use a toolkit that
allows us to use a  touch interface for the GUI  that automatically
scales according to the screen size and resolution (like all android
applications use) while for windows ofcourse a classic window based gui
with a menu bar and with support for mouse + keyboard interface is much
more suitable.

If switching to SDL 2 + QT5 allows this kind of GUI customization per
target platform, then I'm all in favour of it.

I'm also in favour of migrating to GLES for the scaler. Like you say,
even telephones nowadays have GLES hardware support.

I have googled a little bit around and there seems to be some QT5
support for Android and SDL 2 seems to support Android as well. I have
not yet searched for Epoxy. Though, I would like to build some kind of
POC with SDL2 and QT5 (a kind of hello world program) in order to get a
better feeling for the maturity of the Android flavour of these libraries.

Cheers,
Alex


On 07-05-14 09:52, Maarten ter Huurne wrote:
> Hi all,
>
> Currently openMSX uses SDL 1.2 for platform abstraction and has an internal 
> mini GUI toolkit for the OSD that is programmed from Tcl. This is not ideal 
> though:
> - the design of SDL 1.2 is limiting: no support for multiple windows, only 
> exclusive fullscreen mode, no support for joystick hotplugging etc
> - we don't want to reinvent the wheel by making a full GUI toolkit 
> ourselves, but we do want to build more complex GUIs than the OSD toolkit is 
> designed for
>
>
> We tried to run the GUI in a separate process. This works (wxCatapult), but 
> the integration is not very tight. It turns out the having the GUI run 
> asynchronously, in a separate event loop from openMSX itself, leads to a lot 
> of complexities. These complexities slowed down the development of the PyQt 
> version of Catapult so much that we eventually gave up.
>
> An example of these complexities: if the user attempts to move a slider and 
> the GUI waits from an update from openMSX to change the current value, the 
> latency of the movement will be noticable, leading to a poor user 
> experience. But if the GUI updates the current value before openMSX has 
> processed the change, the value for the slider within the GUI and within 
> openMSX will be out of sync for a short time. Also it is then hard to 
> distinguish updates that are the result of the GUI's own commands from 
> updates that are the result of changes from another source (hotkeys, Tcl 
> scripts, replays etc).
>
>
> On the SDL front, SDL 2.0 was released and that is where all future 
> development will be done. SDL 1.2 is a dead end.
>
> We have been talking about this for years, but now the time has come to 
> actually move away from SDL 1.2.
>
>
> What will the new situation look like? I think there are a few different use 
> cases for openMSX:
>
> 1. Gaming
> Playing MSX games, not caring a lot how this is achieved as long as the 
> games run.
> Emulator features used include:
> - save states
> - reverse
> - screenshots
> - cheats
> - autofire
>
> 2. TAS
> Creating tool-assisted speedruns.
> While technically gaming, it is quite different from normal gaming.
>
> 3. Power use
> Running complex MSX setups with many extensions, harddisks, MIDI connections 
> etc. The user cares for the particular MSX setup used, it might mimic the 
> real MSX setup they had or wished they had.
> Emulator features used include:
> - selecting a particular MSX model
> - selecting extensions
> - creating a harddisk image and importing files to it
>
> 4. Development
> Developing MSX software, in particular testing cross compiled code.
> Emulator features used include:
> - debugging features
> - dir-as-disk
>
> A use case I'd like to support in the future is to use openMSX as a plugin 
> for a multi-emulator front-end such as OpenEmu or RetroArch. Since these 
> front-ends don't have MSX specific knowledge, I think only the gaming use 
> case can be supported there.
>
>
> We also support different types of devices:
>
> A. PC with mouse and keyboard
> B. game consoles, PC with game controllers
> C. touch screen devices
>
> I think TAS recording, power use and development will mainly happen on PC 
> with mouse and keyboard. However, I know for example Alex likes to run turbo 
> R demos on an Android tablet, which I would classify as power use.
>
>
> It might be useful to be able to compile openMSX for a particular use case. 
> For example, to play games you don't need dir-as-disk, harddisk, MIDI etc. 
> However, the cheats do depend on debugger functionality. I'm not sure if it 
> would be feasible to actually compile openMSX without unnecessary features 
> or wheter we should only leave out the UI for those features.
>
> I think both Catapult and the openMSX Debugger would no longer be separate 
> programs, but have their functionality integrated into openMSX itself. That 
> functionality would be conditionally compiled, so that we wouldn't have to 
> install a full featured debugger UI on a game console.
>
>
> For rendering and scaling, OpenGL (ES) seems the obvious target. By "(ES)" I 
> mean using the subset of GL features present in ES and have fragments of 
> conditionally compiled code to cover the differences. The specs are moving 
> in the direction of having GL ES as a proper subset of GL, but that is not 
> the case yet.
>
> We currently use GLEW for handling GL extensions, but GLEW doesn't support 
> GL ES. A possible solution would be to switch to Epoxy:
>   https://github.com/anholt/libepoxy
>
> Do we want to keep software scaling support or switch to hardware scaling 
> only? Is there a purpose for software scaling other than supporting systems 
> without pixel shaders? Because that was important in the past, but nowadays 
> even phones do pixel shaders. And as ultra-high resolution displays are 
> getting more common, software scaling on a single CPU core cannot really 
> keep up and I'm not sure if it's worth investing in multi-core CPU support 
> when GPUs are better equipped for these kinds of workloads.
>
>
> For the choice of the GUI toolkit, there is a preference for Qt 5. It 
> integrates well with C++, it can handle different UI designs on top of the 
> same engines (using QML), it is available on most platforms we support (*1) 
> and it has good documentation. It is also already used in the openMSX 
> Debugger.
>
> (*1) Dingoo A320 would probably have too little memory for openMSX + Qt. It 
> also doesn't have OpenGL ES support. However, the current openMSX release 
> for Dingoo has all the necessary features, so I would be fine with ending 
> Dingoo support in openMSX 0.11.0 and if necessary release bug fixes from the 
> 0.10.x branch.
>
>
> One reason we didn't originally want to add a GUI toolkit in openMSX itself 
> was that we were afraid the GUI code would get mixed with the emulation code 
> and would make the code base unmaintainable. That is still a risk, so I 
> would like to establish some architectural rules about how the GUI interacts 
> with the rest of openMSX and also enforce these rules as part of the build 
> or a static code check.
>
> In particular, I'd like to avoid the situation we're in with SDL 1.2, where 
> parts of openMSX depend on SDL while they really shouldn't. I have started 
> an analysis of the dependencies and have already removed a few, but a lot 
> more work will have to be done to push SDL out of the core of openMSX and 
> into the edge.
>
> An idea that appeals to me is to be able to compile openMSX against 
> different toolkits. For example, a gaming-only build could use SDL 2.x, 
> while a full featured build would use Qt. I don't know though what kind of 
> impact that would have on the code: I wouldn't want to create an elaborate 
> abstraction layer around the toolkits.
>
>
> Currently openMSX uses Tcl for lots of things:
> - commands entered on the OSD console
> - user scripting and customization (hotkeys)
> - the OSD UI
> - feature implementation: cheat finder, debugger helpers etc
>
> We could write Tcl wrappers so we can create Qt widgets. However, I think we 
> would gain more by using QML, since that makes it much easier to adapt to 
> different form factors. But in QML, JavaScript is the language of choice for 
> scripting.
>
> Which places where we currently use Tcl would be migrated to JavaScript? I 
> think the OSD UI should be migrated (because of QML) and the commands 
> entered on the OSD console should not (JavaScript syntax is not suitable). 
> What about user scripting? Tcl would be easier for simple scripts, but 
> JavaScript is more convenient for complex scripts. Maybe support both?
>
> And does it make sense to keep a full Tcl interpreter or would it be 
> sufficient to have a mini Tcl-like interpreter that could handle console 
> commands but wouldn't do variables, procedures, tracing etc? We had 
> something like that before Tcl was introduced. It only makes sense though if 
> the functionality is very limited; we don't want to reimplement Tcl.
>
> I must say that while I like Tcl as a language for simple scripts, I don't 
> like it as a programming language. It is quite different from languages that 
> I regularly use, so every time I have to write Tcl, I have to look up basic 
> things. Also some things that are simple in other languages aren't simple in 
> Tcl; look for example at the ugly things we needed to make navigation 
> through long file lists in the OSD menu run quickly on slow CPUs (commits 
> from July 2009). So I would be in favor of replacing Tcl for all use cases 
> that go beyond simple scripting.
>
>
> I think at this point we need two things:
> - agree on what openMSX will look like (architecturally) at the end of this 
> transition
> - find concrete things to work on so we can move the code base forward
>
> About the latter: I would like to have a working application for most of the 
> migration, so I'd prefer to first do incremental changes that will simplify 
> the toolkit switch, then switch without actually taking advantage of the 
> toolkit yet and only in a final step start making changes to the UI. There 
> could even be releases inbetween these steps.
>
> I'd like to hear your opinions and insights on this.
>
> Bye,
> 		Maarten
>
>
> ------------------------------------------------------------------------------
> Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
> • 3 signs your SCM is hindering your productivity
> • Requirements for releasing software faster
> • Expert tips and advice for migrating your SCM now
> http://p.sf.net/sfu/perforce
> _______________________________________________
> openMSX-devel mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openmsx-devel
>

Re: [openMSX-devel] Toolkit migration

[Sean Y. <se...@me...>]

On Wed, May 07, 2014 at 09:52:54AM +0200, Maarten ter Huurne wrote:
> Hi all,
> 
> Currently openMSX uses SDL 1.2 for platform abstraction and has an internal 
> mini GUI toolkit for the OSD that is programmed from Tcl. This is not ideal 
> though:
> - the design of SDL 1.2 is limiting: no support for multiple windows, only 
> exclusive fullscreen mode, no support for joystick hotplugging etc
> - we don't want to reinvent the wheel by making a full GUI toolkit 
> ourselves, but we do want to build more complex GUIs than the OSD toolkit is 
> designed for
> 
> 
> We tried to run the GUI in a separate process. This works (wxCatapult), but 
> the integration is not very tight. It turns out the having the GUI run 
> asynchronously, in a separate event loop from openMSX itself, leads to a lot 
> of complexities. These complexities slowed down the development of the PyQt 
> version of Catapult so much that we eventually gave up.
> 
> An example of these complexities: if the user attempts to move a slider and 
> the GUI waits from an update from openMSX to change the current value, the 
> latency of the movement will be noticable, leading to a poor user 
> experience. But if the GUI updates the current value before openMSX has 
> processed the change, the value for the slider within the GUI and within 
> openMSX will be out of sync for a short time. Also it is then hard to 
> distinguish updates that are the result of the GUI's own commands from 
> updates that are the result of changes from another source (hotkeys, Tcl 
> scripts, replays etc).
> 
> 
> On the SDL front, SDL 2.0 was released and that is where all future 
> development will be done. SDL 1.2 is a dead end.
> 
> We have been talking about this for years, but now the time has come to 
> actually move away from SDL 1.2.

It would be great to be able to support wayland natively; support for this
will be added to SDL 2.0 and not SDL 1.2.
 
> What will the new situation look like? I think there are a few different use 
> cases for openMSX:
> 
> 1. Gaming
> Playing MSX games, not caring a lot how this is achieved as long as the 
> games run.

Indeed; this would mean presenting a list of games:
 - selecting an appropriate MSX for that game
 - for joysticks/touch screen devices provide mapping for buttons used 
   for that game

> Emulator features used include:
> - save states
> - reverse
> - screenshots
> - cheats
> - autofire
> 
> 2. TAS
> Creating tool-assisted speedruns.
> While technically gaming, it is quite different from normal gaming.
> 
> 3. Power use
> Running complex MSX setups with many extensions, harddisks, MIDI connections 
> etc. The user cares for the particular MSX setup used, it might mimic the 
> real MSX setup they had or wished they had.
> Emulator features used include:
> - selecting a particular MSX model
> - selecting extensions
> - creating a harddisk image and importing files to it
> 
> 4. Development
> Developing MSX software, in particular testing cross compiled code.
> Emulator features used include:
> - debugging features
> - dir-as-disk
> 
> A use case I'd like to support in the future is to use openMSX as a plugin 
> for a multi-emulator front-end such as OpenEmu or RetroArch. Since these 
> front-ends don't have MSX specific knowledge, I think only the gaming use 
> case can be supported there.
> 
> 
> We also support different types of devices:
> 
> A. PC with mouse and keyboard
> B. game consoles, PC with game controllers
> C. touch screen devices
> 
> I think TAS recording, power use and development will mainly happen on PC 
> with mouse and keyboard. However, I know for example Alex likes to run turbo 
> R demos on an Android tablet, which I would classify as power use.
> 
> 
> It might be useful to be able to compile openMSX for a particular use case. 
> For example, to play games you don't need dir-as-disk, harddisk, MIDI etc. 
> However, the cheats do depend on debugger functionality. I'm not sure if it 
> would be feasible to actually compile openMSX without unnecessary features 
> or wheter we should only leave out the UI for those features.
> 
> I think both Catapult and the openMSX Debugger would no longer be separate 
> programs, but have their functionality integrated into openMSX itself. That 
> functionality would be conditionally compiled, so that we wouldn't have to 
> install a full featured debugger UI on a game console.
> 
> 
> For rendering and scaling, OpenGL (ES) seems the obvious target. By "(ES)" I 
> mean using the subset of GL features present in ES and have fragments of 
> conditionally compiled code to cover the differences. The specs are moving 
> in the direction of having GL ES as a proper subset of GL, but that is not 
> the case yet.
> 
> We currently use GLEW for handling GL extensions, but GLEW doesn't support 
> GL ES. A possible solution would be to switch to Epoxy:
>   https://github.com/anholt/libepoxy
> 
> Do we want to keep software scaling support or switch to hardware scaling 
> only? Is there a purpose for software scaling other than supporting systems 
> without pixel shaders? Because that was important in the past, but nowadays 
> even phones do pixel shaders. And as ultra-high resolution displays are 
> getting more common, software scaling on a single CPU core cannot really 
> keep up and I'm not sure if it's worth investing in multi-core CPU support 
> when GPUs are better equipped for these kinds of workloads.

Even the open source intel and radeon drivers handle the pixel shaders 
fine. If the software scaling can be removed, then doing yuv conversion
for lasterdiscs can be done in pixel shaders. Currently this would mean
duplicating a lot of code.
 
> For the choice of the GUI toolkit, there is a preference for Qt 5. It 
> integrates well with C++, it can handle different UI designs on top of the 
> same engines (using QML), it is available on most platforms we support (*1) 
> and it has good documentation. It is also already used in the openMSX 
> Debugger.
> 
> (*1) Dingoo A320 would probably have too little memory for openMSX + Qt. It 
> also doesn't have OpenGL ES support. However, the current openMSX release 
> for Dingoo has all the necessary features, so I would be fine with ending 
> Dingoo support in openMSX 0.11.0 and if necessary release bug fixes from the 
> 0.10.x branch.
> 
> 
> One reason we didn't originally want to add a GUI toolkit in openMSX itself 
> was that we were afraid the GUI code would get mixed with the emulation code 
> and would make the code base unmaintainable. That is still a risk, so I 
> would like to establish some architectural rules about how the GUI interacts 
> with the rest of openMSX and also enforce these rules as part of the build 
> or a static code check.
> 
> In particular, I'd like to avoid the situation we're in with SDL 1.2, where 
> parts of openMSX depend on SDL while they really shouldn't. I have started 
> an analysis of the dependencies and have already removed a few, but a lot 
> more work will have to be done to push SDL out of the core of openMSX and 
> into the edge.
> 
> An idea that appeals to me is to be able to compile openMSX against 
> different toolkits. For example, a gaming-only build could use SDL 2.x, 
> while a full featured build would use Qt. I don't know though what kind of 
> impact that would have on the code: I wouldn't want to create an elaborate 
> abstraction layer around the toolkits.
> 
> 
> Currently openMSX uses Tcl for lots of things:
> - commands entered on the OSD console
> - user scripting and customization (hotkeys)
> - the OSD UI
> - feature implementation: cheat finder, debugger helpers etc
> 
> We could write Tcl wrappers so we can create Qt widgets. However, I think we 
> would gain more by using QML, since that makes it much easier to adapt to 
> different form factors. But in QML, JavaScript is the language of choice for 
> scripting.
> 
> Which places where we currently use Tcl would be migrated to JavaScript? I 
> think the OSD UI should be migrated (because of QML) and the commands 
> entered on the OSD console should not (JavaScript syntax is not suitable). 
> What about user scripting? Tcl would be easier for simple scripts, but 
> JavaScript is more convenient for complex scripts. Maybe support both?
> 
> And does it make sense to keep a full Tcl interpreter or would it be 
> sufficient to have a mini Tcl-like interpreter that could handle console 
> commands but wouldn't do variables, procedures, tracing etc? We had 
> something like that before Tcl was introduced. It only makes sense though if 
> the functionality is very limited; we don't want to reimplement Tcl.
> 
> I must say that while I like Tcl as a language for simple scripts, I don't 
> like it as a programming language. It is quite different from languages that 
> I regularly use, so every time I have to write Tcl, I have to look up basic 
> things. Also some things that are simple in other languages aren't simple in 
> Tcl; look for example at the ugly things we needed to make navigation 
> through long file lists in the OSD menu run quickly on slow CPUs (commits 
> from July 2009). So I would be in favor of replacing Tcl for all use cases 
> that go beyond simple scripting.

I've never been keen on tcl. There are some very efficient implementations
of JavaScript.
> 
> 
> I think at this point we need two things:
> - agree on what openMSX will look like (architecturally) at the end of this 
> transition
> - find concrete things to work on so we can move the code base forward
> 
> About the latter: I would like to have a working application for most of the 
> migration, so I'd prefer to first do incremental changes that will simplify 
> the toolkit switch, then switch without actually taking advantage of the 
> toolkit yet and only in a final step start making changes to the UI. There 
> could even be releases inbetween these steps.
> 
> I'd like to hear your opinions and insights on this.

This is exactly where I wanted openmsx to go, but more so.


Sean

[openMSX-devel] Fwd: Toolkit migration

[Wouter V. <ver...@gm...>]

Resend to whole mailinglist instead of just Maarten.

---------- Forwarded message ----------
From: Wouter Vermaelen <ver...@gm...>
Date: Thu, May 8, 2014 at 4:17 PM
Subject: Re: [openMSX-devel] Toolkit migration
To: Maarten ter Huurne <ma...@tr...>


Hi,

Like your mail about unit tests, I agree with most of your points. So
I'll only reply to those where I have a slightly different opinion or
where I'd like to add something. I've also reordered your mail a bit.



> About the latter: I would like to have a working application for most of
the
> migration, so I'd prefer to first do incremental changes that will
simplify
> the toolkit switch, then switch without actually taking advantage of the
> toolkit yet and only in a final step start making changes to the UI. There
> could even be releases inbetween these steps.

This was the last point of your mail, but I think it's very important.
I have a rough idea where I'd (personally) like to end up but
unfortunately I don't see a clear path yet (with small incremental
changes) that will lead us there.

Ideally I'd like to end up with (only) a Qt5 code base (see also
below). We could make a detour via SDL2, but e.g. the event system (at
least the unicode keyboard handling part) is different between SDL1.2
and SDL2.0 and very different from Qt. I once looked at SDL2 and there
were more differences like this (unfortunately I can't recall them
right now). So in a way going via SDL2 to Qt5 requires us to do some
throw-away work.

On the other hand directly going to Qt5 may be a too(?) big step.
Taking into account that I (and the other developers?) don't have
nearly as much openmsx-development-time as in the past.



> I think at this point we need two things:
> - agree on what openMSX will look like (architecturally) at the end of
this
> transition
> - find concrete things to work on so we can move the code base forward

Maybe one thing we can already do is make our code openGL ES compliant
(I think we can even do this while still using SDL1.2). This is
something we have to do anyway, whether we switch to SDL2, Qt5 or to
Qt5 via SDL2.



> For the choice of the GUI toolkit, there is a preference for Qt 5. It
> integrates well with C++, it can handle different UI designs on top of the
> same engines (using QML), it is available on most platforms we support
(*1)
> and it has good documentation. It is also already used in the openMSX
> Debugger.

I don't know any GUI toolkit really well (GUI programming is still very
low on my personal list of interests), though I've been watching some Qt5
tech-talk videos lately and those have left a very positive impression. I
especially like how easy it is with QML to put two very different GUIs
(one for mouse+keyboard, one for touch) on the same underlying code.

(And QML allows for some very interesting rendering optimization that are
hard to achieve in more traditional widget based toolkits. This might be
important for the lower-end devices, or just for battery life.)

Note that QML (Qt4, Qt5) is _very_ different from the Qt3 stuff we've used
in the past for the debugger.



> For rendering and scaling, OpenGL (ES) seems the obvious target. By
"(ES)" I
> mean using the subset of GL features present in ES and have fragments of
> conditionally compiled code to cover the differences. The specs are moving
> in the direction of having GL ES as a proper subset of GL, but that is not
> the case yet.

Isn't, for our purposes, GL-ES already a proper subset of openGL? IOW
can't we already assume that if our code works with GL-ES it will also
work with plain openGL? At least I can't immediately think of any
counter example.



> Do we want to keep software scaling support or switch to hardware scaling
> only? Is there a purpose for software scaling other than supporting
systems
> without pixel shaders? Because that was important in the past, but
nowadays
> even phones do pixel shaders. And as ultra-high resolution displays are
> getting more common, software scaling on a single CPU core cannot really
> keep up and I'm not sure if it's worth investing in multi-core CPU support
> when GPUs are better equipped for these kinds of workloads.

One year ago I would have disagreed. But indeed, now even the simplest
devices offer openGL ES 2, so it makes sense to start requiring it in
openMSX. Even if this means that newer openMSX versions won't run on
Dingoo anymore.



> We currently use GLEW for handling GL extensions, but GLEW doesn't support
> GL ES. A possible solution would be to switch to Epoxy:
>   https://github.com/anholt/libepoxy

Is GLEW/Epoxy only for GL extensions? Do we still require extensions?
Or have all extensions we use become standard GL functionality in the
mean time? Would be nice if we could target standard openGL ES 2.0.



> It might be useful to be able to compile openMSX for a particular use
case.
> For example, to play games you don't need dir-as-disk, harddisk, MIDI etc.
> However, the cheats do depend on debugger functionality. I'm not sure if
it
> would be feasible to actually compile openMSX without unnecessary features
> or wheter we should only leave out the UI for those features.
>
> I think both Catapult and the openMSX Debugger would no longer be separate
> programs, but have their functionality integrated into openMSX itself.
That
> functionality would be conditionally compiled, so that we wouldn't have to
> install a full featured debugger UI on a game console.

In general, I prefer to keep the code base as much as possible the same
between all the different platforms, and with the least amount of
conditionally compiled code as possible.

It may be true that dirAsDsk, HD, MIDI, ... are not useful in some
scenarios, but including them anyway only has a small cost (slightly
bigger binary). IMHO this cost is less than the cost of maintaining
different code bases.

Just to be clear: our current level of conditionally compiled code is
fine (if it can remove the dependency on an extra library), but I
wouldn't want to make more stuff optional.

And my hope is that the different GUIs (touch vs keyb/mouse) can be
made with exactly the same C++ code, only different QML files.



> An idea that appeals to me is to be able to compile openMSX against
> different toolkits. For example, a gaming-only build could use SDL 2.x,
> while a full featured build would use Qt. I don't know though what kind of
> impact that would have on the code: I wouldn't want to create an elaborate
> abstraction layer around the toolkits.

I don't think I agree. One problem we already have is that we can't
decently test all our different platforms. This will only get worse if
we use two (or more) very different toolkits.

OTOH even now it happens that the same library behaves different on
different platforms. But I think it will be worse with two different
toolkits.

My preference is to use Qt5 for everything. It might be the case that
this is not possible in the end (e.g. a platform with good support for
SDL2 but not for Qt5). But IMHO it should at least be our initial
goal.



> A use case I'd like to support in the future is to use openMSX as a plugin
> for a multi-emulator front-end such as OpenEmu or RetroArch. Since these
> front-ends don't have MSX specific knowledge, I think only the gaming use
> case can be supported there.

For me personally this is low priority. I only briefly looked at those
front-ends, but in some cases they don't fit well with openMSX. E.g.
they assume a frame-oriented emulator while openMSX is EmuTime
oriented. It's likely possible to make openMSX fit in those
front-ends, but it won't always be an easy/natural fit.

I also don't like having abstraction layers that in the end only have
one concrete implementation. Or multiple implementations where
all-but-one are rarely used. We already have too many features in
openMSX that are rarely used (if at all).



> Currently openMSX uses Tcl for lots of things:
> - commands entered on the OSD console
> - user scripting and customization (hotkeys)
> - the OSD UI
> - feature implementation: cheat finder, debugger helpers etc
>
> We could write Tcl wrappers so we can create Qt widgets. However, I think
we
> would gain more by using QML, since that makes it much easier to adapt to
> different form factors. But in QML, JavaScript is the language of choice
for
> scripting.

To be clear, with Qt5 I mean the QML-part, not the widgets-part. Also
from the tech-talks/documentation I've seen it's clear that widgets
are being phased-out in favor of QML.


> Which places where we currently use Tcl would be migrated to JavaScript? I
> think the OSD UI should be migrated (because of QML) and the commands
> entered on the OSD console should not (JavaScript syntax is not suitable).
> What about user scripting? Tcl would be easier for simple scripts, but
> JavaScript is more convenient for complex scripts. Maybe support both?

I agree, for entering small commands interactively Tcl is more suited.
For declarative stuff (QML) JavaScript is more suited. Having multiple
implementation languages (Tcl, C++, JavaScript) might not be ideal.
Although from another point of view it may actually be a good thing
because it naturally enforces a separation between the different
tasks:
 - core emulation stuff: C++
 - purely GUI stuff: QML, JavaScript  (likely multiple
      implementations for desktop/hand-held)
 - emulator scripting: Tcl
So a non-trivial script (e.g. the cheat stuff) should be written once
in Tcl with 2 QML GUIs (mouse/touch) on top of it. Instead of
duplicating the script logic in the 2 GUIs.



> And does it make sense to keep a full Tcl interpreter or would it be
> sufficient to have a mini Tcl-like interpreter that could handle console
> commands but wouldn't do variables, procedures, tracing etc? We had
> something like that before Tcl was introduced. It only makes sense though
if
> the functionality is very limited; we don't want to reimplement Tcl.

I don't think it's easy to get rid of Tcl, especially not in the short
term. Trying to implement a lightweight Tcl ourself would be a lot of
work.

For integrating QML/JavaScript with the rest of openMSX I was thinking
of the following:

* JavaScript -> openMSX direction:
  Allow JavaScript code to execute Tcl commands. So add one JavaScript
  function that takes a string and returns another string. This
  immediately gives JavaScript the same power as we currently have in
  Tcl.

  If we notice that some things are too slow we could selectively
  implement extra JavaScript functions that directly go to C++.

* openMSX -> JavaScript direction:
  We already have the CliComm event mechanism to send 'interesting'
  events to GUI-like applications. We can reuse this infrastructure
  for QML. So a CliComm event would be handled as a call from C++ to a
  JavaScript function.

>From the Qt documentation/videos that I've read/watched. This kind of
JavaScript integration should be possible.



> I must say that while I like Tcl as a language for simple scripts, I don't
> like it as a programming language. It is quite different from languages
that
> I regularly use, so every time I have to write Tcl, I have to look up
basic
> things. Also some things that are simple in other languages aren't simple
in
> Tcl; look for example at the ugly things we needed to make navigation
> through long file lists in the OSD menu run quickly on slow CPUs (commits
> from July 2009). So I would be in favor of replacing Tcl for all use cases
> that go beyond simple scripting.

Part of that may also be structure of the OSD menu system instead of
the language itself. Personally I like Tcl, but I'm not married to it.
So if in the end we want to replace it with JavaScript that fine with
me.

However replacing Tcl won't be an easy task. It should definitely not
be a short- or even mid-term goal IMHO.


Wouter

Re: [openMSX-devel] Toolkit migration

[Manuel B. <ma...@ms...>]

Hi Maarten,

First of all: YAY! We have been planning these things for years but 
finally some focus seems to have landed on them!
I've been waiting for a long time for this.

Generally I'm thus very happy with this mail and agree (because most of 
it was already prediscussed on IRC for several years). I will comment on 
some details below.

On 07-05-14 09:52, Maarten ter Huurne wrote:
> We have been talking about this for years, but now the time has come to
> actually move away from SDL 1.2.

Yes, indeed!

> It might be useful to be able to compile openMSX for a particular use case.
> For example, to play games you don't need dir-as-disk, harddisk, MIDI etc.
> However, the cheats do depend on debugger functionality. I'm not sure if it
> would be feasible to actually compile openMSX without unnecessary features
> or wheter we should only leave out the UI for those features.

Let's keep it as simple as possible. I don't think it's necessary to 
leave out such features and keep a single core code base.

> I think both Catapult and the openMSX Debugger would no longer be separate
> programs, but have their functionality integrated into openMSX itself. That
> functionality would be conditionally compiled, so that we wouldn't have to
> install a full featured debugger UI on a game console.

Like the plugin idea we had a few years ago? (There were some symbol 
export issues back then...)

> For rendering and scaling, OpenGL (ES) seems the obvious target. By "(ES)" I
> mean using the subset of GL features present in ES and have fragments of
> conditionally compiled code to cover the differences. The specs are moving
> in the direction of having GL ES as a proper subset of GL, but that is not
> the case yet.

Can we already realize all current GL functionality with this subset? If 
yes, why not already move to this subset?

> Do we want to keep software scaling support or switch to hardware scaling
> only? Is there a purpose for software scaling other than supporting systems
> without pixel shaders? Because that was important in the past, but nowadays
> even phones do pixel shaders. And as ultra-high resolution displays are
> getting more common, software scaling on a single CPU core cannot really
> keep up and I'm not sure if it's worth investing in multi-core CPU support
> when GPUs are better equipped for these kinds of workloads.

Doesn't the software scaling option give better portability?

> For the choice of the GUI toolkit, there is a preference for Qt 5. It
> integrates well with C++, it can handle different UI designs on top of the
> same engines (using QML), it is available on most platforms we support (*1)
> and it has good documentation. It is also already used in the openMSX
> Debugger.

No, that was Qt 4, which is quite differently and as I understood Qt 5 
will be used quite differently than how Qt 4 is now used in the debugger.

> (*1) Dingoo A320 would probably have too little memory for openMSX + Qt. It
> also doesn't have OpenGL ES support. However, the current openMSX release
> for Dingoo has all the necessary features, so I would be fine with ending
> Dingoo support in openMSX 0.11.0 and if necessary release bug fixes from the
> 0.10.x branch.

I doubt there will be lots of enthusiasm to keep that stuff alive, but 
maybe I'll get surprised ;-)

> In particular, I'd like to avoid the situation we're in with SDL 1.2, where
> parts of openMSX depend on SDL while they really shouldn't. I have started
> an analysis of the dependencies and have already removed a few, but a lot
> more work will have to be done to push SDL out of the core of openMSX and
> into the edge.

Which fits with the other thread about setting up unit testing. For unit 
testing you need your objects to have interfaces in other to be able to 
mock/stub them. So these objectives go hand in hand.

> An idea that appeals to me is to be able to compile openMSX against
> different toolkits. For example, a gaming-only build could use SDL 2.x,
> while a full featured build would use Qt. I don't know though what kind of

Most gamers still would like to see a GUI.

> impact that would have on the code: I wouldn't want to create an elaborate
> abstraction layer around the toolkits.

As long as there is enough toolkit independent abstraction around the 
openMSX core code, right?

> Currently openMSX uses Tcl for lots of things:
> - commands entered on the OSD console
> - user scripting and customization (hotkeys)
> - the OSD UI
> - feature implementation: cheat finder, debugger helpers etc

wc count on scripts dir excluding trainerdefs is about 14KLOC.

Tcl may not be ideal, but after a long period of getting used to it, I 
really think it's pretty OK.

> Which places where we currently use Tcl would be migrated to JavaScript? I
> think the OSD UI should be migrated (because of QML) and the commands
> entered on the OSD console should not (JavaScript syntax is not suitable).

This would be quote some work, because almost many of these scripts 
implement funny OSD UI widgets.

> What about user scripting? Tcl would be easier for simple scripts, but
> JavaScript is more convenient for complex scripts. Maybe support both?

I think (at least during migration, but probably forever) we should keep 
the Tcl stuff. Our live command line shell is even based on it. Commands 
you give to openMSX are basically Tcl commands.

> And does it make sense to keep a full Tcl interpreter or would it be
> sufficient to have a mini Tcl-like interpreter that could handle console
> commands but wouldn't do variables, procedures, tracing etc? We had
> something like that before Tcl was introduced. It only makes sense though if
> the functionality is very limited; we don't want to reimplement Tcl.

We use more than very basic Tcl, I think... Especially for debug 
expressions and such.

> from July 2009). So I would be in favor of replacing Tcl for all use cases
> that go beyond simple scripting.

Good luck with that ;-)

> I think at this point we need two things:
> - agree on what openMSX will look like (architecturally) at the end of this
> transition

I think you already sketched an outline of the ideas we have now.

> - find concrete things to work on so we can move the code base forward

I'm all open for suggestions. I already offered working on getting our 
SDL dependencies to the edges. Suggestions on what I can contribute 
there are most welcome (on IRC).

> About the latter: I would like to have a working application for most of the
> migration, so I'd prefer to first do incremental changes that will simplify
> the toolkit switch, then switch without actually taking advantage of the
> toolkit yet and only in a final step start making changes to the UI. There
> could even be releases inbetween these steps.

Very much agreed. I'd like to keep openMSX working all the time and if 
it gets broken, repair it directly or a.s.a.p.

-- 
Grtjs, Manuel

PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ )
PPS: Visit my homepage at http://manuel.msxnet.org/

Re: [openMSX-devel] Toolkit migration

[GuyveR800 <guy...@xs...>]

On 08/05/14 17:54, Manuel Bilderbeek wrote:
>> (*1) Dingoo A320 would probably have too little memory for openMSX + Qt. It
>> also doesn't have OpenGL ES support. However, the current openMSX release
>> for Dingoo has all the necessary features, so I would be fine with ending
>> Dingoo support in openMSX 0.11.0 and if necessary release bug fixes from the
>> 0.10.x branch.
>
> I doubt there will be lots of enthusiasm to keep that stuff alive, but
> maybe I'll get surprised ;-)

Last time I suggested removing Dingoo support, because it was blocking 
necessary progress, I was told that it was *absolutely vital* to 
openMSX. So you didn't allow me to commit my OpenGL-only version of 
openMSX...

> I'm all open for suggestions. I already offered working on getting our
> SDL dependencies to the edges. Suggestions on what I can contribute
> there are most welcome (on IRC).

Nobody offered to do this when I tried to get my SDL-less version of 
openMSX committed. This was one of the main reasons for you to disallow 
my work to be committed.