Community
Participate
Working Groups
When you open and then close some Java files, Mylar filter on Package Explorer view leave interest on package nodes. I believe these nodes should disappear as soon as there is no interesting classes under.
Definitely a bug. Bug is this the same behavior as bug 118541?
*** Bug 107948 has been marked as a duplicate of this bug. ***
*** Bug 129198 has been marked as a duplicate of this bug. ***
A related and equally annoying problem is that containers (folders, packages) lose interest too quickly even if they might have interesting resources in them.
When I add below code at the last of method MylarContextManager.manipulateInterestForNode(IMylarElement element, boolean increment, boolean forceLandmark, String sourceId), the defect maybe can be fixed, and it need more test //update parent interesting String parentHandle = bridge.getParentHandle(element.getHandleIdentifier()); IMylarElement parentElement = getElement(parentHandle); manipulateInterestForNode(parentElement, increment, forceLandmark, sourceId);
Created attachment 35722 [details] a strongly suggested fix patch It should can fix this problem. Again, I don't complete understand the meaning of propagateToParents in method handleInteractionEvent(InteractionEvent event, boolean propagateToParents). So I update the parent maunally. In general, I strongly apply this patch and do some enhancement based on this patch. It worth us to do it. Please believe me.
Comment on attachment 35722 [details] a strongly suggested fix patch I forget another file. In addition, the fix is also updated.
Created attachment 35730 [details] a strongly suggested fix patch Update two files.
Comment on attachment 35730 [details] a strongly suggested fix patch A new patch is provided
Created attachment 35732 [details] a strongly suggested fix patch it should fix this bug Refactor the patch to add a method needUpdateParent(IMylarElement). I tested it and it works well. I spent much time on it and I really suggest to apply this patch. In addition, I suggest to use two methods to handle note interest instead of manipulateInterestForNode, which are incrementInterest and decrementInterent.
Wang, it is a great efford, but it really make sense to write unit test for this issue. Here is an entry form Mylar's documentation for contributors: http://www.eclipse.org/mylar/doc/devref.php#contributing-patches ---- For most patches, a failing unit test should be written first. Before creating a new JUnit test class class check the components test suite (e.g. AllTasklistTests) for similar test cases (e.g. AllTasklistTests.suite()). ---- I am sure Mik would review your code, but it would save him some time if he would get test for this issue. And it could save time for you as well, so you won't need to submit 3 patches fixing each other in several hours.
Thanks for you hard work on this Wang, I am raising the priority to ensure that I get to your patch this week, and because it is important that this gets fixed for 0.5. But Eugene right, and a unit test is key for any patch of this form. Only a slight change to the interest model can have big consequences to how it works after a context has been active for a long period of time, so you unit test(s) should document and verify every change that you've made to the model. Please take a look at the tests in ContextManagerTest and write a similar one, then I will try to apply your patch and see if I need to extend the test coverage further.
The collory of this is fixed (bug 117979), so this should now be easier, but some additional model management improvements will needed to be done as part of this.
Please consider to raise priority for this? It is been really old and quit annoying issue...
Yes, this is annoying and we need to improve the corresponding bookkeeping in the model (i.e. propagation of interest to parents).
All model changes will be made post 0.7.0.
Deferring.
Created attachment 60224 [details] Package explorer - screenshot-1
Created attachment 60225 [details] Package explorer - screenshot-2
Can you please raise the priority for this bug? I have a high workspace, with +20 projects, not so large, but with inter-dependencies, so I touch many of them while working on a task. The problem is that after some time working, the package explorer gets in a "bloated" state, where the focused UI begins to confuse instead of help (hey Mik, this causes a vertical scrollbar to appear!!! this is unacceptable!! ;) I identified a lot of uninteresting elements in the previous 2 screenshots, among them, the empty packages which are the original focus of this bug. But I also identified other elements which I don't like to be there. I don't know if they are caused by the same bug or not. So, they are: - rt.jar, screenshot-1 - I think this was caused by some J2SE class that lost interest, but the jar remains. There is no need to show "jars" or library containers who don't have interesting classes. - import declarations, screenshot-1 - I remember there was some import statements with interest because I focused them on java editor, but they lost interest and the empty "import declarations" container remains. - Java file with no class focused, last highlight from screenshot-1 - not so harmful, but quite strange. - Binary class "DateMidnight.class", screenshot-2 - the same as above. - Empty folder, screenshot-2 - there was a text file I was editing on this folder; after some time it lost interest, but the folder remains. Totally useless. IHMO, regarding java elements, a container (jar, library, java file, etc.) would retain interest only if it has at least 1 java class/interface focused.
I will try to do this for M2, but task context model changes of this sort are very involved. But I agree that the extra nodes are unacceptable. Scrollbars are evil ;)
Created attachment 60228 [details] Package Explorer - screenshot-3 Another one I caught today: it left a interest on org.eclipse.mylar.bugzilla.tests project, but IMHO it does not help me very much. The funny is that I don't even remember having touched or navigated on anything in org.eclipse.mylar.bugzilla.tests project while working on this task.
About the second highlight on screenshot-3: I know why it raised a interest on org.eclipse.jface.layout: I opened some layout classes (GridData, GridDataFactory, GridLayout) because I was working on a patch for task editor, but I didn't remember some methods and wanted to see their javadoc. I opened them several times and I'd like to Mylar automatically recognize them as something important/recurrent to this task, and don't let them lose interest so quickly. In another words: if I'm working on a GUI-related task and often navigate through layout APIs, it is natural to have Mylar recognize them as something important.
Moving to RC1 due to API and Tasks UI focus on 2.0M3.
Any context model changes unfortunately have to get postponed until after 2.0. I would really like to fix this but it will involve a fundamental change in how we do the bookkeeping of interest propagation to parents and handling of decay.
This has been considerably improved and most of the underlying problem (bug 207225) has been addressed. Will keep the bug open while we monitor the effects on longer running task contexts.
There's not clear solution to this without doing some major changes in the bookkeeping of the context model. Scheduling for exploration in 3.1.
Mylyn has been restructured, and our issue tracking has moved to GitHub [1]. We are closing ~14K Bugzilla issues to give the new team a fresh start. If you feel that this issue is still relevant, please create a new one on GitHub. [1] https://github.com/orgs/eclipse-mylyn
