1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
|
TODO
====
Potential TODO items for Hatari UI (in addition to the ones listed in
its sources).
* Fix rest of Gtk v3 / PyGTK deprecation warnings by creating all
Python UI menus with XML and Gtk application framework instead of
using Gtk v2 Action + ActionGroup widgets, see:
- https://python-gtk-3-tutorial.readthedocs.io/en/latest/application.html
* Rewrite all configuration dialogs into Mac UI style single (notebook)
dialog with tabs, using Gtk v3 Grid layout widget, so that only single
configuration menu entry remains
* Interface between UI and Hatari so that Hatari will forward error
and other dialog texts to UI for showing, and waits until user has
acknowledged them (two-way communication)
* Support all 8 ACSI and SCSI drives
* Use file selector widget instead of text widget for specifying input
paths for memory snapshots and devices, so that user can't provide
invalid paths (sound, snapshot and device output files can be
non-existing as they're created on demand)
* Separate "Atari monitor" and "Hatari window" settings dialogs
(move options from "Display" and monitor setting from "Machine"
dialogs to here and add VDI options to Atari Monitor dialog)
* Features for Help menu:
- Create empty floppy images (+ convert directories to hard disks?)
- MSA<->ST converter
- ZIP->ST converter
* Add more Hatari debugger features to the debug UI:
- DSP support
- History support
- Profiling support
- DSP symbols loading
(CPU symbols are loaded automatically from programs)
- Support for stepping the emulation (both step & next commands)
- multiple views to memory (refreshed whenever emulation is stopped)
- supporting also register relative views (register values
parsing should move to common functionality first)
- breakpoint support (issue: how to stop emulation on breakpoint
but still allow Hatari to process remote commands?)
- trace & debug log viewers?
* Translation support for the UI:
- use gettext
- build needs to build & install message catalogs
- some way for Hatari to forward dialog ID to the remote UI
with dialog string parameters (filenames etc) which then
need to be localized too & shown...
* Hatari UI specific configuration which stores:
- list of last used configuration files which would be shown
either in their own menu or dialog
- list of last used memory snapshots (10?)
- disk image dir (uses Hatari config value as default)
- trace settings
- remove dialog specific load/save stuff
- screenshot name
- needs support also to Hatari src/screenSnapShot.c
* Supporting other, less important Hatari configuration options:
- keyboard repeat, key mapping type & file, mouse warping & grabbing
- HD booting, something for multiple GEMDOS partition directories
- separate A/B disk paths for images that are within ZIP archives
- joystick autofire toggling, defining the keys for joyemu
- vdi planes and size, spec512 threshold, ST blitter
- cartridge image (where? it has many limitations)
- log file and levels, console output, bios intercept, run-VBLs
(Many of these aren't supported by the internal Hatari UI either, or
are missing corresponding command line options so they will require
additional support on the Hatari control.c side too or they can
be only enabled at boot, not disabled.)
|
