Community
Participate
Working Groups
Build Identifier: HEAD The Debug Hover should receive similar modifications as the variables and expresssions views: - check if it is save to ask for all children - track a child count limit if not - provide the <more children> element The current implementation shows as many elements as currently being pushed for in the variable/expressions view. If they didn't provide a value, one child is shown. So no real problem, just a bit confusing sometimes. Reproducible: Always
I hadn't thought of this. I think that once bug 302121 goes in, the current bug will become very important. Having a user move her mouse over code and having it hang because we ask for all the children is pretty bad.
(In reply to comment #1) > I hadn't thought of this. I think that once bug 302121 goes in, the current > bug will become very important. Having a user move her mouse over code and > having it hang because we ask for all the children is pretty bad. I'm not quite sure what you are saying. I used the hover frequently during my stress testing. MIExpressions + MIVariableManager is so defensive that if the caller does not provide a limit, a limit of one is used. Committing 302121 should not cause any serious problems. I entered this bug to remind ourselves to fix a cosmetic bug, which is: - you only see one child, even if there are more - if you see more the one, then it it besause the variables or expressions view already made them fetch more children. - there is no opportunity to fetch additionional children from the hover.
(In reply to comment #2) > (In reply to comment #1) > > I hadn't thought of this. I think that once bug 302121 goes in, the current > > bug will become very important. Having a user move her mouse over code and > > having it hang because we ask for all the children is pretty bad. > I'm not quite sure what you are saying. I used the hover frequently during my > stress testing. MIExpressions + MIVariableManager is so defensive that if the > caller does not provide a limit, a limit of one is used. Committing 302121 > should not cause any serious problems. > > I entered this bug to remind ourselves to fix a cosmetic bug, which is: > - you only see one child, even if there are more > - if you see more the one, then it it besause the variables or expressions view > already made them fetch more children. > - there is no opportunity to fetch additionional children from the hover. So it is only the <more children...> that is missing? That is not as big a deal. I'm relieved :-)
(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > So it is only the <more children...> that is missing? Yes. I volunteer to look into providing the patch (as I do for any of the other [pretty printing] bugs I submitted, but it might take a couple of weeks until I can find some time to work for the common good:-(
Created attachment 182533 [details] Fix
That was easy :-) Committed to HEAD. Thanks Jens.
Before I mark this as fixed, I have one question. I noticed that if we open a pretty-printed object in the expressions view and fetch more children, this will not affect the variables view or the hover. What I mean is that if we increase the limit in one of the views, that limit will not be increased for the same variable, in the other view or hover. This is because the hover, the variables view and the expressions view each have their own instance of GdbVariableVMNode which stores the limit in its own copy of childCountLimits. Jens, do you think that a limit should be unique per expression independent of the view, or is it ok to have it different for each view? I don't think it is a big deal, and it may even be better the way it is now. I just never noticed this before. What do you think, from a user's perspective?
*** cdt cvs genie on behalf of mkhouzam *** Bug 326660: Adapt the new Debug Hover to support Pretty Printed objects [*] GdbViewModelAdapter.java 1.7 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb.ui/src/org/eclipse/cdt/dsf/gdb/internal/ui/viewmodel/GdbViewModelAdapter.java?root=Tools_Project&r1=1.6&r2=1.7
(In reply to comment #7) > Before I mark this as fixed, I have one question. > I noticed that if we open a pretty-printed object in the expressions view and > fetch more children, this will not affect the variables view or the hover. > What I mean is that if we increase the limit in one of the views, that limit > will not be increased for the same variable, in the other view or hover. > This is because the hover, the variables view and the expressions view each > have their own instance of GdbVariableVMNode which stores the limit in its own > copy of childCountLimits. > Jens, do you think that a limit should be unique per expression independent of > the view, or is it ok to have it different for each view? I don't think it is > a big deal, and it may even be better the way it is now. I just never noticed > this before. > What do you think, from a user's perspective? I was thinking about it, too. And I decided for the current solution simply because I think an action in the one view should not affect the content in the other. E.g. in the hover, I might not want to see that large number of children I'm looking at in the variables view.
(In reply to comment #9) > I was thinking about it, too. And I decided for the current solution simply > because I think an action in the one view should not affect the content in the > other. E.g. in the hover, I might not want to see that large number of children > I'm looking at in the variables view. Sounds good. We can always change later on if we get different user-feedback. Thanks
