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

[Eero Tamminen]

Hi,

On Saturday 17 July 2010, Anders Eriksson wrote:
> >> Hatari crashes when recording starts while using --avi-vcodec bmp
> >> What happens is that the Hatari window dissapears and there's a ~400
> >> byte avi file created. I need to control-c or forcequit Hatari after
> >> that.
> >
> > Were you able to get any backtraces of that with e.g. Valgrind or
> > native OSX tools?
>
> I'm not the right guy for this; I don't know what Valgrind is or even
> less how to use it or what a native OS X tool would be. Somebody else
> with better understanding of these things have to do the debugging.

Is there anobody else both using Hatari on OSX and who can replicate
this crash?  Jerome?


> >> I never said it was no work, only that I disagreed to hiding options
> >> from the GUI. People (your normal users, not the few devs) do not
> >> launch stuff from the terminal, simple as that.
> >
> > At least you/somebody would need to come up with a design of what the
> > UI should look like with all of these options you're interested about.
>
> The OS X GUI is very fine as it is, some more hotkeys would be nice and
> there is no screen-estate problem to add more and more features to it.
>
> Just because the SDL GUI can't do X and Y, why should that also cripple a
> decent GUI as the one on OS X?

The non-standard Hatari GUIs (like the OSX specific one and my Python/Gtk
specific one) of course aren't dependent on the SDL UI.

It's also _much_ easier to do things in them as they aren't constrained to
the Hatari window size, they have many more widgets, the widgets and 
containers resize themselves automatically (SDL GUI widgets are even
more primitive than GEM ones) etc.


> Anyway just for the heck of it I threw together a 64x25 ASCII page with a
> way it could handle any number of setting screens and avoid the "go back
> to main" annoyance.
>
> http://ae.dhs.nu/tmp/hatarisdlgui.txt

Thanks!  That looks pretty good. :-)

It's basically a tabbed interface with tab scrolling done a bit
unconventionally (usually arrows for scrolling tabs are at the tab
row/column ends, but in your design they would take more space and with this
many items, having tabs at top would've been less useful so your design is
better).

Usability:
+ Needing one click less to back out from settings is an improvement.
- The UI is a bit more crowded so it might be a bit harder to hit
  the buttons (e.g. on 3.5"/266 DPI touchscreen one of Hatari devices has).

Looks:
- With the settings always filling the whole sreen, some of the views will
  be very full, some less so (e.g. ROM settings).  This may look a bit
  unbalanced.  Would need design for all the views to comment more
  on this.

Implementation issues:
- Need to do large changes to implementations of *all* view to take into
  account the new looks.  There's currently no support for subviews in
  neither the code for showing of the UI or interpreting the user actions on
  one.
- The top level menu handling needs to be rewritten so that it's done in all
  the subviews (e.g. through helper function and returning what was
  clicked).
- SDL UI doesn't currently provide a scrolled list widget, so implementing
  the tabs list is also a bit more work than one might assume.


I've thought that I could change the Python/Gtk UI to use a tabbed interface
for settings too, but I'm a bit undecided on whether I should split HW
options that require reboot from the non-reboot HW options (like floppy)
and from emulator options (like scaling).

Could somebody post screenshots of what the all OSX UI tabs look like?

Hatari screenshots page has only few of them and I think they're out of
date:
	http://hatari.berlios.de/scrshots3.html


	- Eero