Community
Participate
Working Groups
Eclipse now provides support for flat look editors (FormWidget). Hyades editors making use of the flat look should make use of Eclipse platform support for flat look.
According to Dr. Dejan Glozic: "The 'flatUI' is now called Eclipse Forms and is API since Eclipse 3.0. Here is the document: http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/pde-ui- home/working/EclipseForms/EclipseForms.html "
Right, that's exactly what you need to use in order to enable the "flat look" for your editors. You can take a look at the SymptomEditor in the org.eclipse.hyades.sdb plugin if you need an example.
A little background on this enhancement. According to Eclipse Forms Programming Guide at: http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/pde-ui-home/working/EclipseForms/EclipseForms.html "Eclipse Forms is a plug-in that exposes a set of customs widgets and other supporting classes that were before used as internal to PDE and Update components. They provide for creating polished, 'Web-like' UIs by modestly extending SWT and/or manipulating style bits, colors, fonts and other properties in order to get the desired behavior. This technology was used throughout PDE multi-page editors and will now be available as public API in Eclipse 3.0." After investigation of the eclipse forms toolkit and TPTP editor framework, there are surprising similarities between the two in design and the look they're trying to achieve. Specifically, both are achieving: multi-page form editors, managed forms, column layout in editor forms, use of expandable Sections, "flat" look without 3D borders, hyperlink text, etc. Both are achieving the same above-listed goals, but through different implementations. Before this eclipse forms feature becomes public, Hyades implemented its own editor framework (mostly in plugin org.eclipse.hyades.ui and org.eclipse.hyades.test.ui) that is shared by almost all current TPTP editors.
I have very serious doubts that Eclipse Forms framework can be used successfully to accomplish the needs of RPT test editor. Just a quick look reveals that there is no support for StyledText in org.eclipse.ui.forms, nor for org.eclipse.jface.text.TextViewer. StyledText is custom control capable of displaying Unicode characters of many languages independent of underlying OS support (this is used throughout RPT editor). It is also the type of control created by TextViewer internally for managing text data. In turn, TextViewer (and IDocument interface) is required for communicating various events (such as SelectionProvider etc) to Eclipse platform. Without this ability, RPT (and any other editor) is crippled in its ability to support such common things as retargetable action, standard marker types (bookmarks, tasks, problems), Find dialog, extraction of selected text for Search/Replace dialog and/or anything else the Eclipse platform expects of an editor. In other words, Eclipse provides very good support for and is oriented towards Text editors, whereas RPT editor (as are many others) is what is known as Form Editor. To make a form editor to *appear* more like a better-understood and better-supported Text Editor, a form editor must have most of it's controls be managed by corresponded viewers (such as TreeViewer for tree, Table Viewer for table, and TextViewer/IDocument for text fields). Without that, the contents of any form-based editor are the black-box for Eclipse platform.
Per discussion with Wayne and Joe on 3/15/05, we're marking TPTP editor classes in *public* (not internal) packages as deprecated as a warning that external tool vendors should not extend them for Eclipse Forms support. Added in class Javadoc: @deprecated <p>The implementation of this class is not based on Eclipse Forms(a.k.a. "flat" look) framework that was made available publically in Eclipse 3.0. If you would like your editor(s) to be built with the Eclipse Forms technology, this is NOT the class to extend. To know more about Eclipse Forms: <br> <a href="http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/pde-ui-home/working/EclipseForms/EclipseForms.html">Eclipse Forms Programming Guide</a> </p> Affected classes: org.eclipse.hyades.ui.editor.EditorExtension org.eclipse.hyades.test.ui.editor.extension.BaseEditorExtension org.eclipse.hyades.test.ui.editor.extension.TestSuiteEditorExtension org.eclipse.hyades.test.ui.editor.form.TestCasesForm org.eclipse.hyades.test.ui.editor.form.TestContextOverview org.eclipse.hyades.test.ui.editor.form.util.EditorForm org.eclipse.hyades.test.ui.editor.form.util.EditorSection org.eclipse.hyades.test.ui.editor.form.util.NamedElementSection org.eclipse.hyades.test.ui.editor.form.util.NamedElementsSection org.eclipse.hyades.test.ui.editor.form.util.TestObjectiveSection org.eclipse.hyades.test.ui.editor.form.util.WidgetFactory
Somebody needs to make sure the New Forms APIs are enhanced to support StyledText, TextViewer and SashForm. The support can be made in the Forms packages themselves or in Hyades code through inheritance. Unless this support exists, the Forms APIs are useless to RPT.
*** Bug 80539 has been marked as a duplicate of this bug. ***
[sizing = 6~8 weeks]
[sizing = 8 weeks] Updated design doc. This estimation includes: 1) extend existing Eclipse Forms API to support more controls (eg. StyledText, TextViewer, SashForm) that is required by TPTP editors as well as underlying products. This can take 1 ~ 2 person weeks for investigation, coding and testing. 2) transform current TPTP editors to use the new Forms API. This means rewrite the editor implementation but not re-design them. This can take 4 ~ 5 person weeks for coding and testing. 3) documentation impact with screen shots. 1 person week.
Deferred per replan.
Downstream products no longer require and have withdrawn request. We should review further to determine if needed in future release.
*** Bug 74136 has been marked as a duplicate of this bug. ***
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
*** Bug 78903 has been marked as a duplicate of this bug. ***
*** Bug 124180 has been marked as a duplicate of this bug. ***
*** Bug 119449 has been marked as a duplicate of this bug. ***
Correcting version for this enhancement (defaulting to the current release). See http://www.eclipse.org/tptp/home/documents/process/development/bugzilla.html for more information.
Correction: Future is a valid version for this enhancement based on http://www.eclipse.org/tptp/home/documents/process/development/bugzilla.html. As such, the implicit assumption is that is enhancement is of a lower priority. If incorrect, the originator should correct the version.
Updating target to future as requested by the PMC. Enhancements are targeted to future if not in plan for the current release.
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=175399#c5 for an additional requirement.
*** Bug 175399 has been marked as a duplicate of this bug. ***
Correcting priority since not a 4.5 candidate enhancement (see http://www.eclipse.org/tptp/home/documents/process/development/bugzilla.html).
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).
In my view, porting existing TPTP code to FormsUI should include the following (and this is rather rough description; I am sure there are quirks I have not thought about): 1. Writing new WidgetFactory and FormWidgetFactory classes, that would subclassed from Forms' FormToolkit class. Most of [RPT] editors use these classes to create widgets and lay them out in the UI. If we could keep the names of the new factories the same, and also maintain method signatures, the impact on the client code should not be too big. 2. The same goes for the TPTP UI code that builds the editor presentation space, i.e. EditorForm and EditorSection classes. FormsUI offers its own implementations of classes with similar if not identical purpose. Therefore, Forms' classes should be used to build the editor's UI, before the control is passed to the client code. All for this makes sense of course, if TPTP want to continue to offer libraries for building UI. There is a separate issue here, related to the existence and use of IEditorExtension mechanisms. If we want to break away from these (and I think we should) then porting the UI to FormsUI in TPTP probably does not make much sense, as it will not decouple product code from TPTP UI subsystem.
(In reply to comment #26) > In my view, porting existing TPTP code to FormsUI should include the following > (and this is rather rough description; I am sure there are quirks I have not > thought about): > > 1. Writing new WidgetFactory and FormWidgetFactory classes, that would > subclassed from Forms' FormToolkit class. Most of [RPT] editors use these > classes to create widgets and lay them out in the UI. If we could keep the > names of the new factories the same, and also maintain method signatures, the > impact on the client code should not be too big. > > 2. The same goes for the TPTP UI code that builds the editor presentation > space, i.e. EditorForm and EditorSection classes. FormsUI offers its own > implementations of classes with similar if not identical purpose. Therefore, > Forms' classes should be used to build the editor's UI, before the control is > passed to the client code. > > All for this makes sense of course, if TPTP want to continue to offer libraries > for building UI. There is a separate issue here, related to the existence and > use of IEditorExtension mechanisms. If we want to break away from these (and I > think we should) then porting the UI to FormsUI in TPTP probably does not make > much sense, as it will not decouple product code from TPTP UI subsystem. > Thanks Alex! I have updated the sizing estimates for this enhancement to 3 PW and refactored the description document based on your comments. Once the consuming product determines if they need this enhancement, please reopen.
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 the originator of this enhancement/defect has an inactive Bugzilla account 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.
