search

mcu-debug / rtos-views

RTOS views for microcontrollers
MIT License
24 stars 11 forks source link

Internal: Restructure the data and view models #29

Open haneefdm opened 1 year ago

haneefdm commented 1 year ago

This is spawned from the comment https://github.com/mcu-debug/rtos-views/issues/2#issuecomment-1439040705

A couple of things:

It is one of those things. I started out small, I didn't know much about WebViews back then and followed examples to generate the entire HTML/CSS on the fly. But with memory view, I learned a LOT, and I used React

My worry is that React is not that easy or simple for most people. It also has quite a few UI bugs/quirks that they can't fix for legacy reasons. Using React (or something else) means that the view(s) is totally separated from the model(s)

I don't think our model is generic enough or a view can handle cases. Too many special cases. Once we separate the model and view, we have to be strict and we may need to look at everything and see what it takes -- maybe very little, but I don't think so.

haneefdm commented 1 year ago

Lets discuss

vrepetenko commented 1 year ago

maybe use something like this: https://github.com/DTeam-Top/vscode-page

haneefdm commented 1 year ago

Hi @vrepetenko thanks for the link. I think I implemented most of something like that in the memory-view

My message passing is a bit more sophisticated than that I think.

I used react to generate/manipulate the DOM. I can't believe how limited it is and how many bugs I found, but most people know those traps and work around them.

Unlike the memory viewer, this is so much simpler so React might just work fine. Even better if we don't have to modify it frequently and we focus on the model.

But we don't need React. We can use plain JS/TS.

Today, we generate plain/complete HTML/CSS. Ugly as it is, there would only be a benefit if a better programmatic was nicer.

haneefdm commented 1 year ago

@vrepetenko You posted this image

image

Is this something you developed and if so, could you share details?

vrepetenko commented 1 year ago

hi @haneefdm ! Yes, I will share details tomorrow. But panel state restore is not implemented yet, it needs messaging to save selected tab as I understand. And TRACE need it as well: read trace data by user request from XRTOS tab, it can take up to 10 seconds to get all data.

vrepetenko commented 1 year ago

Is this something you developed and if so, could you share details?

https://github.com/vrepetenko/rtos-views/tree/feature/ChibiOS-Support

haneefdm commented 1 year ago

Very nice. Yes, I agree that we would like to see more than just threads. It is where we started. There is nothing wrong with each OS having different kinds of information.

But what you have just done seems just as open-coded as what we had, except very custom to ChibiOS. That is fine. Even for threads, you don't have to use what I created for common use. What I do care about is matching the look and feel very closely, and using vscode UI elements.

With your use of TABs, there is no state information to remember which TAB should be exposed on a refresh/reload. It would be very annoying if the view is constantly reset. If I was doing this like a real webview with JavaScript/Typescript attached to it, I would also not generate the HTML for TABs that are not visible - but it could be a minor optimization. There is currently a global js file where you can add some javascript to remember state. You can probably also do it inline as well.

https://github.com/vrepetenko/rtos-views/blob/feature/ChibiOS-Support/resources/rtos.js

vrepetenko commented 1 year ago

yes, It was done in current style, nothing new in there, except getHTMLDataGrid. ) ok, I will add JS for tab change event listener to rtos.js and rtosPanelsState (active tab) to RTOSBase.

haneefdm commented 1 year ago

When you save/restore state, lets use a convention for it to be RTOS specific state.

S Something like <rtos-name>-<state-var> You can make that state an object so you can store everything in it -- even if you start with just one property.

I can't remember the lifecycle of the state variable saved on the vscode API available to webviews. Session or what? It needs to be a minimum of a session. With memory-view, I made it to be a state variable for the workspace to make it work across sessions.

If needed, I can add the infrastructure for saving at the workspace scope. Or you can take a stab at it. Let me know

Thanks for your work, btw