Community
Participate
Working Groups
N20070622-0010 'Open With > Other... > External Programs' needs a cancellable progress monitor. When I do this the first time, I'm blocked for more than half a minute. Later invocations are a bit quicker, but still take some time. @see EditorSelectionDialog.fillEditorTable() You should use IProgressService.busyCursorWhile(IRunnableWithProgress) instead of manually fiddling around with the cursor in getExternalEditors().
Mass update - removing 3.4 target. This was one of the bugs I marked for investigation (and potential fixing) in 3.4 but I ran out of time. Please ping on the bug if fixing it would be really important for 3.4, and does not require API changes or feature work.
Remy is now responsible for watching the [EditorMgmt] component area.
(In reply to comment #0) > 'Open With > Other... > External Programs' needs a cancellable progress > monitor. When I do this the first time, I'm blocked for more than half a > minute. At the moment, all operations are "batched". The programs are retrieved using SWT's Program API, the programs are filtered, and the images are finally created. This doesn't seem to tie in well with cancellation per se. Markus, what did you expect to see if the operation was cancelled? A blank table? For bookkeeping purposes to remind myself, the other related bug is bug 173759.
> Markus, what did you expect to see if the operation was cancelled? A blank > table? Either that, or switch to 'Internal Editors' (which opens without delay).
I think the empty table idea is okay. If the user goes back to the 'External Programs' section it'll reload, does that sound okay with you, Markus? I'm not too gung ho about adding a 'Reload' button.
> I'm not too gung ho about adding a 'Reload' button. Yeah, that would be overkill. But after canceling, the only options the user has are to close the dialog or to switch to the 'Internal editors' tab ... I mean ... radio (see bug 173095). I don't think it would be that hard to implement the 90% case (jump to the other tab). That would elegantly solve all UI issues (no need for reload, no empty table, saves users a click).
I will see if I can bring this up on the UI call tomorrow and get some feedback from the other team members. Thanks for your comments thus far, Markus.
We discussed this briefly on the UI call. One suggestion was to use a job instead and have the table show up with a 'Pending...' node or whatever and then the content would be replaced when the calculation was done. This would allow the fetching to be done in the background when the dialog first came up. There were however concerns over how CPU intensive this would be as the user would be forced to pay the cost of asking the OS for its editors even if they just wanted to use an internal Eclipse editor. Of course, we could delay the job scheduling to only occur if the user was actually looking for external editors. Note that I did make an _incorrect_ comment on the call. The "page" selection _is_ preserved so if you select an external editor. You'll be back on that page the next time you open the dialog. Susan: To get the dialog to show up, just right-click on a file and then use Open With > Other...
The Job idea sounds good (only scheduled when 'External Programs' is selected, canceled when the user closes the dialog).
Yes, I think the job is the right way to go. That way, the user can always go back to internal if they wish or cancel the dialog (I think explicit cancel/automatic radio jumping seems like overkill) fyi, if you end up using DeferredTreeContentManager for this (which might be overkill) or even some other job, you'll have the "no progress can be shown anywhere while the dialog is open" problem described in bug 293098. Of course, it sounds as if there's not much room to report progress anyway given the nature of the SWT API. I also agree that the use of radio buttons is a bit odd but that is bug 173759.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
