Community
Participate
Working Groups
Currently some views listen for selection events on other views and make use of this information to update their own selections to something related to the original selection. For example, if you have the log view and log interactions view open at the same time, and select a log record in one of them, the other view will automatically update and select that same log record, if it's there. The problem is that there's no standard way to do this. The platform should provide this service to all views. Views should be able to: 1. Broadcast selection changes to all other views that are listening. 2. Listen for selection changes from other views. 3. Query the current selection (for newly opened views). The information broadcast should be a common form that most views would understand. The model object associated with the selection would be a good example. In addition, for those selections that have a time associated with them, it should also broadcast the time, in case the receiving method does not understand the model object, it could fall back to the time (if it's a time- based view).
Important for higher product.
*** Bug 75258 has been marked as a duplicate of this bug. ***
Important comments from 75258 for trace interactions (UML2SD): Currently, the trace interactions broadcast their selection by the mean of an org.eclipse.hyades.uml2sd.trace.selection.IDateSelection implementing object. It also listens to such kind of selections made in other views. This allows to scroll in the SD, giving a date and is mandatory for an higher product. 87602 (the kept record on this subject) must take these capabilities into account when proposing a more widely used system.
Deferring from 4.1 as per the official 4.1 enhancement plan. http://eclipse.org/tptp/home/project_info/featureplans/features.php?source=All&project=All&release=4.1&file=TPTPFeatures_4.1.xml
Setting to next release.
Setting target to future so it doesn't show up in the 4.2 feature query.
Mass update of P1 enhancements and defects targetted to future to P2.
As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As such, TPTP is not delivering enhancements. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement is resolved as WONTFIX. For this enhancement to be considered, please re-open with an attached patch including the Description Document (see http://www.eclipse.org/tptp/home/documents/process/development/description_documents.html), code (see http://www.eclipse.org/tptp/home/documents/resources/TPTPDevGuide.htm), and test cases (see http://www.eclipse.org/tptp/home/documents/process/TPTP_Testing_Strategy.html).
As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant enhancements/defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement/defect is verified/closed by the Project Lead since this enhancement/defect has been resolved and unverified for more than 1 year and considered to be fixed. If this enhancement/defect is still unresolved and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open.
