Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Blendsplitter #117

Open
wants to merge 67 commits into
base: master
Choose a base branch
from
Open

Blendsplitter #117

wants to merge 67 commits into from

Conversation

turbor
Copy link
Contributor

@turbor turbor commented Apr 21, 2022

This is the new blendsplitter layout for the debugger.
Code is usable but still needs some extra love, feedback is welcome.

Things that still need to be implemented

  • Better cursor shapes when splitting
  • Saving/loading of the session layout of all work spaces, splitters and states of switchingwidgets
  • Splashscreen at startup with tips to explain the new way of working.
  • Maybe drag-and-drop to switch switchingWidgets from place in the splitters
  • Icons in the drop down so that the combobox is smaller and text only show when selecting

turbor and others added 27 commits April 20, 2022 11:09
These are already slightly adjust to be in a flat subdirectory.
Original code can be found at https://github.com/marekdedic/BlendSplitter
and was MIT licensed when converted.
Simply moved the expander.png in our already existing qrc file.
Mainly since I didn't feel like working out how to incorporate 2 qrc
files in our buildsystem :-)
Better coloring when widget disabled.
Highlight current SP address.
Currently the old view is in a splitter visible on first workspace.

The old code had a lot of direct signals/slots and calls between
DebuggerForm and all the *Viewer code To decouple this the
SignalDispatcher was created as a central way to forward signals to all
views that registers. Also the CPU registers state code now also lives
in the SignalDispatcher.

This means that now we can have multiple DisasmViewers since the code
doesn't rely on one and exactly one disasmView to exist.

As a side effect the QAction that would toggle breakpoints are now
disabled, since that code can no longer as the cursorAdress from the
one-and-only disasmView the old code assumed.
After splitting you end up with two SwitchingWidgets of the same type
In effect only BlendSplitter layout in use now
Also tried some fancier popup menu on the SplitterHandle, but this
causes a lot of crashes. I assume that the handler is already free'ed while the
mouseReleaseEvent is still being processed causing these SegFaults.

Also I got divide by zero errors when creating new StackViewer with an open
openMSX connection, it seems to handle the command reply before the widget is
fully initialized???

Also the changing of background (when connecting/disconnecting the emulator) in
the scrollarea isn't eassily triggered. If you resize by hand it will correctly
change the color not covered by the single widget, but simply setting an new
background doesn't cause an update, neither doesn explicitely calling update()
or repaint().
This widget simply contains a richtext label to explain the new workings
of the debugger.

The idea is that this is the default widget for a new SwitchingWidget
until the user is familiar with the workings and we have a setting to
switch this behaviour to a more regular blender like splitting of the
current area.
Use JSon format to save and load the current workspaces
TODO: set the enabledWidget status to current connection status.
Maybe save setting from the widgets in the SwitchingWidgets also?
And prevent direct emitting of the signal so that the SignalDispatcher
is the single source of truth.
In preferences you can now can select a default workspace to load when
starting. Also added a 'new user' setting so that the QuickGuide is
clearly visible for new users.
The CPU view/code debugger is now a workspace that can be added/removed.
Moved code in single class, and improved usage.
ESC will now cancel any ongoing edits.
Clicking on other tabs will now close the lineEdit.
And the tabs are now movable.
Thanks to a quick review of Wouter
Since there is code that doesn't use ui files, we now manually set the
QObject names to make debugging simpler
@sjaaq
Copy link

sjaaq commented May 10, 2022

Looks good with blendsplitter! I tried this version today but it seems the codeview is not jumping to the position of PC, it is always at #0000 for me. Am I missing something here? Stepping over code F8 also does not change the code view.
image

It also takes some time on my recent laptop to start the debugger (around 7 seconds) until the gui shows. The non-blendsplitter version is instant (for instance build 126).

This is going to replace the PaletteDialog that is now called from the
TileViewer and SpriteViewer, but was not yet used in the bitmapviewer...

As soon as those viewers are adapted, we will remove the PaletteDialog
@turbor
Copy link
Contributor Author

turbor commented May 11, 2022

Looks good with blendsplitter! I tried this version today but it seems the codeview is not jumping to the position of PC, it is always at #0000 for me. Am I missing something here? Stepping over code F8 also does not change the code view.

That is more because I missed something, more precisely I must have missed a signal/slot connection somewhere.

Allow me to quickly explain: The old debugger had exactly one code viewer, one register viewer, one stack viewer, one main memory viewer etc. You could hide them, but there was always one instance of them in memory. And the code used that knowledge. So the code viewer held the 64 KB the cpu could see, the register viewer was responsible for updating registers and telling the code viewer that PC had changed and the stack viewer that SP had changed, the slot view told the code viewer if the visible memory had changed etc.
So there was a lot of signals-slot connections between these single instances of the widgets and the debugger depended on those signals to work.

In the blendsplitter way of working you can of zero, one or even more of every possible widget. So the new class SignalDispatcher is now kind of a data bus that is responsible for all those signals and data centralization.
It is clear that I somewhere missed hooking up a few signals and slots when I was trying to understand the spaghetti of signals that was being thrown around.
I have not yet done an actual debugging session myself with the new code, being solely focused on getting all widgets to show up properly and having the data sharing working reasonably well.

It also takes some time on my recent laptop to start the debugger (around 7 seconds) until the gui shows. The non-blendsplitter version is instant (for instance build 126).

I'll have to look into that. There is a lot of extra internal overhead now before the GUI can be build but going from 0 to 7 seconds seems like a lot of overhead.
On the other hand: your screenshot suggest that you use the default workspaces, so I would suggest closing the other workspaces and saving a single (cpu) workspace as your default startup (there is a new tab under System -> Preferences..). At the moment you are also instantiating the sprite viewer, the tile viewer, the bitmap viewer and all the vdp register viewers. So in effect the debugger has to do a lot more work in comparison with the old debugger, so if you could try that first...

turbor and others added 16 commits May 19, 2022 23:14
When the 'slots:' indicator is removed in the header files the names do
no longer end up in the QMetaObject. This is not needed with the new Qt5
way of hooking up signal/slots, but the ui files use this to autoconnect
the slots to GUI elements by the on_<widgetname>_<signalname> naming
convention.
This no longer worked so we are fixing that here.
The VDPCommandRegViewer will be fixed more correctly later :-)
* Consistent indentation:
We currently have a mix of indentation style: sometimes we use 1 tab,
sometimes we use 4 spaces. I don't have a strong preference. But do use
the same style within a single function (preferably also within the
whole file). I guess some code was edited using an editor which did not
have tab-stops at 8 spaces. This lead to horribly inconsistent
(unreadable) indentation in some functions.

* Various typographical conventions:
** no space before comma, space after comma
** space before and after operators
** no space before or after parenthesis
Avoid repeating the same lookup twice (and risk making a typo between
the 1st / 2nd string literal).
No need to implement an empty default constructor.

No need to explicitly call the default constructor of a base-class.
Commit 2c3fd4c removed 'slot' annotations from header files. But this
(unintentionally) broke automatic (string-based) connection setup via
the 'setupUi()' call.

Commit 205a992 already partially fixed this. This commit does the
rest.
Let's get rid of the old PaletteDialog and use the MSXPalette as it was
intended to be used.
Now that the PaletteViewer has taken over all the functions of the
PaletteDialog we remove all traces of this old dialog.
MBilderbeek and others added 13 commits May 24, 2022 22:53
The autosync is only meant for the VDP palette to sync to the current
openMSX session, so make this more clear in the GUI.
Now we can decode 8 bytes as a character.
And since character definitions do not need to be aligned in
memory the hexviewer address can now be unaligned as well.
Keeping up to date with the latest work on the BreakpointViewer
Take decoded chars width into account.
Cyan line in decoded char to indicate marker address.
Allow shift+left/right when in unaligned mode to shift addresses in
single byte steps.
Since openMSX 18.0-106-ge55a4a904 (commit e55a4a9044b...) the TCL
command 'machine_info device VDP' now also returns the version string
from the machines XML config. This is now used to select the correct
view for the VDPRegViewer when decoding the VDP registers.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants