Hi Peter sorry for my late response. My spam-filter tagged your mail by mistake, I just discovered it.
wow! A whole lot of ideas! I'll need some time to get through all of them :-) I was was also thinking about whether it makes sense to have compositeTable accessible by the viewer api. But I did not get as concrete as you did. My first impression is that replacing item by integer should work, on the other hand I feel like this API-break kills most of the benefits one would get (effective compliance is broken). The only advantage I still see is that people are used to the viewer api and would get into it real fast. I totally agree with you that a common model-layer to CT would be a major benefit but I am not sure if a mimed viewer API really is the right choice. Regards André > Currently, CompositeTable treats the concepts of focus, selection, and > "current" as identical. I would like to separate focus and selection > and track them separately, similar to the way that an SWT Table treats > selection, with SINGLE and MULTI support and methods to retrieve the > selected indices and items. As a next step, I would like to implement > CHECK style selections. Ultimately, I would like to use CompositeTable > as an ISelectionProvider that can act as a drop-in replacement for a > TableViewer and as an ICheckable that can replace CheckboxTableViewer. > > There are a number of issues that need to be solved, and I'd like to > describe my ideas and get some feedback from the list before I dive in. > I'd appreciate any comments you could provide. > > 0. Fill the architectural role of JFace Viewer. > > Overall, I propose to build a CompositeTableViewer (CTV) class to fill > the architectural role of a JFace Viewer. Unfortunately, due to the > statically-typed Item in method signatures, this class cannot derive > from Viewer. I will attempt to make it semantically compatible, even if > it cannot have true binary compatibility. > > 1. Emulate the JFace Element-Item mapping. > > Unlike the native Table and Tree controls (and the other Nebula grids), > CompositeTable does not have a concept of an Item to represent each row. > CompositeTable is "pure virtual" -- rows are continuously reused, while > SWT Table is "lazy" -- rows are created as needed, but once present they > are not reused. AFAIK, this was a deliberate choice to avoid memory > cost. Unfortunately, much of the JFace Viewer API depends on the > existence of a statically-typed and long-lived Item for each row. > > CompositeTable does have the concept of an index, however. Operations > on rows are performed in terms of a row index within the entire > collection being displayed. This could be seen as roughly equivalent to > SWT operations that are performed in terms of an Item. Therefore, I > propose that the selection and check concepts should work in terms of > collection indices within CompositeTable. Thus CT can take on the > architectural role of the SWT widget within the JFace architecture, > despite the lack of an Item concept. All JFace API that accepts an Item > parameter would be rewritten to take an Integer parameter instead. > > AFAIK, JFace does not guarantee that an Item will always map to the same > element. A change in sort order will change this mapping. Does anyone > know of a reason why an index number could not stand in for an Item > within a Viewer implementation? > > 2. Emulate the SWT Table selection/check API. > > 2a. Table provides various selection-related methods -- often with > multiple overloads: deselect/deselectAll, select/selectAll, > setSelection, > showSelection, getSelectonIndex/getSelectionIndices, getSelectionCount, > isSelected, addSelectionListener/removeSelectionListener. Also, the > remove/removeAll() methods interact with the selection state. The > check-state methods on TableItem would need to be moved up to > CompositeTable, as well: get/setGrayed, get/setChecked. > > 2b. Some of the CompositeTable APIs use an index relative to the top of > the control, instead of relative to the collection being displayed. > There seems to be an easy workaround for each case. I propose that the > API be standardized to always operate in terms of the entire collection. > Operations which need to work in terms of the row Control arrangement > should be package-private or protected. > > 3. Implement visual feedback for selection and checked states. > > 3a. On one hand, it would be nice if CompositeTable could provide a > consistent UI for selection and checked states "for free" like an SWT > Table does. On the other hand, the whole purpose of CompositeTable is > to support custom rendering of table rows. My instinct is to leave this > up to the label provider to render, but provide a mechanism in > CompositeTable to track selections and checked states cheaply, outside > of the row Control itself. That way, generic ISelectionProvider and > ICheckable implementations can be written, even though they do not know > how the selection and checked states will be manipulated by users. > Client code will need to update the mapping between the CompositeTable's > internal state and the visual state of each row, in whatever way is > appropriate for the specific row Control. > > Would it be better for setSelection to automatically refresh any > affected row Controls, or should it be the client code's responsibility > to refresh if/when it is necessary? > > 3b. Even if a general solution is impossible, I could provide a default > implementation that wraps each row Control in a new Composite. > Selection would appear as a border highlight and could be toggled by > clicking on a small "tab" or "handle" along one side of the row -- just > a blank space that responds to click events. (This might also need some > kind of visual affordance, to indicate that it can be clicked.) Checked > state would be implemented by a standard SWT.CHECK Button with no label, > placed within the "tab". > > 3c. Client code would enable the default selection/check support by > specifying style bits in the constructor. SWT.SINGLE or SWT.MULTI would > enable selection, and SWT.CHECK would add checked state support. > SWT.LEAD and SWT.TRAIL would control the location of the selection > "tab". > > 3d. In the future, the selection "tab" could be the basis for a new drag > and drop row-reordering feature. I don't intend to work on this myself > for a long time, since the rest of this proposal will take long enough! > > 4. Emulate the JFace IContentProvider/ILabelProvider separation of > concerns. > > CTV will manage the mapping from a data element to a row index and from > a row index to a row Control. It will adapt existing > IStructuredContentProvider and ILazyContentProvider implementations to > work with CompositeTable. Custom logic will still be required to push > data from the data element into the row Control and vice versa, but this > will be separated from the source of the data in the same way that JFace > separates IContentProvider from ILabelProvider. > > 5. Emulate the ILabelProvider API. > > I would appreciate help on this aspect of the design. > > In the JFace architecture, an ILabelProvider is responsible for mapping > a data element into terms that the SWT Control can use directly. It > performs this mapping on an element-by-element basis. > > 5a. With ILabelProvider and ITableLabelProvider, each portion of the GUI > is mapped with separate method calls, such as getText() and getImage(). > With IViewerLabelProvider, the entire GUI is mapped in a single method. > Since the structure of a CompositeTable row Control is unspecified and > varies from instance to instance, it seems more appropriate to use the > all-at-once approach and let the provider handle differences in > structure by itself. > > 5b. With JFace IViewerLabelProvider, the Viewer is responsible for the > last step of pushing data from the ViewerLabel into the Item. I don't > see how this will be possible for CTV, since a row Control is a black > box. > > AFAIK, this separation between the label provider and the SWT Item was > intended to allow label decorators to modify the values created by the > provider before they are set on the Item. This is a worthwhile > optimization, and I would prefer to support the same pattern with > CompositeTable. Unfortunately, I can't figure out a way to do it. Even > if it was possible to construct an intermediate object similar to > ViewerLabel that would work for arbitrary row Controls, the CTV cannot > know what to do with it when it is time to actually update the Control. > > I propose that this aspect of the JFace API is incompatible with > CompositeTable's purpose, and so it should not be emulated. The object > which will fill the architectural role of ILabelProvider will be > responsible for directly modifying the row Control. The concept of a > label decorator will be outside the scope of this design. The update > method will be passed the row Control directly, rather than an > intermediate object. > > 5c. IBaseLabelProvider is the root of the type hierarchy for all JFace > label providers. I intend for the new CTV-specific provider to derive > from it. > > 5d. Name suggestions would be welcome. ICompositeTableLabelProvider? > Perhaps the name should reflect the expanded role described in 4b -- > ICompositeTableRowRenderer? > > 6. Support as many other JFace features as possible. > > Sorting, filtering, and IElementComparer are directly applicable to > CompositeTableViewer. DoubleClickListener, OpenListener, drag and drop > support, and custom tooltips might or might not make sense. > > > Conclusion: > > This design would provide two useful new capabilities for > CompositeTable: selection and checked states. It would also provide an > MVC harness with an API as close to JFace as possible without > sacrificing core features. Although it would not be a true drop-in > replacement for TableViewer, it would maximize code reuse and leverage > developer experience with the JFace architecture. > > Implementation Notes: > > I plan to start with the SWT-level features (2 and 3). These features > are relatively simple and will be immediately useful, even without > JFace-style APIs. > > Once that is complete, I plan to take the source code for the complete > Viewer hierarchy and find-replace from Item to Integer. If I'm lucky, > most of the code should translate directly. Since Items cannot be > reordered and serve mostly as opaque keys within the JFace > implementation, Integer should be semantically equivalent in this > context. I believe that the only methods of Item that the Viewer > implementation relies on are getData() and setData(). It should be > possible to replace these methods with simple array accesses. Then I > will inspect to see where this naïve rule breaks down and re-implement > whatever is necessary. I expect that the label provider logic will need > significant rework, for example. Features with questionable semantics > for CTV will be removed or disabled/ignored. > > > Again, your comments would be very much appreciated. If anyone else is > interested in helping with this work, that would be appreciated even > more! > > -- > Peter Centgraf > > > _______________________________________________ > nebula-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/nebula-dev > > > !DSPAM:4609665c233011811889055! -- André Dietisheim Stv-Bereichsleiter Products Puzzle ITC GmbH Eigerplatz 4 CH-3007 Bern Telefon +41 31 370 22 00 Mobile +41 76 423 03 02 Fax +41 31 370 22 01 Puzzle ist Mitglied der ODF Alliance: <http://www.puzzle.ch/odfalliance/> _______________________________________________ nebula-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/nebula-dev
