Community
Participate
Working Groups
configured mylyn, explicitly unchecked prefrences -> tasks -> context -> [ ] remove file from context when editor is closed. nevertheless, after a while closed files disappear suddenly from the context (so far both .java and text files). this is basically the same issue as 226464 which i reported in april 2008, was marked as a duplicate of 232664 and has been closed as "RESOLVED FIXED" in october 2008 -- but still is with us ... -- Configuration Details -- Product: Eclipse 1.3.2.20110218-0812 (org.eclipse.epp.package.jee.product) Installed Features: org.eclipse.mylyn_feature 3.4.3.v20110131-0100-e3x-7Z7f7AFBBoPbVQ7iNFebXJDypa
The interest of elements that are not interacted with decays over time. This ensures that the navigator views only show elements most relevant to the task you are working on. Without decay views would get overloaded quickly with that you may have only interacted with briefly. The elements remain in your context however and you can make the visible from the context page on the task editor by moving the threshold slider to the left. Arne, can you describe what the behavior is that you expect?
the idea of minimizing visible context may be appealing, but - how do you define "decay"? not having interacted with a file for a period of time does not mean, that it isn't crucial to be easy accessed -- hence, i need it to be visible all the time in case i need to open it immediately - "overload" is a s subjective as color or font size. what for one may be an overload already may leave still room for more to others - it is not clear to me (the average user?) why files suddenly disappear - "make the visible from the context page on the task editor" is a solution, which does not present itself naturally and the editor might not be open anyway - if there's an option "remove file from context when editor is closed." i expect it to be the one to steer appearance in the context tree visible. but obviously it does something completely different -- but for any kind of behaviour, i expect it to be configurable so, i expect: - _all_ kind of appearance/disappearance has to be configurable (what, when, why) -- if automatic clean up is a good idea to the majority, make it the default, but do not force it upon everybody w/o way to disable it - display some kind of information about what just happended (that progress icon in the lower border springs to mind, which could simply display an tooltip when hovering)
> the context page on the task editor which btw is another issue: how do i get there? apparently i am to have the "tasks" view open, which will "overload" my existing setup of perspective ...
*** Bug 343133 has been marked as a duplicate of this bug. ***
Copied over from Bug 343133 for reference .... > To restate my question as simply as possible, files created / modified as part > of a task do seem to be subject to decay and eventual removal from the task > context - is this a bug or by design? Yes, this is by design. Files do not actually get removed but the are filtered from focused views when their interest level falls below a certain threshold. > If it is by design, that is a problem as, if I add a new file or modify an > existing file while a task is active, that file will always be relevant to that > task and should never be automatically removed. Elements that are modified get a higher interest level than elements that are selected only so it takes much longer for their interest to decay below the threshold. Still, when working on a task for a long time you may end up editing many files and focused views would become overloaded without decay. Also see bug 178891 for a related discussion. It would be helpful if you added your statements to bug 341631 so they doesn't get lost.
Hi Steffen With respect to your comment "Yes, this is by design. Files do not actually get removed but the are filtered from focused views when their interest level falls below a certain threshold" There is probably no right answer to the question of whether new / modified files should be subject to decay but, in my opinion, they shouldn't. Maybe I think this because of the way I work (which may be wrong) or the nature of the changes I make to the application I work on. A typical task I might be assigned is to add a new report to the application. This may involved adding to / changing the database schema, Hibernate mapping files, DAOs, business layer classes, property files, JSPs, JSTL tags, Spring configuration files, unit tests, and so on. The quickest way for me to implement the new report is to find a similar report that already exists and base the implementation of the new report on the implementation of the existing report. This is a common modus operandi. Ideally, I would open the Mylyn task that is associated with the existing report to see the files that were created / modified during the completion of the task and the files that were somehow considered relevant to the task. Unfortunately, I can't do this with Mylyn because the context of the task associated with the existing report does not necessarily contain all of the created / modified files. Any suggestions as to how I can change my method of working to a better one and that works with Mylyn? If not, any chance that we can make Mylyn more configurable, e.g. having an option to make Mylyn not decay new / modified files? One last point on methods of working. You said that "... when working on a task for a long time ...". Again, in my opinion, tasks by nature don't take a long time. A software development task may take weeks to complete but not months or years. I am a typical software developer working on a typical application. I really want to use Mylyn but, as it stands, it is not useful to me. Hopefully, we can make it useful. Regards Stephen
i don't think there's a "wrong" way to work here -- only "not the way it was intended to be used". whenever i test this feature it is because i want a way to get a reliable and stable set of files -- and changes to that set must be done by me and me only. that's till not the case and thus is topped using it again, although i really could use a limiting facility. just because i haven't touched a file for a while doesn't mean i don't need it in my set. the decay as a default might match the way the developers of this feature want to work with it and hence it is justified to make it the default (at least unless a majority of users votes otherwise). but for every feature that automatically changes something there must be a simple way to disable those automatics! in this case, the presumption that "not touched in a long time" equals "not needed anymore" is a very clear case of "that's not necessarily true always and for all". hence, it has to be configurable by the user.
Arne I think we are in agreement here. The principle of automatically managing context is sound BUT the management must be configurable so that it is useful across a broad range of personal development styles AND defaults must be sensible. From my experiences with Mylyn, the default behaviour should be that 'things' (e.g. Java source code files) added or changed while a task is active are never automatically removed from the task context. Maybe someone thinks that this behaviour should be configurable. I'm not bothered if it is or isn't although I strongly believe the default should be to never remove them. I think automatically removing things from task context that have been viewed is correct although, again, maybe this should be configurable. A point worth mentioning (although here may not be the place to make it). The team I work in (an average team in an average large financial institution) has about 15 relatively competent software developers and not one of them uses Mylyn. In fact, only one or two have ever heard of it. To me, this suggests that the current incarnation of Mylyn is not the panacea to low productivity that Mik's videos and articles have led us to believe. Hopefully, some developer input such as ours may change that. Steve
i miss a option to configure the decay behavior. for me the best is if files disappear from context only by close of editor.
*** Bug 354279 has been marked as a duplicate of this bug. ***
I wonder if it would be useful to add an affordance to views that would allow temporarily changing the threshold for interesting elements, so that you wouldn't have to use the context preview page for that.
over three years and a major version jump of Eclipse -- and yet, this annoying bug is still there. any change this rather trivial issue is fixed in a near future? afterr all, _disabling_ an automatic that runs amok should be rather simple, shouldn't it? btw: as per commt #1: "the task editor by moving the threshold slider" - that slider has no indicator in which direction to move to do what (in fact, it has no label to explain what it is for at all) - you cannot reset it to the state it had before, it doesn't even indicate where you were or where you are now - the kind of filtering is so broad, it is close to useless -- in a single movement, how small it may be, it switches from little to nothing or all, there's little to no control over its effect in short, even that (in comment #3 already dismissed) "workaround" does not help
As previously mentioned, the current behaviour is as designed. It is one of the key features of Mylyn context. You can always disable context filtering if you don't want it. So I wouldn't call this a bug, it's a feature request to make interest filtering customizable or add another filter mode which shows everything that was ever in the context. I think that's a great idea and if you'd like to make a contribution, we should discuss design ideas on this bug.
this is a bug. period. rule #1: the user decides what to do -- any automatic has to defer to the user's decision. if an automatic fails to provide for overriding by a user, this is a bug. the way entries disappear is incomprehensible, one never knows what will be there and what not. this is a bug user cannot influence what entries disappear and what entries remain. this is a bug. disabling context filtering is no solution, but a workaround, by proposing it you basically acknowledge that content filtering is not fit for productive use and fails to address any of the above three points.
As I said, the behaviour is intended. If you'd like more control over it, I encourage you to make a contribution.
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
