GUI: prevent coreview from losing focus when new machine is created

[jdupak]

No description provided.

[ppisa]

Unfortunatelly, I have to report that logic seems to be broken for me still. When I open in empty mode, then open all three examples and then recompile some of them and witch to coreview and press recompile again then some other code is filled into program memory. It seems that current_srceditor reference is maintained incorrectly somewhere.

I can try to add there print or use breakpoints to check when it is unintentionally changed. The most probably when coreview disappears then the first following tab is focussed and that reassigns the current_srceditor. The logic should workaround that problem probably such way, that code removing coreview tab should explicitly set focus to the current_srceditor the first if not empty and only then remove coreview. Some boolean variable should held that coreview has been closed when focused. Later, if focus is changed by user the bool should be negated. When coreview is inserted again and bool is asserted then the focus should be changed to it. In other case it should stay where it is.

The logic is not nice and it is workaround but usability has precedence there.

[jdupak]

The more I think about it, the more I am convinced that it is not a good idea to have a joint tab widget with both core and editor. It creates all these weird situations, like not knowing which editor is selected because none is right now. It seems that the problem I tried to fix is part of a somewhat deeper problem of insufficient flexibility. I am closing this and starting a new issue to think this through.

[jdupak]

@ppisa Try now, I have split the tabs for editor end coreview. I think it makes more sense like this. In the future, I would like to make both docks and get rid of the central widget. Then we should probably use this to get enough flexibility, without the central widget: https://github.com/githubuser0xFFFF/Qt-Advanced-Docking-System.

[ppisa]

I agree that from the code structure and application logic this solution is better but from the novice user perspective it is is questionable. It is little harder to guess where to click to get to my source file on the other hand it is logical that when I switch to editor I am at right tab. Some disadvantage is that if there is only single tab in the editor then the nae of the source file is not seen...

May it be, it would worth to sacrifice some small vertical space in the editor on the top or bottom and put there whole path to the source, line and column numbers. If the path length is to long to fit into provided horizontal area then to replace starting part with ellipsis. I think there is such function in Qt to shorten paths...
Another problem is that click to the message in the corresponding windows select right tab in the editor, but does not switch to edit tab from Core view. Option to enable view of lines numbers on the left of the edited text would be invited and was one of reasons while Karel Koci did not used internal assembler within his seminaries.

It would worth to get some feedback from the users for this change but generally if above mentioned glitches are resolved then I agree that internal logic enhancement and simplification prevails the need to adapt fr the change and need for two clicks instead of one in some use cases.

[jdupak]

@ppisa please review

Added

• "Editor ()" in to level tab
• Close icon on each editor tab
• Status bar with full path (ellided in the middle if does not fit)
• Status bar line and col indicator
• Focus and color highlight from message (dismissed on typing or another message clock)
• Disabled makefile buttion if no working directory is available
• Line number option in menu

Fixed

• Makefile build

[jdupak]

Preview https://comparch.edu.cvut.cz/qtrvsim/app-unstable/

[jdupak]

resolves #79