Community
Participate
Working Groups
Open test editors are not refreshed when removing referenced test assets. [See https://bugs.eclipse.org/bugs/show_bug.cgi?id=220555#c4]: Jerome, we need to refresh the open editors when removing referenced test assets. In theory, open editors perform a reload because the resource they opened have changed. [See https://bugs.eclipse.org/bugs/show_bug.cgi?id=166025#c76] Would be great if open editor could be notified when a change occur, so that the refresh can be made in memory, instead of having to reload the file. It's a bit complex to implement, because not only we have to notify editors that something changed, but also what, and each editor must update its information for each kind of change (resource disappeared, renamed, etc) it's not a trivial change....
Jerome, please provide a sizing.
works needed : . implement a mini protocol for editor change, that notify : - what changed (EMF resource) - how it changed (logical rename, physical rename, physical move, delete) . update all editors to be able to deal with theses informations estimated time : coding 2 weeks minimum + huge testing (lots of potential side effect)
(In reply to comment #2) > works needed : > . implement a mini protocol for editor change, that notify : > - what changed (EMF resource) > - how it changed (logical rename, physical rename, physical move, delete) > . update all editors to be able to deal with theses informations > estimated time : coding 2 weeks minimum + huge testing (lots of potential side > effect) > Jerome, please update the Orig. Est. field with your estimate.
update estimated work including testing part
Deferring to future as approved by the TPTP PMC (http://dev.eclipse.org/mhonarc/lists/tptp-pmc/msg04926.html).
after some testing, it seems that i can reuse an evolution i coded one year ago that allow the user to put listeners around elementary changes (move/rename/delete/update) if i make the editor register on theses refactoring listener, they could be updated directly i'll have to code a filter to only be notified on changes relative to the things displayed in the editor to decrease a lot the number of notification. ideal would be to make this registering on higher possible level (in BaseEditorExtension perhaps) and refine it on the specialized editors i will try to make a prototype with deployment editor to see if it's a doable solution Paul, any thoughts on the subject ?
seems there is some strange behavior on editor opening that make all this listener mechanism to not work (created bugzilla 312025 for this problem) working on it before continuing my prototyping
(In reply to comment #6) > after some testing, it seems that i can reuse an evolution i coded one year ago > that allow the user to put listeners around elementary changes > (move/rename/delete/update) > if i make the editor register on theses refactoring listener, they could be > updated directly > i'll have to code a filter to only be notified on changes relative to the > things displayed in the editor to decrease a lot the number of notification. > ideal would be to make this registering on higher possible level (in > BaseEditorExtension perhaps) and refine it on the specialized editors > > i will try to make a prototype with deployment editor to see if it's a doable > solution > > Paul, any thoughts on the subject ? Seems like the right approach. As you suggest, we should only emit useful events for the type of listener. Being considered for TPTP 4.7.0.
Given that we enter TPTP 4.7.0 shutdown on Monday (http://www.eclipse.org/tptp/home/project_info/releaseinfo/4.7/schedule.html) and the size of this change, deferring to future. Jerome, please attach the patch once complete and we will target the defect to the next release.
Created attachment 170614 [details] patch (first part of mechanism) this is a partial patch it add a mechanism where editors are notified when a resource they display is affected by a refactoring event (in this patch, there is a console display on listener adding/removing and on refactoring notification to illustrate the mechanism) example : if a deployment dpl use the artifact art1, art2 and the locations loc1 and loc2, its editor will now listen all theses resources (dpl, art1, art2, loc1, loc2) on the same way, a test will listen for the datapool and external test it uses, but will not listen on its test log (test log are not displayed in the editor) artifact / deployment / datapool will only listen the resource on witch they are opened (even if they keep reference to other test element, their editor do not display them) remaining work : . make that editors use this notification to update themself . unplug original resource listener . tons of testing
not sure what version of tptp this defect is targeted for?
(In reply to comment #11) > not sure what version of tptp this defect is targeted for? Alex, this defect is not currently targeted to a specific TPTP release. As such, there are no plans to deliver a fix. Does your consuming product require this defect?
No longer required by a consuming product.
Closing.