halshow: show pins and parameters in one tree#4147
Conversation
Pin and parameter names share one namespace, so present them in a single 'Pins & Parameters' tree. Leaf node ids keep the real type (pin+/param+) so show, watch and popup handlers work unchanged; param leaves use the watch-tab param color. A 'Separate parameters' checkbox in the Tree View menu (saved in preferences) restores the old layout.
|
Will this not be superfluous when we get rid of the parameters? |
|
This is an alternative to dropping the parameters, as Bertho said and wrote, parameters can coexist, the getter/setter can get us there, this solves the "I can't find them" argument, which seems to be the main case for removal? |
|
Regardless what the ultimate fate of parameters will be. The current situation is that we have them and are a far cry from getting them removed. Fixing the presentation in halshow now is a good thing (even if it will be changed again later on). My work on getter/setter has uncovered quite a few situations where things were (ab)used in ways as very expensive storage (due to the volatile modifier). Other places have (sometimes odd) combined normal/hal memory constructs. None of these situations can be fixed automatically (or search/replace) and need some code adaptations to work as intended. Only when the interface is clean, then removing "parameters" is possible. However, you could simply see them as pins with different attributes, which is possible too. The underlying structures will eventually be merged in the cleanup. Then there is ample time to discuss whether we should drop other attributes. |
|
Parameters let a component author state that a value was not intended to be changed in real time. I still don't see why that signal has no value, or why we should throw it away. |
|
There is one more issue that can be considered a "problem". Parameters cannot be used in signals. |
|
I think it would be simpler to get rid of parameters and just use pins. |
|
Well, if getter/setter ever gets voted in, then you can eliminate the entire parameter branch in an experiment by only changing five functions in hallib. |
But they can be changed, so its more or less only a naming...
There is no checkbox for the setting but I don't think we need that. Don't get me wrong, it's fine for me to have them together in the tree. Edit: |
|
Toggle is in tree view menu, not really a checkbox, but it does get a check mark if you click on it |
In the filter/search settings? I didn't expect it there.. |
|
Tree view, top menu mate Sorry not on the computer or I'd send you a picture |
|
I'm not removing parameters, so I don't think I have to adapt the menus yet, I can keep it as draft and remove parameters menus if that's what we are going for, I still think the distinction is valuable, simplicity at the storage level does not require throwing away the concept of having pins with parameters attributes |
Yes sorry, I meant in the bigger picture on the system, which was not really what your talking of hete. Ill be quiet now :) |
Ah, found it. There I would have expected it even less :)
Of course, my bad. Forget my comments about that. |
It is very much related to the Tree View, but no complaints about moving it, we could keep it in both places, I don't think it will hurt. |
It's also a persistent setting ;-). Two places would be too much for that little setting. |
Pins and parameters share one namespace, but halshow presents them as two parallel trees, so users keep looking for an item in the tree where it is not. This merges them into a single "Pins & Parameters" tree:
pin+name/param+name), so show, watch, popup menus and saved watchlists work unchangedTested with a sim config and a driven xvfb session: tree build, filter (plain and full-path regex), watch tab, Show in Tree, mode toggle, preferences persistence. Docs screenshots not updated yet; I will do that if the approach is agreed on.

@BsAtHome this follows your point that nothing prevents one tree with a uniform search, since pin and parameter names cannot collide. If pins and parameters later merge internally behind the getter/setter work, the UI is already in the right shape for it.
@rene-dev I am aware this goes in the other direction than your noparam branch: it keeps parameters and shows them where users naturally look instead of removing them. Is there a discussion to be had about which way to go, before this moves forward?