GUI rearrangements

Bug #579334 reported by Onkar Shinde
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gnusim8085
New
Wishlist
Unassigned

Bug Description

The UI could benefit from some minor rearrangements to make it more intuitive and less cluttered. For example, for debugging/runtime purposes there could be one comprehensive tab that provides all relevant information at a glance:
 - registers & flags
 - memory
 - stack
 - I/O ports

Likewise, it would be helpful if there were dedicated tabs for viewing/manipulation of memory & I/O ports.

In fact, this would make it possible to optionally hide the original register & flag view, thus freeing precious screen estate. Thinking about it, a full view of all registers and flags could even be provided on top of the editor, for example as a toolbar element where it would not occupy any space within the main window.

Also, for the editor itself it might be a good idea to provide users with the possibility to customize the font size.

As mentioned in another suggestion yesterday, I also feel that it might be a good idea to provide the option to switch to an opcode view of the assembled file by using a corresponding separate tab above the editor area, i.e. two tabs that allow the user to switch between "source" and (annotated) "opcode" view, the latter of which probably should be set readonly by default.

Help and instruction set references would also be best provided within a corresponding "reference" or "Docs" tab, where currently data, stack and the keypad tabs are displayed. This would make any documentation very easily and directly accessible.

Also, if the current register & flag displays are retained the way they're currently implemented, it might add to the UI's readability if there was an obvious difference between register/flag names and their values, this could for example be accomplished by using different fonts or colors for displaying name and values. In fact, it might even be worth to consider dynamically changing a register's font color when it has just been modified, to highlight this change.

A small inconvenience is also caused by the fact that saving a file using the file save dialog doesn't yet honor pressing the enter key, rather one has to really click the corresponding UI button.

Tags: ui
Revision history for this message
Bug Importer (bug-importer) wrote :

Logged In: NO

maybe the register and flag elements could simply be made free floating, so that they can be easily moved to a new direction?

Revision history for this message
Bug Importer (bug-importer) wrote :

Logged In: NO

Regarding I/O port visualization I would like to add that many other uC simulator packages traditionally use an image of the corresponding chip to visualize HI/LO state of pins by coloring them accordingly. gpsim also does it this way, i.e. check out http://gpsim.sourceforge.net/screenshots/breadboard.png

So, one could simply display a small image of an 8085 and illustrate HI/LO states using colors

Revision history for this message
Bug Importer (bug-importer) wrote :

Logged In: NO

The load file facility should either by default provide filetypes for common file extensions (*.asm, *.s) or at least also offer to display ALL files in a given directory.

There's another issue that novice user probably encounter frequently:
while stepping through source code, the editor area is rightly set readonly, however this isn't really visible or communicated in any way - it would be better visualized by also changing its background color accordingly (i.e. grey out), and optionally even displaying an information box when the user tries to edit source code while it is still being run by the simulator.

Revision history for this message
Bug Importer (bug-importer) wrote :

Logged In: NO

for a memory tab implementation, I would personally like to see an additional option to automatically jump to memory locations that are being accessed, i.e. some form of checkbox that says:

[x] jump to currently accessed address in tab

This should probably be shown at the top or at the bottom of the memory tab, so that memory accesses can be easily traced for all of the memory by using such an option.

Revision history for this message
Bug Importer (bug-importer) wrote :

Logged In: NO

Regarding comment #3, this inconvenience related to the default *.txt extension, has also been discussed on the forum:
http://sourceforge.net/forum/forum.php?thread_id=1645122&forum_id=296047

Boris

Revision history for this message
Bug Importer (bug-importer) wrote :

Logged In: NO

I just took a stab at it and created a patch, it's posted at: http://sourceforge.net/tracker/index.php?func=detail&aid=1889361&group_id=86462&atid=579701

Boris

Revision history for this message
Bug Importer (bug-importer) wrote :

Logged In: NO

The following freeware/closed source Win32 simulator might also serve as a good reference for possible future gnusim8085 features:
http://www.softpedia.com/get/Others/Home-Education/GRL-Real8085.shtml

Revision history for this message
Bug Importer (bug-importer) wrote :

Logged In: NO

Item #1875407 is also related to this one.

Revision history for this message
Bug Importer (bug-importer) wrote :

Logged In: NO

And #1875405 as well

Revision history for this message
Bug Importer (bug-importer) wrote :

Being able to change the font size and coloring is really desirable!

Revision history for this message
Bug Importer (bug-importer) wrote :
Revision history for this message
Bug Importer (bug-importer) wrote :

The hex/dec calculator/converter would probably also be ideally put on some dedicated tab in the notebook area, this would free some more space on the screen, so that we can eventually enlarge the editor screen, as discussed here: http://sourceforge.net/tracker/index.php?func=detail&aid=1942893&group_id=86462&atid=579699

Revision history for this message
Bug Importer (bug-importer) wrote :

if saving space is important, one could just as well provide this calculator facility via the toolbar, too. I mean, it just needs to text fields, a picker and a button, right?

Revision history for this message
The Escapist (wisd00m) wrote :

This is just a minor UI issue, but it would probably make sense to disable the keypad buttons (or the whole tab!) while the program is being run/debugged - currently it is possible to click buttons, which won't have any effect obviously.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related blueprints

Remote bug watches

Bug watches keep track of this bug in other bug trackers.