You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 19, 2024. It is now read-only.
Context: currently, the only indication of the parameters with which the current display was fetched is the actual values of the configuration inputs (address, offset, length). If the user changes those values and either doesn't try to fetch memory or tries and fails, the display is not updated, and we lose the connection between the inputs and the current state of the display. It would be desirable to display the parameters used for the current state of the table apart from the inputs so that the user can always tell what context the data displayed comes from.
Maybe an alternative would be to add some information to the table display indicating the parameters with which the data displayed was fetched. That would at least address the potential for confusion.
I personally like this idea. Since it might require a little bit of UI re-design maybe it's better left for a separate PR if that's OK with you.
How would you feel about moving the search area outside of the tab?
At the moment a user needs to click on the top-right button to create a new memory tab, then perform a search. Maybe we could just put the search parameters at the top of the panel and the user would only need to perform a search to get a new tab created. If the search is successful and the tab is correctly created we might show there the parameters used for the search in the new tab, which would be only updatable when navigating the memory using the Load more buttons.
Context: currently, the only indication of the parameters with which the current display was fetched is the actual values of the configuration inputs (address, offset, length). If the user changes those values and either doesn't try to fetch memory or tries and fails, the display is not updated, and we lose the connection between the inputs and the current state of the display. It would be desirable to display the parameters used for the current state of the table apart from the inputs so that the user can always tell what context the data displayed comes from.
I personally like this idea. Since it might require a little bit of UI re-design maybe it's better left for a separate PR if that's OK with you.
Originally posted by @federicobozzini in #132 (comment)
The text was updated successfully, but these errors were encountered: