Dani R. wrote: ↑
Tue Jan 14, 2020 7:42 pm
Jaymos wrote: ↑
Tue Jan 14, 2020 12:44 am
UNIT removed from g. Left BLANK.
INFO g swapped with VIEW g[.].
How are these changes? Comments?
For the moment I would retain (additional?) UNIT at g[ 5 ].
VIEW is a function and not a menu. I think that was the reason why VIEW found its position on g[ 0 ] respectively g[ . ]. Probably most likely to be used in programs. Yes, probably REGS.V is more comfortable to use in everyday life.
To remove a bit confusion, the upcoming version number change will not be Layout 2A, I will make it Layout 42B, so one can remember this is the DM42 version. Layout 1A will become Layout 1B.
UNIT: I will return UNIT
to g on L2A. Having UNIT there is better than having it empty, and I need nothing else there.
ASSIGN ASN: Another option is ASN PPP
(Pre-Packed Profiles)? One of your previous comments made me think this.
It does not mean it is final. I can easily change.
VIEW/INFO: I now remember about the original placement. But Let me consider the pros and cons again. Maybe we change, maybe we agree to keep it. The facts are: LAYOUT2:
1. REGS.V & FLAGS.V are not menus, but commands for viewers, VIEW is similar and not out of place on g on both layouts.
2. VIEW is used to view named variables, i.e.
and yes you can use REGS.V, but REGS.V has 112 registers plus the named variables, so for quick checks, VIEW is not only for programming, but essential for interactive use. Again it fits nicely on g.
3. From a functional point of view, VIEW displays named registers until next keypress, and SHOW shows X until next keypress. Similar, therefore it fits next to SHOW.
4. INFO is a menu and VIEW not. So VIEW does not fit next to CLK, CNST & UNIT. But it does fit with REGS.V and FLAGS.V.
I think after analysing it, it is better to change VIEW/INFO back to where it was. Point 3 is the strongest.
Below the changes as stated above. More comments?
I increased the exposure of the photo, but the extra noise creates a large file. So I had to get the resolution down - so must trouble because I cannot make a screen dump of reliable colour on the Mac screen, for a GTK3 image ... So there is the reason for the crappy quality of the images ...