| Re: [hatari-devel] Adding more information to statusbar |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi,
On perjantai 02 toukokuu 2014, Nicolas Pomarède wrote:
> Le 02/05/2014 09:14, Eero Tamminen a écrit :
> > On torstai 01 toukokuu 2014, Nicolas Pomarède wrote:
> >> Le 01/05/2014 19:49, Eero Tamminen a écrit :
> >>> That's a good idea!
> >>>
> >>> First row could be for for indicators:
> >>> - drive activity leds
> >>> - current floppy track
> >>> - frame skip
> >>> - sound/video recording led
> >
> > It could look something like this:
> > [] A:23 [] B:-- [] HD FS: 0 [] REC F1 for options
> > Console Debugger
> > Paused
I forgot, there needs to be space also for fast forward
/ slowdown indication. ">>" is good symbol for fast forward,
but what I could use for slowdown notification?
Regarding exception debugging information, that is mainly relevant
if there's a keyboard shortcut for toggling it. User needs to know
whether he toggled it on or OFF.
In hindsight, listing for which exceptions catching is enabled would
take too much space (unless it replaces something else while it's in
effect), so probably it would better to show just whether exception
debugging is enabled with e.g. "EX" or "D".
> On the 1st line, I'd like to keep 10-15 chars for the FDC infos, so I'm
> not sure it leaves enough space for the message on the right ?
In that case, I guess it still needs to alternate with system
information text (help shown at start, pause & debugger info
show when relevant).
At least I'm going to shorten the startup wait until help text
goes away, it has been getting annoying to wait for it to go away,
to see Hatari config "at glance".
If I'll move the info stuff to second statusbar line, will you
do the indicator updates?
> We should also consider that when we start with "-z 1", the status bar
> is a little narrower, so display should work in this case too.
That doesn't affect it, different font size is used then.
Whether borders are enabled and smaller Falcon screen
modes are more of a problem.
> >>> - possible other HW access leds (blitter, sound DMA, Mic?)
> >
> > Nicolas, what do you think of showing leds for other HW,
> > for what HW it would make sense?
>
> I remember a patch was sent for blitter at one time.
Frank's patch had just small change to blitter.c, unfortunately
it seems to be missing the statubar.c changes (which is more code).
> I'm not sure about dma sound and mic being useful.
Similarly to Blitter, DMA would show usage of STE features,
so aren't they both to same amount useful / useless? :-)
There are so few programs using Mic, that that's probably
not of interest.
> > It could look something like:
> > 4MB 16Mhz 030 (WinUAE) VGA JOY:JK--- TOS v3.06 Falcon
>
> Maybe "Machine" first as this looks like the more important choice in
> the emulation ? Then RAM, speed, cpu, TOS, screen, joystick ?
I put TOS & Machine information last because their size isn't
fixed, but I guess I could just center the information.
I don't think the information "reads" nicely if machine
type is at start, it's better after main HW info (see below).
> > Any suggestions how I could best show CPU (prefetch, cycle exact,
> > MMU), FPU (none, 68881, 68882, internal) and DSP (none, dummy, full)
> > emulation options?
> >
> > As space is short, which of them would be more important info
> > than e.g. CPU core or monitor type?
>
> Regarding prefetch, cycle exact and MMU, I would say that default values
> should be left untouched, so any user that want to change them should be
> aware of what he did, no need to display the result.
> Same for DSP, default is to enable it, if you change it, you should know
> it (and I don't think it remains a lot of programs where you don't want
> to enable DSP in falcon mode)
>
> Of course, sometimes people might change options without knowing it or
> by mistake, but there's nothing we can do about it, displaying it in the
> status bar won't make the user understand better.
Ok.
> FPU could be dislayed if we have some space left, not sure if that's
> useful to have it in the status bar when you can see it in the option
> screen with F12.
Hm. FPU selection is relevant only for WinUAE, so it could act as
indicator of that too...
> > CPU core type has really strong effect on emulation (WinUAE core works
> > better for Falcon emulation, much worse for ST/STE), so accidentally
> > using wrong hatari build is very relevant for bug reports or when
> > otherwise testing Falcon compatibility with different cores.
> >
> > When we have just one core, we can just replace that info in statusbar
> > with something else.
>
> I don't think we should waste space now just because we add a 2nd row.
> If people accidentally run the wrong exe and report bug, then we will
> ask anyway "what build did you run ?".
When switching between the versions often, it's easy to miss which
one you're running unless you check the console output.
But core type is actually build, not configuration information.
I'll add it to window title information for the development versions.
> As for prefecth or cycle exact, these options are suppose to disappear
> one day (even today, I would not recommand to change prefetch or cycle
> exact), displaying them in so little space will just confuse the user
> with touch information / acronyms.
>
> Maybe we can display CPU type as 000/020/030 and FPU as 881/882 ; so a
> 68030 with FPU would be "030+881" (if we have 2 extra chars, better put
> "68030" in full)
It could look like this for WinUAE:
14MB 16Mhz 030+881 Falcon, TOS v4.04, RGB, JK---
And this for oldUAE:
4MB 8Mhz 86000 ST, TOS v1.04, TV, JK---
> > If you think value of 1 should really be used always, change the
> > default, maybe add also a warning on startup if it's not 1.
>
> I plan to put spec512 threshold to "1" for next release, so no more need
> to display it.
Ok.
- Eero