Community
Participate
Working Groups
I think the concept of ICellModifier is not really intuative. I think that all the things spread about those many classes can be handled from TableColum/TreeColumn in an easier way.
Created attachment 41958 [details] Complete reimplementation for TreeViewer and TableViewer TableViewer and TreeViewer have to be reimplemented in my case because sub-classing does not provide access to treeViewerImpl/tableViewerImpl.
Created attachment 41965 [details] Refactored to make tab-traversing more intelligent TabTraversing is now applied to the currently active editor and removed when it is closed. The rest stays as is.
I agree that an abstraction for columns is needed. However, I would like to add the column abstraction to TableViewer and TreeViewer instead of copying the code.
While doing this, we should add support for element-specific cell editors (there is a bug for this but I cannot find it right now). Marking as 3.3.
Well in my proposal I only needed to copy the viewers because you I can not get access to tableViewerImpl/treeViewerImpl the whole magic is done in TableEditor/TreeEditor and the TreeColumn/TableColumn. If you studied the example you don't need to duplicate too much of your code if you use the IMultiColum-Interface. The best about this it could be made backward compatible by deciding internally if the old TableEditor or the new one should be used. If you want me to I can send you a patch which incooperates the whole into existing TreeViewer/TableViewer. My idea is the following: org.eclipse.jface.viewers.TableColumn/TreeColumn (abstract-classes): - Registers the CellEditors needed for the various object types you have (nowadays Table/TreeViewer.setCellEditors()) - provides the values for the editor (nowadays ICellModifier) - updates the object from the editor (nowadays ICellModifier) IMultiColumn: - interface if you implement all your logic into one concrete Table/TreeColumn (see TableViewer in my example) This approach has in my ideas the following advantages: - multiple celleditors in one column based upon the object you are editing - IMultiColumn if you have say only columns dealing with TextCellEditor you can have the famous already known column-index switch-case from LableProvider
(In reply to comment #4) > While doing this, we should add support for element-specific cell editors > (there is a bug for this but I cannot find it right now). > > Marking as 3.3. > See my example it's working already ;-)
(In reply to comment #6) > (In reply to comment #4) > > While doing this, we should add support for element-specific cell editors > > (there is a bug for this but I cannot find it right now). > > > > Marking as 3.3. > > > > See my example it's working already ;-) > and this implementation already incoopertates tab-traversing in a bit more elegant way than described in bug #75114
*** Bug 75114 has been marked as a duplicate of this bug. ***
Created attachment 42048 [details] Path for Viewers to add new editing support adds new interfaces for Viewers (TreeViewer/TableViewer): - multiple cell-editors per column based upon current model (IEditableColumn) - support for ICellModifier like Column-Implementations (IEditableMultiColumn) - Tab-Traversal support for both APIs The whole system is backward compatible the old style of setting CellEditors, ColumnProperties, ICellModifier is working as it has in the past but I've marked them as deprecated which might be too strict
Created attachment 42050 [details] Example/Test Code to show that both APIs are working
Thank you for the patch! I don't have time right now to review it, but I will come back to this early in the 3.3 cycle.
(In reply to comment #11) > Thank you for the patch! I don't have time right now to review it, but I will > come back to this early in the 3.3 cycle. > Thanks. Are the any other interesting areas in JFace I could dive into and produce patches, hopefully not all that big than this one?
*** Bug 75557 has been marked as a duplicate of this bug. ***
> *** Bug 75557 has been marked as a duplicate of this bug. *** Note that there is an attachment to bug 75557 that should be looked at as well.
Created attachment 42561 [details] Revised patch to avoid subclassing of SWT-Widget I rethought the last patch which had the problem that it sub-classed TableColumn and TreeColumn which is not following the SWT-Paradigm and had the draw-back that one could not add support for editing to existing TreeColumns/TableColumns. It holds holds the patch for bug #83200 but it's not hard to remove it when it is not accepted
(In reply to comment #4) > While doing this, we should add support for element-specific cell editors > (there is a bug for this but I cannot find it right now). I believe this is in bug 70800 (TableViewer) and bug 113713 (TreeViewer).
Maybe this bug could be closed and all discussion move to bug 149193 which tries to invent a new concept for viewers.
I think we could close this bug because it has no need any more: - Tabediting is discussed and implemented in bug #151295 - CellEditors-Activation is discussed and implemented in bug #87733 I think the bugs 144111 144114 144115 could be moved to bug #151295 although 151295 goes beyond what is needed for BiRT (only Tab-Editing) if I read the bug reports right
*** This bug has been marked as a duplicate of bug 151295 ***
