Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Nebula » [GridViewer]How to change text of rowHeader with a labelprovider ?
[GridViewer]How to change text of rowHeader with a labelprovider ? [message #35065] Tue, 22 May 2007 10:14 Go to next message
Defert Philippe is currently offline Defert PhilippeFriend
Messages: 62
Registered: July 2009
Member
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 #35102 is a reply to message #35065] Tue, 22 May 2007 11:11 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6651
Registered: July 2009
Senior Member
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 #35132 is a reply to message #35102] Tue, 22 May 2007 13:04 Go to previous messageGo to next message
Defert Philippe is currently offline Defert PhilippeFriend
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 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
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 Go to previous messageGo to next message
Chris Gross is currently offline Chris GrossFriend
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 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
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 #35267 is a reply to message #35246] Tue, 22 May 2007 20:04 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6651
Registered: July 2009
Senior Member
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 #35290 is a reply to message #35267] Wed, 23 May 2007 10:17 Go to previous messageGo to next message
Nicolas Richeton is currently offline Nicolas RichetonFriend
Messages: 179
Registered: July 2009
Senior Member
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 #35321 is a reply to message #35290] Wed, 23 May 2007 10:28 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6651
Registered: July 2009
Senior Member
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 #35356 is a reply to message #35267] Wed, 23 May 2007 15:21 Go to previous messageGo to next message
Chris Gross is currently offline Chris GrossFriend
Messages: 253
Registered: July 2009
Senior Member
> - Why can't one set the Item back to default behaviour (showing
> row-numbers)
This was the original intention but I put a defensive null check in
GridItem#setHeaderText that I shouldn't have. By calling
GridItem.setHeaderText(null) the default behavior should return. I've
removed the null check so it should work in the next nightly build.

> - Would it be possible to implement beside setting a text also an image,
> color, font, ...?
Thats certainly possible and you could do it now if you wrote your own
renderer for the row header. If enough people ask for it I'll put it in
the base Grid.

> - 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
Follow up in other message in thread...
Re: [GridViewer]How to change text of rowHeader with a labelprovider ? [message #35389 is a reply to message #35321] Wed, 23 May 2007 15:33 Go to previous messageGo to next message
Chris Gross is currently offline Chris GrossFriend
Messages: 253
Registered: July 2009
Senior Member
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 #35424 is a reply to message #35389] Thu, 24 May 2007 16:56 Go to previous messageGo to next message
Nicolas Richeton is currently offline Nicolas RichetonFriend
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 Go to previous messageGo to next message
Chris Gross is currently offline Chris GrossFriend
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 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
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 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
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 Go to previous messageGo to next message
Chris Gross is currently offline Chris GrossFriend
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 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
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 Go to previous messageGo to next message
Chris Gross is currently offline Chris GrossFriend
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 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
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 Go to previous messageGo to next message
Chris Gross is currently offline Chris GrossFriend
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 Go to previous messageGo to next message
Nicolas Richeton is currently offline Nicolas RichetonFriend
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 Go to previous message
Chris Gross is currently offline Chris GrossFriend
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 #582445 is a reply to message #35065] Tue, 22 May 2007 11:11 Go to previous message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6651
Registered: July 2009
Senior Member
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 #582454 is a reply to message #35102] Tue, 22 May 2007 13:04 Go to previous message
Defert Philippe is currently offline Defert PhilippeFriend
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 Go to previous message
Thomas Schindl is currently offline Thomas SchindlFriend
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 Go to previous message
Chris Gross is currently offline Chris GrossFriend
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 Go to previous message
Thomas Schindl is currently offline Thomas SchindlFriend
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 #582518 is a reply to message #35246] Tue, 22 May 2007 20:04 Go to previous message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6651
Registered: July 2009
Senior Member
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 #582528 is a reply to message #35267] Wed, 23 May 2007 10:17 Go to previous message
Nicolas Richeton is currently offline Nicolas RichetonFriend
Messages: 179
Registered: July 2009
Senior Member
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 #582542 is a reply to message #35290] Wed, 23 May 2007 10:28 Go to previous message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6651
Registered: July 2009
Senior Member
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 #582558 is a reply to message #35267] Wed, 23 May 2007 15:21 Go to previous message
Chris Gross is currently offline Chris GrossFriend
Messages: 471
Registered: July 2009
Senior Member
> - Why can't one set the Item back to default behaviour (showing
> row-numbers)
This was the original intention but I put a defensive null check in
GridItem#setHeaderText that I shouldn't have. By calling
GridItem.setHeaderText(null) the default behavior should return. I've
removed the null check so it should work in the next nightly build.

> - Would it be possible to implement beside setting a text also an image,
> color, font, ...?
Thats certainly possible and you could do it now if you wrote your own
renderer for the row header. If enough people ask for it I'll put it in
the base Grid.

> - 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
Follow up in other message in thread...
Re: [GridViewer]How to change text of rowHeader with a labelprovider ? [message #582578 is a reply to message #35321] Wed, 23 May 2007 15:33 Go to previous message
Chris Gross is currently offline Chris GrossFriend
Messages: 471
Registered: July 2009
Senior Member
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 #582589 is a reply to message #35389] Thu, 24 May 2007 16:56 Go to previous message
Nicolas Richeton is currently offline Nicolas RichetonFriend
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 Go to previous message
Chris Gross is currently offline Chris GrossFriend
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 Go to previous message
Thomas Schindl is currently offline Thomas SchindlFriend
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 Go to previous message
Thomas Schindl is currently offline Thomas SchindlFriend
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 Go to previous message
Chris Gross is currently offline Chris GrossFriend
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 Go to previous message
Thomas Schindl is currently offline Thomas SchindlFriend
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 Go to previous message
Chris Gross is currently offline Chris GrossFriend
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 Go to previous message
Thomas Schindl is currently offline Thomas SchindlFriend
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 Go to previous message
Chris Gross is currently offline Chris GrossFriend
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 Go to previous message
Nicolas Richeton is currently offline Nicolas RichetonFriend
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 Go to previous message
Chris Gross is currently offline Chris GrossFriend
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
>>>>>>>>>>>>>>>
Previous Topic:Multicolumn sorting ...
Next Topic:cell selection
Goto Forum:
  


Current Time: Fri Mar 29 00:04:37 GMT 2024

Powered by FUDForum. Page generated in 0.09391 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top