Home » Eclipse Projects » Nebula » [GridViewer]How to change text of rowHeader with a labelprovider ?
| |
Re: [GridViewer]How to change text of rowHeader with a labelprovider ? [message #35132 is a reply to message #35102] |
Tue, 22 May 2007 13:04 |
Defert Philippe Messages: 62 Registered: July 2009 |
Member |
|
|
Tom,
i wrote my own GridViewer that extends
org.eclipse.nebula.jface.gridviewer.GridViewer
and i override doUpdateItem(...)
protected void doUpdateItem(Widget widget, Object element, boolean
fullMap) {
super.doUpdateItem(widget, element, fullMap);
// Check if it needs to process rowHeader
if (getGrid().isRowHeaderVisible() && getLabelProvider() instanceof
GridLabelProvider) {
if (widget instanceof GridItem) {
final GridItem item = (GridItem) widget;
int indexOfItem = Arrays.asList(getGrid().getItems()).indexOf(item);
String newRowHeaderText = ((GridLabelProvider)
getLabelProvider()).getRowHeaderText(element, indexOfItem);
item.setHeaderText(newRowHeaderText);
}
}
}
and i wrote a GridLabelProvider class
public class GridLabelProvider extends LabelProvider implements
ITableLabelProvider {
public Image getColumnImage(Object element, int columnIndex) {
return null;
}
public String getColumnText(Object element, int columnIndex) {
return element == null ? "" : element.toString();
}
public String getRowHeaderText(Object element, int rowIndex){
return ""+rowIndex;
}
}
now, if you want to print something of content's data in rowHeader, you
can extends GridLabelProvider and overide getRowHeaderText() .
Tom, What do you think about my workaround ?
I will appreciate your comments .
Philippe
Tom Schindl a écrit :
> Hi,
>
> GridViewer is currently not able to implement this as far as I can
> remember when I wrote it because JFace provides no hooks for this.
>
> The problem is not the first creation of the Item but what happens if an
> item is added, removed, ... . Nevertheless please log a bug and the next
> time I'll work on the nebula viewers I'll see how this could be
> implemented. If you want you can take a look yourself and create a patch
> I can review amd comment on it(please CC me on the bug if you filed one)
>
> Tom
>
> DEFERT Philippe schrieb:
>> Hi,
>>
>> is it possible to modify rowheader text with jface binding mechanism as
>> a Labelprovider ?
>> I know it is possible directly on griditem but i would not use griditem.
>>
>> do you plan to provide a "GridLabelProvider" ?
>>
>> Thanks
>>
>> Philippe
>
>
|
|
|
Re: [GridViewer]How to change text of rowHeader with a labelprovider ? [message #35160 is a reply to message #35132] |
Tue, 22 May 2007 15:45 |
Thomas Schindl Messages: 6651 Registered: July 2009 |
Senior Member |
|
|
Hi,
From the first impression this looks good but as already outlined this
is not the only thing you need to take care of e.g. if you want to
assign row-numbers using this LabelProvider if you insert/remove a row
from the grid you need to update all items below the one you inserted
deleted.
Please log a bug and we can discuss there. A problem I see is that this
might provide problems with the new Viewer-Infrastructure but I need to
think about this a bit.
Tom
DEFERT Philippe schrieb:
> Tom,
>
> i wrote my own GridViewer that extends
> org.eclipse.nebula.jface.gridviewer.GridViewer
> and i override doUpdateItem(...)
>
> protected void doUpdateItem(Widget widget, Object element, boolean
> fullMap) {
>
> super.doUpdateItem(widget, element, fullMap);
> // Check if it needs to process rowHeader
> if (getGrid().isRowHeaderVisible() && getLabelProvider()
> instanceof GridLabelProvider) {
> if (widget instanceof GridItem) {
> final GridItem item = (GridItem) widget;
> int indexOfItem =
> Arrays.asList(getGrid().getItems()).indexOf(item);
> String newRowHeaderText = ((GridLabelProvider)
> getLabelProvider()).getRowHeaderText(element, indexOfItem);
> item.setHeaderText(newRowHeaderText);
>
> }
>
> }
> }
>
>
> and i wrote a GridLabelProvider class
>
> public class GridLabelProvider extends LabelProvider implements
> ITableLabelProvider {
>
> public Image getColumnImage(Object element, int columnIndex) {
>
> return null;
> }
>
> public String getColumnText(Object element, int columnIndex) {
>
> return element == null ? "" : element.toString();
> }
> public String getRowHeaderText(Object element, int rowIndex){
> return ""+rowIndex;
> }
> }
>
>
> now, if you want to print something of content's data in rowHeader, you
> can extends GridLabelProvider and overide getRowHeaderText() .
>
> Tom, What do you think about my workaround ?
> I will appreciate your comments .
>
> Philippe
>
> Tom Schindl a écrit :
>> Hi,
>>
>> GridViewer is currently not able to implement this as far as I can
>> remember when I wrote it because JFace provides no hooks for this.
>>
>> The problem is not the first creation of the Item but what happens if an
>> item is added, removed, ... . Nevertheless please log a bug and the next
>> time I'll work on the nebula viewers I'll see how this could be
>> implemented. If you want you can take a look yourself and create a patch
>> I can review amd comment on it(please CC me on the bug if you filed one)
>>
>> Tom
>>
>> DEFERT Philippe schrieb:
>>> Hi,
>>>
>>> is it possible to modify rowheader text with jface binding mechanism as
>>> a Labelprovider ?
>>> I know it is possible directly on griditem but i would not use griditem.
>>>
>>> do you plan to provide a "GridLabelProvider" ?
>>>
>>> Thanks
>>>
>>> Philippe
>>
>>
--
B e s t S o l u t i o n . a t EDV Systemhaus GmbH
----------------------------------------------------
tom schindl Eclipse JFace Committer
|
|
|
Re: [GridViewer]How to change text of rowHeader with a labelprovider ? [message #35232 is a reply to message #35160] |
Tue, 22 May 2007 17:39 |
Chris Gross Messages: 253 Registered: July 2009 |
Senior Member |
|
|
The Grid will assign row numbers for you automatically if you don't set
anything in the row header text. So you shouldn't have to do anything
to get that behavior.
If you do want to set the row header text, couldn't you just use the new
CellLabelProvider API?
-Chris
Tom Schindl wrote:
> Hi,
>
> From the first impression this looks good but as already outlined this
> is not the only thing you need to take care of e.g. if you want to
> assign row-numbers using this LabelProvider if you insert/remove a row
> from the grid you need to update all items below the one you inserted
> deleted.
>
> Please log a bug and we can discuss there. A problem I see is that this
> might provide problems with the new Viewer-Infrastructure but I need to
> think about this a bit.
>
> Tom
>
> DEFERT Philippe schrieb:
>> Tom,
>>
>> i wrote my own GridViewer that extends
>> org.eclipse.nebula.jface.gridviewer.GridViewer
>> and i override doUpdateItem(...)
>>
>> protected void doUpdateItem(Widget widget, Object element, boolean
>> fullMap) {
>>
>> super.doUpdateItem(widget, element, fullMap);
>> // Check if it needs to process rowHeader
>> if (getGrid().isRowHeaderVisible() && getLabelProvider()
>> instanceof GridLabelProvider) {
>> if (widget instanceof GridItem) {
>> final GridItem item = (GridItem) widget;
>> int indexOfItem =
>> Arrays.asList(getGrid().getItems()).indexOf(item);
>> String newRowHeaderText = ((GridLabelProvider)
>> getLabelProvider()).getRowHeaderText(element, indexOfItem);
>> item.setHeaderText(newRowHeaderText);
>>
>> }
>>
>> }
>> }
>>
>>
>> and i wrote a GridLabelProvider class
>>
>> public class GridLabelProvider extends LabelProvider implements
>> ITableLabelProvider {
>>
>> public Image getColumnImage(Object element, int columnIndex) {
>>
>> return null;
>> }
>>
>> public String getColumnText(Object element, int columnIndex) {
>>
>> return element == null ? "" : element.toString();
>> }
>> public String getRowHeaderText(Object element, int rowIndex){
>> return ""+rowIndex;
>> }
>> }
>>
>>
>> now, if you want to print something of content's data in rowHeader, you
>> can extends GridLabelProvider and overide getRowHeaderText() .
>>
>> Tom, What do you think about my workaround ?
>> I will appreciate your comments .
>>
>> Philippe
>>
>> Tom Schindl a écrit :
>>> Hi,
>>>
>>> GridViewer is currently not able to implement this as far as I can
>>> remember when I wrote it because JFace provides no hooks for this.
>>>
>>> The problem is not the first creation of the Item but what happens if an
>>> item is added, removed, ... . Nevertheless please log a bug and the next
>>> time I'll work on the nebula viewers I'll see how this could be
>>> implemented. If you want you can take a look yourself and create a patch
>>> I can review amd comment on it(please CC me on the bug if you filed one)
>>>
>>> Tom
>>>
>>> DEFERT Philippe schrieb:
>>>> Hi,
>>>>
>>>> is it possible to modify rowheader text with jface binding mechanism as
>>>> a Labelprovider ?
>>>> I know it is possible directly on griditem but i would not use griditem.
>>>>
>>>> do you plan to provide a "GridLabelProvider" ?
>>>>
>>>> Thanks
>>>>
>>>> Philippe
>>>
>
>
|
|
|
Re: [GridViewer]How to change text of rowHeader with a labelprovider ? [message #35246 is a reply to message #35232] |
Tue, 22 May 2007 18:50 |
Thomas Schindl Messages: 6651 Registered: July 2009 |
Senior Member |
|
|
Hi,
You are right Chris that's what I meant I haven't thought about this
carefully enough. Hence the request for a bug report.
Maybe we could provide a standard label provider ontop of
ColumnLabelProvider. I'm against adding something depending on the old
API using the hack below :-)
I logged https://bugs.eclipse.org/bugs/show_bug.cgi?id=188430 and will
provide an example implementation.
Tom
Chris Gross schrieb:
> The Grid will assign row numbers for you automatically if you don't set
> anything in the row header text. So you shouldn't have to do anything
> to get that behavior.
>
> If you do want to set the row header text, couldn't you just use the new
> CellLabelProvider API?
>
> -Chris
>
> Tom Schindl wrote:
>> Hi,
>>
>> From the first impression this looks good but as already outlined this
>> is not the only thing you need to take care of e.g. if you want to
>> assign row-numbers using this LabelProvider if you insert/remove a row
>> from the grid you need to update all items below the one you inserted
>> deleted.
>>
>> Please log a bug and we can discuss there. A problem I see is that this
>> might provide problems with the new Viewer-Infrastructure but I need to
>> think about this a bit.
>>
>> Tom
>>
>> DEFERT Philippe schrieb:
>>> Tom,
>>>
>>> i wrote my own GridViewer that extends
>>> org.eclipse.nebula.jface.gridviewer.GridViewer
>>> and i override doUpdateItem(...)
>>>
>>> protected void doUpdateItem(Widget widget, Object element, boolean
>>> fullMap) {
>>> super.doUpdateItem(widget, element, fullMap);
>>> // Check if it needs to process rowHeader
>>> if (getGrid().isRowHeaderVisible() && getLabelProvider()
>>> instanceof GridLabelProvider) {
>>> if (widget instanceof GridItem) {
>>> final GridItem item = (GridItem) widget;
>>> int indexOfItem =
>>> Arrays.asList(getGrid().getItems()).indexOf(item);
>>> String newRowHeaderText = ((GridLabelProvider)
>>> getLabelProvider()).getRowHeaderText(element, indexOfItem);
>>> item.setHeaderText(newRowHeaderText);
>>>
>>> }
>>> }
>>> }
>>>
>>>
>>> and i wrote a GridLabelProvider class
>>>
>>> public class GridLabelProvider extends LabelProvider implements
>>> ITableLabelProvider {
>>>
>>> public Image getColumnImage(Object element, int columnIndex) {
>>> return null;
>>> }
>>>
>>> public String getColumnText(Object element, int columnIndex) {
>>> return element == null ? "" : element.toString();
>>> }
>>> public String getRowHeaderText(Object element, int rowIndex){
>>> return ""+rowIndex;
>>> }
>>> }
>>>
>>>
>>> now, if you want to print something of content's data in rowHeader, you
>>> can extends GridLabelProvider and overide getRowHeaderText() .
>>>
>>> Tom, What do you think about my workaround ?
>>> I will appreciate your comments .
>>>
>>> Philippe
>>>
>>> Tom Schindl a écrit :
>>>> Hi,
>>>>
>>>> GridViewer is currently not able to implement this as far as I can
>>>> remember when I wrote it because JFace provides no hooks for this.
>>>>
>>>> The problem is not the first creation of the Item but what happens
>>>> if an
>>>> item is added, removed, ... . Nevertheless please log a bug and the
>>>> next
>>>> time I'll work on the nebula viewers I'll see how this could be
>>>> implemented. If you want you can take a look yourself and create a
>>>> patch
>>>> I can review amd comment on it(please CC me on the bug if you filed
>>>> one)
>>>>
>>>> Tom
>>>>
>>>> DEFERT Philippe schrieb:
>>>>> Hi,
>>>>>
>>>>> is it possible to modify rowheader text with jface binding
>>>>> mechanism as
>>>>> a Labelprovider ?
>>>>> I know it is possible directly on griditem but i would not use
>>>>> griditem.
>>>>>
>>>>> do you plan to provide a "GridLabelProvider" ?
>>>>>
>>>>> Thanks
>>>>>
>>>>> Philippe
>>>>
>>
>>
|
|
| | | | | |
Re: [GridViewer]How to change text of rowHeader with a labelprovider ? [message #35424 is a reply to message #35389] |
Thu, 24 May 2007 16:56 |
Nicolas Richeton Messages: 179 Registered: July 2009 |
Senior Member |
|
|
I believe that using the same method signature but no common code is OK
for now.
But some core package may be usefull in the future too. For example, I
used AbstractRenderer and TreeNodeToggleRenderer in the Gallery widget
so this code is duplicated in PGroup, Grid and Gallery...
This API will be used to limit the number of handles required when using
different images, styles and color for each item in Grid, Gallery,
Tree and Tables.
I think we need :
* A listener for items that are scrolled out of the visible area.
Interesting informations are the item and maybe some data on the way it
was hidden (parent was collapsed or scrollbar were moved)
* A method which returns all the visible items.
Table already has getTopIndex() that can be used together with widget
and item sizes to calculate the visible items. But this approach cannot
be used with other widgets where any item can be expanded/collapsed.
* We don't need a listener for items which are becoming visible because
the paint event can be used for this.
May be we should use bugzilla to discuss of this ?
--
Nicolas
Chris Gross a écrit :
> Hmm... there could be potential problems if the resources are not
> available even though the rows are out of view. Off the top of my head
> I know that GridColumn#pack will need to know the size of the contents
> of each cell. So that would suffer (but probably not a big deal). There
> might be other problems. I have to think a little.
>
> I think its a good idea to try to ensure that Nebula widgets try to
> share common API but I'm not sure its a good idea to formalize that in
> an interface. Where would that interface live? In some core package
> and then in some core plugin/jar? That would make things a little more
> messy/complicated. What happens when the different widgets start having
> diverging requirements? With each Nebula widget potentially going in
> different directions I think any common interfaces could become
> constrictive. If we have a real concrete use-case for requiring the
> interface then I could probably be convinced.
>
> What do we need in the API?
>
> -Chris
>
> Tom Schindl wrote:
>> Hi,
>>
>> This would make sense the only problem I currently see is that Nebula
>> isn't structured this way but I could be wrong though.
>>
>> But I definately agree that there should be a central position in
>> nebula providing interfaces, ... like this.
>>
>> I'd propose something like "nebula.core" to hold things like this? For
>> your gallery widget I think this a very important thing because your
>> widget is by its purpose allocating a lot of system resources.
>>
>> Tom
>>
>> Nicolas Richeton schrieb:
>>> About the listener for visible/invisible items :
>>>
>>> I want to add this feature to the gallery widget. Maybe we could use
>>> the same API for all Nebula widgets ?
>>>
>>> --
>>> Nicolas
>>>
>>> Tom Schindl a écrit :
>>>> Implementation ready and uploaded but it was really an easy one :-)
>>>>
>>>> Some questions on the GridItem though:
>>>>
>>>> - Why can't one set the Item back to default behaviour (showing
>>>> row-numbers)
>>>>
>>>> - Would it be possible to implement beside setting a text also an
>>>> image,
>>>> color, font, ...?
>>>>
>>>> This would be a cool feature I think e.g. highlighting rows with an
>>>> error marker?
>>>>
>>>> - I suppose that the Grid knows which items are currently visible? Is
>>>> there some listener available to track which items are scrolled
>>>> out of
>>>> view. This would be extremely helpful when working with
>>>> OS-Resources(Images, Fonts, Colors) because when not needed anymore
>>>> they could be disposed
>>>>
>>>> I think the GridColumnLabelProvider could be enhanced to take care
>>>> of such resources and this would make GridViewer and Grid even more
>>>> interesting for people currently facing problems with SWT-Table/Tree
>>>> because there's no easy way to determine this (see
>>>> http://tom-eclipse-dev.blogspot.com/2007/01/what-items-are-v isible-in-tabletree.html).
>>>>
>>>>
>>>> Tom
>>>>
>>>> Tom Schindl schrieb:
>>>>> Hi,
>>>>>
>>>>> You are right Chris that's what I meant I haven't thought about
>>>>> this carefully enough. Hence the request for a bug report.
>>>>>
>>>>> Maybe we could provide a standard label provider ontop of
>>>>> ColumnLabelProvider. I'm against adding something depending on the
>>>>> old API using the hack below :-)
>>>>>
>>>>> I logged https://bugs.eclipse.org/bugs/show_bug.cgi?id=188430 and
>>>>> will provide an example implementation.
>>>>>
>>>>> Tom
>>>>>
|
|
|
Re: [GridViewer]How to change text of rowHeader with a labelprovider ? [message #35458 is a reply to message #35424] |
Thu, 24 May 2007 19:57 |
Chris Gross Messages: 253 Registered: July 2009 |
Senior Member |
|
|
I think we might as well discuss it here for now.
As I started to think about this some more I realize that this is very
similar to virtual support already implemented in Table/Tree. Table
will use the SWT.SetData callback when an item is scrolled into view.
The big difference is that it doesn't offer a way to clear items as they
scroll out of view. You can use Table#clear to reset an item and the
SWT.SetData will be called as necessary again, but theres no way (AFAIK)
that you can automatically clear an item after it goes out of view.
Perhaps we should just add that single feature and work with the
existing SWT.VIRTUAL pattern.
Regards,
-Chris
Nicolas Richeton wrote:
> I believe that using the same method signature but no common code is OK
> for now.
> But some core package may be usefull in the future too. For example, I
> used AbstractRenderer and TreeNodeToggleRenderer in the Gallery widget
> so this code is duplicated in PGroup, Grid and Gallery...
>
>
> This API will be used to limit the number of handles required when using
> different images, styles and color for each item in Grid, Gallery,
> Tree and Tables.
>
> I think we need :
> * A listener for items that are scrolled out of the visible area.
> Interesting informations are the item and maybe some data on the way it
> was hidden (parent was collapsed or scrollbar were moved)
>
> * A method which returns all the visible items.
> Table already has getTopIndex() that can be used together with widget
> and item sizes to calculate the visible items. But this approach cannot
> be used with other widgets where any item can be expanded/collapsed.
>
> * We don't need a listener for items which are becoming visible because
> the paint event can be used for this.
>
> May be we should use bugzilla to discuss of this ?
>
> --
> Nicolas
>
>
>
> Chris Gross a écrit :
>> Hmm... there could be potential problems if the resources are not
>> available even though the rows are out of view. Off the top of my
>> head I know that GridColumn#pack will need to know the size of the
>> contents of each cell. So that would suffer (but probably not a big
>> deal). There might be other problems. I have to think a little.
>>
>> I think its a good idea to try to ensure that Nebula widgets try to
>> share common API but I'm not sure its a good idea to formalize that in
>> an interface. Where would that interface live? In some core package
>> and then in some core plugin/jar? That would make things a little
>> more messy/complicated. What happens when the different widgets start
>> having diverging requirements? With each Nebula widget potentially
>> going in different directions I think any common interfaces could
>> become constrictive. If we have a real concrete use-case for
>> requiring the interface then I could probably be convinced.
>>
>> What do we need in the API?
>>
>> -Chris
>>
>> Tom Schindl wrote:
>>> Hi,
>>>
>>> This would make sense the only problem I currently see is that Nebula
>>> isn't structured this way but I could be wrong though.
>>>
>>> But I definately agree that there should be a central position in
>>> nebula providing interfaces, ... like this.
>>>
>>> I'd propose something like "nebula.core" to hold things like this?
>>> For your gallery widget I think this a very important thing because
>>> your widget is by its purpose allocating a lot of system resources.
>>>
>>> Tom
>>>
>>> Nicolas Richeton schrieb:
>>>> About the listener for visible/invisible items :
>>>>
>>>> I want to add this feature to the gallery widget. Maybe we could use
>>>> the same API for all Nebula widgets ?
>>>>
>>>> --
>>>> Nicolas
>>>>
>>>> Tom Schindl a écrit :
>>>>> Implementation ready and uploaded but it was really an easy one :-)
>>>>>
>>>>> Some questions on the GridItem though:
>>>>>
>>>>> - Why can't one set the Item back to default behaviour (showing
>>>>> row-numbers)
>>>>>
>>>>> - Would it be possible to implement beside setting a text also an
>>>>> image,
>>>>> color, font, ...?
>>>>>
>>>>> This would be a cool feature I think e.g. highlighting rows with an
>>>>> error marker?
>>>>>
>>>>> - I suppose that the Grid knows which items are currently visible? Is
>>>>> there some listener available to track which items are scrolled
>>>>> out of
>>>>> view. This would be extremely helpful when working with
>>>>> OS-Resources(Images, Fonts, Colors) because when not needed anymore
>>>>> they could be disposed
>>>>>
>>>>> I think the GridColumnLabelProvider could be enhanced to take care
>>>>> of such resources and this would make GridViewer and Grid even more
>>>>> interesting for people currently facing problems with
>>>>> SWT-Table/Tree because there's no easy way to determine this (see
>>>>> http://tom-eclipse-dev.blogspot.com/2007/01/what-items-are-v isible-in-tabletree.html).
>>>>>
>>>>>
>>>>> Tom
>>>>>
>>>>> Tom Schindl schrieb:
>>>>>> Hi,
>>>>>>
>>>>>> You are right Chris that's what I meant I haven't thought about
>>>>>> this carefully enough. Hence the request for a bug report.
>>>>>>
>>>>>> Maybe we could provide a standard label provider ontop of
>>>>>> ColumnLabelProvider. I'm against adding something depending on the
>>>>>> old API using the hack below :-)
>>>>>>
>>>>>> I logged https://bugs.eclipse.org/bugs/show_bug.cgi?id=188430 and
>>>>>> will provide an example implementation.
>>>>>>
>>>>>> Tom
>>>>>>
|
|
|
Re: [GridViewer]How to change text of rowHeader with a labelprovider ? [message #35497 is a reply to message #35458] |
Thu, 24 May 2007 22:11 |
Thomas Schindl Messages: 6651 Registered: July 2009 |
Senior Member |
|
|
I like this, no I love this :-), staying as near to SWT as possible is a
great thing. The only thing I ask myself is where you get the constant
from if you don't have a single common package all these things live in.
I understand your point of view that there should not be too many
dependencies and controls may evolve differently but defining a common
set of things in not a bad thing and to get really usable it doesn't
matter because once a control declared something API it has to stay for
ever (http://inside-swt.blogspot.com/2007/02/its-end-of-era.html).
Tom
Chris Gross schrieb:
> I think we might as well discuss it here for now.
>
> As I started to think about this some more I realize that this is very
> similar to virtual support already implemented in Table/Tree. Table
> will use the SWT.SetData callback when an item is scrolled into view.
> The big difference is that it doesn't offer a way to clear items as they
> scroll out of view. You can use Table#clear to reset an item and the
> SWT.SetData will be called as necessary again, but theres no way (AFAIK)
> that you can automatically clear an item after it goes out of view.
> Perhaps we should just add that single feature and work with the
> existing SWT.VIRTUAL pattern.
>
> Regards,
> -Chris
>
> Nicolas Richeton wrote:
>> I believe that using the same method signature but no common code is
>> OK for now.
>> But some core package may be usefull in the future too. For example, I
>> used AbstractRenderer and TreeNodeToggleRenderer in the Gallery widget
>> so this code is duplicated in PGroup, Grid and Gallery...
>>
>>
>> This API will be used to limit the number of handles required when
>> using different images, styles and color for each item in Grid,
>> Gallery, Tree and Tables.
>>
>> I think we need :
>> * A listener for items that are scrolled out of the visible area.
>> Interesting informations are the item and maybe some data on the way
>> it was hidden (parent was collapsed or scrollbar were moved)
>>
>> * A method which returns all the visible items.
>> Table already has getTopIndex() that can be used together with widget
>> and item sizes to calculate the visible items. But this approach
>> cannot be used with other widgets where any item can be
>> expanded/collapsed.
>>
>> * We don't need a listener for items which are becoming visible
>> because the paint event can be used for this.
>>
>> May be we should use bugzilla to discuss of this ?
>>
>> --
>> Nicolas
>>
>>
>>
>> Chris Gross a écrit :
>>> Hmm... there could be potential problems if the resources are not
>>> available even though the rows are out of view. Off the top of my
>>> head I know that GridColumn#pack will need to know the size of the
>>> contents of each cell. So that would suffer (but probably not a big
>>> deal). There might be other problems. I have to think a little.
>>>
>>> I think its a good idea to try to ensure that Nebula widgets try to
>>> share common API but I'm not sure its a good idea to formalize that
>>> in an interface. Where would that interface live? In some core
>>> package and then in some core plugin/jar? That would make things a
>>> little more messy/complicated. What happens when the different
>>> widgets start having diverging requirements? With each Nebula widget
>>> potentially going in different directions I think any common
>>> interfaces could become constrictive. If we have a real concrete
>>> use-case for requiring the interface then I could probably be convinced.
>>>
>>> What do we need in the API?
>>>
>>> -Chris
>>>
>>> Tom Schindl wrote:
>>>> Hi,
>>>>
>>>> This would make sense the only problem I currently see is that
>>>> Nebula isn't structured this way but I could be wrong though.
>>>>
>>>> But I definately agree that there should be a central position in
>>>> nebula providing interfaces, ... like this.
>>>>
>>>> I'd propose something like "nebula.core" to hold things like this?
>>>> For your gallery widget I think this a very important thing because
>>>> your widget is by its purpose allocating a lot of system resources.
>>>>
>>>> Tom
>>>>
>>>> Nicolas Richeton schrieb:
>>>>> About the listener for visible/invisible items :
>>>>>
>>>>> I want to add this feature to the gallery widget. Maybe we could
>>>>> use the same API for all Nebula widgets ?
>>>>>
>>>>> --
>>>>> Nicolas
>>>>>
>>>>> Tom Schindl a écrit :
>>>>>> Implementation ready and uploaded but it was really an easy one :-)
>>>>>>
>>>>>> Some questions on the GridItem though:
>>>>>>
>>>>>> - Why can't one set the Item back to default behaviour (showing
>>>>>> row-numbers)
>>>>>>
>>>>>> - Would it be possible to implement beside setting a text also an
>>>>>> image,
>>>>>> color, font, ...?
>>>>>>
>>>>>> This would be a cool feature I think e.g. highlighting rows with an
>>>>>> error marker?
>>>>>>
>>>>>> - I suppose that the Grid knows which items are currently visible? Is
>>>>>> there some listener available to track which items are scrolled
>>>>>> out of
>>>>>> view. This would be extremely helpful when working with
>>>>>> OS-Resources(Images, Fonts, Colors) because when not needed anymore
>>>>>> they could be disposed
>>>>>>
>>>>>> I think the GridColumnLabelProvider could be enhanced to take care
>>>>>> of such resources and this would make GridViewer and Grid even
>>>>>> more interesting for people currently facing problems with
>>>>>> SWT-Table/Tree because there's no easy way to determine this (see
>>>>>> http://tom-eclipse-dev.blogspot.com/2007/01/what-items-are-v isible-in-tabletree.html).
>>>>>>
>>>>>>
>>>>>> Tom
>>>>>>
>>>>>> Tom Schindl schrieb:
>>>>>>> Hi,
>>>>>>>
>>>>>>> You are right Chris that's what I meant I haven't thought about
>>>>>>> this carefully enough. Hence the request for a bug report.
>>>>>>>
>>>>>>> Maybe we could provide a standard label provider ontop of
>>>>>>> ColumnLabelProvider. I'm against adding something depending on
>>>>>>> the old API using the hack below :-)
>>>>>>>
>>>>>>> I logged https://bugs.eclipse.org/bugs/show_bug.cgi?id=188430 and
>>>>>>> will provide an example implementation.
>>>>>>>
>>>>>>> Tom
>>>>>>>
|
|
|
Re: [GridViewer]How to change text of rowHeader with a labelprovider ? [message #35533 is a reply to message #35497] |
Fri, 25 May 2007 09:12 |
Thomas Schindl Messages: 6651 Registered: July 2009 |
Senior Member |
|
|
Hi,
One more note Chris.
The SetData callback has the problem that it only informs you when rows
are scrolled into view but it's not working for cells/columns. I think
nebula controls should not suffer from the same problem SWT-Controls do
because they don't support the concept of cells (which is already solved
in your Grid => JFace for key-navigation is very simple in contrast to
SWT-Implementation :-).
I take the point of view that the Listener should work on top of the
Cell-Concept instead of the only row-based SWT-Concept. Wouldn't it make
sense that all columnbased controls implement the same interface?
Tom
Tom Schindl schrieb:
> I like this, no I love this :-), staying as near to SWT as possible is a
> great thing. The only thing I ask myself is where you get the constant
> from if you don't have a single common package all these things live in.
>
> I understand your point of view that there should not be too many
> dependencies and controls may evolve differently but defining a common
> set of things in not a bad thing and to get really usable it doesn't
> matter because once a control declared something API it has to stay for
> ever (http://inside-swt.blogspot.com/2007/02/its-end-of-era.html).
>
> Tom
>
> Chris Gross schrieb:
>> I think we might as well discuss it here for now.
>>
>> As I started to think about this some more I realize that this is very
>> similar to virtual support already implemented in Table/Tree. Table
>> will use the SWT.SetData callback when an item is scrolled into view.
>> The big difference is that it doesn't offer a way to clear items as
>> they scroll out of view. You can use Table#clear to reset an item and
>> the SWT.SetData will be called as necessary again, but theres no way
>> (AFAIK) that you can automatically clear an item after it goes out of
>> view. Perhaps we should just add that single feature and work with the
>> existing SWT.VIRTUAL pattern.
>>
>> Regards,
>> -Chris
>>
>> Nicolas Richeton wrote:
>>> I believe that using the same method signature but no common code is
>>> OK for now.
>>> But some core package may be usefull in the future too. For example,
>>> I used AbstractRenderer and TreeNodeToggleRenderer in the Gallery
>>> widget so this code is duplicated in PGroup, Grid and Gallery...
>>>
>>>
>>> This API will be used to limit the number of handles required when
>>> using different images, styles and color for each item in Grid,
>>> Gallery, Tree and Tables.
>>>
>>> I think we need :
>>> * A listener for items that are scrolled out of the visible area.
>>> Interesting informations are the item and maybe some data on the way
>>> it was hidden (parent was collapsed or scrollbar were moved)
>>>
>>> * A method which returns all the visible items.
>>> Table already has getTopIndex() that can be used together with widget
>>> and item sizes to calculate the visible items. But this approach
>>> cannot be used with other widgets where any item can be
>>> expanded/collapsed.
>>>
>>> * We don't need a listener for items which are becoming visible
>>> because the paint event can be used for this.
>>>
>>> May be we should use bugzilla to discuss of this ?
>>>
>>> --
>>> Nicolas
>>>
>>>
>>>
>>> Chris Gross a écrit :
>>>> Hmm... there could be potential problems if the resources are not
>>>> available even though the rows are out of view. Off the top of my
>>>> head I know that GridColumn#pack will need to know the size of the
>>>> contents of each cell. So that would suffer (but probably not a big
>>>> deal). There might be other problems. I have to think a little.
>>>>
>>>> I think its a good idea to try to ensure that Nebula widgets try to
>>>> share common API but I'm not sure its a good idea to formalize that
>>>> in an interface. Where would that interface live? In some core
>>>> package and then in some core plugin/jar? That would make things a
>>>> little more messy/complicated. What happens when the different
>>>> widgets start having diverging requirements? With each Nebula
>>>> widget potentially going in different directions I think any common
>>>> interfaces could become constrictive. If we have a real concrete
>>>> use-case for requiring the interface then I could probably be
>>>> convinced.
>>>>
>>>> What do we need in the API?
>>>>
>>>> -Chris
>>>>
>>>> Tom Schindl wrote:
>>>>> Hi,
>>>>>
>>>>> This would make sense the only problem I currently see is that
>>>>> Nebula isn't structured this way but I could be wrong though.
>>>>>
>>>>> But I definately agree that there should be a central position in
>>>>> nebula providing interfaces, ... like this.
>>>>>
>>>>> I'd propose something like "nebula.core" to hold things like this?
>>>>> For your gallery widget I think this a very important thing because
>>>>> your widget is by its purpose allocating a lot of system resources.
>>>>>
>>>>> Tom
>>>>>
>>>>> Nicolas Richeton schrieb:
>>>>>> About the listener for visible/invisible items :
>>>>>>
>>>>>> I want to add this feature to the gallery widget. Maybe we could
>>>>>> use the same API for all Nebula widgets ?
>>>>>>
>>>>>> --
>>>>>> Nicolas
>>>>>>
>>>>>> Tom Schindl a écrit :
>>>>>>> Implementation ready and uploaded but it was really an easy one :-)
>>>>>>>
>>>>>>> Some questions on the GridItem though:
>>>>>>>
>>>>>>> - Why can't one set the Item back to default behaviour (showing
>>>>>>> row-numbers)
>>>>>>>
>>>>>>> - Would it be possible to implement beside setting a text also an
>>>>>>> image,
>>>>>>> color, font, ...?
>>>>>>>
>>>>>>> This would be a cool feature I think e.g. highlighting rows
>>>>>>> with an
>>>>>>> error marker?
>>>>>>>
>>>>>>> - I suppose that the Grid knows which items are currently
>>>>>>> visible? Is
>>>>>>> there some listener available to track which items are scrolled
>>>>>>> out of
>>>>>>> view. This would be extremely helpful when working with
>>>>>>> OS-Resources(Images, Fonts, Colors) because when not needed
>>>>>>> anymore
>>>>>>> they could be disposed
>>>>>>>
>>>>>>> I think the GridColumnLabelProvider could be enhanced to take
>>>>>>> care of such resources and this would make GridViewer and Grid
>>>>>>> even more interesting for people currently facing problems with
>>>>>>> SWT-Table/Tree because there's no easy way to determine this (see
>>>>>>> http://tom-eclipse-dev.blogspot.com/2007/01/what-items-are-v isible-in-tabletree.html).
>>>>>>>
>>>>>>>
>>>>>>> Tom
>>>>>>>
>>>>>>> Tom Schindl schrieb:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> You are right Chris that's what I meant I haven't thought about
>>>>>>>> this carefully enough. Hence the request for a bug report.
>>>>>>>>
>>>>>>>> Maybe we could provide a standard label provider ontop of
>>>>>>>> ColumnLabelProvider. I'm against adding something depending on
>>>>>>>> the old API using the hack below :-)
>>>>>>>>
>>>>>>>> I logged https://bugs.eclipse.org/bugs/show_bug.cgi?id=188430
>>>>>>>> and will provide an example implementation.
>>>>>>>>
>>>>>>>> Tom
>>>>>>>>
|
|
|
Re: [GridViewer]How to change text of rowHeader with a labelprovider ? [message #35566 is a reply to message #35533] |
Fri, 25 May 2007 15:31 |
Chris Gross Messages: 253 Registered: July 2009 |
Senior Member |
|
|
True the SetData callback isn't cell specific but is that absolutely
needed? The row based callback should still allow you to manage
resources enough so that only a reasonable number around at one time.
If we made this cell specific would we require the use of a viewer? I
don't quite understand how it would work. We would still need the
widget layer to provide the basic callbacks including information on
what columns are visible/invisible. Seems a little more complicated.
If we stay with SetData, then it would work well with existing JFace
virtual support.
Regards,
-Chris
Tom Schindl wrote:
> Hi,
>
> One more note Chris.
>
> The SetData callback has the problem that it only informs you when rows
> are scrolled into view but it's not working for cells/columns. I think
> nebula controls should not suffer from the same problem SWT-Controls do
> because they don't support the concept of cells (which is already solved
> in your Grid => JFace for key-navigation is very simple in contrast to
> SWT-Implementation :-).
>
> I take the point of view that the Listener should work on top of the
> Cell-Concept instead of the only row-based SWT-Concept. Wouldn't it make
> sense that all columnbased controls implement the same interface?
>
> Tom
>
>
> Tom Schindl schrieb:
>> I like this, no I love this :-), staying as near to SWT as possible is
>> a great thing. The only thing I ask myself is where you get the
>> constant from if you don't have a single common package all these
>> things live in.
>>
>> I understand your point of view that there should not be too many
>> dependencies and controls may evolve differently but defining a common
>> set of things in not a bad thing and to get really usable it doesn't
>> matter because once a control declared something API it has to stay
>> for ever (http://inside-swt.blogspot.com/2007/02/its-end-of-era.html).
>>
>> Tom
>>
>> Chris Gross schrieb:
>>> I think we might as well discuss it here for now.
>>>
>>> As I started to think about this some more I realize that this is
>>> very similar to virtual support already implemented in Table/Tree.
>>> Table will use the SWT.SetData callback when an item is scrolled into
>>> view. The big difference is that it doesn't offer a way to clear
>>> items as they scroll out of view. You can use Table#clear to reset
>>> an item and the SWT.SetData will be called as necessary again, but
>>> theres no way (AFAIK) that you can automatically clear an item after
>>> it goes out of view. Perhaps we should just add that single feature
>>> and work with the existing SWT.VIRTUAL pattern.
>>>
>>> Regards,
>>> -Chris
>>>
>>> Nicolas Richeton wrote:
>>>> I believe that using the same method signature but no common code is
>>>> OK for now.
>>>> But some core package may be usefull in the future too. For example,
>>>> I used AbstractRenderer and TreeNodeToggleRenderer in the Gallery
>>>> widget so this code is duplicated in PGroup, Grid and Gallery...
>>>>
>>>>
>>>> This API will be used to limit the number of handles required when
>>>> using different images, styles and color for each item in Grid,
>>>> Gallery, Tree and Tables.
>>>>
>>>> I think we need :
>>>> * A listener for items that are scrolled out of the visible area.
>>>> Interesting informations are the item and maybe some data on the way
>>>> it was hidden (parent was collapsed or scrollbar were moved)
>>>>
>>>> * A method which returns all the visible items.
>>>> Table already has getTopIndex() that can be used together with
>>>> widget and item sizes to calculate the visible items. But this
>>>> approach cannot be used with other widgets where any item can be
>>>> expanded/collapsed.
>>>>
>>>> * We don't need a listener for items which are becoming visible
>>>> because the paint event can be used for this.
>>>>
>>>> May be we should use bugzilla to discuss of this ?
>>>>
>>>> --
>>>> Nicolas
>>>>
>>>>
>>>>
>>>> Chris Gross a écrit :
>>>>> Hmm... there could be potential problems if the resources are not
>>>>> available even though the rows are out of view. Off the top of my
>>>>> head I know that GridColumn#pack will need to know the size of the
>>>>> contents of each cell. So that would suffer (but probably not a
>>>>> big deal). There might be other problems. I have to think a little.
>>>>>
>>>>> I think its a good idea to try to ensure that Nebula widgets try to
>>>>> share common API but I'm not sure its a good idea to formalize that
>>>>> in an interface. Where would that interface live? In some core
>>>>> package and then in some core plugin/jar? That would make things a
>>>>> little more messy/complicated. What happens when the different
>>>>> widgets start having diverging requirements? With each Nebula
>>>>> widget potentially going in different directions I think any common
>>>>> interfaces could become constrictive. If we have a real concrete
>>>>> use-case for requiring the interface then I could probably be
>>>>> convinced.
>>>>>
>>>>> What do we need in the API?
>>>>>
>>>>> -Chris
>>>>>
>>>>> Tom Schindl wrote:
>>>>>> Hi,
>>>>>>
>>>>>> This would make sense the only problem I currently see is that
>>>>>> Nebula isn't structured this way but I could be wrong though.
>>>>>>
>>>>>> But I definately agree that there should be a central position in
>>>>>> nebula providing interfaces, ... like this.
>>>>>>
>>>>>> I'd propose something like "nebula.core" to hold things like this?
>>>>>> For your gallery widget I think this a very important thing
>>>>>> because your widget is by its purpose allocating a lot of system
>>>>>> resources.
>>>>>>
>>>>>> Tom
>>>>>>
>>>>>> Nicolas Richeton schrieb:
>>>>>>> About the listener for visible/invisible items :
>>>>>>>
>>>>>>> I want to add this feature to the gallery widget. Maybe we could
>>>>>>> use the same API for all Nebula widgets ?
>>>>>>>
>>>>>>> --
>>>>>>> Nicolas
>>>>>>>
>>>>>>> Tom Schindl a écrit :
>>>>>>>> Implementation ready and uploaded but it was really an easy one :-)
>>>>>>>>
>>>>>>>> Some questions on the GridItem though:
>>>>>>>>
>>>>>>>> - Why can't one set the Item back to default behaviour (showing
>>>>>>>> row-numbers)
>>>>>>>>
>>>>>>>> - Would it be possible to implement beside setting a text also
>>>>>>>> an image,
>>>>>>>> color, font, ...?
>>>>>>>>
>>>>>>>> This would be a cool feature I think e.g. highlighting rows
>>>>>>>> with an
>>>>>>>> error marker?
>>>>>>>>
>>>>>>>> - I suppose that the Grid knows which items are currently
>>>>>>>> visible? Is
>>>>>>>> there some listener available to track which items are
>>>>>>>> scrolled out of
>>>>>>>> view. This would be extremely helpful when working with
>>>>>>>> OS-Resources(Images, Fonts, Colors) because when not needed
>>>>>>>> anymore
>>>>>>>> they could be disposed
>>>>>>>>
>>>>>>>> I think the GridColumnLabelProvider could be enhanced to take
>>>>>>>> care of such resources and this would make GridViewer and Grid
>>>>>>>> even more interesting for people currently facing problems with
>>>>>>>> SWT-Table/Tree because there's no easy way to determine this
>>>>>>>> (see
>>>>>>>> http://tom-eclipse-dev.blogspot.com/2007/01/what-items-are-v isible-in-tabletree.html).
>>>>>>>>
>>>>>>>>
>>>>>>>> Tom
>>>>>>>>
>>>>>>>> Tom Schindl schrieb:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> You are right Chris that's what I meant I haven't thought about
>>>>>>>>> this carefully enough. Hence the request for a bug report.
>>>>>>>>>
>>>>>>>>> Maybe we could provide a standard label provider ontop of
>>>>>>>>> ColumnLabelProvider. I'm against adding something depending on
>>>>>>>>> the old API using the hack below :-)
>>>>>>>>>
>>>>>>>>> I logged https://bugs.eclipse.org/bugs/show_bug.cgi?id=188430
>>>>>>>>> and will provide an example implementation.
>>>>>>>>>
>>>>>>>>> Tom
>>>>>>>>>
|
|
|
Re: [GridViewer]How to change text of rowHeader with a labelprovider ? [message #36077 is a reply to message #35566] |
Tue, 05 June 2007 20:11 |
Thomas Schindl Messages: 6651 Registered: July 2009 |
Senior Member |
|
|
Sorry for coming back after such a long time.
Well if we I don't think we need to depend on any Viewer-Code I need to
investigate but for Tables/Trees with many columns this might still be
an issue.
The other thing that makes neverous is that the SetData-Callback in
SWT-Controls get's a different meaning in Grid which might provoke
problems with the AbstractTable/TreeViewer in future what do you do if
you add VIRTUAL-Support to Grid?
With all the work done in 190252 is there maybe already internal-API to
query the currently visible GridCells?
Tom
Chris Gross schrieb:
> True the SetData callback isn't cell specific but is that absolutely
> needed? The row based callback should still allow you to manage
> resources enough so that only a reasonable number around at one time.
> If we made this cell specific would we require the use of a viewer? I
> don't quite understand how it would work. We would still need the
> widget layer to provide the basic callbacks including information on
> what columns are visible/invisible. Seems a little more complicated. If
> we stay with SetData, then it would work well with existing JFace
> virtual support.
>
> Regards,
> -Chris
>
>
>
> Tom Schindl wrote:
>> Hi,
>>
>> One more note Chris.
>>
>> The SetData callback has the problem that it only informs you when
>> rows are scrolled into view but it's not working for cells/columns. I
>> think nebula controls should not suffer from the same problem
>> SWT-Controls do because they don't support the concept of cells (which
>> is already solved in your Grid => JFace for key-navigation is very
>> simple in contrast to SWT-Implementation :-).
>>
>> I take the point of view that the Listener should work on top of the
>> Cell-Concept instead of the only row-based SWT-Concept. Wouldn't it
>> make sense that all columnbased controls implement the same interface?
>>
>> Tom
>>
>>
>> Tom Schindl schrieb:
>>> I like this, no I love this :-), staying as near to SWT as possible
>>> is a great thing. The only thing I ask myself is where you get the
>>> constant from if you don't have a single common package all these
>>> things live in.
>>>
>>> I understand your point of view that there should not be too many
>>> dependencies and controls may evolve differently but defining a
>>> common set of things in not a bad thing and to get really usable it
>>> doesn't matter because once a control declared something API it has
>>> to stay for ever
>>> (http://inside-swt.blogspot.com/2007/02/its-end-of-era.html).
>>>
>>> Tom
>>>
>>> Chris Gross schrieb:
>>>> I think we might as well discuss it here for now.
>>>>
>>>> As I started to think about this some more I realize that this is
>>>> very similar to virtual support already implemented in Table/Tree.
>>>> Table will use the SWT.SetData callback when an item is scrolled
>>>> into view. The big difference is that it doesn't offer a way to
>>>> clear items as they scroll out of view. You can use Table#clear to
>>>> reset an item and the SWT.SetData will be called as necessary again,
>>>> but theres no way (AFAIK) that you can automatically clear an item
>>>> after it goes out of view. Perhaps we should just add that single
>>>> feature and work with the existing SWT.VIRTUAL pattern.
>>>>
>>>> Regards,
>>>> -Chris
>>>>
>>>> Nicolas Richeton wrote:
>>>>> I believe that using the same method signature but no common code
>>>>> is OK for now.
>>>>> But some core package may be usefull in the future too. For
>>>>> example, I used AbstractRenderer and TreeNodeToggleRenderer in the
>>>>> Gallery widget so this code is duplicated in PGroup, Grid and
>>>>> Gallery...
>>>>>
>>>>>
>>>>> This API will be used to limit the number of handles required when
>>>>> using different images, styles and color for each item in Grid,
>>>>> Gallery, Tree and Tables.
>>>>>
>>>>> I think we need :
>>>>> * A listener for items that are scrolled out of the visible area.
>>>>> Interesting informations are the item and maybe some data on the
>>>>> way it was hidden (parent was collapsed or scrollbar were moved)
>>>>>
>>>>> * A method which returns all the visible items.
>>>>> Table already has getTopIndex() that can be used together with
>>>>> widget and item sizes to calculate the visible items. But this
>>>>> approach cannot be used with other widgets where any item can be
>>>>> expanded/collapsed.
>>>>>
>>>>> * We don't need a listener for items which are becoming visible
>>>>> because the paint event can be used for this.
>>>>>
>>>>> May be we should use bugzilla to discuss of this ?
>>>>>
>>>>> --
>>>>> Nicolas
>>>>>
>>>>>
>>>>>
>>>>> Chris Gross a écrit :
>>>>>> Hmm... there could be potential problems if the resources are not
>>>>>> available even though the rows are out of view. Off the top of my
>>>>>> head I know that GridColumn#pack will need to know the size of the
>>>>>> contents of each cell. So that would suffer (but probably not a
>>>>>> big deal). There might be other problems. I have to think a little.
>>>>>>
>>>>>> I think its a good idea to try to ensure that Nebula widgets try
>>>>>> to share common API but I'm not sure its a good idea to formalize
>>>>>> that in an interface. Where would that interface live? In some
>>>>>> core package and then in some core plugin/jar? That would make
>>>>>> things a little more messy/complicated. What happens when the
>>>>>> different widgets start having diverging requirements? With each
>>>>>> Nebula widget potentially going in different directions I think
>>>>>> any common interfaces could become constrictive. If we have a
>>>>>> real concrete use-case for requiring the interface then I could
>>>>>> probably be convinced.
>>>>>>
>>>>>> What do we need in the API?
>>>>>>
>>>>>> -Chris
>>>>>>
>>>>>> Tom Schindl wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> This would make sense the only problem I currently see is that
>>>>>>> Nebula isn't structured this way but I could be wrong though.
>>>>>>>
>>>>>>> But I definately agree that there should be a central position in
>>>>>>> nebula providing interfaces, ... like this.
>>>>>>>
>>>>>>> I'd propose something like "nebula.core" to hold things like
>>>>>>> this? For your gallery widget I think this a very important thing
>>>>>>> because your widget is by its purpose allocating a lot of system
>>>>>>> resources.
>>>>>>>
>>>>>>> Tom
>>>>>>>
>>>>>>> Nicolas Richeton schrieb:
>>>>>>>> About the listener for visible/invisible items :
>>>>>>>>
>>>>>>>> I want to add this feature to the gallery widget. Maybe we could
>>>>>>>> use the same API for all Nebula widgets ?
>>>>>>>>
>>>>>>>> --
>>>>>>>> Nicolas
>>>>>>>>
>>>>>>>> Tom Schindl a écrit :
>>>>>>>>> Implementation ready and uploaded but it was really an easy one
>>>>>>>>> :-)
>>>>>>>>>
>>>>>>>>> Some questions on the GridItem though:
>>>>>>>>>
>>>>>>>>> - Why can't one set the Item back to default behaviour (showing
>>>>>>>>> row-numbers)
>>>>>>>>>
>>>>>>>>> - Would it be possible to implement beside setting a text also
>>>>>>>>> an image,
>>>>>>>>> color, font, ...?
>>>>>>>>>
>>>>>>>>> This would be a cool feature I think e.g. highlighting rows
>>>>>>>>> with an
>>>>>>>>> error marker?
>>>>>>>>>
>>>>>>>>> - I suppose that the Grid knows which items are currently
>>>>>>>>> visible? Is
>>>>>>>>> there some listener available to track which items are
>>>>>>>>> scrolled out of
>>>>>>>>> view. This would be extremely helpful when working with
>>>>>>>>> OS-Resources(Images, Fonts, Colors) because when not needed
>>>>>>>>> anymore
>>>>>>>>> they could be disposed
>>>>>>>>>
>>>>>>>>> I think the GridColumnLabelProvider could be enhanced to take
>>>>>>>>> care of such resources and this would make GridViewer and Grid
>>>>>>>>> even more interesting for people currently facing problems with
>>>>>>>>> SWT-Table/Tree because there's no easy way to determine this
>>>>>>>>> (see
>>>>>>>>> http://tom-eclipse-dev.blogspot.com/2007/01/what-items-are-v isible-in-tabletree.html).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Tom
>>>>>>>>>
>>>>>>>>> Tom Schindl schrieb:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> You are right Chris that's what I meant I haven't thought
>>>>>>>>>> about this carefully enough. Hence the request for a bug report.
>>>>>>>>>>
>>>>>>>>>> Maybe we could provide a standard label provider ontop of
>>>>>>>>>> ColumnLabelProvider. I'm against adding something depending on
>>>>>>>>>> the old API using the hack below :-)
>>>>>>>>>>
>>>>>>>>>> I logged https://bugs.eclipse.org/bugs/show_bug.cgi?id=188430
>>>>>>>>>> and will provide an example implementation.
>>>>>>>>>>
>>>>>>>>>> Tom
>>>>>>>>>>
|
|
|
Re: [GridViewer]How to change text of rowHeader with a labelprovider ? [message #36146 is a reply to message #36077] |
Thu, 07 June 2007 15:15 |
Chris Gross Messages: 253 Registered: July 2009 |
Senior Member |
|
|
I did add virtual support to Grid recently. I modeled the virtual
support in Grid exactly after Table/Tree. And I think these
requirements that we're talking about (maintaining fewer resources)
really maps right in with the way virtual support is designed. The
SetData callback is just saying someone needs the values of this item -
please go fill them in.
I'm certain we could expose a method to return the visible rows (along
with a listener when this value changes) but I'd rather not have to if
there is an existing mechanism that seems designed to solve the same
problem.
-Chris
Tom Schindl wrote:
> Sorry for coming back after such a long time.
>
> Well if we I don't think we need to depend on any Viewer-Code I need to
> investigate but for Tables/Trees with many columns this might still be
> an issue.
>
> The other thing that makes neverous is that the SetData-Callback in
> SWT-Controls get's a different meaning in Grid which might provoke
> problems with the AbstractTable/TreeViewer in future what do you do if
> you add VIRTUAL-Support to Grid?
>
> With all the work done in 190252 is there maybe already internal-API to
> query the currently visible GridCells?
>
> Tom
>
> Chris Gross schrieb:
>> True the SetData callback isn't cell specific but is that absolutely
>> needed? The row based callback should still allow you to manage
>> resources enough so that only a reasonable number around at one time.
>> If we made this cell specific would we require the use of a viewer? I
>> don't quite understand how it would work. We would still need the
>> widget layer to provide the basic callbacks including information on
>> what columns are visible/invisible. Seems a little more complicated.
>> If we stay with SetData, then it would work well with existing JFace
>> virtual support.
>>
>> Regards,
>> -Chris
>>
>>
>>
>> Tom Schindl wrote:
>>> Hi,
>>>
>>> One more note Chris.
>>>
>>> The SetData callback has the problem that it only informs you when
>>> rows are scrolled into view but it's not working for cells/columns. I
>>> think nebula controls should not suffer from the same problem
>>> SWT-Controls do because they don't support the concept of cells
>>> (which is already solved in your Grid => JFace for key-navigation is
>>> very simple in contrast to SWT-Implementation :-).
>>>
>>> I take the point of view that the Listener should work on top of the
>>> Cell-Concept instead of the only row-based SWT-Concept. Wouldn't it
>>> make sense that all columnbased controls implement the same interface?
>>>
>>> Tom
>>>
>>>
>>> Tom Schindl schrieb:
>>>> I like this, no I love this :-), staying as near to SWT as possible
>>>> is a great thing. The only thing I ask myself is where you get the
>>>> constant from if you don't have a single common package all these
>>>> things live in.
>>>>
>>>> I understand your point of view that there should not be too many
>>>> dependencies and controls may evolve differently but defining a
>>>> common set of things in not a bad thing and to get really usable it
>>>> doesn't matter because once a control declared something API it has
>>>> to stay for ever
>>>> (http://inside-swt.blogspot.com/2007/02/its-end-of-era.html).
>>>>
>>>> Tom
>>>>
>>>> Chris Gross schrieb:
>>>>> I think we might as well discuss it here for now.
>>>>>
>>>>> As I started to think about this some more I realize that this is
>>>>> very similar to virtual support already implemented in Table/Tree.
>>>>> Table will use the SWT.SetData callback when an item is scrolled
>>>>> into view. The big difference is that it doesn't offer a way to
>>>>> clear items as they scroll out of view. You can use Table#clear to
>>>>> reset an item and the SWT.SetData will be called as necessary
>>>>> again, but theres no way (AFAIK) that you can automatically clear
>>>>> an item after it goes out of view. Perhaps we should just add that
>>>>> single feature and work with the existing SWT.VIRTUAL pattern.
>>>>>
>>>>> Regards,
>>>>> -Chris
>>>>>
>>>>> Nicolas Richeton wrote:
>>>>>> I believe that using the same method signature but no common code
>>>>>> is OK for now.
>>>>>> But some core package may be usefull in the future too. For
>>>>>> example, I used AbstractRenderer and TreeNodeToggleRenderer in the
>>>>>> Gallery widget so this code is duplicated in PGroup, Grid and
>>>>>> Gallery...
>>>>>>
>>>>>>
>>>>>> This API will be used to limit the number of handles required when
>>>>>> using different images, styles and color for each item in Grid,
>>>>>> Gallery, Tree and Tables.
>>>>>>
>>>>>> I think we need :
>>>>>> * A listener for items that are scrolled out of the visible area.
>>>>>> Interesting informations are the item and maybe some data on the
>>>>>> way it was hidden (parent was collapsed or scrollbar were moved)
>>>>>>
>>>>>> * A method which returns all the visible items.
>>>>>> Table already has getTopIndex() that can be used together with
>>>>>> widget and item sizes to calculate the visible items. But this
>>>>>> approach cannot be used with other widgets where any item can be
>>>>>> expanded/collapsed.
>>>>>>
>>>>>> * We don't need a listener for items which are becoming visible
>>>>>> because the paint event can be used for this.
>>>>>>
>>>>>> May be we should use bugzilla to discuss of this ?
>>>>>>
>>>>>> --
>>>>>> Nicolas
>>>>>>
>>>>>>
>>>>>>
>>>>>> Chris Gross a écrit :
>>>>>>> Hmm... there could be potential problems if the resources are not
>>>>>>> available even though the rows are out of view. Off the top of
>>>>>>> my head I know that GridColumn#pack will need to know the size of
>>>>>>> the contents of each cell. So that would suffer (but probably
>>>>>>> not a big deal). There might be other problems. I have to think
>>>>>>> a little.
>>>>>>>
>>>>>>> I think its a good idea to try to ensure that Nebula widgets try
>>>>>>> to share common API but I'm not sure its a good idea to formalize
>>>>>>> that in an interface. Where would that interface live? In some
>>>>>>> core package and then in some core plugin/jar? That would make
>>>>>>> things a little more messy/complicated. What happens when the
>>>>>>> different widgets start having diverging requirements? With each
>>>>>>> Nebula widget potentially going in different directions I think
>>>>>>> any common interfaces could become constrictive. If we have a
>>>>>>> real concrete use-case for requiring the interface then I could
>>>>>>> probably be convinced.
>>>>>>>
>>>>>>> What do we need in the API?
>>>>>>>
>>>>>>> -Chris
>>>>>>>
>>>>>>> Tom Schindl wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> This would make sense the only problem I currently see is that
>>>>>>>> Nebula isn't structured this way but I could be wrong though.
>>>>>>>>
>>>>>>>> But I definately agree that there should be a central position
>>>>>>>> in nebula providing interfaces, ... like this.
>>>>>>>>
>>>>>>>> I'd propose something like "nebula.core" to hold things like
>>>>>>>> this? For your gallery widget I think this a very important
>>>>>>>> thing because your widget is by its purpose allocating a lot of
>>>>>>>> system resources.
>>>>>>>>
>>>>>>>> Tom
>>>>>>>>
>>>>>>>> Nicolas Richeton schrieb:
>>>>>>>>> About the listener for visible/invisible items :
>>>>>>>>>
>>>>>>>>> I want to add this feature to the gallery widget. Maybe we
>>>>>>>>> could use the same API for all Nebula widgets ?
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Nicolas
>>>>>>>>>
>>>>>>>>> Tom Schindl a écrit :
>>>>>>>>>> Implementation ready and uploaded but it was really an easy
>>>>>>>>>> one :-)
>>>>>>>>>>
>>>>>>>>>> Some questions on the GridItem though:
>>>>>>>>>>
>>>>>>>>>> - Why can't one set the Item back to default behaviour (showing
>>>>>>>>>> row-numbers)
>>>>>>>>>>
>>>>>>>>>> - Would it be possible to implement beside setting a text also
>>>>>>>>>> an image,
>>>>>>>>>> color, font, ...?
>>>>>>>>>>
>>>>>>>>>> This would be a cool feature I think e.g. highlighting rows
>>>>>>>>>> with an
>>>>>>>>>> error marker?
>>>>>>>>>>
>>>>>>>>>> - I suppose that the Grid knows which items are currently
>>>>>>>>>> visible? Is
>>>>>>>>>> there some listener available to track which items are
>>>>>>>>>> scrolled out of
>>>>>>>>>> view. This would be extremely helpful when working with
>>>>>>>>>> OS-Resources(Images, Fonts, Colors) because when not needed
>>>>>>>>>> anymore
>>>>>>>>>> they could be disposed
>>>>>>>>>>
>>>>>>>>>> I think the GridColumnLabelProvider could be enhanced to take
>>>>>>>>>> care of such resources and this would make GridViewer and Grid
>>>>>>>>>> even more interesting for people currently facing problems
>>>>>>>>>> with SWT-Table/Tree because there's no easy way to determine
>>>>>>>>>> this (see
>>>>>>>>>> http://tom-eclipse-dev.blogspot.com/2007/01/what-items-are-v isible-in-tabletree.html).
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Tom
>>>>>>>>>>
>>>>>>>>>> Tom Schindl schrieb:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> You are right Chris that's what I meant I haven't thought
>>>>>>>>>>> about this carefully enough. Hence the request for a bug report.
>>>>>>>>>>>
>>>>>>>>>>> Maybe we could provide a standard label provider ontop of
>>>>>>>>>>> ColumnLabelProvider. I'm against adding something depending
>>>>>>>>>>> on the old API using the hack below :-)
>>>>>>>>>>>
>>>>>>>>>>> I logged https://bugs.eclipse.org/bugs/show_bug.cgi?id=188430
>>>>>>>>>>> and will provide an example implementation.
>>>>>>>>>>>
>>>>>>>>>>> Tom
>>>>>>>>>>>
|
|
|
Re: [GridViewer]How to change text of rowHeader with a labelprovider ? [message #36180 is a reply to message #36146] |
Fri, 08 June 2007 11:10 |
Thomas Schindl Messages: 6651 Registered: July 2009 |
Senior Member |
|
|
Well SetData-callback informs you that Row is scrolled into view but
what do we send when a Row is scrolled out of view? This is the
interesting event we should get to clean up resources, not?
Tom
Chris Gross schrieb:
> I did add virtual support to Grid recently. I modeled the virtual
> support in Grid exactly after Table/Tree. And I think these
> requirements that we're talking about (maintaining fewer resources)
> really maps right in with the way virtual support is designed. The
> SetData callback is just saying someone needs the values of this item -
> please go fill them in.
>
> I'm certain we could expose a method to return the visible rows (along
> with a listener when this value changes) but I'd rather not have to if
> there is an existing mechanism that seems designed to solve the same
> problem.
>
> -Chris
>
> Tom Schindl wrote:
>> Sorry for coming back after such a long time.
>>
>> Well if we I don't think we need to depend on any Viewer-Code I need
>> to investigate but for Tables/Trees with many columns this might still
>> be an issue.
>>
>> The other thing that makes neverous is that the SetData-Callback in
>> SWT-Controls get's a different meaning in Grid which might provoke
>> problems with the AbstractTable/TreeViewer in future what do you do if
>> you add VIRTUAL-Support to Grid?
>>
>> With all the work done in 190252 is there maybe already internal-API
>> to query the currently visible GridCells?
>>
>> Tom
>>
>> Chris Gross schrieb:
>>> True the SetData callback isn't cell specific but is that absolutely
>>> needed? The row based callback should still allow you to manage
>>> resources enough so that only a reasonable number around at one time.
>>> If we made this cell specific would we require the use of a viewer?
>>> I don't quite understand how it would work. We would still need the
>>> widget layer to provide the basic callbacks including information on
>>> what columns are visible/invisible. Seems a little more complicated.
>>> If we stay with SetData, then it would work well with existing JFace
>>> virtual support.
>>>
>>> Regards,
>>> -Chris
>>>
>>>
>>>
>>> Tom Schindl wrote:
>>>> Hi,
>>>>
>>>> One more note Chris.
>>>>
>>>> The SetData callback has the problem that it only informs you when
>>>> rows are scrolled into view but it's not working for cells/columns.
>>>> I think nebula controls should not suffer from the same problem
>>>> SWT-Controls do because they don't support the concept of cells
>>>> (which is already solved in your Grid => JFace for key-navigation is
>>>> very simple in contrast to SWT-Implementation :-).
>>>>
>>>> I take the point of view that the Listener should work on top of the
>>>> Cell-Concept instead of the only row-based SWT-Concept. Wouldn't it
>>>> make sense that all columnbased controls implement the same interface?
>>>>
>>>> Tom
>>>>
>>>>
>>>> Tom Schindl schrieb:
>>>>> I like this, no I love this :-), staying as near to SWT as possible
>>>>> is a great thing. The only thing I ask myself is where you get the
>>>>> constant from if you don't have a single common package all these
>>>>> things live in.
>>>>>
>>>>> I understand your point of view that there should not be too many
>>>>> dependencies and controls may evolve differently but defining a
>>>>> common set of things in not a bad thing and to get really usable it
>>>>> doesn't matter because once a control declared something API it has
>>>>> to stay for ever
>>>>> (http://inside-swt.blogspot.com/2007/02/its-end-of-era.html).
>>>>>
>>>>> Tom
>>>>>
>>>>> Chris Gross schrieb:
>>>>>> I think we might as well discuss it here for now.
>>>>>>
>>>>>> As I started to think about this some more I realize that this is
>>>>>> very similar to virtual support already implemented in
>>>>>> Table/Tree. Table will use the SWT.SetData callback when an item
>>>>>> is scrolled into view. The big difference is that it doesn't offer
>>>>>> a way to clear items as they scroll out of view. You can use
>>>>>> Table#clear to reset an item and the SWT.SetData will be called as
>>>>>> necessary again, but theres no way (AFAIK) that you can
>>>>>> automatically clear an item after it goes out of view. Perhaps we
>>>>>> should just add that single feature and work with the existing
>>>>>> SWT.VIRTUAL pattern.
>>>>>>
>>>>>> Regards,
>>>>>> -Chris
>>>>>>
>>>>>> Nicolas Richeton wrote:
>>>>>>> I believe that using the same method signature but no common code
>>>>>>> is OK for now.
>>>>>>> But some core package may be usefull in the future too. For
>>>>>>> example, I used AbstractRenderer and TreeNodeToggleRenderer in
>>>>>>> the Gallery widget so this code is duplicated in PGroup, Grid and
>>>>>>> Gallery...
>>>>>>>
>>>>>>>
>>>>>>> This API will be used to limit the number of handles required
>>>>>>> when using different images, styles and color for each item in
>>>>>>> Grid, Gallery, Tree and Tables.
>>>>>>>
>>>>>>> I think we need :
>>>>>>> * A listener for items that are scrolled out of the visible area.
>>>>>>> Interesting informations are the item and maybe some data on the
>>>>>>> way it was hidden (parent was collapsed or scrollbar were moved)
>>>>>>>
>>>>>>> * A method which returns all the visible items.
>>>>>>> Table already has getTopIndex() that can be used together with
>>>>>>> widget and item sizes to calculate the visible items. But this
>>>>>>> approach cannot be used with other widgets where any item can be
>>>>>>> expanded/collapsed.
>>>>>>>
>>>>>>> * We don't need a listener for items which are becoming visible
>>>>>>> because the paint event can be used for this.
>>>>>>>
>>>>>>> May be we should use bugzilla to discuss of this ?
>>>>>>>
>>>>>>> --
>>>>>>> Nicolas
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Chris Gross a écrit :
>>>>>>>> Hmm... there could be potential problems if the resources are
>>>>>>>> not available even though the rows are out of view. Off the top
>>>>>>>> of my head I know that GridColumn#pack will need to know the
>>>>>>>> size of the contents of each cell. So that would suffer (but
>>>>>>>> probably not a big deal). There might be other problems. I have
>>>>>>>> to think a little.
>>>>>>>>
>>>>>>>> I think its a good idea to try to ensure that Nebula widgets try
>>>>>>>> to share common API but I'm not sure its a good idea to
>>>>>>>> formalize that in an interface. Where would that interface
>>>>>>>> live? In some core package and then in some core plugin/jar?
>>>>>>>> That would make things a little more messy/complicated. What
>>>>>>>> happens when the different widgets start having diverging
>>>>>>>> requirements? With each Nebula widget potentially going in
>>>>>>>> different directions I think any common interfaces could become
>>>>>>>> constrictive. If we have a real concrete use-case for requiring
>>>>>>>> the interface then I could probably be convinced.
>>>>>>>>
>>>>>>>> What do we need in the API?
>>>>>>>>
>>>>>>>> -Chris
>>>>>>>>
>>>>>>>> Tom Schindl wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> This would make sense the only problem I currently see is that
>>>>>>>>> Nebula isn't structured this way but I could be wrong though.
>>>>>>>>>
>>>>>>>>> But I definately agree that there should be a central position
>>>>>>>>> in nebula providing interfaces, ... like this.
>>>>>>>>>
>>>>>>>>> I'd propose something like "nebula.core" to hold things like
>>>>>>>>> this? For your gallery widget I think this a very important
>>>>>>>>> thing because your widget is by its purpose allocating a lot of
>>>>>>>>> system resources.
>>>>>>>>>
>>>>>>>>> Tom
>>>>>>>>>
>>>>>>>>> Nicolas Richeton schrieb:
>>>>>>>>>> About the listener for visible/invisible items :
>>>>>>>>>>
>>>>>>>>>> I want to add this feature to the gallery widget. Maybe we
>>>>>>>>>> could use the same API for all Nebula widgets ?
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Nicolas
>>>>>>>>>>
>>>>>>>>>> Tom Schindl a écrit :
>>>>>>>>>>> Implementation ready and uploaded but it was really an easy
>>>>>>>>>>> one :-)
>>>>>>>>>>>
>>>>>>>>>>> Some questions on the GridItem though:
>>>>>>>>>>>
>>>>>>>>>>> - Why can't one set the Item back to default behaviour (showing
>>>>>>>>>>> row-numbers)
>>>>>>>>>>>
>>>>>>>>>>> - Would it be possible to implement beside setting a text
>>>>>>>>>>> also an image,
>>>>>>>>>>> color, font, ...?
>>>>>>>>>>>
>>>>>>>>>>> This would be a cool feature I think e.g. highlighting rows
>>>>>>>>>>> with an
>>>>>>>>>>> error marker?
>>>>>>>>>>>
>>>>>>>>>>> - I suppose that the Grid knows which items are currently
>>>>>>>>>>> visible? Is
>>>>>>>>>>> there some listener available to track which items are
>>>>>>>>>>> scrolled out of
>>>>>>>>>>> view. This would be extremely helpful when working with
>>>>>>>>>>> OS-Resources(Images, Fonts, Colors) because when not needed
>>>>>>>>>>> anymore
>>>>>>>>>>> they could be disposed
>>>>>>>>>>>
>>>>>>>>>>> I think the GridColumnLabelProvider could be enhanced to take
>>>>>>>>>>> care of such resources and this would make GridViewer and
>>>>>>>>>>> Grid even more interesting for people currently facing
>>>>>>>>>>> problems with SWT-Table/Tree because there's no easy way to
>>>>>>>>>>> determine this (see
>>>>>>>>>>> http://tom-eclipse-dev.blogspot.com/2007/01/what-items-are-v isible-in-tabletree.html).
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Tom
>>>>>>>>>>>
>>>>>>>>>>> Tom Schindl schrieb:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> You are right Chris that's what I meant I haven't thought
>>>>>>>>>>>> about this carefully enough. Hence the request for a bug
>>>>>>>>>>>> report.
>>>>>>>>>>>>
>>>>>>>>>>>> Maybe we could provide a standard label provider ontop of
>>>>>>>>>>>> ColumnLabelProvider. I'm against adding something depending
>>>>>>>>>>>> on the old API using the hack below :-)
>>>>>>>>>>>>
>>>>>>>>>>>> I logged
>>>>>>>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=188430 and
>>>>>>>>>>>> will provide an example implementation.
>>>>>>>>>>>>
>>>>>>>>>>>> Tom
>>>>>>>>>>>>
|
|
|
Re: [GridViewer]How to change text of rowHeader with a labelprovider ? [message #36214 is a reply to message #36180] |
Fri, 08 June 2007 15:18 |
Chris Gross Messages: 253 Registered: July 2009 |
Senior Member |
|
|
Right. We would need to add a new callback to compliment SetData.
Perhaps ClearData? The constant will have to live on Grid (and
Gallery). This feels like a smaller, better change.
-Chris
Tom Schindl wrote:
> Well SetData-callback informs you that Row is scrolled into view but
> what do we send when a Row is scrolled out of view? This is the
> interesting event we should get to clean up resources, not?
>
> Tom
>
> Chris Gross schrieb:
>> I did add virtual support to Grid recently. I modeled the virtual
>> support in Grid exactly after Table/Tree. And I think these
>> requirements that we're talking about (maintaining fewer resources)
>> really maps right in with the way virtual support is designed. The
>> SetData callback is just saying someone needs the values of this item
>> - please go fill them in.
>>
>> I'm certain we could expose a method to return the visible rows (along
>> with a listener when this value changes) but I'd rather not have to if
>> there is an existing mechanism that seems designed to solve the same
>> problem.
>>
>> -Chris
>>
>> Tom Schindl wrote:
>>> Sorry for coming back after such a long time.
>>>
>>> Well if we I don't think we need to depend on any Viewer-Code I need
>>> to investigate but for Tables/Trees with many columns this might
>>> still be an issue.
>>>
>>> The other thing that makes neverous is that the SetData-Callback in
>>> SWT-Controls get's a different meaning in Grid which might provoke
>>> problems with the AbstractTable/TreeViewer in future what do you do
>>> if you add VIRTUAL-Support to Grid?
>>>
>>> With all the work done in 190252 is there maybe already internal-API
>>> to query the currently visible GridCells?
>>>
>>> Tom
>>>
>>> Chris Gross schrieb:
>>>> True the SetData callback isn't cell specific but is that absolutely
>>>> needed? The row based callback should still allow you to manage
>>>> resources enough so that only a reasonable number around at one time.
>>>> If we made this cell specific would we require the use of a viewer?
>>>> I don't quite understand how it would work. We would still need the
>>>> widget layer to provide the basic callbacks including information on
>>>> what columns are visible/invisible. Seems a little more
>>>> complicated. If we stay with SetData, then it would work well with
>>>> existing JFace virtual support.
>>>>
>>>> Regards,
>>>> -Chris
>>>>
>>>>
>>>>
>>>> Tom Schindl wrote:
>>>>> Hi,
>>>>>
>>>>> One more note Chris.
>>>>>
>>>>> The SetData callback has the problem that it only informs you when
>>>>> rows are scrolled into view but it's not working for cells/columns.
>>>>> I think nebula controls should not suffer from the same problem
>>>>> SWT-Controls do because they don't support the concept of cells
>>>>> (which is already solved in your Grid => JFace for key-navigation
>>>>> is very simple in contrast to SWT-Implementation :-).
>>>>>
>>>>> I take the point of view that the Listener should work on top of
>>>>> the Cell-Concept instead of the only row-based SWT-Concept.
>>>>> Wouldn't it make sense that all columnbased controls implement the
>>>>> same interface?
>>>>>
>>>>> Tom
>>>>>
>>>>>
>>>>> Tom Schindl schrieb:
>>>>>> I like this, no I love this :-), staying as near to SWT as
>>>>>> possible is a great thing. The only thing I ask myself is where
>>>>>> you get the constant from if you don't have a single common
>>>>>> package all these things live in.
>>>>>>
>>>>>> I understand your point of view that there should not be too many
>>>>>> dependencies and controls may evolve differently but defining a
>>>>>> common set of things in not a bad thing and to get really usable
>>>>>> it doesn't matter because once a control declared something API it
>>>>>> has to stay for ever
>>>>>> (http://inside-swt.blogspot.com/2007/02/its-end-of-era.html).
>>>>>>
>>>>>> Tom
>>>>>>
>>>>>> Chris Gross schrieb:
>>>>>>> I think we might as well discuss it here for now.
>>>>>>>
>>>>>>> As I started to think about this some more I realize that this is
>>>>>>> very similar to virtual support already implemented in
>>>>>>> Table/Tree. Table will use the SWT.SetData callback when an item
>>>>>>> is scrolled into view. The big difference is that it doesn't
>>>>>>> offer a way to clear items as they scroll out of view. You can
>>>>>>> use Table#clear to reset an item and the SWT.SetData will be
>>>>>>> called as necessary again, but theres no way (AFAIK) that you can
>>>>>>> automatically clear an item after it goes out of view. Perhaps we
>>>>>>> should just add that single feature and work with the existing
>>>>>>> SWT.VIRTUAL pattern.
>>>>>>>
>>>>>>> Regards,
>>>>>>> -Chris
>>>>>>>
>>>>>>> Nicolas Richeton wrote:
>>>>>>>> I believe that using the same method signature but no common
>>>>>>>> code is OK for now.
>>>>>>>> But some core package may be usefull in the future too. For
>>>>>>>> example, I used AbstractRenderer and TreeNodeToggleRenderer in
>>>>>>>> the Gallery widget so this code is duplicated in PGroup, Grid
>>>>>>>> and Gallery...
>>>>>>>>
>>>>>>>>
>>>>>>>> This API will be used to limit the number of handles required
>>>>>>>> when using different images, styles and color for each item in
>>>>>>>> Grid, Gallery, Tree and Tables.
>>>>>>>>
>>>>>>>> I think we need :
>>>>>>>> * A listener for items that are scrolled out of the visible
>>>>>>>> area. Interesting informations are the item and maybe some data
>>>>>>>> on the way it was hidden (parent was collapsed or scrollbar were
>>>>>>>> moved)
>>>>>>>>
>>>>>>>> * A method which returns all the visible items.
>>>>>>>> Table already has getTopIndex() that can be used together with
>>>>>>>> widget and item sizes to calculate the visible items. But this
>>>>>>>> approach cannot be used with other widgets where any item can be
>>>>>>>> expanded/collapsed.
>>>>>>>>
>>>>>>>> * We don't need a listener for items which are becoming visible
>>>>>>>> because the paint event can be used for this.
>>>>>>>>
>>>>>>>> May be we should use bugzilla to discuss of this ?
>>>>>>>>
>>>>>>>> --
>>>>>>>> Nicolas
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Chris Gross a écrit :
>>>>>>>>> Hmm... there could be potential problems if the resources are
>>>>>>>>> not available even though the rows are out of view. Off the
>>>>>>>>> top of my head I know that GridColumn#pack will need to know
>>>>>>>>> the size of the contents of each cell. So that would suffer
>>>>>>>>> (but probably not a big deal). There might be other problems.
>>>>>>>>> I have to think a little.
>>>>>>>>>
>>>>>>>>> I think its a good idea to try to ensure that Nebula widgets
>>>>>>>>> try to share common API but I'm not sure its a good idea to
>>>>>>>>> formalize that in an interface. Where would that interface
>>>>>>>>> live? In some core package and then in some core plugin/jar?
>>>>>>>>> That would make things a little more messy/complicated. What
>>>>>>>>> happens when the different widgets start having diverging
>>>>>>>>> requirements? With each Nebula widget potentially going in
>>>>>>>>> different directions I think any common interfaces could become
>>>>>>>>> constrictive. If we have a real concrete use-case for
>>>>>>>>> requiring the interface then I could probably be convinced.
>>>>>>>>>
>>>>>>>>> What do we need in the API?
>>>>>>>>>
>>>>>>>>> -Chris
>>>>>>>>>
>>>>>>>>> Tom Schindl wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> This would make sense the only problem I currently see is that
>>>>>>>>>> Nebula isn't structured this way but I could be wrong though.
>>>>>>>>>>
>>>>>>>>>> But I definately agree that there should be a central position
>>>>>>>>>> in nebula providing interfaces, ... like this.
>>>>>>>>>>
>>>>>>>>>> I'd propose something like "nebula.core" to hold things like
>>>>>>>>>> this? For your gallery widget I think this a very important
>>>>>>>>>> thing because your widget is by its purpose allocating a lot
>>>>>>>>>> of system resources.
>>>>>>>>>>
>>>>>>>>>> Tom
>>>>>>>>>>
>>>>>>>>>> Nicolas Richeton schrieb:
>>>>>>>>>>> About the listener for visible/invisible items :
>>>>>>>>>>>
>>>>>>>>>>> I want to add this feature to the gallery widget. Maybe we
>>>>>>>>>>> could use the same API for all Nebula widgets ?
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Nicolas
>>>>>>>>>>>
>>>>>>>>>>> Tom Schindl a écrit :
>>>>>>>>>>>> Implementation ready and uploaded but it was really an easy
>>>>>>>>>>>> one :-)
>>>>>>>>>>>>
>>>>>>>>>>>> Some questions on the GridItem though:
>>>>>>>>>>>>
>>>>>>>>>>>> - Why can't one set the Item back to default behaviour (showing
>>>>>>>>>>>> row-numbers)
>>>>>>>>>>>>
>>>>>>>>>>>> - Would it be possible to implement beside setting a text
>>>>>>>>>>>> also an image,
>>>>>>>>>>>> color, font, ...?
>>>>>>>>>>>>
>>>>>>>>>>>> This would be a cool feature I think e.g. highlighting
>>>>>>>>>>>> rows with an
>>>>>>>>>>>> error marker?
>>>>>>>>>>>>
>>>>>>>>>>>> - I suppose that the Grid knows which items are currently
>>>>>>>>>>>> visible? Is
>>>>>>>>>>>> there some listener available to track which items are
>>>>>>>>>>>> scrolled out of
>>>>>>>>>>>> view. This would be extremely helpful when working with
>>>>>>>>>>>> OS-Resources(Images, Fonts, Colors) because when not
>>>>>>>>>>>> needed anymore
>>>>>>>>>>>> they could be disposed
>>>>>>>>>>>>
>>>>>>>>>>>> I think the GridColumnLabelProvider could be enhanced to
>>>>>>>>>>>> take care of such resources and this would make GridViewer
>>>>>>>>>>>> and Grid even more interesting for people currently facing
>>>>>>>>>>>> problems with SWT-Table/Tree because there's no easy way to
>>>>>>>>>>>> determine this (see
>>>>>>>>>>>> http://tom-eclipse-dev.blogspot.com/2007/01/what-items-are-v isible-in-tabletree.html).
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Tom
>>>>>>>>>>>>
>>>>>>>>>>>> Tom Schindl schrieb:
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> You are right Chris that's what I meant I haven't thought
>>>>>>>>>>>>> about this carefully enough. Hence the request for a bug
>>>>>>>>>>>>> report.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Maybe we could provide a standard label provider ontop of
>>>>>>>>>>>>> ColumnLabelProvider. I'm against adding something depending
>>>>>>>>>>>>> on the old API using the hack below :-)
>>>>>>>>>>>>>
>>>>>>>>>>>>> I logged
>>>>>>>>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=188430 and
>>>>>>>>>>>>> will provide an example implementation.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Tom
>>>>>>>>>>>>>
|
|
|
Re: [GridViewer]How to change text of rowHeader with a labelprovider ? [message #36248 is a reply to message #36214] |
Mon, 11 June 2007 11:43 |
Nicolas Richeton Messages: 179 Registered: July 2009 |
Senior Member |
|
|
AFAIK SetData is only fired the first time an item is scrolled into
view. This can be used to allocate resources only if we clear each item
on ClearData. The only drawback is that there will be a lot more
SetData events than usual and probably a performance impact (for
example, if items are created from a database).
Paint is fired each time an item is painted. This is a better place to
allocate resources, if it was not already done. It allows to keep
internal item data between paints.
Maybe we need some intermediate events, something like ScrollIn (item
becomes visible) / ScrollOut (item is no longer visible).
--
Nicolas.
Chris Gross a écrit :
> Right. We would need to add a new callback to compliment SetData.
> Perhaps ClearData? The constant will have to live on Grid (and
> Gallery). This feels like a smaller, better change.
>
> -Chris
>
> Tom Schindl wrote:
>> Well SetData-callback informs you that Row is scrolled into view but
>> what do we send when a Row is scrolled out of view? This is the
>> interesting event we should get to clean up resources, not?
>>
>> Tom
>>
>> Chris Gross schrieb:
>>> I did add virtual support to Grid recently. I modeled the virtual
>>> support in Grid exactly after Table/Tree. And I think these
>>> requirements that we're talking about (maintaining fewer resources)
>>> really maps right in with the way virtual support is designed. The
>>> SetData callback is just saying someone needs the values of this item
>>> - please go fill them in.
>>>
>>> I'm certain we could expose a method to return the visible rows
>>> (along with a listener when this value changes) but I'd rather not
>>> have to if there is an existing mechanism that seems designed to
>>> solve the same problem.
>>>
>>> -Chris
>>>
>>> Tom Schindl wrote:
>>>> Sorry for coming back after such a long time.
>>>>
>>>> Well if we I don't think we need to depend on any Viewer-Code I need
>>>> to investigate but for Tables/Trees with many columns this might
>>>> still be an issue.
>>>>
>>>> The other thing that makes neverous is that the SetData-Callback in
>>>> SWT-Controls get's a different meaning in Grid which might provoke
>>>> problems with the AbstractTable/TreeViewer in future what do you do
>>>> if you add VIRTUAL-Support to Grid?
>>>>
>>>> With all the work done in 190252 is there maybe already internal-API
>>>> to query the currently visible GridCells?
>>>>
>>>> Tom
>>>>
>>>> Chris Gross schrieb:
>>>>> True the SetData callback isn't cell specific but is that
>>>>> absolutely needed? The row based callback should still allow you
>>>>> to manage resources enough so that only a reasonable number around
>>>>> at one time.
>>>>> If we made this cell specific would we require the use of a
>>>>> viewer? I don't quite understand how it would work. We would
>>>>> still need the widget layer to provide the basic callbacks
>>>>> including information on what columns are visible/invisible. Seems
>>>>> a little more complicated. If we stay with SetData, then it would
>>>>> work well with existing JFace virtual support.
>>>>>
>>>>> Regards,
>>>>> -Chris
>>>>>
>>>>>
>>>>>
>>>>> Tom Schindl wrote:
>>>>>> Hi,
>>>>>>
>>>>>> One more note Chris.
>>>>>>
>>>>>> The SetData callback has the problem that it only informs you when
>>>>>> rows are scrolled into view but it's not working for
>>>>>> cells/columns. I think nebula controls should not suffer from the
>>>>>> same problem SWT-Controls do because they don't support the
>>>>>> concept of cells (which is already solved in your Grid => JFace
>>>>>> for key-navigation is very simple in contrast to
>>>>>> SWT-Implementation :-).
>>>>>>
>>>>>> I take the point of view that the Listener should work on top of
>>>>>> the Cell-Concept instead of the only row-based SWT-Concept.
>>>>>> Wouldn't it make sense that all columnbased controls implement
>>>>>> the same interface?
>>>>>>
>>>>>> Tom
>>>>>>
>>>>>>
>>>>>> Tom Schindl schrieb:
>>>>>>> I like this, no I love this :-), staying as near to SWT as
>>>>>>> possible is a great thing. The only thing I ask myself is where
>>>>>>> you get the constant from if you don't have a single common
>>>>>>> package all these things live in.
>>>>>>>
>>>>>>> I understand your point of view that there should not be too many
>>>>>>> dependencies and controls may evolve differently but defining a
>>>>>>> common set of things in not a bad thing and to get really usable
>>>>>>> it doesn't matter because once a control declared something API
>>>>>>> it has to stay for ever
>>>>>>> (http://inside-swt.blogspot.com/2007/02/its-end-of-era.html).
>>>>>>>
>>>>>>> Tom
>>>>>>>
>>>>>>> Chris Gross schrieb:
>>>>>>>> I think we might as well discuss it here for now.
>>>>>>>>
>>>>>>>> As I started to think about this some more I realize that this
>>>>>>>> is very similar to virtual support already implemented in
>>>>>>>> Table/Tree. Table will use the SWT.SetData callback when an
>>>>>>>> item is scrolled into view. The big difference is that it
>>>>>>>> doesn't offer a way to clear items as they scroll out of view.
>>>>>>>> You can use Table#clear to reset an item and the SWT.SetData
>>>>>>>> will be called as necessary again, but theres no way (AFAIK)
>>>>>>>> that you can automatically clear an item after it goes out of
>>>>>>>> view. Perhaps we should just add that single feature and work
>>>>>>>> with the existing SWT.VIRTUAL pattern.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> -Chris
>>>>>>>>
>>>>>>>> Nicolas Richeton wrote:
>>>>>>>>> I believe that using the same method signature but no common
>>>>>>>>> code is OK for now.
>>>>>>>>> But some core package may be usefull in the future too. For
>>>>>>>>> example, I used AbstractRenderer and TreeNodeToggleRenderer in
>>>>>>>>> the Gallery widget so this code is duplicated in PGroup, Grid
>>>>>>>>> and Gallery...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This API will be used to limit the number of handles required
>>>>>>>>> when using different images, styles and color for each item
>>>>>>>>> in Grid, Gallery, Tree and Tables.
>>>>>>>>>
>>>>>>>>> I think we need :
>>>>>>>>> * A listener for items that are scrolled out of the visible
>>>>>>>>> area. Interesting informations are the item and maybe some data
>>>>>>>>> on the way it was hidden (parent was collapsed or scrollbar
>>>>>>>>> were moved)
>>>>>>>>>
>>>>>>>>> * A method which returns all the visible items.
>>>>>>>>> Table already has getTopIndex() that can be used together with
>>>>>>>>> widget and item sizes to calculate the visible items. But this
>>>>>>>>> approach cannot be used with other widgets where any item can
>>>>>>>>> be expanded/collapsed.
>>>>>>>>>
>>>>>>>>> * We don't need a listener for items which are becoming visible
>>>>>>>>> because the paint event can be used for this.
>>>>>>>>>
>>>>>>>>> May be we should use bugzilla to discuss of this ?
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Nicolas
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Chris Gross a écrit :
>>>>>>>>>> Hmm... there could be potential problems if the resources are
>>>>>>>>>> not available even though the rows are out of view. Off the
>>>>>>>>>> top of my head I know that GridColumn#pack will need to know
>>>>>>>>>> the size of the contents of each cell. So that would suffer
>>>>>>>>>> (but probably not a big deal). There might be other problems.
>>>>>>>>>> I have to think a little.
>>>>>>>>>>
>>>>>>>>>> I think its a good idea to try to ensure that Nebula widgets
>>>>>>>>>> try to share common API but I'm not sure its a good idea to
>>>>>>>>>> formalize that in an interface. Where would that interface
>>>>>>>>>> live? In some core package and then in some core plugin/jar?
>>>>>>>>>> That would make things a little more messy/complicated. What
>>>>>>>>>> happens when the different widgets start having diverging
>>>>>>>>>> requirements? With each Nebula widget potentially going in
>>>>>>>>>> different directions I think any common interfaces could
>>>>>>>>>> become constrictive. If we have a real concrete use-case for
>>>>>>>>>> requiring the interface then I could probably be convinced.
>>>>>>>>>>
>>>>>>>>>> What do we need in the API?
>>>>>>>>>>
>>>>>>>>>> -Chris
>>>>>>>>>>
>>>>>>>>>> Tom Schindl wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> This would make sense the only problem I currently see is
>>>>>>>>>>> that Nebula isn't structured this way but I could be wrong
>>>>>>>>>>> though.
>>>>>>>>>>>
>>>>>>>>>>> But I definately agree that there should be a central
>>>>>>>>>>> position in nebula providing interfaces, ... like this.
>>>>>>>>>>>
>>>>>>>>>>> I'd propose something like "nebula.core" to hold things like
>>>>>>>>>>> this? For your gallery widget I think this a very important
>>>>>>>>>>> thing because your widget is by its purpose allocating a lot
>>>>>>>>>>> of system resources.
>>>>>>>>>>>
>>>>>>>>>>> Tom
>>>>>>>>>>>
>>>>>>>>>>> Nicolas Richeton schrieb:
>>>>>>>>>>>> About the listener for visible/invisible items :
>>>>>>>>>>>>
>>>>>>>>>>>> I want to add this feature to the gallery widget. Maybe we
>>>>>>>>>>>> could use the same API for all Nebula widgets ?
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Nicolas
>>>>>>>>>>>>
>>>>>>>>>>>> Tom Schindl a écrit :
>>>>>>>>>>>>> Implementation ready and uploaded but it was really an easy
>>>>>>>>>>>>> one :-)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Some questions on the GridItem though:
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Why can't one set the Item back to default behaviour
>>>>>>>>>>>>> (showing
>>>>>>>>>>>>> row-numbers)
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Would it be possible to implement beside setting a text
>>>>>>>>>>>>> also an image,
>>>>>>>>>>>>> color, font, ...?
>>>>>>>>>>>>>
>>>>>>>>>>>>> This would be a cool feature I think e.g. highlighting
>>>>>>>>>>>>> rows with an
>>>>>>>>>>>>> error marker?
>>>>>>>>>>>>>
>>>>>>>>>>>>> - I suppose that the Grid knows which items are currently
>>>>>>>>>>>>> visible? Is
>>>>>>>>>>>>> there some listener available to track which items are
>>>>>>>>>>>>> scrolled out of
>>>>>>>>>>>>> view. This would be extremely helpful when working with
>>>>>>>>>>>>> OS-Resources(Images, Fonts, Colors) because when not
>>>>>>>>>>>>> needed anymore
>>>>>>>>>>>>> they could be disposed
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think the GridColumnLabelProvider could be enhanced to
>>>>>>>>>>>>> take care of such resources and this would make GridViewer
>>>>>>>>>>>>> and Grid even more interesting for people currently facing
>>>>>>>>>>>>> problems with SWT-Table/Tree because there's no easy way to
>>>>>>>>>>>>> determine this (see
>>>>>>>>>>>>> http://tom-eclipse-dev.blogspot.com/2007/01/what-items-are-v isible-in-tabletree.html).
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Tom
>>>>>>>>>>>>>
>>>>>>>>>>>>> Tom Schindl schrieb:
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You are right Chris that's what I meant I haven't thought
>>>>>>>>>>>>>> about this carefully enough. Hence the request for a bug
>>>>>>>>>>>>>> report.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Maybe we could provide a standard label provider ontop of
>>>>>>>>>>>>>> ColumnLabelProvider. I'm against adding something
>>>>>>>>>>>>>> depending on the old API using the hack below :-)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I logged
>>>>>>>>>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=188430 and
>>>>>>>>>>>>>> will provide an example implementation.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Tom
>>>>>>>>>>>>>>
|
|
|
Re: [GridViewer]How to change text of rowHeader with a labelprovider ? [message #36283 is a reply to message #36248] |
Mon, 11 June 2007 17:37 |
Chris Gross Messages: 253 Registered: July 2009 |
Senior Member |
|
|
I'm thinking that the actual clear()-ing of the item data will not occur
automatically. They can listen to ClearData and call clear() if they
want. If they don't call clear then they wont get another SetData
event. So it should be relatively performance neutral.
It should be noted that SetData is sent the first time data is requested
for an item. This can be because the item was scrolled into view or
because some other class called Item#getText() or any other getter. The
makes the virtual nature much more robust than just a
scroll-in/scroll-out feature.
Regards,
-Chris
Nicolas Richeton wrote:
> AFAIK SetData is only fired the first time an item is scrolled into
> view. This can be used to allocate resources only if we clear each item
> on ClearData. The only drawback is that there will be a lot more
> SetData events than usual and probably a performance impact (for
> example, if items are created from a database).
>
> Paint is fired each time an item is painted. This is a better place to
> allocate resources, if it was not already done. It allows to keep
> internal item data between paints.
>
> Maybe we need some intermediate events, something like ScrollIn (item
> becomes visible) / ScrollOut (item is no longer visible).
>
> --
> Nicolas.
>
>
> Chris Gross a écrit :
>> Right. We would need to add a new callback to compliment SetData.
>> Perhaps ClearData? The constant will have to live on Grid (and
>> Gallery). This feels like a smaller, better change.
>>
>> -Chris
>>
>> Tom Schindl wrote:
>>> Well SetData-callback informs you that Row is scrolled into view but
>>> what do we send when a Row is scrolled out of view? This is the
>>> interesting event we should get to clean up resources, not?
>>>
>>> Tom
>>>
>>> Chris Gross schrieb:
>>>> I did add virtual support to Grid recently. I modeled the virtual
>>>> support in Grid exactly after Table/Tree. And I think these
>>>> requirements that we're talking about (maintaining fewer resources)
>>>> really maps right in with the way virtual support is designed. The
>>>> SetData callback is just saying someone needs the values of this
>>>> item - please go fill them in.
>>>>
>>>> I'm certain we could expose a method to return the visible rows
>>>> (along with a listener when this value changes) but I'd rather not
>>>> have to if there is an existing mechanism that seems designed to
>>>> solve the same problem.
>>>>
>>>> -Chris
>>>>
>>>> Tom Schindl wrote:
>>>>> Sorry for coming back after such a long time.
>>>>>
>>>>> Well if we I don't think we need to depend on any Viewer-Code I
>>>>> need to investigate but for Tables/Trees with many columns this
>>>>> might still be an issue.
>>>>>
>>>>> The other thing that makes neverous is that the SetData-Callback in
>>>>> SWT-Controls get's a different meaning in Grid which might provoke
>>>>> problems with the AbstractTable/TreeViewer in future what do you do
>>>>> if you add VIRTUAL-Support to Grid?
>>>>>
>>>>> With all the work done in 190252 is there maybe already
>>>>> internal-API to query the currently visible GridCells?
>>>>>
>>>>> Tom
>>>>>
>>>>> Chris Gross schrieb:
>>>>>> True the SetData callback isn't cell specific but is that
>>>>>> absolutely needed? The row based callback should still allow you
>>>>>> to manage resources enough so that only a reasonable number around
>>>>>> at one time.
>>>>>> If we made this cell specific would we require the use of a
>>>>>> viewer? I don't quite understand how it would work. We would
>>>>>> still need the widget layer to provide the basic callbacks
>>>>>> including information on what columns are visible/invisible.
>>>>>> Seems a little more complicated. If we stay with SetData, then it
>>>>>> would work well with existing JFace virtual support.
>>>>>>
>>>>>> Regards,
>>>>>> -Chris
>>>>>>
>>>>>>
>>>>>>
>>>>>> Tom Schindl wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> One more note Chris.
>>>>>>>
>>>>>>> The SetData callback has the problem that it only informs you
>>>>>>> when rows are scrolled into view but it's not working for
>>>>>>> cells/columns. I think nebula controls should not suffer from the
>>>>>>> same problem SWT-Controls do because they don't support the
>>>>>>> concept of cells (which is already solved in your Grid => JFace
>>>>>>> for key-navigation is very simple in contrast to
>>>>>>> SWT-Implementation :-).
>>>>>>>
>>>>>>> I take the point of view that the Listener should work on top of
>>>>>>> the Cell-Concept instead of the only row-based SWT-Concept.
>>>>>>> Wouldn't it make sense that all columnbased controls implement
>>>>>>> the same interface?
>>>>>>>
>>>>>>> Tom
>>>>>>>
>>>>>>>
>>>>>>> Tom Schindl schrieb:
>>>>>>>> I like this, no I love this :-), staying as near to SWT as
>>>>>>>> possible is a great thing. The only thing I ask myself is where
>>>>>>>> you get the constant from if you don't have a single common
>>>>>>>> package all these things live in.
>>>>>>>>
>>>>>>>> I understand your point of view that there should not be too
>>>>>>>> many dependencies and controls may evolve differently but
>>>>>>>> defining a common set of things in not a bad thing and to get
>>>>>>>> really usable it doesn't matter because once a control declared
>>>>>>>> something API it has to stay for ever
>>>>>>>> (http://inside-swt.blogspot.com/2007/02/its-end-of-era.html).
>>>>>>>>
>>>>>>>> Tom
>>>>>>>>
>>>>>>>> Chris Gross schrieb:
>>>>>>>>> I think we might as well discuss it here for now.
>>>>>>>>>
>>>>>>>>> As I started to think about this some more I realize that this
>>>>>>>>> is very similar to virtual support already implemented in
>>>>>>>>> Table/Tree. Table will use the SWT.SetData callback when an
>>>>>>>>> item is scrolled into view. The big difference is that it
>>>>>>>>> doesn't offer a way to clear items as they scroll out of view.
>>>>>>>>> You can use Table#clear to reset an item and the SWT.SetData
>>>>>>>>> will be called as necessary again, but theres no way (AFAIK)
>>>>>>>>> that you can automatically clear an item after it goes out of
>>>>>>>>> view. Perhaps we should just add that single feature and work
>>>>>>>>> with the existing SWT.VIRTUAL pattern.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> -Chris
>>>>>>>>>
>>>>>>>>> Nicolas Richeton wrote:
>>>>>>>>>> I believe that using the same method signature but no common
>>>>>>>>>> code is OK for now.
>>>>>>>>>> But some core package may be usefull in the future too. For
>>>>>>>>>> example, I used AbstractRenderer and TreeNodeToggleRenderer in
>>>>>>>>>> the Gallery widget so this code is duplicated in PGroup, Grid
>>>>>>>>>> and Gallery...
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This API will be used to limit the number of handles required
>>>>>>>>>> when using different images, styles and color for each item
>>>>>>>>>> in Grid, Gallery, Tree and Tables.
>>>>>>>>>>
>>>>>>>>>> I think we need :
>>>>>>>>>> * A listener for items that are scrolled out of the visible
>>>>>>>>>> area. Interesting informations are the item and maybe some
>>>>>>>>>> data on the way it was hidden (parent was collapsed or
>>>>>>>>>> scrollbar were moved)
>>>>>>>>>>
>>>>>>>>>> * A method which returns all the visible items.
>>>>>>>>>> Table already has getTopIndex() that can be used together with
>>>>>>>>>> widget and item sizes to calculate the visible items. But this
>>>>>>>>>> approach cannot be used with other widgets where any item can
>>>>>>>>>> be expanded/collapsed.
>>>>>>>>>>
>>>>>>>>>> * We don't need a listener for items which are becoming
>>>>>>>>>> visible because the paint event can be used for this.
>>>>>>>>>>
>>>>>>>>>> May be we should use bugzilla to discuss of this ?
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Nicolas
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Chris Gross a écrit :
>>>>>>>>>>> Hmm... there could be potential problems if the resources are
>>>>>>>>>>> not available even though the rows are out of view. Off the
>>>>>>>>>>> top of my head I know that GridColumn#pack will need to know
>>>>>>>>>>> the size of the contents of each cell. So that would suffer
>>>>>>>>>>> (but probably not a big deal). There might be other
>>>>>>>>>>> problems. I have to think a little.
>>>>>>>>>>>
>>>>>>>>>>> I think its a good idea to try to ensure that Nebula widgets
>>>>>>>>>>> try to share common API but I'm not sure its a good idea to
>>>>>>>>>>> formalize that in an interface. Where would that interface
>>>>>>>>>>> live? In some core package and then in some core
>>>>>>>>>>> plugin/jar? That would make things a little more
>>>>>>>>>>> messy/complicated. What happens when the different widgets
>>>>>>>>>>> start having diverging requirements? With each Nebula widget
>>>>>>>>>>> potentially going in different directions I think any common
>>>>>>>>>>> interfaces could become constrictive. If we have a real
>>>>>>>>>>> concrete use-case for requiring the interface then I could
>>>>>>>>>>> probably be convinced.
>>>>>>>>>>>
>>>>>>>>>>> What do we need in the API?
>>>>>>>>>>>
>>>>>>>>>>> -Chris
>>>>>>>>>>>
>>>>>>>>>>> Tom Schindl wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> This would make sense the only problem I currently see is
>>>>>>>>>>>> that Nebula isn't structured this way but I could be wrong
>>>>>>>>>>>> though.
>>>>>>>>>>>>
>>>>>>>>>>>> But I definately agree that there should be a central
>>>>>>>>>>>> position in nebula providing interfaces, ... like this.
>>>>>>>>>>>>
>>>>>>>>>>>> I'd propose something like "nebula.core" to hold things like
>>>>>>>>>>>> this? For your gallery widget I think this a very important
>>>>>>>>>>>> thing because your widget is by its purpose allocating a lot
>>>>>>>>>>>> of system resources.
>>>>>>>>>>>>
>>>>>>>>>>>> Tom
>>>>>>>>>>>>
>>>>>>>>>>>> Nicolas Richeton schrieb:
>>>>>>>>>>>>> About the listener for visible/invisible items :
>>>>>>>>>>>>>
>>>>>>>>>>>>> I want to add this feature to the gallery widget. Maybe we
>>>>>>>>>>>>> could use the same API for all Nebula widgets ?
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Nicolas
>>>>>>>>>>>>>
>>>>>>>>>>>>> Tom Schindl a écrit :
>>>>>>>>>>>>>> Implementation ready and uploaded but it was really an
>>>>>>>>>>>>>> easy one :-)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Some questions on the GridItem though:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - Why can't one set the Item back to default behaviour
>>>>>>>>>>>>>> (showing
>>>>>>>>>>>>>> row-numbers)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - Would it be possible to implement beside setting a text
>>>>>>>>>>>>>> also an image,
>>>>>>>>>>>>>> color, font, ...?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This would be a cool feature I think e.g. highlighting
>>>>>>>>>>>>>> rows with an
>>>>>>>>>>>>>> error marker?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - I suppose that the Grid knows which items are currently
>>>>>>>>>>>>>> visible? Is
>>>>>>>>>>>>>> there some listener available to track which items are
>>>>>>>>>>>>>> scrolled out of
>>>>>>>>>>>>>> view. This would be extremely helpful when working with
>>>>>>>>>>>>>> OS-Resources(Images, Fonts, Colors) because when not
>>>>>>>>>>>>>> needed anymore
>>>>>>>>>>>>>> they could be disposed
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think the GridColumnLabelProvider could be enhanced to
>>>>>>>>>>>>>> take care of such resources and this would make GridViewer
>>>>>>>>>>>>>> and Grid even more interesting for people currently facing
>>>>>>>>>>>>>> problems with SWT-Table/Tree because there's no easy way
>>>>>>>>>>>>>> to determine this (see
>>>>>>>>>>>>>> http://tom-eclipse-dev.blogspot.com/2007/01/what-items-are-v isible-in-tabletree.html).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Tom
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Tom Schindl schrieb:
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You are right Chris that's what I meant I haven't thought
>>>>>>>>>>>>>>> about this carefully enough. Hence the request for a bug
>>>>>>>>>>>>>>> report.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Maybe we could provide a standard label provider ontop of
>>>>>>>>>>>>>>> ColumnLabelProvider. I'm against adding something
>>>>>>>>>>>>>>> depending on the old API using the hack below :-)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I logged
>>>>>>>>>>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=188430 and
>>>>>>>>>>>>>>> will provide an example implementation.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Tom
>>>>>>>>>>>>>>>
|
|
| |
Re: [GridViewer]How to change text of rowHeader with a labelprovider ? [message #582454 is a reply to message #35102] |
Tue, 22 May 2007 13:04 |
Defert Philippe Messages: 62 Registered: July 2009 |
Member |
|
|
Tom,
i wrote my own GridViewer that extends
org.eclipse.nebula.jface.gridviewer.GridViewer
and i override doUpdateItem(...)
protected void doUpdateItem(Widget widget, Object element, boolean
fullMap) {
super.doUpdateItem(widget, element, fullMap);
// Check if it needs to process rowHeader
if (getGrid().isRowHeaderVisible() && getLabelProvider() instanceof
GridLabelProvider) {
if (widget instanceof GridItem) {
final GridItem item = (GridItem) widget;
int indexOfItem = Arrays.asList(getGrid().getItems()).indexOf(item);
String newRowHeaderText = ((GridLabelProvider)
getLabelProvider()).getRowHeaderText(element, indexOfItem);
item.setHeaderText(newRowHeaderText);
}
}
}
and i wrote a GridLabelProvider class
public class GridLabelProvider extends LabelProvider implements
ITableLabelProvider {
public Image getColumnImage(Object element, int columnIndex) {
return null;
}
public String getColumnText(Object element, int columnIndex) {
return element == null ? "" : element.toString();
}
public String getRowHeaderText(Object element, int rowIndex){
return ""+rowIndex;
}
}
now, if you want to print something of content's data in rowHeader, you
can extends GridLabelProvider and overide getRowHeaderText() .
Tom, What do you think about my workaround ?
I will appreciate your comments .
Philippe
Tom Schindl a écrit :
> Hi,
>
> GridViewer is currently not able to implement this as far as I can
> remember when I wrote it because JFace provides no hooks for this.
>
> The problem is not the first creation of the Item but what happens if an
> item is added, removed, ... . Nevertheless please log a bug and the next
> time I'll work on the nebula viewers I'll see how this could be
> implemented. If you want you can take a look yourself and create a patch
> I can review amd comment on it(please CC me on the bug if you filed one)
>
> Tom
>
> DEFERT Philippe schrieb:
>> Hi,
>>
>> is it possible to modify rowheader text with jface binding mechanism as
>> a Labelprovider ?
>> I know it is possible directly on griditem but i would not use griditem.
>>
>> do you plan to provide a "GridLabelProvider" ?
>>
>> Thanks
>>
>> Philippe
>
>
|
|
|
Re: [GridViewer]How to change text of rowHeader with a labelprovider ? [message #582467 is a reply to message #35132] |
Tue, 22 May 2007 15:45 |
Thomas Schindl Messages: 6651 Registered: July 2009 |
Senior Member |
|
|
Hi,
From the first impression this looks good but as already outlined this
is not the only thing you need to take care of e.g. if you want to
assign row-numbers using this LabelProvider if you insert/remove a row
from the grid you need to update all items below the one you inserted
deleted.
Please log a bug and we can discuss there. A problem I see is that this
might provide problems with the new Viewer-Infrastructure but I need to
think about this a bit.
Tom
DEFERT Philippe schrieb:
> Tom,
>
> i wrote my own GridViewer that extends
> org.eclipse.nebula.jface.gridviewer.GridViewer
> and i override doUpdateItem(...)
>
> protected void doUpdateItem(Widget widget, Object element, boolean
> fullMap) {
>
> super.doUpdateItem(widget, element, fullMap);
> // Check if it needs to process rowHeader
> if (getGrid().isRowHeaderVisible() && getLabelProvider()
> instanceof GridLabelProvider) {
> if (widget instanceof GridItem) {
> final GridItem item = (GridItem) widget;
> int indexOfItem =
> Arrays.asList(getGrid().getItems()).indexOf(item);
> String newRowHeaderText = ((GridLabelProvider)
> getLabelProvider()).getRowHeaderText(element, indexOfItem);
> item.setHeaderText(newRowHeaderText);
>
> }
>
> }
> }
>
>
> and i wrote a GridLabelProvider class
>
> public class GridLabelProvider extends LabelProvider implements
> ITableLabelProvider {
>
> public Image getColumnImage(Object element, int columnIndex) {
>
> return null;
> }
>
> public String getColumnText(Object element, int columnIndex) {
>
> return element == null ? "" : element.toString();
> }
> public String getRowHeaderText(Object element, int rowIndex){
> return ""+rowIndex;
> }
> }
>
>
> now, if you want to print something of content's data in rowHeader, you
> can extends GridLabelProvider and overide getRowHeaderText() .
>
> Tom, What do you think about my workaround ?
> I will appreciate your comments .
>
> Philippe
>
> Tom Schindl a écrit :
>> Hi,
>>
>> GridViewer is currently not able to implement this as far as I can
>> remember when I wrote it because JFace provides no hooks for this.
>>
>> The problem is not the first creation of the Item but what happens if an
>> item is added, removed, ... . Nevertheless please log a bug and the next
>> time I'll work on the nebula viewers I'll see how this could be
>> implemented. If you want you can take a look yourself and create a patch
>> I can review amd comment on it(please CC me on the bug if you filed one)
>>
>> Tom
>>
>> DEFERT Philippe schrieb:
>>> Hi,
>>>
>>> is it possible to modify rowheader text with jface binding mechanism as
>>> a Labelprovider ?
>>> I know it is possible directly on griditem but i would not use griditem.
>>>
>>> do you plan to provide a "GridLabelProvider" ?
>>>
>>> Thanks
>>>
>>> Philippe
>>
>>
--
B e s t S o l u t i o n . a t EDV Systemhaus GmbH
----------------------------------------------------
tom schindl Eclipse JFace Committer
|
|
|
Re: [GridViewer]How to change text of rowHeader with a labelprovider ? [message #582490 is a reply to message #35160] |
Tue, 22 May 2007 17:39 |
Chris Gross Messages: 471 Registered: July 2009 |
Senior Member |
|
|
The Grid will assign row numbers for you automatically if you don't set
anything in the row header text. So you shouldn't have to do anything
to get that behavior.
If you do want to set the row header text, couldn't you just use the new
CellLabelProvider API?
-Chris
Tom Schindl wrote:
> Hi,
>
> From the first impression this looks good but as already outlined this
> is not the only thing you need to take care of e.g. if you want to
> assign row-numbers using this LabelProvider if you insert/remove a row
> from the grid you need to update all items below the one you inserted
> deleted.
>
> Please log a bug and we can discuss there. A problem I see is that this
> might provide problems with the new Viewer-Infrastructure but I need to
> think about this a bit.
>
> Tom
>
> DEFERT Philippe schrieb:
>> Tom,
>>
>> i wrote my own GridViewer that extends
>> org.eclipse.nebula.jface.gridviewer.GridViewer
>> and i override doUpdateItem(...)
>>
>> protected void doUpdateItem(Widget widget, Object element, boolean
>> fullMap) {
>>
>> super.doUpdateItem(widget, element, fullMap);
>> // Check if it needs to process rowHeader
>> if (getGrid().isRowHeaderVisible() && getLabelProvider()
>> instanceof GridLabelProvider) {
>> if (widget instanceof GridItem) {
>> final GridItem item = (GridItem) widget;
>> int indexOfItem =
>> Arrays.asList(getGrid().getItems()).indexOf(item);
>> String newRowHeaderText = ((GridLabelProvider)
>> getLabelProvider()).getRowHeaderText(element, indexOfItem);
>> item.setHeaderText(newRowHeaderText);
>>
>> }
>>
>> }
>> }
>>
>>
>> and i wrote a GridLabelProvider class
>>
>> public class GridLabelProvider extends LabelProvider implements
>> ITableLabelProvider {
>>
>> public Image getColumnImage(Object element, int columnIndex) {
>>
>> return null;
>> }
>>
>> public String getColumnText(Object element, int columnIndex) {
>>
>> return element == null ? "" : element.toString();
>> }
>> public String getRowHeaderText(Object element, int rowIndex){
>> return ""+rowIndex;
>> }
>> }
>>
>>
>> now, if you want to print something of content's data in rowHeader, you
>> can extends GridLabelProvider and overide getRowHeaderText() .
>>
>> Tom, What do you think about my workaround ?
>> I will appreciate your comments .
>>
>> Philippe
>>
>> Tom Schindl a écrit :
>>> Hi,
>>>
>>> GridViewer is currently not able to implement this as far as I can
>>> remember when I wrote it because JFace provides no hooks for this.
>>>
>>> The problem is not the first creation of the Item but what happens if an
>>> item is added, removed, ... . Nevertheless please log a bug and the next
>>> time I'll work on the nebula viewers I'll see how this could be
>>> implemented. If you want you can take a look yourself and create a patch
>>> I can review amd comment on it(please CC me on the bug if you filed one)
>>>
>>> Tom
>>>
>>> DEFERT Philippe schrieb:
>>>> Hi,
>>>>
>>>> is it possible to modify rowheader text with jface binding mechanism as
>>>> a Labelprovider ?
>>>> I know it is possible directly on griditem but i would not use griditem.
>>>>
>>>> do you plan to provide a "GridLabelProvider" ?
>>>>
>>>> Thanks
>>>>
>>>> Philippe
>>>
>
>
|
|
|
Re: [GridViewer]How to change text of rowHeader with a labelprovider ? [message #582505 is a reply to message #35232] |
Tue, 22 May 2007 18:50 |
Thomas Schindl Messages: 6651 Registered: July 2009 |
Senior Member |
|
|
Hi,
You are right Chris that's what I meant I haven't thought about this
carefully enough. Hence the request for a bug report.
Maybe we could provide a standard label provider ontop of
ColumnLabelProvider. I'm against adding something depending on the old
API using the hack below :-)
I logged https://bugs.eclipse.org/bugs/show_bug.cgi?id=188430 and will
provide an example implementation.
Tom
Chris Gross schrieb:
> The Grid will assign row numbers for you automatically if you don't set
> anything in the row header text. So you shouldn't have to do anything
> to get that behavior.
>
> If you do want to set the row header text, couldn't you just use the new
> CellLabelProvider API?
>
> -Chris
>
> Tom Schindl wrote:
>> Hi,
>>
>> From the first impression this looks good but as already outlined this
>> is not the only thing you need to take care of e.g. if you want to
>> assign row-numbers using this LabelProvider if you insert/remove a row
>> from the grid you need to update all items below the one you inserted
>> deleted.
>>
>> Please log a bug and we can discuss there. A problem I see is that this
>> might provide problems with the new Viewer-Infrastructure but I need to
>> think about this a bit.
>>
>> Tom
>>
>> DEFERT Philippe schrieb:
>>> Tom,
>>>
>>> i wrote my own GridViewer that extends
>>> org.eclipse.nebula.jface.gridviewer.GridViewer
>>> and i override doUpdateItem(...)
>>>
>>> protected void doUpdateItem(Widget widget, Object element, boolean
>>> fullMap) {
>>> super.doUpdateItem(widget, element, fullMap);
>>> // Check if it needs to process rowHeader
>>> if (getGrid().isRowHeaderVisible() && getLabelProvider()
>>> instanceof GridLabelProvider) {
>>> if (widget instanceof GridItem) {
>>> final GridItem item = (GridItem) widget;
>>> int indexOfItem =
>>> Arrays.asList(getGrid().getItems()).indexOf(item);
>>> String newRowHeaderText = ((GridLabelProvider)
>>> getLabelProvider()).getRowHeaderText(element, indexOfItem);
>>> item.setHeaderText(newRowHeaderText);
>>>
>>> }
>>> }
>>> }
>>>
>>>
>>> and i wrote a GridLabelProvider class
>>>
>>> public class GridLabelProvider extends LabelProvider implements
>>> ITableLabelProvider {
>>>
>>> public Image getColumnImage(Object element, int columnIndex) {
>>> return null;
>>> }
>>>
>>> public String getColumnText(Object element, int columnIndex) {
>>> return element == null ? "" : element.toString();
>>> }
>>> public String getRowHeaderText(Object element, int rowIndex){
>>> return ""+rowIndex;
>>> }
>>> }
>>>
>>>
>>> now, if you want to print something of content's data in rowHeader, you
>>> can extends GridLabelProvider and overide getRowHeaderText() .
>>>
>>> Tom, What do you think about my workaround ?
>>> I will appreciate your comments .
>>>
>>> Philippe
>>>
>>> Tom Schindl a écrit :
>>>> Hi,
>>>>
>>>> GridViewer is currently not able to implement this as far as I can
>>>> remember when I wrote it because JFace provides no hooks for this.
>>>>
>>>> The problem is not the first creation of the Item but what happens
>>>> if an
>>>> item is added, removed, ... . Nevertheless please log a bug and the
>>>> next
>>>> time I'll work on the nebula viewers I'll see how this could be
>>>> implemented. If you want you can take a look yourself and create a
>>>> patch
>>>> I can review amd comment on it(please CC me on the bug if you filed
>>>> one)
>>>>
>>>> Tom
>>>>
>>>> DEFERT Philippe schrieb:
>>>>> Hi,
>>>>>
>>>>> is it possible to modify rowheader text with jface binding
>>>>> mechanism as
>>>>> a Labelprovider ?
>>>>> I know it is possible directly on griditem but i would not use
>>>>> griditem.
>>>>>
>>>>> do you plan to provide a "GridLabelProvider" ?
>>>>>
>>>>> Thanks
>>>>>
>>>>> Philippe
>>>>
>>
>>
|
|
| | | | | |
Re: [GridViewer]How to change text of rowHeader with a labelprovider ? [message #582589 is a reply to message #35389] |
Thu, 24 May 2007 16:56 |
Nicolas Richeton Messages: 179 Registered: July 2009 |
Senior Member |
|
|
I believe that using the same method signature but no common code is OK
for now.
But some core package may be usefull in the future too. For example, I
used AbstractRenderer and TreeNodeToggleRenderer in the Gallery widget
so this code is duplicated in PGroup, Grid and Gallery...
This API will be used to limit the number of handles required when using
different images, styles and color for each item in Grid, Gallery,
Tree and Tables.
I think we need :
* A listener for items that are scrolled out of the visible area.
Interesting informations are the item and maybe some data on the way it
was hidden (parent was collapsed or scrollbar were moved)
* A method which returns all the visible items.
Table already has getTopIndex() that can be used together with widget
and item sizes to calculate the visible items. But this approach cannot
be used with other widgets where any item can be expanded/collapsed.
* We don't need a listener for items which are becoming visible because
the paint event can be used for this.
May be we should use bugzilla to discuss of this ?
--
Nicolas
Chris Gross a écrit :
> Hmm... there could be potential problems if the resources are not
> available even though the rows are out of view. Off the top of my head
> I know that GridColumn#pack will need to know the size of the contents
> of each cell. So that would suffer (but probably not a big deal). There
> might be other problems. I have to think a little.
>
> I think its a good idea to try to ensure that Nebula widgets try to
> share common API but I'm not sure its a good idea to formalize that in
> an interface. Where would that interface live? In some core package
> and then in some core plugin/jar? That would make things a little more
> messy/complicated. What happens when the different widgets start having
> diverging requirements? With each Nebula widget potentially going in
> different directions I think any common interfaces could become
> constrictive. If we have a real concrete use-case for requiring the
> interface then I could probably be convinced.
>
> What do we need in the API?
>
> -Chris
>
> Tom Schindl wrote:
>> Hi,
>>
>> This would make sense the only problem I currently see is that Nebula
>> isn't structured this way but I could be wrong though.
>>
>> But I definately agree that there should be a central position in
>> nebula providing interfaces, ... like this.
>>
>> I'd propose something like "nebula.core" to hold things like this? For
>> your gallery widget I think this a very important thing because your
>> widget is by its purpose allocating a lot of system resources.
>>
>> Tom
>>
>> Nicolas Richeton schrieb:
>>> About the listener for visible/invisible items :
>>>
>>> I want to add this feature to the gallery widget. Maybe we could use
>>> the same API for all Nebula widgets ?
>>>
>>> --
>>> Nicolas
>>>
>>> Tom Schindl a écrit :
>>>> Implementation ready and uploaded but it was really an easy one :-)
>>>>
>>>> Some questions on the GridItem though:
>>>>
>>>> - Why can't one set the Item back to default behaviour (showing
>>>> row-numbers)
>>>>
>>>> - Would it be possible to implement beside setting a text also an
>>>> image,
>>>> color, font, ...?
>>>>
>>>> This would be a cool feature I think e.g. highlighting rows with an
>>>> error marker?
>>>>
>>>> - I suppose that the Grid knows which items are currently visible? Is
>>>> there some listener available to track which items are scrolled
>>>> out of
>>>> view. This would be extremely helpful when working with
>>>> OS-Resources(Images, Fonts, Colors) because when not needed anymore
>>>> they could be disposed
>>>>
>>>> I think the GridColumnLabelProvider could be enhanced to take care
>>>> of such resources and this would make GridViewer and Grid even more
>>>> interesting for people currently facing problems with SWT-Table/Tree
>>>> because there's no easy way to determine this (see
>>>> http://tom-eclipse-dev.blogspot.com/2007/01/what-items-are-v isible-in-tabletree.html).
>>>>
>>>>
>>>> Tom
>>>>
>>>> Tom Schindl schrieb:
>>>>> Hi,
>>>>>
>>>>> You are right Chris that's what I meant I haven't thought about
>>>>> this carefully enough. Hence the request for a bug report.
>>>>>
>>>>> Maybe we could provide a standard label provider ontop of
>>>>> ColumnLabelProvider. I'm against adding something depending on the
>>>>> old API using the hack below :-)
>>>>>
>>>>> I logged https://bugs.eclipse.org/bugs/show_bug.cgi?id=188430 and
>>>>> will provide an example implementation.
>>>>>
>>>>> Tom
>>>>>
|
|
|
Re: [GridViewer]How to change text of rowHeader with a labelprovider ? [message #582607 is a reply to message #35424] |
Thu, 24 May 2007 19:57 |
Chris Gross Messages: 471 Registered: July 2009 |
Senior Member |
|
|
I think we might as well discuss it here for now.
As I started to think about this some more I realize that this is very
similar to virtual support already implemented in Table/Tree. Table
will use the SWT.SetData callback when an item is scrolled into view.
The big difference is that it doesn't offer a way to clear items as they
scroll out of view. You can use Table#clear to reset an item and the
SWT.SetData will be called as necessary again, but theres no way (AFAIK)
that you can automatically clear an item after it goes out of view.
Perhaps we should just add that single feature and work with the
existing SWT.VIRTUAL pattern.
Regards,
-Chris
Nicolas Richeton wrote:
> I believe that using the same method signature but no common code is OK
> for now.
> But some core package may be usefull in the future too. For example, I
> used AbstractRenderer and TreeNodeToggleRenderer in the Gallery widget
> so this code is duplicated in PGroup, Grid and Gallery...
>
>
> This API will be used to limit the number of handles required when using
> different images, styles and color for each item in Grid, Gallery,
> Tree and Tables.
>
> I think we need :
> * A listener for items that are scrolled out of the visible area.
> Interesting informations are the item and maybe some data on the way it
> was hidden (parent was collapsed or scrollbar were moved)
>
> * A method which returns all the visible items.
> Table already has getTopIndex() that can be used together with widget
> and item sizes to calculate the visible items. But this approach cannot
> be used with other widgets where any item can be expanded/collapsed.
>
> * We don't need a listener for items which are becoming visible because
> the paint event can be used for this.
>
> May be we should use bugzilla to discuss of this ?
>
> --
> Nicolas
>
>
>
> Chris Gross a écrit :
>> Hmm... there could be potential problems if the resources are not
>> available even though the rows are out of view. Off the top of my
>> head I know that GridColumn#pack will need to know the size of the
>> contents of each cell. So that would suffer (but probably not a big
>> deal). There might be other problems. I have to think a little.
>>
>> I think its a good idea to try to ensure that Nebula widgets try to
>> share common API but I'm not sure its a good idea to formalize that in
>> an interface. Where would that interface live? In some core package
>> and then in some core plugin/jar? That would make things a little
>> more messy/complicated. What happens when the different widgets start
>> having diverging requirements? With each Nebula widget potentially
>> going in different directions I think any common interfaces could
>> become constrictive. If we have a real concrete use-case for
>> requiring the interface then I could probably be convinced.
>>
>> What do we need in the API?
>>
>> -Chris
>>
>> Tom Schindl wrote:
>>> Hi,
>>>
>>> This would make sense the only problem I currently see is that Nebula
>>> isn't structured this way but I could be wrong though.
>>>
>>> But I definately agree that there should be a central position in
>>> nebula providing interfaces, ... like this.
>>>
>>> I'd propose something like "nebula.core" to hold things like this?
>>> For your gallery widget I think this a very important thing because
>>> your widget is by its purpose allocating a lot of system resources.
>>>
>>> Tom
>>>
>>> Nicolas Richeton schrieb:
>>>> About the listener for visible/invisible items :
>>>>
>>>> I want to add this feature to the gallery widget. Maybe we could use
>>>> the same API for all Nebula widgets ?
>>>>
>>>> --
>>>> Nicolas
>>>>
>>>> Tom Schindl a écrit :
>>>>> Implementation ready and uploaded but it was really an easy one :-)
>>>>>
>>>>> Some questions on the GridItem though:
>>>>>
>>>>> - Why can't one set the Item back to default behaviour (showing
>>>>> row-numbers)
>>>>>
>>>>> - Would it be possible to implement beside setting a text also an
>>>>> image,
>>>>> color, font, ...?
>>>>>
>>>>> This would be a cool feature I think e.g. highlighting rows with an
>>>>> error marker?
>>>>>
>>>>> - I suppose that the Grid knows which items are currently visible? Is
>>>>> there some listener available to track which items are scrolled
>>>>> out of
>>>>> view. This would be extremely helpful when working with
>>>>> OS-Resources(Images, Fonts, Colors) because when not needed anymore
>>>>> they could be disposed
>>>>>
>>>>> I think the GridColumnLabelProvider could be enhanced to take care
>>>>> of such resources and this would make GridViewer and Grid even more
>>>>> interesting for people currently facing problems with
>>>>> SWT-Table/Tree because there's no easy way to determine this (see
>>>>> http://tom-eclipse-dev.blogspot.com/2007/01/what-items-are-v isible-in-tabletree.html).
>>>>>
>>>>>
>>>>> Tom
>>>>>
>>>>> Tom Schindl schrieb:
>>>>>> Hi,
>>>>>>
>>>>>> You are right Chris that's what I meant I haven't thought about
>>>>>> this carefully enough. Hence the request for a bug report.
>>>>>>
>>>>>> Maybe we could provide a standard label provider ontop of
>>>>>> ColumnLabelProvider. I'm against adding something depending on the
>>>>>> old API using the hack below :-)
>>>>>>
>>>>>> I logged https://bugs.eclipse.org/bugs/show_bug.cgi?id=188430 and
>>>>>> will provide an example implementation.
>>>>>>
>>>>>> Tom
>>>>>>
|
|
|
Re: [GridViewer]How to change text of rowHeader with a labelprovider ? [message #582623 is a reply to message #35458] |
Thu, 24 May 2007 22:11 |
Thomas Schindl Messages: 6651 Registered: July 2009 |
Senior Member |
|
|
I like this, no I love this :-), staying as near to SWT as possible is a
great thing. The only thing I ask myself is where you get the constant
from if you don't have a single common package all these things live in.
I understand your point of view that there should not be too many
dependencies and controls may evolve differently but defining a common
set of things in not a bad thing and to get really usable it doesn't
matter because once a control declared something API it has to stay for
ever (http://inside-swt.blogspot.com/2007/02/its-end-of-era.html).
Tom
Chris Gross schrieb:
> I think we might as well discuss it here for now.
>
> As I started to think about this some more I realize that this is very
> similar to virtual support already implemented in Table/Tree. Table
> will use the SWT.SetData callback when an item is scrolled into view.
> The big difference is that it doesn't offer a way to clear items as they
> scroll out of view. You can use Table#clear to reset an item and the
> SWT.SetData will be called as necessary again, but theres no way (AFAIK)
> that you can automatically clear an item after it goes out of view.
> Perhaps we should just add that single feature and work with the
> existing SWT.VIRTUAL pattern.
>
> Regards,
> -Chris
>
> Nicolas Richeton wrote:
>> I believe that using the same method signature but no common code is
>> OK for now.
>> But some core package may be usefull in the future too. For example, I
>> used AbstractRenderer and TreeNodeToggleRenderer in the Gallery widget
>> so this code is duplicated in PGroup, Grid and Gallery...
>>
>>
>> This API will be used to limit the number of handles required when
>> using different images, styles and color for each item in Grid,
>> Gallery, Tree and Tables.
>>
>> I think we need :
>> * A listener for items that are scrolled out of the visible area.
>> Interesting informations are the item and maybe some data on the way
>> it was hidden (parent was collapsed or scrollbar were moved)
>>
>> * A method which returns all the visible items.
>> Table already has getTopIndex() that can be used together with widget
>> and item sizes to calculate the visible items. But this approach
>> cannot be used with other widgets where any item can be
>> expanded/collapsed.
>>
>> * We don't need a listener for items which are becoming visible
>> because the paint event can be used for this.
>>
>> May be we should use bugzilla to discuss of this ?
>>
>> --
>> Nicolas
>>
>>
>>
>> Chris Gross a écrit :
>>> Hmm... there could be potential problems if the resources are not
>>> available even though the rows are out of view. Off the top of my
>>> head I know that GridColumn#pack will need to know the size of the
>>> contents of each cell. So that would suffer (but probably not a big
>>> deal). There might be other problems. I have to think a little.
>>>
>>> I think its a good idea to try to ensure that Nebula widgets try to
>>> share common API but I'm not sure its a good idea to formalize that
>>> in an interface. Where would that interface live? In some core
>>> package and then in some core plugin/jar? That would make things a
>>> little more messy/complicated. What happens when the different
>>> widgets start having diverging requirements? With each Nebula widget
>>> potentially going in different directions I think any common
>>> interfaces could become constrictive. If we have a real concrete
>>> use-case for requiring the interface then I could probably be convinced.
>>>
>>> What do we need in the API?
>>>
>>> -Chris
>>>
>>> Tom Schindl wrote:
>>>> Hi,
>>>>
>>>> This would make sense the only problem I currently see is that
>>>> Nebula isn't structured this way but I could be wrong though.
>>>>
>>>> But I definately agree that there should be a central position in
>>>> nebula providing interfaces, ... like this.
>>>>
>>>> I'd propose something like "nebula.core" to hold things like this?
>>>> For your gallery widget I think this a very important thing because
>>>> your widget is by its purpose allocating a lot of system resources.
>>>>
>>>> Tom
>>>>
>>>> Nicolas Richeton schrieb:
>>>>> About the listener for visible/invisible items :
>>>>>
>>>>> I want to add this feature to the gallery widget. Maybe we could
>>>>> use the same API for all Nebula widgets ?
>>>>>
>>>>> --
>>>>> Nicolas
>>>>>
>>>>> Tom Schindl a écrit :
>>>>>> Implementation ready and uploaded but it was really an easy one :-)
>>>>>>
>>>>>> Some questions on the GridItem though:
>>>>>>
>>>>>> - Why can't one set the Item back to default behaviour (showing
>>>>>> row-numbers)
>>>>>>
>>>>>> - Would it be possible to implement beside setting a text also an
>>>>>> image,
>>>>>> color, font, ...?
>>>>>>
>>>>>> This would be a cool feature I think e.g. highlighting rows with an
>>>>>> error marker?
>>>>>>
>>>>>> - I suppose that the Grid knows which items are currently visible? Is
>>>>>> there some listener available to track which items are scrolled
>>>>>> out of
>>>>>> view. This would be extremely helpful when working with
>>>>>> OS-Resources(Images, Fonts, Colors) because when not needed anymore
>>>>>> they could be disposed
>>>>>>
>>>>>> I think the GridColumnLabelProvider could be enhanced to take care
>>>>>> of such resources and this would make GridViewer and Grid even
>>>>>> more interesting for people currently facing problems with
>>>>>> SWT-Table/Tree because there's no easy way to determine this (see
>>>>>> http://tom-eclipse-dev.blogspot.com/2007/01/what-items-are-v isible-in-tabletree.html).
>>>>>>
>>>>>>
>>>>>> Tom
>>>>>>
>>>>>> Tom Schindl schrieb:
>>>>>>> Hi,
>>>>>>>
>>>>>>> You are right Chris that's what I meant I haven't thought about
>>>>>>> this carefully enough. Hence the request for a bug report.
>>>>>>>
>>>>>>> Maybe we could provide a standard label provider ontop of
>>>>>>> ColumnLabelProvider. I'm against adding something depending on
>>>>>>> the old API using the hack below :-)
>>>>>>>
>>>>>>> I logged https://bugs.eclipse.org/bugs/show_bug.cgi?id=188430 and
>>>>>>> will provide an example implementation.
>>>>>>>
>>>>>>> Tom
>>>>>>>
|
|
|
Re: [GridViewer]How to change text of rowHeader with a labelprovider ? [message #582633 is a reply to message #35497] |
Fri, 25 May 2007 09:12 |
Thomas Schindl Messages: 6651 Registered: July 2009 |
Senior Member |
|
|
Hi,
One more note Chris.
The SetData callback has the problem that it only informs you when rows
are scrolled into view but it's not working for cells/columns. I think
nebula controls should not suffer from the same problem SWT-Controls do
because they don't support the concept of cells (which is already solved
in your Grid => JFace for key-navigation is very simple in contrast to
SWT-Implementation :-).
I take the point of view that the Listener should work on top of the
Cell-Concept instead of the only row-based SWT-Concept. Wouldn't it make
sense that all columnbased controls implement the same interface?
Tom
Tom Schindl schrieb:
> I like this, no I love this :-), staying as near to SWT as possible is a
> great thing. The only thing I ask myself is where you get the constant
> from if you don't have a single common package all these things live in.
>
> I understand your point of view that there should not be too many
> dependencies and controls may evolve differently but defining a common
> set of things in not a bad thing and to get really usable it doesn't
> matter because once a control declared something API it has to stay for
> ever (http://inside-swt.blogspot.com/2007/02/its-end-of-era.html).
>
> Tom
>
> Chris Gross schrieb:
>> I think we might as well discuss it here for now.
>>
>> As I started to think about this some more I realize that this is very
>> similar to virtual support already implemented in Table/Tree. Table
>> will use the SWT.SetData callback when an item is scrolled into view.
>> The big difference is that it doesn't offer a way to clear items as
>> they scroll out of view. You can use Table#clear to reset an item and
>> the SWT.SetData will be called as necessary again, but theres no way
>> (AFAIK) that you can automatically clear an item after it goes out of
>> view. Perhaps we should just add that single feature and work with the
>> existing SWT.VIRTUAL pattern.
>>
>> Regards,
>> -Chris
>>
>> Nicolas Richeton wrote:
>>> I believe that using the same method signature but no common code is
>>> OK for now.
>>> But some core package may be usefull in the future too. For example,
>>> I used AbstractRenderer and TreeNodeToggleRenderer in the Gallery
>>> widget so this code is duplicated in PGroup, Grid and Gallery...
>>>
>>>
>>> This API will be used to limit the number of handles required when
>>> using different images, styles and color for each item in Grid,
>>> Gallery, Tree and Tables.
>>>
>>> I think we need :
>>> * A listener for items that are scrolled out of the visible area.
>>> Interesting informations are the item and maybe some data on the way
>>> it was hidden (parent was collapsed or scrollbar were moved)
>>>
>>> * A method which returns all the visible items.
>>> Table already has getTopIndex() that can be used together with widget
>>> and item sizes to calculate the visible items. But this approach
>>> cannot be used with other widgets where any item can be
>>> expanded/collapsed.
>>>
>>> * We don't need a listener for items which are becoming visible
>>> because the paint event can be used for this.
>>>
>>> May be we should use bugzilla to discuss of this ?
>>>
>>> --
>>> Nicolas
>>>
>>>
>>>
>>> Chris Gross a écrit :
>>>> Hmm... there could be potential problems if the resources are not
>>>> available even though the rows are out of view. Off the top of my
>>>> head I know that GridColumn#pack will need to know the size of the
>>>> contents of each cell. So that would suffer (but probably not a big
>>>> deal). There might be other problems. I have to think a little.
>>>>
>>>> I think its a good idea to try to ensure that Nebula widgets try to
>>>> share common API but I'm not sure its a good idea to formalize that
>>>> in an interface. Where would that interface live? In some core
>>>> package and then in some core plugin/jar? That would make things a
>>>> little more messy/complicated. What happens when the different
>>>> widgets start having diverging requirements? With each Nebula
>>>> widget potentially going in different directions I think any common
>>>> interfaces could become constrictive. If we have a real concrete
>>>> use-case for requiring the interface then I could probably be
>>>> convinced.
>>>>
>>>> What do we need in the API?
>>>>
>>>> -Chris
>>>>
>>>> Tom Schindl wrote:
>>>>> Hi,
>>>>>
>>>>> This would make sense the only problem I currently see is that
>>>>> Nebula isn't structured this way but I could be wrong though.
>>>>>
>>>>> But I definately agree that there should be a central position in
>>>>> nebula providing interfaces, ... like this.
>>>>>
>>>>> I'd propose something like "nebula.core" to hold things like this?
>>>>> For your gallery widget I think this a very important thing because
>>>>> your widget is by its purpose allocating a lot of system resources.
>>>>>
>>>>> Tom
>>>>>
>>>>> Nicolas Richeton schrieb:
>>>>>> About the listener for visible/invisible items :
>>>>>>
>>>>>> I want to add this feature to the gallery widget. Maybe we could
>>>>>> use the same API for all Nebula widgets ?
>>>>>>
>>>>>> --
>>>>>> Nicolas
>>>>>>
>>>>>> Tom Schindl a écrit :
>>>>>>> Implementation ready and uploaded but it was really an easy one :-)
>>>>>>>
>>>>>>> Some questions on the GridItem though:
>>>>>>>
>>>>>>> - Why can't one set the Item back to default behaviour (showing
>>>>>>> row-numbers)
>>>>>>>
>>>>>>> - Would it be possible to implement beside setting a text also an
>>>>>>> image,
>>>>>>> color, font, ...?
>>>>>>>
>>>>>>> This would be a cool feature I think e.g. highlighting rows
>>>>>>> with an
>>>>>>> error marker?
>>>>>>>
>>>>>>> - I suppose that the Grid knows which items are currently
>>>>>>> visible? Is
>>>>>>> there some listener available to track which items are scrolled
>>>>>>> out of
>>>>>>> view. This would be extremely helpful when working with
>>>>>>> OS-Resources(Images, Fonts, Colors) because when not needed
>>>>>>> anymore
>>>>>>> they could be disposed
>>>>>>>
>>>>>>> I think the GridColumnLabelProvider could be enhanced to take
>>>>>>> care of such resources and this would make GridViewer and Grid
>>>>>>> even more interesting for people currently facing problems with
>>>>>>> SWT-Table/Tree because there's no easy way to determine this (see
>>>>>>> http://tom-eclipse-dev.blogspot.com/2007/01/what-items-are-v isible-in-tabletree.html).
>>>>>>>
>>>>>>>
>>>>>>> Tom
>>>>>>>
>>>>>>> Tom Schindl schrieb:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> You are right Chris that's what I meant I haven't thought about
>>>>>>>> this carefully enough. Hence the request for a bug report.
>>>>>>>>
>>>>>>>> Maybe we could provide a standard label provider ontop of
>>>>>>>> ColumnLabelProvider. I'm against adding something depending on
>>>>>>>> the old API using the hack below :-)
>>>>>>>>
>>>>>>>> I logged https://bugs.eclipse.org/bugs/show_bug.cgi?id=188430
>>>>>>>> and will provide an example implementation.
>>>>>>>>
>>>>>>>> Tom
>>>>>>>>
|
|
|
Re: [GridViewer]How to change text of rowHeader with a labelprovider ? [message #582662 is a reply to message #35533] |
Fri, 25 May 2007 15:31 |
Chris Gross Messages: 471 Registered: July 2009 |
Senior Member |
|
|
True the SetData callback isn't cell specific but is that absolutely
needed? The row based callback should still allow you to manage
resources enough so that only a reasonable number around at one time.
If we made this cell specific would we require the use of a viewer? I
don't quite understand how it would work. We would still need the
widget layer to provide the basic callbacks including information on
what columns are visible/invisible. Seems a little more complicated.
If we stay with SetData, then it would work well with existing JFace
virtual support.
Regards,
-Chris
Tom Schindl wrote:
> Hi,
>
> One more note Chris.
>
> The SetData callback has the problem that it only informs you when rows
> are scrolled into view but it's not working for cells/columns. I think
> nebula controls should not suffer from the same problem SWT-Controls do
> because they don't support the concept of cells (which is already solved
> in your Grid => JFace for key-navigation is very simple in contrast to
> SWT-Implementation :-).
>
> I take the point of view that the Listener should work on top of the
> Cell-Concept instead of the only row-based SWT-Concept. Wouldn't it make
> sense that all columnbased controls implement the same interface?
>
> Tom
>
>
> Tom Schindl schrieb:
>> I like this, no I love this :-), staying as near to SWT as possible is
>> a great thing. The only thing I ask myself is where you get the
>> constant from if you don't have a single common package all these
>> things live in.
>>
>> I understand your point of view that there should not be too many
>> dependencies and controls may evolve differently but defining a common
>> set of things in not a bad thing and to get really usable it doesn't
>> matter because once a control declared something API it has to stay
>> for ever (http://inside-swt.blogspot.com/2007/02/its-end-of-era.html).
>>
>> Tom
>>
>> Chris Gross schrieb:
>>> I think we might as well discuss it here for now.
>>>
>>> As I started to think about this some more I realize that this is
>>> very similar to virtual support already implemented in Table/Tree.
>>> Table will use the SWT.SetData callback when an item is scrolled into
>>> view. The big difference is that it doesn't offer a way to clear
>>> items as they scroll out of view. You can use Table#clear to reset
>>> an item and the SWT.SetData will be called as necessary again, but
>>> theres no way (AFAIK) that you can automatically clear an item after
>>> it goes out of view. Perhaps we should just add that single feature
>>> and work with the existing SWT.VIRTUAL pattern.
>>>
>>> Regards,
>>> -Chris
>>>
>>> Nicolas Richeton wrote:
>>>> I believe that using the same method signature but no common code is
>>>> OK for now.
>>>> But some core package may be usefull in the future too. For example,
>>>> I used AbstractRenderer and TreeNodeToggleRenderer in the Gallery
>>>> widget so this code is duplicated in PGroup, Grid and Gallery...
>>>>
>>>>
>>>> This API will be used to limit the number of handles required when
>>>> using different images, styles and color for each item in Grid,
>>>> Gallery, Tree and Tables.
>>>>
>>>> I think we need :
>>>> * A listener for items that are scrolled out of the visible area.
>>>> Interesting informations are the item and maybe some data on the way
>>>> it was hidden (parent was collapsed or scrollbar were moved)
>>>>
>>>> * A method which returns all the visible items.
>>>> Table already has getTopIndex() that can be used together with
>>>> widget and item sizes to calculate the visible items. But this
>>>> approach cannot be used with other widgets where any item can be
>>>> expanded/collapsed.
>>>>
>>>> * We don't need a listener for items which are becoming visible
>>>> because the paint event can be used for this.
>>>>
>>>> May be we should use bugzilla to discuss of this ?
>>>>
>>>> --
>>>> Nicolas
>>>>
>>>>
>>>>
>>>> Chris Gross a écrit :
>>>>> Hmm... there could be potential problems if the resources are not
>>>>> available even though the rows are out of view. Off the top of my
>>>>> head I know that GridColumn#pack will need to know the size of the
>>>>> contents of each cell. So that would suffer (but probably not a
>>>>> big deal). There might be other problems. I have to think a little.
>>>>>
>>>>> I think its a good idea to try to ensure that Nebula widgets try to
>>>>> share common API but I'm not sure its a good idea to formalize that
>>>>> in an interface. Where would that interface live? In some core
>>>>> package and then in some core plugin/jar? That would make things a
>>>>> little more messy/complicated. What happens when the different
>>>>> widgets start having diverging requirements? With each Nebula
>>>>> widget potentially going in different directions I think any common
>>>>> interfaces could become constrictive. If we have a real concrete
>>>>> use-case for requiring the interface then I could probably be
>>>>> convinced.
>>>>>
>>>>> What do we need in the API?
>>>>>
>>>>> -Chris
>>>>>
>>>>> Tom Schindl wrote:
>>>>>> Hi,
>>>>>>
>>>>>> This would make sense the only problem I currently see is that
>>>>>> Nebula isn't structured this way but I could be wrong though.
>>>>>>
>>>>>> But I definately agree that there should be a central position in
>>>>>> nebula providing interfaces, ... like this.
>>>>>>
>>>>>> I'd propose something like "nebula.core" to hold things like this?
>>>>>> For your gallery widget I think this a very important thing
>>>>>> because your widget is by its purpose allocating a lot of system
>>>>>> resources.
>>>>>>
>>>>>> Tom
>>>>>>
>>>>>> Nicolas Richeton schrieb:
>>>>>>> About the listener for visible/invisible items :
>>>>>>>
>>>>>>> I want to add this feature to the gallery widget. Maybe we could
>>>>>>> use the same API for all Nebula widgets ?
>>>>>>>
>>>>>>> --
>>>>>>> Nicolas
>>>>>>>
>>>>>>> Tom Schindl a écrit :
>>>>>>>> Implementation ready and uploaded but it was really an easy one :-)
>>>>>>>>
>>>>>>>> Some questions on the GridItem though:
>>>>>>>>
>>>>>>>> - Why can't one set the Item back to default behaviour (showing
>>>>>>>> row-numbers)
>>>>>>>>
>>>>>>>> - Would it be possible to implement beside setting a text also
>>>>>>>> an image,
>>>>>>>> color, font, ...?
>>>>>>>>
>>>>>>>> This would be a cool feature I think e.g. highlighting rows
>>>>>>>> with an
>>>>>>>> error marker?
>>>>>>>>
>>>>>>>> - I suppose that the Grid knows which items are currently
>>>>>>>> visible? Is
>>>>>>>> there some listener available to track which items are
>>>>>>>> scrolled out of
>>>>>>>> view. This would be extremely helpful when working with
>>>>>>>> OS-Resources(Images, Fonts, Colors) because when not needed
>>>>>>>> anymore
>>>>>>>> they could be disposed
>>>>>>>>
>>>>>>>> I think the GridColumnLabelProvider could be enhanced to take
>>>>>>>> care of such resources and this would make GridViewer and Grid
>>>>>>>> even more interesting for people currently facing problems with
>>>>>>>> SWT-Table/Tree because there's no easy way to determine this
>>>>>>>> (see
>>>>>>>> http://tom-eclipse-dev.blogspot.com/2007/01/what-items-are-v isible-in-tabletree.html).
>>>>>>>>
>>>>>>>>
>>>>>>>> Tom
>>>>>>>>
>>>>>>>> Tom Schindl schrieb:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> You are right Chris that's what I meant I haven't thought about
>>>>>>>>> this carefully enough. Hence the request for a bug report.
>>>>>>>>>
>>>>>>>>> Maybe we could provide a standard label provider ontop of
>>>>>>>>> ColumnLabelProvider. I'm against adding something depending on
>>>>>>>>> the old API using the hack below :-)
>>>>>>>>>
>>>>>>>>> I logged https://bugs.eclipse.org/bugs/show_bug.cgi?id=188430
>>>>>>>>> and will provide an example implementation.
>>>>>>>>>
>>>>>>>>> Tom
>>>>>>>>>
|
|
|
Re: [GridViewer]How to change text of rowHeader with a labelprovider ? [message #582905 is a reply to message #35566] |
Tue, 05 June 2007 20:11 |
Thomas Schindl Messages: 6651 Registered: July 2009 |
Senior Member |
|
|
Sorry for coming back after such a long time.
Well if we I don't think we need to depend on any Viewer-Code I need to
investigate but for Tables/Trees with many columns this might still be
an issue.
The other thing that makes neverous is that the SetData-Callback in
SWT-Controls get's a different meaning in Grid which might provoke
problems with the AbstractTable/TreeViewer in future what do you do if
you add VIRTUAL-Support to Grid?
With all the work done in 190252 is there maybe already internal-API to
query the currently visible GridCells?
Tom
Chris Gross schrieb:
> True the SetData callback isn't cell specific but is that absolutely
> needed? The row based callback should still allow you to manage
> resources enough so that only a reasonable number around at one time.
> If we made this cell specific would we require the use of a viewer? I
> don't quite understand how it would work. We would still need the
> widget layer to provide the basic callbacks including information on
> what columns are visible/invisible. Seems a little more complicated. If
> we stay with SetData, then it would work well with existing JFace
> virtual support.
>
> Regards,
> -Chris
>
>
>
> Tom Schindl wrote:
>> Hi,
>>
>> One more note Chris.
>>
>> The SetData callback has the problem that it only informs you when
>> rows are scrolled into view but it's not working for cells/columns. I
>> think nebula controls should not suffer from the same problem
>> SWT-Controls do because they don't support the concept of cells (which
>> is already solved in your Grid => JFace for key-navigation is very
>> simple in contrast to SWT-Implementation :-).
>>
>> I take the point of view that the Listener should work on top of the
>> Cell-Concept instead of the only row-based SWT-Concept. Wouldn't it
>> make sense that all columnbased controls implement the same interface?
>>
>> Tom
>>
>>
>> Tom Schindl schrieb:
>>> I like this, no I love this :-), staying as near to SWT as possible
>>> is a great thing. The only thing I ask myself is where you get the
>>> constant from if you don't have a single common package all these
>>> things live in.
>>>
>>> I understand your point of view that there should not be too many
>>> dependencies and controls may evolve differently but defining a
>>> common set of things in not a bad thing and to get really usable it
>>> doesn't matter because once a control declared something API it has
>>> to stay for ever
>>> (http://inside-swt.blogspot.com/2007/02/its-end-of-era.html).
>>>
>>> Tom
>>>
>>> Chris Gross schrieb:
>>>> I think we might as well discuss it here for now.
>>>>
>>>> As I started to think about this some more I realize that this is
>>>> very similar to virtual support already implemented in Table/Tree.
>>>> Table will use the SWT.SetData callback when an item is scrolled
>>>> into view. The big difference is that it doesn't offer a way to
>>>> clear items as they scroll out of view. You can use Table#clear to
>>>> reset an item and the SWT.SetData will be called as necessary again,
>>>> but theres no way (AFAIK) that you can automatically clear an item
>>>> after it goes out of view. Perhaps we should just add that single
>>>> feature and work with the existing SWT.VIRTUAL pattern.
>>>>
>>>> Regards,
>>>> -Chris
>>>>
>>>> Nicolas Richeton wrote:
>>>>> I believe that using the same method signature but no common code
>>>>> is OK for now.
>>>>> But some core package may be usefull in the future too. For
>>>>> example, I used AbstractRenderer and TreeNodeToggleRenderer in the
>>>>> Gallery widget so this code is duplicated in PGroup, Grid and
>>>>> Gallery...
>>>>>
>>>>>
>>>>> This API will be used to limit the number of handles required when
>>>>> using different images, styles and color for each item in Grid,
>>>>> Gallery, Tree and Tables.
>>>>>
>>>>> I think we need :
>>>>> * A listener for items that are scrolled out of the visible area.
>>>>> Interesting informations are the item and maybe some data on the
>>>>> way it was hidden (parent was collapsed or scrollbar were moved)
>>>>>
>>>>> * A method which returns all the visible items.
>>>>> Table already has getTopIndex() that can be used together with
>>>>> widget and item sizes to calculate the visible items. But this
>>>>> approach cannot be used with other widgets where any item can be
>>>>> expanded/collapsed.
>>>>>
>>>>> * We don't need a listener for items which are becoming visible
>>>>> because the paint event can be used for this.
>>>>>
>>>>> May be we should use bugzilla to discuss of this ?
>>>>>
>>>>> --
>>>>> Nicolas
>>>>>
>>>>>
>>>>>
>>>>> Chris Gross a écrit :
>>>>>> Hmm... there could be potential problems if the resources are not
>>>>>> available even though the rows are out of view. Off the top of my
>>>>>> head I know that GridColumn#pack will need to know the size of the
>>>>>> contents of each cell. So that would suffer (but probably not a
>>>>>> big deal). There might be other problems. I have to think a little.
>>>>>>
>>>>>> I think its a good idea to try to ensure that Nebula widgets try
>>>>>> to share common API but I'm not sure its a good idea to formalize
>>>>>> that in an interface. Where would that interface live? In some
>>>>>> core package and then in some core plugin/jar? That would make
>>>>>> things a little more messy/complicated. What happens when the
>>>>>> different widgets start having diverging requirements? With each
>>>>>> Nebula widget potentially going in different directions I think
>>>>>> any common interfaces could become constrictive. If we have a
>>>>>> real concrete use-case for requiring the interface then I could
>>>>>> probably be convinced.
>>>>>>
>>>>>> What do we need in the API?
>>>>>>
>>>>>> -Chris
>>>>>>
>>>>>> Tom Schindl wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> This would make sense the only problem I currently see is that
>>>>>>> Nebula isn't structured this way but I could be wrong though.
>>>>>>>
>>>>>>> But I definately agree that there should be a central position in
>>>>>>> nebula providing interfaces, ... like this.
>>>>>>>
>>>>>>> I'd propose something like "nebula.core" to hold things like
>>>>>>> this? For your gallery widget I think this a very important thing
>>>>>>> because your widget is by its purpose allocating a lot of system
>>>>>>> resources.
>>>>>>>
>>>>>>> Tom
>>>>>>>
>>>>>>> Nicolas Richeton schrieb:
>>>>>>>> About the listener for visible/invisible items :
>>>>>>>>
>>>>>>>> I want to add this feature to the gallery widget. Maybe we could
>>>>>>>> use the same API for all Nebula widgets ?
>>>>>>>>
>>>>>>>> --
>>>>>>>> Nicolas
>>>>>>>>
>>>>>>>> Tom Schindl a écrit :
>>>>>>>>> Implementation ready and uploaded but it was really an easy one
>>>>>>>>> :-)
>>>>>>>>>
>>>>>>>>> Some questions on the GridItem though:
>>>>>>>>>
>>>>>>>>> - Why can't one set the Item back to default behaviour (showing
>>>>>>>>> row-numbers)
>>>>>>>>>
>>>>>>>>> - Would it be possible to implement beside setting a text also
>>>>>>>>> an image,
>>>>>>>>> color, font, ...?
>>>>>>>>>
>>>>>>>>> This would be a cool feature I think e.g. highlighting rows
>>>>>>>>> with an
>>>>>>>>> error marker?
>>>>>>>>>
>>>>>>>>> - I suppose that the Grid knows which items are currently
>>>>>>>>> visible? Is
>>>>>>>>> there some listener available to track which items are
>>>>>>>>> scrolled out of
>>>>>>>>> view. This would be extremely helpful when working with
>>>>>>>>> OS-Resources(Images, Fonts, Colors) because when not needed
>>>>>>>>> anymore
>>>>>>>>> they could be disposed
>>>>>>>>>
>>>>>>>>> I think the GridColumnLabelProvider could be enhanced to take
>>>>>>>>> care of such resources and this would make GridViewer and Grid
>>>>>>>>> even more interesting for people currently facing problems with
>>>>>>>>> SWT-Table/Tree because there's no easy way to determine this
>>>>>>>>> (see
>>>>>>>>> http://tom-eclipse-dev.blogspot.com/2007/01/what-items-are-v isible-in-tabletree.html).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Tom
>>>>>>>>>
>>>>>>>>> Tom Schindl schrieb:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> You are right Chris that's what I meant I haven't thought
>>>>>>>>>> about this carefully enough. Hence the request for a bug report.
>>>>>>>>>>
>>>>>>>>>> Maybe we could provide a standard label provider ontop of
>>>>>>>>>> ColumnLabelProvider. I'm against adding something depending on
>>>>>>>>>> the old API using the hack below :-)
>>>>>>>>>>
>>>>>>>>>> I logged https://bugs.eclipse.org/bugs/show_bug.cgi?id=188430
>>>>>>>>>> and will provide an example implementation.
>>>>>>>>>>
>>>>>>>>>> Tom
>>>>>>>>>>
|
|
|
Re: [GridViewer]How to change text of rowHeader with a labelprovider ? [message #582949 is a reply to message #36077] |
Thu, 07 June 2007 15:15 |
Chris Gross Messages: 471 Registered: July 2009 |
Senior Member |
|
|
I did add virtual support to Grid recently. I modeled the virtual
support in Grid exactly after Table/Tree. And I think these
requirements that we're talking about (maintaining fewer resources)
really maps right in with the way virtual support is designed. The
SetData callback is just saying someone needs the values of this item -
please go fill them in.
I'm certain we could expose a method to return the visible rows (along
with a listener when this value changes) but I'd rather not have to if
there is an existing mechanism that seems designed to solve the same
problem.
-Chris
Tom Schindl wrote:
> Sorry for coming back after such a long time.
>
> Well if we I don't think we need to depend on any Viewer-Code I need to
> investigate but for Tables/Trees with many columns this might still be
> an issue.
>
> The other thing that makes neverous is that the SetData-Callback in
> SWT-Controls get's a different meaning in Grid which might provoke
> problems with the AbstractTable/TreeViewer in future what do you do if
> you add VIRTUAL-Support to Grid?
>
> With all the work done in 190252 is there maybe already internal-API to
> query the currently visible GridCells?
>
> Tom
>
> Chris Gross schrieb:
>> True the SetData callback isn't cell specific but is that absolutely
>> needed? The row based callback should still allow you to manage
>> resources enough so that only a reasonable number around at one time.
>> If we made this cell specific would we require the use of a viewer? I
>> don't quite understand how it would work. We would still need the
>> widget layer to provide the basic callbacks including information on
>> what columns are visible/invisible. Seems a little more complicated.
>> If we stay with SetData, then it would work well with existing JFace
>> virtual support.
>>
>> Regards,
>> -Chris
>>
>>
>>
>> Tom Schindl wrote:
>>> Hi,
>>>
>>> One more note Chris.
>>>
>>> The SetData callback has the problem that it only informs you when
>>> rows are scrolled into view but it's not working for cells/columns. I
>>> think nebula controls should not suffer from the same problem
>>> SWT-Controls do because they don't support the concept of cells
>>> (which is already solved in your Grid => JFace for key-navigation is
>>> very simple in contrast to SWT-Implementation :-).
>>>
>>> I take the point of view that the Listener should work on top of the
>>> Cell-Concept instead of the only row-based SWT-Concept. Wouldn't it
>>> make sense that all columnbased controls implement the same interface?
>>>
>>> Tom
>>>
>>>
>>> Tom Schindl schrieb:
>>>> I like this, no I love this :-), staying as near to SWT as possible
>>>> is a great thing. The only thing I ask myself is where you get the
>>>> constant from if you don't have a single common package all these
>>>> things live in.
>>>>
>>>> I understand your point of view that there should not be too many
>>>> dependencies and controls may evolve differently but defining a
>>>> common set of things in not a bad thing and to get really usable it
>>>> doesn't matter because once a control declared something API it has
>>>> to stay for ever
>>>> (http://inside-swt.blogspot.com/2007/02/its-end-of-era.html).
>>>>
>>>> Tom
>>>>
>>>> Chris Gross schrieb:
>>>>> I think we might as well discuss it here for now.
>>>>>
>>>>> As I started to think about this some more I realize that this is
>>>>> very similar to virtual support already implemented in Table/Tree.
>>>>> Table will use the SWT.SetData callback when an item is scrolled
>>>>> into view. The big difference is that it doesn't offer a way to
>>>>> clear items as they scroll out of view. You can use Table#clear to
>>>>> reset an item and the SWT.SetData will be called as necessary
>>>>> again, but theres no way (AFAIK) that you can automatically clear
>>>>> an item after it goes out of view. Perhaps we should just add that
>>>>> single feature and work with the existing SWT.VIRTUAL pattern.
>>>>>
>>>>> Regards,
>>>>> -Chris
>>>>>
>>>>> Nicolas Richeton wrote:
>>>>>> I believe that using the same method signature but no common code
>>>>>> is OK for now.
>>>>>> But some core package may be usefull in the future too. For
>>>>>> example, I used AbstractRenderer and TreeNodeToggleRenderer in the
>>>>>> Gallery widget so this code is duplicated in PGroup, Grid and
>>>>>> Gallery...
>>>>>>
>>>>>>
>>>>>> This API will be used to limit the number of handles required when
>>>>>> using different images, styles and color for each item in Grid,
>>>>>> Gallery, Tree and Tables.
>>>>>>
>>>>>> I think we need :
>>>>>> * A listener for items that are scrolled out of the visible area.
>>>>>> Interesting informations are the item and maybe some data on the
>>>>>> way it was hidden (parent was collapsed or scrollbar were moved)
>>>>>>
>>>>>> * A method which returns all the visible items.
>>>>>> Table already has getTopIndex() that can be used together with
>>>>>> widget and item sizes to calculate the visible items. But this
>>>>>> approach cannot be used with other widgets where any item can be
>>>>>> expanded/collapsed.
>>>>>>
>>>>>> * We don't need a listener for items which are becoming visible
>>>>>> because the paint event can be used for this.
>>>>>>
>>>>>> May be we should use bugzilla to discuss of this ?
>>>>>>
>>>>>> --
>>>>>> Nicolas
>>>>>>
>>>>>>
>>>>>>
>>>>>> Chris Gross a écrit :
>>>>>>> Hmm... there could be potential problems if the resources are not
>>>>>>> available even though the rows are out of view. Off the top of
>>>>>>> my head I know that GridColumn#pack will need to know the size of
>>>>>>> the contents of each cell. So that would suffer (but probably
>>>>>>> not a big deal). There might be other problems. I have to think
>>>>>>> a little.
>>>>>>>
>>>>>>> I think its a good idea to try to ensure that Nebula widgets try
>>>>>>> to share common API but I'm not sure its a good idea to formalize
>>>>>>> that in an interface. Where would that interface live? In some
>>>>>>> core package and then in some core plugin/jar? That would make
>>>>>>> things a little more messy/complicated. What happens when the
>>>>>>> different widgets start having diverging requirements? With each
>>>>>>> Nebula widget potentially going in different directions I think
>>>>>>> any common interfaces could become constrictive. If we have a
>>>>>>> real concrete use-case for requiring the interface then I could
>>>>>>> probably be convinced.
>>>>>>>
>>>>>>> What do we need in the API?
>>>>>>>
>>>>>>> -Chris
>>>>>>>
>>>>>>> Tom Schindl wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> This would make sense the only problem I currently see is that
>>>>>>>> Nebula isn't structured this way but I could be wrong though.
>>>>>>>>
>>>>>>>> But I definately agree that there should be a central position
>>>>>>>> in nebula providing interfaces, ... like this.
>>>>>>>>
>>>>>>>> I'd propose something like "nebula.core" to hold things like
>>>>>>>> this? For your gallery widget I think this a very important
>>>>>>>> thing because your widget is by its purpose allocating a lot of
>>>>>>>> system resources.
>>>>>>>>
>>>>>>>> Tom
>>>>>>>>
>>>>>>>> Nicolas Richeton schrieb:
>>>>>>>>> About the listener for visible/invisible items :
>>>>>>>>>
>>>>>>>>> I want to add this feature to the gallery widget. Maybe we
>>>>>>>>> could use the same API for all Nebula widgets ?
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Nicolas
>>>>>>>>>
>>>>>>>>> Tom Schindl a écrit :
>>>>>>>>>> Implementation ready and uploaded but it was really an easy
>>>>>>>>>> one :-)
>>>>>>>>>>
>>>>>>>>>> Some questions on the GridItem though:
>>>>>>>>>>
>>>>>>>>>> - Why can't one set the Item back to default behaviour (showing
>>>>>>>>>> row-numbers)
>>>>>>>>>>
>>>>>>>>>> - Would it be possible to implement beside setting a text also
>>>>>>>>>> an image,
>>>>>>>>>> color, font, ...?
>>>>>>>>>>
>>>>>>>>>> This would be a cool feature I think e.g. highlighting rows
>>>>>>>>>> with an
>>>>>>>>>> error marker?
>>>>>>>>>>
>>>>>>>>>> - I suppose that the Grid knows which items are currently
>>>>>>>>>> visible? Is
>>>>>>>>>> there some listener available to track which items are
>>>>>>>>>> scrolled out of
>>>>>>>>>> view. This would be extremely helpful when working with
>>>>>>>>>> OS-Resources(Images, Fonts, Colors) because when not needed
>>>>>>>>>> anymore
>>>>>>>>>> they could be disposed
>>>>>>>>>>
>>>>>>>>>> I think the GridColumnLabelProvider could be enhanced to take
>>>>>>>>>> care of such resources and this would make GridViewer and Grid
>>>>>>>>>> even more interesting for people currently facing problems
>>>>>>>>>> with SWT-Table/Tree because there's no easy way to determine
>>>>>>>>>> this (see
>>>>>>>>>> http://tom-eclipse-dev.blogspot.com/2007/01/what-items-are-v isible-in-tabletree.html).
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Tom
>>>>>>>>>>
>>>>>>>>>> Tom Schindl schrieb:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> You are right Chris that's what I meant I haven't thought
>>>>>>>>>>> about this carefully enough. Hence the request for a bug report.
>>>>>>>>>>>
>>>>>>>>>>> Maybe we could provide a standard label provider ontop of
>>>>>>>>>>> ColumnLabelProvider. I'm against adding something depending
>>>>>>>>>>> on the old API using the hack below :-)
>>>>>>>>>>>
>>>>>>>>>>> I logged https://bugs.eclipse.org/bugs/show_bug.cgi?id=188430
>>>>>>>>>>> and will provide an example implementation.
>>>>>>>>>>>
>>>>>>>>>>> Tom
>>>>>>>>>>>
|
|
|
Re: [GridViewer]How to change text of rowHeader with a labelprovider ? [message #582960 is a reply to message #36146] |
Fri, 08 June 2007 11:10 |
Thomas Schindl Messages: 6651 Registered: July 2009 |
Senior Member |
|
|
Well SetData-callback informs you that Row is scrolled into view but
what do we send when a Row is scrolled out of view? This is the
interesting event we should get to clean up resources, not?
Tom
Chris Gross schrieb:
> I did add virtual support to Grid recently. I modeled the virtual
> support in Grid exactly after Table/Tree. And I think these
> requirements that we're talking about (maintaining fewer resources)
> really maps right in with the way virtual support is designed. The
> SetData callback is just saying someone needs the values of this item -
> please go fill them in.
>
> I'm certain we could expose a method to return the visible rows (along
> with a listener when this value changes) but I'd rather not have to if
> there is an existing mechanism that seems designed to solve the same
> problem.
>
> -Chris
>
> Tom Schindl wrote:
>> Sorry for coming back after such a long time.
>>
>> Well if we I don't think we need to depend on any Viewer-Code I need
>> to investigate but for Tables/Trees with many columns this might still
>> be an issue.
>>
>> The other thing that makes neverous is that the SetData-Callback in
>> SWT-Controls get's a different meaning in Grid which might provoke
>> problems with the AbstractTable/TreeViewer in future what do you do if
>> you add VIRTUAL-Support to Grid?
>>
>> With all the work done in 190252 is there maybe already internal-API
>> to query the currently visible GridCells?
>>
>> Tom
>>
>> Chris Gross schrieb:
>>> True the SetData callback isn't cell specific but is that absolutely
>>> needed? The row based callback should still allow you to manage
>>> resources enough so that only a reasonable number around at one time.
>>> If we made this cell specific would we require the use of a viewer?
>>> I don't quite understand how it would work. We would still need the
>>> widget layer to provide the basic callbacks including information on
>>> what columns are visible/invisible. Seems a little more complicated.
>>> If we stay with SetData, then it would work well with existing JFace
>>> virtual support.
>>>
>>> Regards,
>>> -Chris
>>>
>>>
>>>
>>> Tom Schindl wrote:
>>>> Hi,
>>>>
>>>> One more note Chris.
>>>>
>>>> The SetData callback has the problem that it only informs you when
>>>> rows are scrolled into view but it's not working for cells/columns.
>>>> I think nebula controls should not suffer from the same problem
>>>> SWT-Controls do because they don't support the concept of cells
>>>> (which is already solved in your Grid => JFace for key-navigation is
>>>> very simple in contrast to SWT-Implementation :-).
>>>>
>>>> I take the point of view that the Listener should work on top of the
>>>> Cell-Concept instead of the only row-based SWT-Concept. Wouldn't it
>>>> make sense that all columnbased controls implement the same interface?
>>>>
>>>> Tom
>>>>
>>>>
>>>> Tom Schindl schrieb:
>>>>> I like this, no I love this :-), staying as near to SWT as possible
>>>>> is a great thing. The only thing I ask myself is where you get the
>>>>> constant from if you don't have a single common package all these
>>>>> things live in.
>>>>>
>>>>> I understand your point of view that there should not be too many
>>>>> dependencies and controls may evolve differently but defining a
>>>>> common set of things in not a bad thing and to get really usable it
>>>>> doesn't matter because once a control declared something API it has
>>>>> to stay for ever
>>>>> (http://inside-swt.blogspot.com/2007/02/its-end-of-era.html).
>>>>>
>>>>> Tom
>>>>>
>>>>> Chris Gross schrieb:
>>>>>> I think we might as well discuss it here for now.
>>>>>>
>>>>>> As I started to think about this some more I realize that this is
>>>>>> very similar to virtual support already implemented in
>>>>>> Table/Tree. Table will use the SWT.SetData callback when an item
>>>>>> is scrolled into view. The big difference is that it doesn't offer
>>>>>> a way to clear items as they scroll out of view. You can use
>>>>>> Table#clear to reset an item and the SWT.SetData will be called as
>>>>>> necessary again, but theres no way (AFAIK) that you can
>>>>>> automatically clear an item after it goes out of view. Perhaps we
>>>>>> should just add that single feature and work with the existing
>>>>>> SWT.VIRTUAL pattern.
>>>>>>
>>>>>> Regards,
>>>>>> -Chris
>>>>>>
>>>>>> Nicolas Richeton wrote:
>>>>>>> I believe that using the same method signature but no common code
>>>>>>> is OK for now.
>>>>>>> But some core package may be usefull in the future too. For
>>>>>>> example, I used AbstractRenderer and TreeNodeToggleRenderer in
>>>>>>> the Gallery widget so this code is duplicated in PGroup, Grid and
>>>>>>> Gallery...
>>>>>>>
>>>>>>>
>>>>>>> This API will be used to limit the number of handles required
>>>>>>> when using different images, styles and color for each item in
>>>>>>> Grid, Gallery, Tree and Tables.
>>>>>>>
>>>>>>> I think we need :
>>>>>>> * A listener for items that are scrolled out of the visible area.
>>>>>>> Interesting informations are the item and maybe some data on the
>>>>>>> way it was hidden (parent was collapsed or scrollbar were moved)
>>>>>>>
>>>>>>> * A method which returns all the visible items.
>>>>>>> Table already has getTopIndex() that can be used together with
>>>>>>> widget and item sizes to calculate the visible items. But this
>>>>>>> approach cannot be used with other widgets where any item can be
>>>>>>> expanded/collapsed.
>>>>>>>
>>>>>>> * We don't need a listener for items which are becoming visible
>>>>>>> because the paint event can be used for this.
>>>>>>>
>>>>>>> May be we should use bugzilla to discuss of this ?
>>>>>>>
>>>>>>> --
>>>>>>> Nicolas
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Chris Gross a écrit :
>>>>>>>> Hmm... there could be potential problems if the resources are
>>>>>>>> not available even though the rows are out of view. Off the top
>>>>>>>> of my head I know that GridColumn#pack will need to know the
>>>>>>>> size of the contents of each cell. So that would suffer (but
>>>>>>>> probably not a big deal). There might be other problems. I have
>>>>>>>> to think a little.
>>>>>>>>
>>>>>>>> I think its a good idea to try to ensure that Nebula widgets try
>>>>>>>> to share common API but I'm not sure its a good idea to
>>>>>>>> formalize that in an interface. Where would that interface
>>>>>>>> live? In some core package and then in some core plugin/jar?
>>>>>>>> That would make things a little more messy/complicated. What
>>>>>>>> happens when the different widgets start having diverging
>>>>>>>> requirements? With each Nebula widget potentially going in
>>>>>>>> different directions I think any common interfaces could become
>>>>>>>> constrictive. If we have a real concrete use-case for requiring
>>>>>>>> the interface then I could probably be convinced.
>>>>>>>>
>>>>>>>> What do we need in the API?
>>>>>>>>
>>>>>>>> -Chris
>>>>>>>>
>>>>>>>> Tom Schindl wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> This would make sense the only problem I currently see is that
>>>>>>>>> Nebula isn't structured this way but I could be wrong though.
>>>>>>>>>
>>>>>>>>> But I definately agree that there should be a central position
>>>>>>>>> in nebula providing interfaces, ... like this.
>>>>>>>>>
>>>>>>>>> I'd propose something like "nebula.core" to hold things like
>>>>>>>>> this? For your gallery widget I think this a very important
>>>>>>>>> thing because your widget is by its purpose allocating a lot of
>>>>>>>>> system resources.
>>>>>>>>>
>>>>>>>>> Tom
>>>>>>>>>
>>>>>>>>> Nicolas Richeton schrieb:
>>>>>>>>>> About the listener for visible/invisible items :
>>>>>>>>>>
>>>>>>>>>> I want to add this feature to the gallery widget. Maybe we
>>>>>>>>>> could use the same API for all Nebula widgets ?
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Nicolas
>>>>>>>>>>
>>>>>>>>>> Tom Schindl a écrit :
>>>>>>>>>>> Implementation ready and uploaded but it was really an easy
>>>>>>>>>>> one :-)
>>>>>>>>>>>
>>>>>>>>>>> Some questions on the GridItem though:
>>>>>>>>>>>
>>>>>>>>>>> - Why can't one set the Item back to default behaviour (showing
>>>>>>>>>>> row-numbers)
>>>>>>>>>>>
>>>>>>>>>>> - Would it be possible to implement beside setting a text
>>>>>>>>>>> also an image,
>>>>>>>>>>> color, font, ...?
>>>>>>>>>>>
>>>>>>>>>>> This would be a cool feature I think e.g. highlighting rows
>>>>>>>>>>> with an
>>>>>>>>>>> error marker?
>>>>>>>>>>>
>>>>>>>>>>> - I suppose that the Grid knows which items are currently
>>>>>>>>>>> visible? Is
>>>>>>>>>>> there some listener available to track which items are
>>>>>>>>>>> scrolled out of
>>>>>>>>>>> view. This would be extremely helpful when working with
>>>>>>>>>>> OS-Resources(Images, Fonts, Colors) because when not needed
>>>>>>>>>>> anymore
>>>>>>>>>>> they could be disposed
>>>>>>>>>>>
>>>>>>>>>>> I think the GridColumnLabelProvider could be enhanced to take
>>>>>>>>>>> care of such resources and this would make GridViewer and
>>>>>>>>>>> Grid even more interesting for people currently facing
>>>>>>>>>>> problems with SWT-Table/Tree because there's no easy way to
>>>>>>>>>>> determine this (see
>>>>>>>>>>> http://tom-eclipse-dev.blogspot.com/2007/01/what-items-are-v isible-in-tabletree.html).
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Tom
>>>>>>>>>>>
>>>>>>>>>>> Tom Schindl schrieb:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> You are right Chris that's what I meant I haven't thought
>>>>>>>>>>>> about this carefully enough. Hence the request for a bug
>>>>>>>>>>>> report.
>>>>>>>>>>>>
>>>>>>>>>>>> Maybe we could provide a standard label provider ontop of
>>>>>>>>>>>> ColumnLabelProvider. I'm against adding something depending
>>>>>>>>>>>> on the old API using the hack below :-)
>>>>>>>>>>>>
>>>>>>>>>>>> I logged
>>>>>>>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=188430 and
>>>>>>>>>>>> will provide an example implementation.
>>>>>>>>>>>>
>>>>>>>>>>>> Tom
>>>>>>>>>>>>
|
|
|
Re: [GridViewer]How to change text of rowHeader with a labelprovider ? [message #582986 is a reply to message #36180] |
Fri, 08 June 2007 15:18 |
Chris Gross Messages: 471 Registered: July 2009 |
Senior Member |
|
|
Right. We would need to add a new callback to compliment SetData.
Perhaps ClearData? The constant will have to live on Grid (and
Gallery). This feels like a smaller, better change.
-Chris
Tom Schindl wrote:
> Well SetData-callback informs you that Row is scrolled into view but
> what do we send when a Row is scrolled out of view? This is the
> interesting event we should get to clean up resources, not?
>
> Tom
>
> Chris Gross schrieb:
>> I did add virtual support to Grid recently. I modeled the virtual
>> support in Grid exactly after Table/Tree. And I think these
>> requirements that we're talking about (maintaining fewer resources)
>> really maps right in with the way virtual support is designed. The
>> SetData callback is just saying someone needs the values of this item
>> - please go fill them in.
>>
>> I'm certain we could expose a method to return the visible rows (along
>> with a listener when this value changes) but I'd rather not have to if
>> there is an existing mechanism that seems designed to solve the same
>> problem.
>>
>> -Chris
>>
>> Tom Schindl wrote:
>>> Sorry for coming back after such a long time.
>>>
>>> Well if we I don't think we need to depend on any Viewer-Code I need
>>> to investigate but for Tables/Trees with many columns this might
>>> still be an issue.
>>>
>>> The other thing that makes neverous is that the SetData-Callback in
>>> SWT-Controls get's a different meaning in Grid which might provoke
>>> problems with the AbstractTable/TreeViewer in future what do you do
>>> if you add VIRTUAL-Support to Grid?
>>>
>>> With all the work done in 190252 is there maybe already internal-API
>>> to query the currently visible GridCells?
>>>
>>> Tom
>>>
>>> Chris Gross schrieb:
>>>> True the SetData callback isn't cell specific but is that absolutely
>>>> needed? The row based callback should still allow you to manage
>>>> resources enough so that only a reasonable number around at one time.
>>>> If we made this cell specific would we require the use of a viewer?
>>>> I don't quite understand how it would work. We would still need the
>>>> widget layer to provide the basic callbacks including information on
>>>> what columns are visible/invisible. Seems a little more
>>>> complicated. If we stay with SetData, then it would work well with
>>>> existing JFace virtual support.
>>>>
>>>> Regards,
>>>> -Chris
>>>>
>>>>
>>>>
>>>> Tom Schindl wrote:
>>>>> Hi,
>>>>>
>>>>> One more note Chris.
>>>>>
>>>>> The SetData callback has the problem that it only informs you when
>>>>> rows are scrolled into view but it's not working for cells/columns.
>>>>> I think nebula controls should not suffer from the same problem
>>>>> SWT-Controls do because they don't support the concept of cells
>>>>> (which is already solved in your Grid => JFace for key-navigation
>>>>> is very simple in contrast to SWT-Implementation :-).
>>>>>
>>>>> I take the point of view that the Listener should work on top of
>>>>> the Cell-Concept instead of the only row-based SWT-Concept.
>>>>> Wouldn't it make sense that all columnbased controls implement the
>>>>> same interface?
>>>>>
>>>>> Tom
>>>>>
>>>>>
>>>>> Tom Schindl schrieb:
>>>>>> I like this, no I love this :-), staying as near to SWT as
>>>>>> possible is a great thing. The only thing I ask myself is where
>>>>>> you get the constant from if you don't have a single common
>>>>>> package all these things live in.
>>>>>>
>>>>>> I understand your point of view that there should not be too many
>>>>>> dependencies and controls may evolve differently but defining a
>>>>>> common set of things in not a bad thing and to get really usable
>>>>>> it doesn't matter because once a control declared something API it
>>>>>> has to stay for ever
>>>>>> (http://inside-swt.blogspot.com/2007/02/its-end-of-era.html).
>>>>>>
>>>>>> Tom
>>>>>>
>>>>>> Chris Gross schrieb:
>>>>>>> I think we might as well discuss it here for now.
>>>>>>>
>>>>>>> As I started to think about this some more I realize that this is
>>>>>>> very similar to virtual support already implemented in
>>>>>>> Table/Tree. Table will use the SWT.SetData callback when an item
>>>>>>> is scrolled into view. The big difference is that it doesn't
>>>>>>> offer a way to clear items as they scroll out of view. You can
>>>>>>> use Table#clear to reset an item and the SWT.SetData will be
>>>>>>> called as necessary again, but theres no way (AFAIK) that you can
>>>>>>> automatically clear an item after it goes out of view. Perhaps we
>>>>>>> should just add that single feature and work with the existing
>>>>>>> SWT.VIRTUAL pattern.
>>>>>>>
>>>>>>> Regards,
>>>>>>> -Chris
>>>>>>>
>>>>>>> Nicolas Richeton wrote:
>>>>>>>> I believe that using the same method signature but no common
>>>>>>>> code is OK for now.
>>>>>>>> But some core package may be usefull in the future too. For
>>>>>>>> example, I used AbstractRenderer and TreeNodeToggleRenderer in
>>>>>>>> the Gallery widget so this code is duplicated in PGroup, Grid
>>>>>>>> and Gallery...
>>>>>>>>
>>>>>>>>
>>>>>>>> This API will be used to limit the number of handles required
>>>>>>>> when using different images, styles and color for each item in
>>>>>>>> Grid, Gallery, Tree and Tables.
>>>>>>>>
>>>>>>>> I think we need :
>>>>>>>> * A listener for items that are scrolled out of the visible
>>>>>>>> area. Interesting informations are the item and maybe some data
>>>>>>>> on the way it was hidden (parent was collapsed or scrollbar were
>>>>>>>> moved)
>>>>>>>>
>>>>>>>> * A method which returns all the visible items.
>>>>>>>> Table already has getTopIndex() that can be used together with
>>>>>>>> widget and item sizes to calculate the visible items. But this
>>>>>>>> approach cannot be used with other widgets where any item can be
>>>>>>>> expanded/collapsed.
>>>>>>>>
>>>>>>>> * We don't need a listener for items which are becoming visible
>>>>>>>> because the paint event can be used for this.
>>>>>>>>
>>>>>>>> May be we should use bugzilla to discuss of this ?
>>>>>>>>
>>>>>>>> --
>>>>>>>> Nicolas
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Chris Gross a écrit :
>>>>>>>>> Hmm... there could be potential problems if the resources are
>>>>>>>>> not available even though the rows are out of view. Off the
>>>>>>>>> top of my head I know that GridColumn#pack will need to know
>>>>>>>>> the size of the contents of each cell. So that would suffer
>>>>>>>>> (but probably not a big deal). There might be other problems.
>>>>>>>>> I have to think a little.
>>>>>>>>>
>>>>>>>>> I think its a good idea to try to ensure that Nebula widgets
>>>>>>>>> try to share common API but I'm not sure its a good idea to
>>>>>>>>> formalize that in an interface. Where would that interface
>>>>>>>>> live? In some core package and then in some core plugin/jar?
>>>>>>>>> That would make things a little more messy/complicated. What
>>>>>>>>> happens when the different widgets start having diverging
>>>>>>>>> requirements? With each Nebula widget potentially going in
>>>>>>>>> different directions I think any common interfaces could become
>>>>>>>>> constrictive. If we have a real concrete use-case for
>>>>>>>>> requiring the interface then I could probably be convinced.
>>>>>>>>>
>>>>>>>>> What do we need in the API?
>>>>>>>>>
>>>>>>>>> -Chris
>>>>>>>>>
>>>>>>>>> Tom Schindl wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> This would make sense the only problem I currently see is that
>>>>>>>>>> Nebula isn't structured this way but I could be wrong though.
>>>>>>>>>>
>>>>>>>>>> But I definately agree that there should be a central position
>>>>>>>>>> in nebula providing interfaces, ... like this.
>>>>>>>>>>
>>>>>>>>>> I'd propose something like "nebula.core" to hold things like
>>>>>>>>>> this? For your gallery widget I think this a very important
>>>>>>>>>> thing because your widget is by its purpose allocating a lot
>>>>>>>>>> of system resources.
>>>>>>>>>>
>>>>>>>>>> Tom
>>>>>>>>>>
>>>>>>>>>> Nicolas Richeton schrieb:
>>>>>>>>>>> About the listener for visible/invisible items :
>>>>>>>>>>>
>>>>>>>>>>> I want to add this feature to the gallery widget. Maybe we
>>>>>>>>>>> could use the same API for all Nebula widgets ?
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Nicolas
>>>>>>>>>>>
>>>>>>>>>>> Tom Schindl a écrit :
>>>>>>>>>>>> Implementation ready and uploaded but it was really an easy
>>>>>>>>>>>> one :-)
>>>>>>>>>>>>
>>>>>>>>>>>> Some questions on the GridItem though:
>>>>>>>>>>>>
>>>>>>>>>>>> - Why can't one set the Item back to default behaviour (showing
>>>>>>>>>>>> row-numbers)
>>>>>>>>>>>>
>>>>>>>>>>>> - Would it be possible to implement beside setting a text
>>>>>>>>>>>> also an image,
>>>>>>>>>>>> color, font, ...?
>>>>>>>>>>>>
>>>>>>>>>>>> This would be a cool feature I think e.g. highlighting
>>>>>>>>>>>> rows with an
>>>>>>>>>>>> error marker?
>>>>>>>>>>>>
>>>>>>>>>>>> - I suppose that the Grid knows which items are currently
>>>>>>>>>>>> visible? Is
>>>>>>>>>>>> there some listener available to track which items are
>>>>>>>>>>>> scrolled out of
>>>>>>>>>>>> view. This would be extremely helpful when working with
>>>>>>>>>>>> OS-Resources(Images, Fonts, Colors) because when not
>>>>>>>>>>>> needed anymore
>>>>>>>>>>>> they could be disposed
>>>>>>>>>>>>
>>>>>>>>>>>> I think the GridColumnLabelProvider could be enhanced to
>>>>>>>>>>>> take care of such resources and this would make GridViewer
>>>>>>>>>>>> and Grid even more interesting for people currently facing
>>>>>>>>>>>> problems with SWT-Table/Tree because there's no easy way to
>>>>>>>>>>>> determine this (see
>>>>>>>>>>>> http://tom-eclipse-dev.blogspot.com/2007/01/what-items-are-v isible-in-tabletree.html).
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Tom
>>>>>>>>>>>>
>>>>>>>>>>>> Tom Schindl schrieb:
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> You are right Chris that's what I meant I haven't thought
>>>>>>>>>>>>> about this carefully enough. Hence the request for a bug
>>>>>>>>>>>>> report.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Maybe we could provide a standard label provider ontop of
>>>>>>>>>>>>> ColumnLabelProvider. I'm against adding something depending
>>>>>>>>>>>>> on the old API using the hack below :-)
>>>>>>>>>>>>>
>>>>>>>>>>>>> I logged
>>>>>>>>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=188430 and
>>>>>>>>>>>>> will provide an example implementation.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Tom
>>>>>>>>>>>>>
|
|
|
Re: [GridViewer]How to change text of rowHeader with a labelprovider ? [message #583000 is a reply to message #36214] |
Mon, 11 June 2007 11:43 |
Nicolas Richeton Messages: 179 Registered: July 2009 |
Senior Member |
|
|
AFAIK SetData is only fired the first time an item is scrolled into
view. This can be used to allocate resources only if we clear each item
on ClearData. The only drawback is that there will be a lot more
SetData events than usual and probably a performance impact (for
example, if items are created from a database).
Paint is fired each time an item is painted. This is a better place to
allocate resources, if it was not already done. It allows to keep
internal item data between paints.
Maybe we need some intermediate events, something like ScrollIn (item
becomes visible) / ScrollOut (item is no longer visible).
--
Nicolas.
Chris Gross a écrit :
> Right. We would need to add a new callback to compliment SetData.
> Perhaps ClearData? The constant will have to live on Grid (and
> Gallery). This feels like a smaller, better change.
>
> -Chris
>
> Tom Schindl wrote:
>> Well SetData-callback informs you that Row is scrolled into view but
>> what do we send when a Row is scrolled out of view? This is the
>> interesting event we should get to clean up resources, not?
>>
>> Tom
>>
>> Chris Gross schrieb:
>>> I did add virtual support to Grid recently. I modeled the virtual
>>> support in Grid exactly after Table/Tree. And I think these
>>> requirements that we're talking about (maintaining fewer resources)
>>> really maps right in with the way virtual support is designed. The
>>> SetData callback is just saying someone needs the values of this item
>>> - please go fill them in.
>>>
>>> I'm certain we could expose a method to return the visible rows
>>> (along with a listener when this value changes) but I'd rather not
>>> have to if there is an existing mechanism that seems designed to
>>> solve the same problem.
>>>
>>> -Chris
>>>
>>> Tom Schindl wrote:
>>>> Sorry for coming back after such a long time.
>>>>
>>>> Well if we I don't think we need to depend on any Viewer-Code I need
>>>> to investigate but for Tables/Trees with many columns this might
>>>> still be an issue.
>>>>
>>>> The other thing that makes neverous is that the SetData-Callback in
>>>> SWT-Controls get's a different meaning in Grid which might provoke
>>>> problems with the AbstractTable/TreeViewer in future what do you do
>>>> if you add VIRTUAL-Support to Grid?
>>>>
>>>> With all the work done in 190252 is there maybe already internal-API
>>>> to query the currently visible GridCells?
>>>>
>>>> Tom
>>>>
>>>> Chris Gross schrieb:
>>>>> True the SetData callback isn't cell specific but is that
>>>>> absolutely needed? The row based callback should still allow you
>>>>> to manage resources enough so that only a reasonable number around
>>>>> at one time.
>>>>> If we made this cell specific would we require the use of a
>>>>> viewer? I don't quite understand how it would work. We would
>>>>> still need the widget layer to provide the basic callbacks
>>>>> including information on what columns are visible/invisible. Seems
>>>>> a little more complicated. If we stay with SetData, then it would
>>>>> work well with existing JFace virtual support.
>>>>>
>>>>> Regards,
>>>>> -Chris
>>>>>
>>>>>
>>>>>
>>>>> Tom Schindl wrote:
>>>>>> Hi,
>>>>>>
>>>>>> One more note Chris.
>>>>>>
>>>>>> The SetData callback has the problem that it only informs you when
>>>>>> rows are scrolled into view but it's not working for
>>>>>> cells/columns. I think nebula controls should not suffer from the
>>>>>> same problem SWT-Controls do because they don't support the
>>>>>> concept of cells (which is already solved in your Grid => JFace
>>>>>> for key-navigation is very simple in contrast to
>>>>>> SWT-Implementation :-).
>>>>>>
>>>>>> I take the point of view that the Listener should work on top of
>>>>>> the Cell-Concept instead of the only row-based SWT-Concept.
>>>>>> Wouldn't it make sense that all columnbased controls implement
>>>>>> the same interface?
>>>>>>
>>>>>> Tom
>>>>>>
>>>>>>
>>>>>> Tom Schindl schrieb:
>>>>>>> I like this, no I love this :-), staying as near to SWT as
>>>>>>> possible is a great thing. The only thing I ask myself is where
>>>>>>> you get the constant from if you don't have a single common
>>>>>>> package all these things live in.
>>>>>>>
>>>>>>> I understand your point of view that there should not be too many
>>>>>>> dependencies and controls may evolve differently but defining a
>>>>>>> common set of things in not a bad thing and to get really usable
>>>>>>> it doesn't matter because once a control declared something API
>>>>>>> it has to stay for ever
>>>>>>> (http://inside-swt.blogspot.com/2007/02/its-end-of-era.html).
>>>>>>>
>>>>>>> Tom
>>>>>>>
>>>>>>> Chris Gross schrieb:
>>>>>>>> I think we might as well discuss it here for now.
>>>>>>>>
>>>>>>>> As I started to think about this some more I realize that this
>>>>>>>> is very similar to virtual support already implemented in
>>>>>>>> Table/Tree. Table will use the SWT.SetData callback when an
>>>>>>>> item is scrolled into view. The big difference is that it
>>>>>>>> doesn't offer a way to clear items as they scroll out of view.
>>>>>>>> You can use Table#clear to reset an item and the SWT.SetData
>>>>>>>> will be called as necessary again, but theres no way (AFAIK)
>>>>>>>> that you can automatically clear an item after it goes out of
>>>>>>>> view. Perhaps we should just add that single feature and work
>>>>>>>> with the existing SWT.VIRTUAL pattern.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> -Chris
>>>>>>>>
>>>>>>>> Nicolas Richeton wrote:
>>>>>>>>> I believe that using the same method signature but no common
>>>>>>>>> code is OK for now.
>>>>>>>>> But some core package may be usefull in the future too. For
>>>>>>>>> example, I used AbstractRenderer and TreeNodeToggleRenderer in
>>>>>>>>> the Gallery widget so this code is duplicated in PGroup, Grid
>>>>>>>>> and Gallery...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This API will be used to limit the number of handles required
>>>>>>>>> when using different images, styles and color for each item
>>>>>>>>> in Grid, Gallery, Tree and Tables.
>>>>>>>>>
>>>>>>>>> I think we need :
>>>>>>>>> * A listener for items that are scrolled out of the visible
>>>>>>>>> area. Interesting informations are the item and maybe some data
>>>>>>>>> on the way it was hidden (parent was collapsed or scrollbar
>>>>>>>>> were moved)
>>>>>>>>>
>>>>>>>>> * A method which returns all the visible items.
>>>>>>>>> Table already has getTopIndex() that can be used together with
>>>>>>>>> widget and item sizes to calculate the visible items. But this
>>>>>>>>> approach cannot be used with other widgets where any item can
>>>>>>>>> be expanded/collapsed.
>>>>>>>>>
>>>>>>>>> * We don't need a listener for items which are becoming visible
>>>>>>>>> because the paint event can be used for this.
>>>>>>>>>
>>>>>>>>> May be we should use bugzilla to discuss of this ?
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Nicolas
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Chris Gross a écrit :
>>>>>>>>>> Hmm... there could be potential problems if the resources are
>>>>>>>>>> not available even though the rows are out of view. Off the
>>>>>>>>>> top of my head I know that GridColumn#pack will need to know
>>>>>>>>>> the size of the contents of each cell. So that would suffer
>>>>>>>>>> (but probably not a big deal). There might be other problems.
>>>>>>>>>> I have to think a little.
>>>>>>>>>>
>>>>>>>>>> I think its a good idea to try to ensure that Nebula widgets
>>>>>>>>>> try to share common API but I'm not sure its a good idea to
>>>>>>>>>> formalize that in an interface. Where would that interface
>>>>>>>>>> live? In some core package and then in some core plugin/jar?
>>>>>>>>>> That would make things a little more messy/complicated. What
>>>>>>>>>> happens when the different widgets start having diverging
>>>>>>>>>> requirements? With each Nebula widget potentially going in
>>>>>>>>>> different directions I think any common interfaces could
>>>>>>>>>> become constrictive. If we have a real concrete use-case for
>>>>>>>>>> requiring the interface then I could probably be convinced.
>>>>>>>>>>
>>>>>>>>>> What do we need in the API?
>>>>>>>>>>
>>>>>>>>>> -Chris
>>>>>>>>>>
>>>>>>>>>> Tom Schindl wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> This would make sense the only problem I currently see is
>>>>>>>>>>> that Nebula isn't structured this way but I could be wrong
>>>>>>>>>>> though.
>>>>>>>>>>>
>>>>>>>>>>> But I definately agree that there should be a central
>>>>>>>>>>> position in nebula providing interfaces, ... like this.
>>>>>>>>>>>
>>>>>>>>>>> I'd propose something like "nebula.core" to hold things like
>>>>>>>>>>> this? For your gallery widget I think this a very important
>>>>>>>>>>> thing because your widget is by its purpose allocating a lot
>>>>>>>>>>> of system resources.
>>>>>>>>>>>
>>>>>>>>>>> Tom
>>>>>>>>>>>
>>>>>>>>>>> Nicolas Richeton schrieb:
>>>>>>>>>>>> About the listener for visible/invisible items :
>>>>>>>>>>>>
>>>>>>>>>>>> I want to add this feature to the gallery widget. Maybe we
>>>>>>>>>>>> could use the same API for all Nebula widgets ?
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Nicolas
>>>>>>>>>>>>
>>>>>>>>>>>> Tom Schindl a écrit :
>>>>>>>>>>>>> Implementation ready and uploaded but it was really an easy
>>>>>>>>>>>>> one :-)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Some questions on the GridItem though:
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Why can't one set the Item back to default behaviour
>>>>>>>>>>>>> (showing
>>>>>>>>>>>>> row-numbers)
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Would it be possible to implement beside setting a text
>>>>>>>>>>>>> also an image,
>>>>>>>>>>>>> color, font, ...?
>>>>>>>>>>>>>
>>>>>>>>>>>>> This would be a cool feature I think e.g. highlighting
>>>>>>>>>>>>> rows with an
>>>>>>>>>>>>> error marker?
>>>>>>>>>>>>>
>>>>>>>>>>>>> - I suppose that the Grid knows which items are currently
>>>>>>>>>>>>> visible? Is
>>>>>>>>>>>>> there some listener available to track which items are
>>>>>>>>>>>>> scrolled out of
>>>>>>>>>>>>> view. This would be extremely helpful when working with
>>>>>>>>>>>>> OS-Resources(Images, Fonts, Colors) because when not
>>>>>>>>>>>>> needed anymore
>>>>>>>>>>>>> they could be disposed
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think the GridColumnLabelProvider could be enhanced to
>>>>>>>>>>>>> take care of such resources and this would make GridViewer
>>>>>>>>>>>>> and Grid even more interesting for people currently facing
>>>>>>>>>>>>> problems with SWT-Table/Tree because there's no easy way to
>>>>>>>>>>>>> determine this (see
>>>>>>>>>>>>> http://tom-eclipse-dev.blogspot.com/2007/01/what-items-are-v isible-in-tabletree.html).
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Tom
>>>>>>>>>>>>>
>>>>>>>>>>>>> Tom Schindl schrieb:
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You are right Chris that's what I meant I haven't thought
>>>>>>>>>>>>>> about this carefully enough. Hence the request for a bug
>>>>>>>>>>>>>> report.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Maybe we could provide a standard label provider ontop of
>>>>>>>>>>>>>> ColumnLabelProvider. I'm against adding something
>>>>>>>>>>>>>> depending on the old API using the hack below :-)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I logged
>>>>>>>>>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=188430 and
>>>>>>>>>>>>>> will provide an example implementation.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Tom
>>>>>>>>>>>>>>
|
|
|
Re: [GridViewer]How to change text of rowHeader with a labelprovider ? [message #583023 is a reply to message #36248] |
Mon, 11 June 2007 17:37 |
Chris Gross Messages: 471 Registered: July 2009 |
Senior Member |
|
|
I'm thinking that the actual clear()-ing of the item data will not occur
automatically. They can listen to ClearData and call clear() if they
want. If they don't call clear then they wont get another SetData
event. So it should be relatively performance neutral.
It should be noted that SetData is sent the first time data is requested
for an item. This can be because the item was scrolled into view or
because some other class called Item#getText() or any other getter. The
makes the virtual nature much more robust than just a
scroll-in/scroll-out feature.
Regards,
-Chris
Nicolas Richeton wrote:
> AFAIK SetData is only fired the first time an item is scrolled into
> view. This can be used to allocate resources only if we clear each item
> on ClearData. The only drawback is that there will be a lot more
> SetData events than usual and probably a performance impact (for
> example, if items are created from a database).
>
> Paint is fired each time an item is painted. This is a better place to
> allocate resources, if it was not already done. It allows to keep
> internal item data between paints.
>
> Maybe we need some intermediate events, something like ScrollIn (item
> becomes visible) / ScrollOut (item is no longer visible).
>
> --
> Nicolas.
>
>
> Chris Gross a écrit :
>> Right. We would need to add a new callback to compliment SetData.
>> Perhaps ClearData? The constant will have to live on Grid (and
>> Gallery). This feels like a smaller, better change.
>>
>> -Chris
>>
>> Tom Schindl wrote:
>>> Well SetData-callback informs you that Row is scrolled into view but
>>> what do we send when a Row is scrolled out of view? This is the
>>> interesting event we should get to clean up resources, not?
>>>
>>> Tom
>>>
>>> Chris Gross schrieb:
>>>> I did add virtual support to Grid recently. I modeled the virtual
>>>> support in Grid exactly after Table/Tree. And I think these
>>>> requirements that we're talking about (maintaining fewer resources)
>>>> really maps right in with the way virtual support is designed. The
>>>> SetData callback is just saying someone needs the values of this
>>>> item - please go fill them in.
>>>>
>>>> I'm certain we could expose a method to return the visible rows
>>>> (along with a listener when this value changes) but I'd rather not
>>>> have to if there is an existing mechanism that seems designed to
>>>> solve the same problem.
>>>>
>>>> -Chris
>>>>
>>>> Tom Schindl wrote:
>>>>> Sorry for coming back after such a long time.
>>>>>
>>>>> Well if we I don't think we need to depend on any Viewer-Code I
>>>>> need to investigate but for Tables/Trees with many columns this
>>>>> might still be an issue.
>>>>>
>>>>> The other thing that makes neverous is that the SetData-Callback in
>>>>> SWT-Controls get's a different meaning in Grid which might provoke
>>>>> problems with the AbstractTable/TreeViewer in future what do you do
>>>>> if you add VIRTUAL-Support to Grid?
>>>>>
>>>>> With all the work done in 190252 is there maybe already
>>>>> internal-API to query the currently visible GridCells?
>>>>>
>>>>> Tom
>>>>>
>>>>> Chris Gross schrieb:
>>>>>> True the SetData callback isn't cell specific but is that
>>>>>> absolutely needed? The row based callback should still allow you
>>>>>> to manage resources enough so that only a reasonable number around
>>>>>> at one time.
>>>>>> If we made this cell specific would we require the use of a
>>>>>> viewer? I don't quite understand how it would work. We would
>>>>>> still need the widget layer to provide the basic callbacks
>>>>>> including information on what columns are visible/invisible.
>>>>>> Seems a little more complicated. If we stay with SetData, then it
>>>>>> would work well with existing JFace virtual support.
>>>>>>
>>>>>> Regards,
>>>>>> -Chris
>>>>>>
>>>>>>
>>>>>>
>>>>>> Tom Schindl wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> One more note Chris.
>>>>>>>
>>>>>>> The SetData callback has the problem that it only informs you
>>>>>>> when rows are scrolled into view but it's not working for
>>>>>>> cells/columns. I think nebula controls should not suffer from the
>>>>>>> same problem SWT-Controls do because they don't support the
>>>>>>> concept of cells (which is already solved in your Grid => JFace
>>>>>>> for key-navigation is very simple in contrast to
>>>>>>> SWT-Implementation :-).
>>>>>>>
>>>>>>> I take the point of view that the Listener should work on top of
>>>>>>> the Cell-Concept instead of the only row-based SWT-Concept.
>>>>>>> Wouldn't it make sense that all columnbased controls implement
>>>>>>> the same interface?
>>>>>>>
>>>>>>> Tom
>>>>>>>
>>>>>>>
>>>>>>> Tom Schindl schrieb:
>>>>>>>> I like this, no I love this :-), staying as near to SWT as
>>>>>>>> possible is a great thing. The only thing I ask myself is where
>>>>>>>> you get the constant from if you don't have a single common
>>>>>>>> package all these things live in.
>>>>>>>>
>>>>>>>> I understand your point of view that there should not be too
>>>>>>>> many dependencies and controls may evolve differently but
>>>>>>>> defining a common set of things in not a bad thing and to get
>>>>>>>> really usable it doesn't matter because once a control declared
>>>>>>>> something API it has to stay for ever
>>>>>>>> (http://inside-swt.blogspot.com/2007/02/its-end-of-era.html).
>>>>>>>>
>>>>>>>> Tom
>>>>>>>>
>>>>>>>> Chris Gross schrieb:
>>>>>>>>> I think we might as well discuss it here for now.
>>>>>>>>>
>>>>>>>>> As I started to think about this some more I realize that this
>>>>>>>>> is very similar to virtual support already implemented in
>>>>>>>>> Table/Tree. Table will use the SWT.SetData callback when an
>>>>>>>>> item is scrolled into view. The big difference is that it
>>>>>>>>> doesn't offer a way to clear items as they scroll out of view.
>>>>>>>>> You can use Table#clear to reset an item and the SWT.SetData
>>>>>>>>> will be called as necessary again, but theres no way (AFAIK)
>>>>>>>>> that you can automatically clear an item after it goes out of
>>>>>>>>> view. Perhaps we should just add that single feature and work
>>>>>>>>> with the existing SWT.VIRTUAL pattern.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> -Chris
>>>>>>>>>
>>>>>>>>> Nicolas Richeton wrote:
>>>>>>>>>> I believe that using the same method signature but no common
>>>>>>>>>> code is OK for now.
>>>>>>>>>> But some core package may be usefull in the future too. For
>>>>>>>>>> example, I used AbstractRenderer and TreeNodeToggleRenderer in
>>>>>>>>>> the Gallery widget so this code is duplicated in PGroup, Grid
>>>>>>>>>> and Gallery...
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This API will be used to limit the number of handles required
>>>>>>>>>> when using different images, styles and color for each item
>>>>>>>>>> in Grid, Gallery, Tree and Tables.
>>>>>>>>>>
>>>>>>>>>> I think we need :
>>>>>>>>>> * A listener for items that are scrolled out of the visible
>>>>>>>>>> area. Interesting informations are the item and maybe some
>>>>>>>>>> data on the way it was hidden (parent was collapsed or
>>>>>>>>>> scrollbar were moved)
>>>>>>>>>>
>>>>>>>>>> * A method which returns all the visible items.
>>>>>>>>>> Table already has getTopIndex() that can be used together with
>>>>>>>>>> widget and item sizes to calculate the visible items. But this
>>>>>>>>>> approach cannot be used with other widgets where any item can
>>>>>>>>>> be expanded/collapsed.
>>>>>>>>>>
>>>>>>>>>> * We don't need a listener for items which are becoming
>>>>>>>>>> visible because the paint event can be used for this.
>>>>>>>>>>
>>>>>>>>>> May be we should use bugzilla to discuss of this ?
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Nicolas
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Chris Gross a écrit :
>>>>>>>>>>> Hmm... there could be potential problems if the resources are
>>>>>>>>>>> not available even though the rows are out of view. Off the
>>>>>>>>>>> top of my head I know that GridColumn#pack will need to know
>>>>>>>>>>> the size of the contents of each cell. So that would suffer
>>>>>>>>>>> (but probably not a big deal). There might be other
>>>>>>>>>>> problems. I have to think a little.
>>>>>>>>>>>
>>>>>>>>>>> I think its a good idea to try to ensure that Nebula widgets
>>>>>>>>>>> try to share common API but I'm not sure its a good idea to
>>>>>>>>>>> formalize that in an interface. Where would that interface
>>>>>>>>>>> live? In some core package and then in some core
>>>>>>>>>>> plugin/jar? That would make things a little more
>>>>>>>>>>> messy/complicated. What happens when the different widgets
>>>>>>>>>>> start having diverging requirements? With each Nebula widget
>>>>>>>>>>> potentially going in different directions I think any common
>>>>>>>>>>> interfaces could become constrictive. If we have a real
>>>>>>>>>>> concrete use-case for requiring the interface then I could
>>>>>>>>>>> probably be convinced.
>>>>>>>>>>>
>>>>>>>>>>> What do we need in the API?
>>>>>>>>>>>
>>>>>>>>>>> -Chris
>>>>>>>>>>>
>>>>>>>>>>> Tom Schindl wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> This would make sense the only problem I currently see is
>>>>>>>>>>>> that Nebula isn't structured this way but I could be wrong
>>>>>>>>>>>> though.
>>>>>>>>>>>>
>>>>>>>>>>>> But I definately agree that there should be a central
>>>>>>>>>>>> position in nebula providing interfaces, ... like this.
>>>>>>>>>>>>
>>>>>>>>>>>> I'd propose something like "nebula.core" to hold things like
>>>>>>>>>>>> this? For your gallery widget I think this a very important
>>>>>>>>>>>> thing because your widget is by its purpose allocating a lot
>>>>>>>>>>>> of system resources.
>>>>>>>>>>>>
>>>>>>>>>>>> Tom
>>>>>>>>>>>>
>>>>>>>>>>>> Nicolas Richeton schrieb:
>>>>>>>>>>>>> About the listener for visible/invisible items :
>>>>>>>>>>>>>
>>>>>>>>>>>>> I want to add this feature to the gallery widget. Maybe we
>>>>>>>>>>>>> could use the same API for all Nebula widgets ?
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Nicolas
>>>>>>>>>>>>>
>>>>>>>>>>>>> Tom Schindl a écrit :
>>>>>>>>>>>>>> Implementation ready and uploaded but it was really an
>>>>>>>>>>>>>> easy one :-)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Some questions on the GridItem though:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - Why can't one set the Item back to default behaviour
>>>>>>>>>>>>>> (showing
>>>>>>>>>>>>>> row-numbers)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - Would it be possible to implement beside setting a text
>>>>>>>>>>>>>> also an image,
>>>>>>>>>>>>>> color, font, ...?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This would be a cool feature I think e.g. highlighting
>>>>>>>>>>>>>> rows with an
>>>>>>>>>>>>>> error marker?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - I suppose that the Grid knows which items are currently
>>>>>>>>>>>>>> visible? Is
>>>>>>>>>>>>>> there some listener available to track which items are
>>>>>>>>>>>>>> scrolled out of
>>>>>>>>>>>>>> view. This would be extremely helpful when working with
>>>>>>>>>>>>>> OS-Resources(Images, Fonts, Colors) because when not
>>>>>>>>>>>>>> needed anymore
>>>>>>>>>>>>>> they could be disposed
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think the GridColumnLabelProvider could be enhanced to
>>>>>>>>>>>>>> take care of such resources and this would make GridViewer
>>>>>>>>>>>>>> and Grid even more interesting for people currently facing
>>>>>>>>>>>>>> problems with SWT-Table/Tree because there's no easy way
>>>>>>>>>>>>>> to determine this (see
>>>>>>>>>>>>>> http://tom-eclipse-dev.blogspot.com/2007/01/what-items-are-v isible-in-tabletree.html).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Tom
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Tom Schindl schrieb:
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You are right Chris that's what I meant I haven't thought
>>>>>>>>>>>>>>> about this carefully enough. Hence the request for a bug
>>>>>>>>>>>>>>> report.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Maybe we could provide a standard label provider ontop of
>>>>>>>>>>>>>>> ColumnLabelProvider. I'm against adding something
>>>>>>>>>>>>>>> depending on the old API using the hack below :-)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I logged
>>>>>>>>>>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=188430 and
>>>>>>>>>>>>>>> will provide an example implementation.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Tom
>>>>>>>>>>>>>>>
|
|
|
Goto Forum:
Current Time: Thu Sep 19 12:25:30 GMT 2024
Powered by FUDForum. Page generated in 0.09608 seconds
|