[hatari-devel] Bugs and GUI (Was: Little AceTracker question)

[Eero Tamminen]

Hi,

On Sunday 18 July 2010, Anders Eriksson wrote:
> Anyway here are snaps from all parts of Hatari 1.4.0 on OS X:
>
> http://ae.dhs.nu/pics/Hatari140_OSX/

Thanks, this is quite nice & interesting. :-)

What's the "Hatari help" thingy and what "Search" does?

What the debugger looks like?  Does it have support for reading
debugger commands from file (like the builtin debugger has)?


Other comments:

* The "Enable debugger interface" option most likely should be named
  "Invoke debugger on exceptions".

* Who uses "Enable Bios/Xbios interception" and for what kind things?
  Only thing I've myself used it so far is tracing Bios & Xbios, but OSX UI
  doesn't support setting tracing options (like my Python/Gtk GUI does[1]).

* "New floppy image" dialog misses support for creating HD (1.44MB)
  and ED (2.88MB) disk images.

* The "Falcon/TT aspect ratio" setting is useless except for debugging
  changes to Hatari's scaling code, so I think there's no point in offering
  it to users.

  What the "Zoom ST-lowres." option is supposed to do?
  (There's a --zoom command line option in Hatari, but it just selects one
  of the pre-defined max. sizes which therefore overrides user's own max
  settings + that code is not callable from GUI code)

* Avi & sound recording options seem to be missing.  Btw. in case you
  haven't noticed, Hatari will automatically save either in YM or WAV format
  based on filename extension. :-)

* There should be different headings/names for IDE master & slave images.
  GEMDOS write protection supports "auto" mode like floppies do, so plain
  checkbox isn't enough.  Typo: "Alow" -> "Allow".

* Joystick keys configuration is missing.
  (I don't have them in Python/Gtk UI either)

* MIDI input file setting is missing.

* System settings screen looks pretty cramped.  IMHO it's  bad idea to stuff
  memory settings there too + there's no support for saving & restoring
  emulation memory state.

  Btw, for full compatibility testing you might want to turn off the Blitter
  option. It's about ST blitter, not STE one.  It probably should be
  renamed "Blitter emulation (ST only)" even in SDL GUI as it's in command
  line.

* Hatari has no support for changing the control socket at run-time.
  That option is useful only for things that _start_ Hatari to control it
  through a socket so it's sensible only as command line option.  Having
  the socket with fixed file name could even be a security issue.

* I don't see any code for changing (trace) log file during Hatari run-time.
  (would be nice though, I've missed it myself)


[1] See "Trace settings" here:
	http://koti.mbnet.fi/tammat/hatari/hatari-ui.shtml#Screenshots


> having a sidebar with scroll-list isn't unconventional, it exists in most
> modern IDEs for for instance.

In your examples they typically represent file system objects and are also 
hierarchical.  I think your SDL GUI example is closer to tabs (many widget
toolkits like Gtk, Fltk... support having them on at any edge + scrolling
through the tabs).

With tabs it would be best to join the active tab label with its view so
that user associates them better together.  This also makes the view name
at top redundant & saves some vertical space in the view like getting rid of
the "Back to main menu" button did.


> > Usability:
> > Looks:
> > Implementation issues:
>
> Now my textfile wasn't THAT serious, it was only an example how the
> small SDL-GUI could implement more options.

Sure. But thanks anyway! :-)


	- Eero