[hatari-devel] Bugs and GUI (Was: Little AceTracker question)
eerot at users.berlios.de
Sun Jul 18 11:17:49 CEST 2010
On Sunday 18 July 2010, Anders Eriksson wrote:
> Anyway here are snaps from all parts of Hatari 1.4.0 on OS X:
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)?
* 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).
* "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
* 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)
 See "Trace settings" here:
> 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! :-)
More information about the hatari-devel