Re: [openMSX-devel] Qt openMSX Catapult

[Joost Y. D. <jo...@lu...>]

Hi,

On Sunday 22 January 2006 14:34, Manuel Bilderbeek wrote:
> Hi all,
>
> Now that openMSX 0.6.0 has been released, I propose to start working on
> a Qt version of openMSX Catapult, with a fresh design. At least a fresh
> technical design, but maybe also a fresh UI design.
>
> For a good design, we should learn from our past experiences.
>
> The following things were tricky or unadressed in the old Catapult:
> - initialization of all controls, including:
>    - making Catapult ask openMSX for the values and default values of
> settings
> - integration of openMSX and Catapult

I think we should first test if this is possible at all. It seems QT has 
building openGL embedding support, but SDL requires a hacked solution.

> - make the GUI more flexible. E.g.: no cartB dialog when the machine
> doesn't have one.

I like e.g. amaroK's GUI that changes depending on what context you are in a 
very dynamic way.

> - consider plug-in functionality. E.g.: gamers are not interested in a
> cheat finder, but developers are not.

As stated on IRC, plugins could be used (QT has buildin support for this); 
however one could also just make it possible to disable features. Could be 
easier.

> Herman, can you fill me in on stuff that I'm forgetting here?
>
> Some other concerns:
> 1) what parts will be platform specific?
> I hope Qt will cover most of this; it seems to work quite well in the
> debugger for now. Can someone fill me in on this? (I'm not sure about
> the UNIX domain socket part.)
> 2) we currently have it layouted as a launcher, a remote control
> application. Some users suggest to make it more integrated with openMSX
> and don't use loads of button panels, but a normal menu structure,
> around the openMSX window. How can we address this?

Personally I don't like menu's. I never use them. I'd prefer a context 
sidebar.

> 3) wouldn't it be easier if we always keep openMSX running and just load
> different machines in it? This is something that Wouter might implement
> soon and it could help to make Catapult easier to design.

Wouter is already preparing for this it seems :)

> 4) what kind of main architecture should we use?
> I propose a Model-View-Controller-like architecture, with a modular
> communication layer that does the talking to openMSX. The model part can
> be tricky. I don't think having all data stored in the widgets is the
> way to go. Widgets should be Views on data that is in openMSX. We could
> use a big data-model to put our Views on as observers. This would be the
> abstraction of openMSX for Catapult. If we want, we can even cache the
> data in it. We have very short communication lines, but it might not be
> wise to ask values from openMSX for every redraw of a widget... The
> communication layer would be used by the model as a back-end, invisible
> to the rest of the GUI app.

A basic MVC design sounds good. You state that widgets should be views on the 
data that is in openMSX. I think that it is better to decouple it even more 
and have the model be a combination of the openMSX state and the context of 
the catapult application. 

> I hope that especially Herman (knows a lot about the limitations of the
> current Catapult design) and Edwin (knows a lot about making a Qt
> application that talks to openMSX) can comment on this!
>
> Any other comment is welcome as well.
>
> I'm eager to start working on it, but I'd really like to have a good
> design first :)

Don't forget that in open source refactoring is much more justifiable:)

Greetings, Joost

-- 
The planet Andete is famous for it's killer edible poets.