Community
Participate
Working Groups
Build ID: I20070625-1500 Steps To Reproduce: The problem is that Mylyn seems to remove all information from the context for items in resources that I close. To reproduce this scenario: - Create a new task and enable it. - Open some resources (e.g. Java source files), edit some code, etc... The edited methods show up in the (filtered) package explorer. - Now close all open editors. Mylyn removes all those items from the context (i.e. they are not shown any more in the package explorer.) More information: I find this very confusing. If I happen to close all editors before deactivating the context, all information in the context is lost! In my opinion, such resources should rather decay over time, as long as they are not opened again. Landmarks probably should even never decay.
You can turn that off from Window / Preferences... / Mylyn / Context / Manage open editors with task context... or change habit of closing editors and let Mylyn do that for you (i.e. it will close editors when interest on resource is decayed).
I changed this option for around one day, the result being that my context gets polluted with stuff I only open once to look up something. Trying not to change editors might be another solution... However, it's really hard to change such habits. Would it be possible to have Mylyn (optionally) issue a warning before closing an editor?
(In reply to comment #2) > Trying not to change editors might be another solution... However, it's really > hard to change such habits. Would it be possible to have Mylyn (optionally) > issue a warning before closing an editor? Eric: this is a *great* suggestion. This behavior of Mylyn's is both extremely surprising and extremely useful. If you're OK with it I'd like to keep it exactly as is, but the first time it happens pop up a dialog that tells the user that Mylyn considers this to be an indication of a file lacking interest and give them an option to disable this functionality (with a very strong encouragement to try it out). Manually managing editors is soooo 2006 ;)
(In reply to comment #3) > If you're OK with it I'd like to keep it > exactly as is, but the first time it happens pop up a dialog that tells the > user that Mylyn considers this to be an indication of a file lacking interest > and give them an option to disable this functionality (with a very strong > encouragement to try it out). Sounds almost perfect. The only change I would propose to (optionally) not only show it once, because - as I said - it's hard to change habits and the more Mylyn bugs me, the earlier I will learn it. So my proposal would be a dialog as follows: "When closing editors, Mylyn will normally considers this to be an indication of a file lacking interest." Buttons: [Close Editor] [Close Editor and do not warn again] [Cancel] [Disable this feature] Or even better, replace [Close Editor and do not warn again] by a checkbox [do not warn again], whose value is taken into account if [Close Editor] is hit.
I'd suggest to have two checkboxes on that dialog: don't warn about editor closing and disable editor management, and make sure bot of those checkboxes are also presented in the Mylyn global properties (so user can reenable them back). Then dialog would have two concise buttons [Close editor] and [Cancel]
(In reply to comment #5) Even better. In addition, I was wondering whether it would even be possible to (again, optionally) disable the close-action altogether for editors. I.e. the appropriate context menu items and the cross on each tab would be removed or grayed out.
I would like to restrict this dialog to be a standard PONT (point of need training) since that's a common and understood UI idiom, which means it should only have a single "Do not warn again" checkbox, but could have entry points to other parts of the UI if necessary (e.g. hyperlink to prefs page). However, I think I should be able to make it in a way that meets the above concerns.
(In reply to comment #7) Sounds great, Mik. Are you going to support this any time soon?
Yes, it is schedule for 2.1 and there is a chance can get it into 2.1M1 (which should happen within 5 weeks, depending on the platform schedule).
The mapping of Close Editor to Remove from Context has probably caused so much confusion that after a few design discussions with Rob and considerations of newsgroup feedback we have settled on the following: * This facility is now a separate preference from the editor management * While still considered useful, this facility is off by default This means that we no longer need a dialog. Details will be in the New & Noteworthy. Build with this change will be available within 2 hours.
Created attachment 79226 [details] mylyn/context/zip
Great. Thanks for getting this done. I guess I should update asap.
Out of curiosity what was the reason to not use warning dialog and keep this feature on by default?
(In reply to comment #13) > Out of curiosity what was the reason to not use warning dialog and keep this feature on by default? That was a very tough call, and frankly I'm still not sure that making it off by default is the better choice, and there may still be time to change this. My reasoning for making it off by default is: * This option has caused more confusion (bug and newsgroup posts) than any other part of UI automation that we make on by default. * If the majority of users turn it off when they see this dialog the annoyance of a having a dialog come up within the first few hours of using Mylyn may not be worth the benefit of this mapping. Rob favored leaving it and he had been raising the need to address this due to the confusion. My main concern is that making it off may overly bias for the first week of the users' experience. Once you grow accustomed to this, there is a very real benefit and consistency to having your open editors closely match your context. Additional thoughts?
I don't see how one time shown dialog would be annoying and it is also unclear why do you think that majority will turn it off. BTW, "Map editor close to remove from context" is really confusing option, perhaps it is better to use something like "remove from context on editor close"
Any dialog that pops up is annoying, and Mylyn currently doesn't have any other dialogs of this sort in a normal worklfow. However, as per the points in commeth#14 in this case I agree that it is the better option so a dialog will now show once as suggested on this bug. Good point about the confusing option, changed it to: "Remove file from context when editor is closed".
Just to be clear, the option is back to being on by default (i.e. no change from previous releases). Since it is a new option the dialog will show on the first time this action tries to run even if the previous combined option was on.
Created attachment 79290 [details] mylyn/context/zip
Mik, could you change the message for this dialog (EditorInteractionMonitor.editorClosed) to say that the dialog will *not* show again since this seems to be the behavior?
Shawn: thanks for catching that! The final message is: "Closing a file automatically removes it from the Task Context. " + "This is recommended in order to make the open editors match " + "the focused views. It can be disabled via Preferences -> Mylyn -> Context.\n\n" + "This dialog will not show again."
Using "file" related to editor can be misleading. I'd suggest to change wording and also use standard "don't show this" ui. So, something like that. "Corresponding resource will be removed from the Task Context on editor closing.\n\n" + "This is recommended in order to make the open editors match the focused views.\n" + "It can be disabled via Preferences -> Mylyn -> Context." [x] remember my decision [Accept] [Skip] Using such checkbox on the dialog could also help to remove this reference to the corresponding setting. I think it is hard to remember such information when it appear on the dialog that is shown just once.
Eugene: please file a new bug with the request (e.g. using a MessageDialogWithToggle). I was tempted to do that but wanted to keep it as simple as possible, and keep in mind the possibility of linking the check box is a link or button prompting the preference page. The word "file" is used right now because the functionality only works for files, but yes, it could be extended to other editors. The word "resources" is not commonly understood by users who are not plug-in developers so we would have to use "element", but that word is more vague than file.
I am somehow confused by "please open another bug". It is been suggested in comment #4 on this bug report and then dialog UI discussed further, but then implemented in a completely different way, or there is a total misunderstanding about that you meant in comment #7.
