[hatari-devel] Execution history debugger command

[Eero Tamminen]

Hi,

On keskiviikko 01 kesäkuu 2011, Nicolas Pomarède wrote:
> Le 31/05/2011 23:11, Eero Tamminen a écrit :
> >> PS : for those who haven't tried it, just download Steem debug from
> >> Steem website and simply run it with Wine if you use Linux or OSX.

Is there any documentation or manual for it?


> > I don't like binary blobs, could you mail a screenshot of it and tell
> > what exactly in it is nice?
> 
> No, seriously, not again, you already asked me for this :)
>
> Honestly, there's no blobs in Steem,

I searched the whole Steem site, but didn't find sources for it.
Where they are?


> just a zip archive with some
> predefined directories ; unzip, run "wine Steem.exe", can't be much
> easier.

As a principle, I don't run/use things at home or work for which I cannot
get source code for (like Flashplayer), except in (open source) emulators.

(Wine isn't an emulator.  It provides Win32 API and emulates some things,
but the x86 code it runs directly.)


> Doing screenshots won't help, there's too many functionalities to
> describe ; you need to use it to get an idea of what it does, I think
> the real strength is that everything can be done with the UI in a self
> explanatory way (I don't have anything against CLI, but Monst or Steem
> UI are really much easir to use ; combining Hatari's debuger with such
> UI would be a great match)

So Monst UI is fine as is?

(that I'm somewhat familiar with and I still have the Monst manual.)


> Regarding the UI toolkit, I don't think QT would be such a bad choice ;
> at least it's really supported on Windows/Linux/OS X

Supported significantly better than Gtk that's used by the current (remote)
GUI?


As the Qt OSX instructions mention Python:
  http://doc.qt.nokia.com/4.7-snapshot/install-mac.html

Why getting that & Qt installed would be noticeably easier than getting
PyGtk installed?  There's already an experimental all-in-one installer for
it:
	http://sourceforge.net/projects/zero-install/files/PyGTK/2.22.0/

For Windows there's already stable all-in-one PyGtk installer:
	http://www.pygtk.org/downloads.html

(If the used Windows compiler doesn't support standard sockets, then
somebody needs to add support for some Windows specific socket functions to
Hatari for remote API code, but that's not an UI issue.)


> and features all the functionnalities of modern toolkit and can be themed
> to integrate with the user's computer.

Well, if the debugger "UI" is modeled after Monst, it's supposed to look
like an ST program, not Windows/OSX.  :-)

"Themeing" in an SDL program can be done by loading a background image.


> Also, maybe the debuger's UI could be built in hatari (in a kind of
> "gui-qt" directory for example). It has the advantage of not requiring
> external sockets or things like that (as it's currently the case with
> python's one)

If it's built into Hatari, I think it should be done with SDL[1].  This
limits the "UI" to the size of the Hatari screen (SDL provides just one
"framebuffer" as far as I know) which would complicate things because
Hatari window size changes often on Falcon emulation.

[1] While embedding Hatari SDL stuff to OSX UI is already working I think
    adding Qt to that mix would be a bad idea.

As a separate program the UI could be any size and the size could be fixed
at startup.  Instead of separate windows, it could have e.g. separate
screens which are switched using e.g. function keys.


Another problem of building it into Hatari is how you then use the debugger
command line to do things that the UI doesn't support?  The command line
has e.g, full debug symbol name TAB-completion.


	- Eero