Home » Eclipse Projects » Nebula » Nebula components questions
| Nebula components questions [message #21612] |
Tue, 02 January 2007 19:37  |
Eclipse User |
|
|
|
Originally posted by: spoon.bender.org
I am wondering if there is an online table that compares the features of Grid,
CTableTree and CompositeTable? I'm not sure which is the right one to use or
the features/limitations of each.
I'm also wondering if Nebula components have their API javadoc online
somewhere, like other packages?
http://help.eclipse.org/help32/nftopic/org.eclipse.platform. doc.isv/reference/api/index.html
Finally, I wonder if these nebula components can use native headers so they
look native on different OSes? I notice in the screenshots the headers are
not native. Is there a way to use the XP looking TableHeaders on XP, and the
MacOSX ones on OSX and GTK theme aware ones on GTK? Maybe this requires SWT
to make a Tableheader class (will this be in 3.3? Will nebula offer options to
use it?)
I'm particularly looking for the right control to use for a stock tracking
tree grid, which updates very regularly, has a lot of rows and leaves, and
re-sorts very regularly, so all these updates need to be fast and smart
without excess screen redraws (don't redraw things that don't move due to
re-sort every second, just the things that do). Also, are SWT-Tree features
like a header sort indicator and sorted column colors, alternating row colors
(like OS native which really help readability) supported on any of these
controls?
Thanks
|
|
|
| Re: Nebula components questions [message #21659 is a reply to message #21612] |
Tue, 02 January 2007 19:52  |
 Jeremy Dowdall
Messages: 181
Registered: July 2009 |
Senior Member |
|
|
Just a quick note here to point out that CTableTree does use a native
SWT table for its header. The screenshot shows it running on GTK with
the ClearLooks theme - the table contained in the cell (col 3, row 5)
shows an actual native table for comparison.
The toggle is not native, but does change to try and emulate three major
platforms as best it can (carbon, gtk, win32)
Yuri Geller wrote:
> I am wondering if there is an online table that compares the features of Grid,
> CTableTree and CompositeTable? I'm not sure which is the right one to use or
> the features/limitations of each.
>
> I'm also wondering if Nebula components have their API javadoc online
> somewhere, like other packages?
> http://help.eclipse.org/help32/nftopic/org.eclipse.platform. doc.isv/reference/api/index.html
>
> Finally, I wonder if these nebula components can use native headers so they
> look native on different OSes? I notice in the screenshots the headers are
> not native. Is there a way to use the XP looking TableHeaders on XP, and the
> MacOSX ones on OSX and GTK theme aware ones on GTK? Maybe this requires SWT
> to make a Tableheader class (will this be in 3.3? Will nebula offer options to
> use it?)
>
> I'm particularly looking for the right control to use for a stock tracking
> tree grid, which updates very regularly, has a lot of rows and leaves, and
> re-sorts very regularly, so all these updates need to be fast and smart
> without excess screen redraws (don't redraw things that don't move due to
> re-sort every second, just the things that do). Also, are SWT-Tree features
> like a header sort indicator and sorted column colors, alternating row colors
> (like OS native which really help readability) supported on any of these
> controls?
>
> Thanks
>
>
|
|
|
| Re: Nebula components questions [message #21704 is a reply to message #21612] |
Tue, 02 January 2007 22:26 |
Dave Orme
Messages: 424
Registered: July 2009 |
Senior Member |
|
|
Yuri Geller wrote:
> I am wondering if there is an online table that compares the features of Grid,
> CTableTree and CompositeTable? I'm not sure which is the right one to use or
> the features/limitations of each.
Not yet.
Maybe the three authors could meet at EclipseCon and hash this out? I
can see that being useful to folks.
> I'm also wondering if Nebula components have their API javadoc online
> somewhere, like other packages?
> http://help.eclipse.org/help32/nftopic/org.eclipse.platform. doc.isv/reference/api/index.html
Not online, but each download includes a JavaDoc folder with the JavaDoc
HTML files already built.
> Finally, I wonder if these nebula components can use native headers so they
> look native on different OSes? I notice in the screenshots the headers are
> not native. Is there a way to use the XP looking TableHeaders on XP, and the
> MacOSX ones on OSX and GTK theme aware ones on GTK? Maybe this requires SWT
> to make a Tableheader class (will this be in 3.3? Will nebula offer options to
> use it?)
CompositeTable would require SWT to make a Tableheader class. If SWT
supplied a TableHeader class, you could use it with CompositeTable right
now. (With CompositeTable, the header and row are defined by arbitrary
SWT controls that you supply, which could include a TableHeader class.)
> I'm particularly looking for the right control to use for a stock tracking
> tree grid, which updates very regularly, has a lot of rows and leaves, and
> re-sorts very regularly, so all these updates need to be fast and smart
> without excess screen redraws (don't redraw things that don't move due to
> re-sort every second, just the things that do). Also, are SWT-Tree features
> like a header sort indicator and sorted column colors, alternating row colors
> (like OS native which really help readability) supported on any of these
> controls?
If you need tree capabilities, CompositeTable can't (currently) help.
But if you just need a table that only asks for data that is actually
visible, CompositeTable might be right for you.
Best regards,
Dave Orme
|
|
|
| Re: Nebula components questions [message #22107 is a reply to message #21612] |
Thu, 04 January 2007 16:30 |
Chris Gross
Messages: 253
Registered: July 2009 |
Senior Member |
|
|
Just a question... why not use the normal SWT Table or Tree?
-Chris
Yuri Geller wrote:
> I am wondering if there is an online table that compares the features of Grid,
> CTableTree and CompositeTable? I'm not sure which is the right one to use or
> the features/limitations of each.
>
> I'm also wondering if Nebula components have their API javadoc online
> somewhere, like other packages?
> http://help.eclipse.org/help32/nftopic/org.eclipse.platform. doc.isv/reference/api/index.html
>
> Finally, I wonder if these nebula components can use native headers so they
> look native on different OSes? I notice in the screenshots the headers are
> not native. Is there a way to use the XP looking TableHeaders on XP, and the
> MacOSX ones on OSX and GTK theme aware ones on GTK? Maybe this requires SWT
> to make a Tableheader class (will this be in 3.3? Will nebula offer options to
> use it?)
>
> I'm particularly looking for the right control to use for a stock tracking
> tree grid, which updates very regularly, has a lot of rows and leaves, and
> re-sorts very regularly, so all these updates need to be fast and smart
> without excess screen redraws (don't redraw things that don't move due to
> re-sort every second, just the things that do). Also, are SWT-Tree features
> like a header sort indicator and sorted column colors, alternating row colors
> (like OS native which really help readability) supported on any of these
> controls?
>
> Thanks
>
>
|
|
|
| Re: Nebula components questions [message #22151 is a reply to message #22107] |
Thu, 04 January 2007 17:12 |
| Eclipse User |
|
|
|
Originally posted by: spoon.bender.org
I have tried Ktable and it scrolled much faster than a real table, and was
much more smooth than Table especially on GTK, but seems unsupported now and
did not offer tree functionality. I don't think a real tree can ever have the
speed of a (well written) custom drawn tree. Even with a virtual tree, SWT
populates the items and leaves them populated while scrolling down and images
are left im memory. A truely virtual one would be much smarter about this.
I am looking for static headers that don't scroll off screen, leaves that
expand+hide very quickly, and all around top performance and more advanced
features than SWTTree will ever offer. Performance is king. A Table-Tree done
right, like the other toolkits have.
http://www.delphi-gems.com/VirtualTreeview/ is king I think, or like QT's.
It seems with 3 different ones, nebula is going broad, rather than deep with 1
implementation to rule them all, but I don't know where they all plan to go in
the future.
"Chris Gross" <chris.gross@us.ibm.com> wrote in message
news:enja2j$doc$5@utils.eclipse.org...
> Just a question... why not use the normal SWT Table or Tree?
>
> -Chris
>
> Yuri Geller wrote:
>> I am wondering if there is an online table that compares the features of
>> Grid, CTableTree and CompositeTable? I'm not sure which is the right one
>> to use or the features/limitations of each.
>>
>> I'm also wondering if Nebula components have their API javadoc online
>> somewhere, like other packages?
>> http://help.eclipse.org/help32/nftopic/org.eclipse.platform. doc.isv/reference/api/index.html
>>
>> Finally, I wonder if these nebula components can use native headers so they
>> look native on different OSes? I notice in the screenshots the headers are
>> not native. Is there a way to use the XP looking TableHeaders on XP, and
>> the MacOSX ones on OSX and GTK theme aware ones on GTK? Maybe this
>> requires SWT to make a Tableheader class (will this be in 3.3? Will nebula
>> offer options to use it?)
>>
>> I'm particularly looking for the right control to use for a stock tracking
>> tree grid, which updates very regularly, has a lot of rows and leaves, and
>> re-sorts very regularly, so all these updates need to be fast and smart
>> without excess screen redraws (don't redraw things that don't move due to
>> re-sort every second, just the things that do). Also, are SWT-Tree
>> features like a header sort indicator and sorted column colors, alternating
>> row colors (like OS native which really help readability) supported on any
>> of these controls?
>>
>> Thanks
|
|
|
| Re: Nebula components questions [message #22194 is a reply to message #22151] |
Thu, 04 January 2007 17:29 |
Dave Orme
Messages: 424
Registered: July 2009 |
Senior Member |
|
|
CompositeTable is designed from the ground up to meet your kind of
performance requirements.
For example, each visible row is an SWT control. Scrolling down is
implemented by shifting each control up one position, moving the top
control to the bottom, and firing a refresh event on *just* the bottom
control.
CompositeTable just doesn't care about anything that is invisible.
I'd love to have help adding tree capabilities to it. :-)
Best regards,
Dave Orme
Yuri Geller wrote:
> I have tried Ktable and it scrolled much faster than a real table, and was
> much more smooth than Table especially on GTK, but seems unsupported now and
> did not offer tree functionality. I don't think a real tree can ever have the
> speed of a (well written) custom drawn tree. Even with a virtual tree, SWT
> populates the items and leaves them populated while scrolling down and images
> are left im memory. A truely virtual one would be much smarter about this.
>
> I am looking for static headers that don't scroll off screen, leaves that
> expand+hide very quickly, and all around top performance and more advanced
> features than SWTTree will ever offer. Performance is king. A Table-Tree done
> right, like the other toolkits have.
>
> http://www.delphi-gems.com/VirtualTreeview/ is king I think, or like QT's.
>
> It seems with 3 different ones, nebula is going broad, rather than deep with 1
> implementation to rule them all, but I don't know where they all plan to go in
> the future.
>
> "Chris Gross" <chris.gross@us.ibm.com> wrote in message
> news:enja2j$doc$5@utils.eclipse.org...
>> Just a question... why not use the normal SWT Table or Tree?
>>
>> -Chris
>>
>> Yuri Geller wrote:
>>> I am wondering if there is an online table that compares the features of
>>> Grid, CTableTree and CompositeTable? I'm not sure which is the right one
>>> to use or the features/limitations of each.
>>>
>>> I'm also wondering if Nebula components have their API javadoc online
>>> somewhere, like other packages?
>>> http://help.eclipse.org/help32/nftopic/org.eclipse.platform. doc.isv/reference/api/index.html
>>>
>>> Finally, I wonder if these nebula components can use native headers so they
>>> look native on different OSes? I notice in the screenshots the headers are
>>> not native. Is there a way to use the XP looking TableHeaders on XP, and
>>> the MacOSX ones on OSX and GTK theme aware ones on GTK? Maybe this
>>> requires SWT to make a Tableheader class (will this be in 3.3? Will nebula
>>> offer options to use it?)
>>>
>>> I'm particularly looking for the right control to use for a stock tracking
>>> tree grid, which updates very regularly, has a lot of rows and leaves, and
>>> re-sorts very regularly, so all these updates need to be fast and smart
>>> without excess screen redraws (don't redraw things that don't move due to
>>> re-sort every second, just the things that do). Also, are SWT-Tree
>>> features like a header sort indicator and sorted column colors, alternating
>>> row colors (like OS native which really help readability) supported on any
>>> of these controls?
>>>
>>> Thanks
>
>
|
|
|
| Re: Nebula components questions [message #22238 is a reply to message #22194] |
Thu, 04 January 2007 19:46 |
| Eclipse User |
|
|
|
Originally posted by: spoon.bender.org
With CompositeTable, if I have 3 columns and 100 rows visible, does that mean
I have 300 composites created? If I scroll down and view 100 more rows, does
that mean 300 more composites now sit in memory? If so, that doesn't seem like
a scalable table, and seems like a design decision that will hit some pretty
hard brick walls eventually, but perhaps I misunderstand.
As I recall, KTable seemed to create 1 canvas for the size of the client area,
and abstract away the concept of cells. This minimizes memory use (only draw
to 1 small canvas) and maximize visual speed, by offloading the logic of what
to redraw to the cpu and only visually update that which needs to be updated.
The scrollbars are virtual, nothing physically scrolls, only the dataset and
the view of that dataset on the canvas.
Using that as a starting point, adding more logic to create static rows or
header rows, like the "industrial strength" QicsTable
http://www.ics.com/support/docs/qicstableapi/index.html
or cells that span multiple columns or rows, or leafs (sub rows), or embeded
controls
like wxGrid: http://www.simpol.com/guiimages/wxgrid.jpg
or wxSheet: http://www.lehigh.edu/~jrl1/wxwidgets/screenshots/wxsheetdem o.png
would be done by adding more logic to the concept of abstracted cells, while
maintaining a constant visual and interactive speed for both small and
large/complex datasets.
I'm not sure how the other nebula grids are implemented or if they could
handle all of the above (and more), but the above seems to make the most sense
to me. I'll try to find time to test them out, but that's why I originally
was looking for an information table that compared them all (how they
fundamentally work -- are they more for small or large datasets -- how
configurable are they compared to other offerings from other toolkits).
"David J. Orme" <djo@coconut-palm-software.com> wrote in message
news:enjdhr$r0m$1@utils.eclipse.org...
> CompositeTable is designed from the ground up to meet your kind of
> performance requirements.
>
> For example, each visible row is an SWT control. Scrolling down is
> implemented by shifting each control up one position, moving the top control
> to the bottom, and firing a refresh event on *just* the bottom control.
>
> CompositeTable just doesn't care about anything that is invisible.
>
> I'd love to have help adding tree capabilities to it. :-)
>
>
> Best regards,
>
> Dave Orme
>
> Yuri Geller wrote:
>> I have tried Ktable and it scrolled much faster than a real table, and was
>> much more smooth than Table especially on GTK, but seems unsupported now
>> and did not offer tree functionality. I don't think a real tree can ever
>> have the speed of a (well written) custom drawn tree. Even with a virtual
>> tree, SWT populates the items and leaves them populated while scrolling
>> down and images are left im memory. A truely virtual one would be much
>> smarter about this.
>>
>> I am looking for static headers that don't scroll off screen, leaves that
>> expand+hide very quickly, and all around top performance and more advanced
>> features than SWTTree will ever offer. Performance is king. A Table-Tree
>> done right, like the other toolkits have.
>>
>> http://www.delphi-gems.com/VirtualTreeview/ is king I think, or like QT's.
>>
>> It seems with 3 different ones, nebula is going broad, rather than deep
>> with 1 implementation to rule them all, but I don't know where they all
>> plan to go in the future.
>>
>> "Chris Gross" <chris.gross@us.ibm.com> wrote in message
>> news:enja2j$doc$5@utils.eclipse.org...
>>> Just a question... why not use the normal SWT Table or Tree?
>>>
>>> -Chris
>>>
>>> Yuri Geller wrote:
>>>> I am wondering if there is an online table that compares the features of
>>>> Grid, CTableTree and CompositeTable? I'm not sure which is the right one
>>>> to use or the features/limitations of each.
>>>>
>>>> I'm also wondering if Nebula components have their API javadoc online
>>>> somewhere, like other packages?
>>>> http://help.eclipse.org/help32/nftopic/org.eclipse.platform. doc.isv/reference/api/index.html
>>>>
>>>> Finally, I wonder if these nebula components can use native headers so
>>>> they look native on different OSes? I notice in the screenshots the
>>>> headers are not native. Is there a way to use the XP looking
>>>> TableHeaders on XP, and the MacOSX ones on OSX and GTK theme aware ones
>>>> on GTK? Maybe this requires SWT to make a Tableheader class (will this
>>>> be in 3.3? Will nebula offer options to use it?)
>>>>
>>>> I'm particularly looking for the right control to use for a stock
>>>> tracking tree grid, which updates very regularly, has a lot of rows and
>>>> leaves, and re-sorts very regularly, so all these updates need to be fast
>>>> and smart without excess screen redraws (don't redraw things that don't
>>>> move due to re-sort every second, just the things that do). Also, are
>>>> SWT-Tree features like a header sort indicator and sorted column colors,
>>>> alternating row colors (like OS native which really help readability)
>>>> supported on any of these controls?
>>>>
>>>> Thanks
>>
|
|
|
| Re: Nebula components questions [message #22278 is a reply to message #22238] |
Thu, 04 January 2007 20:34 |
Dave Orme
Messages: 424
Registered: July 2009 |
Senior Member |
|
|
Yuri Geller wrote:
> With CompositeTable, if I have 3 columns and 100 rows visible, does that mean
> I have 300 composites created?
That depends on how many Composites your row object contains.
CompositeTable itself only requires 1 Composite per row. So if your
screen can fit 100 rows, you'll have 100 Composites.
> If I scroll down and view 100 more rows, does
> that mean 300 more composites now sit in memory?
No, you'll only ever have Composites for what can be displayed (in this
example, 100 Composites).
Each time you scroll by one row, the visible Composites are shifted up
or down by one position. But the Composite that would have been
scrolled off the top or bottom is reused. It is moved into the empty
space created by shifting the other Composites, and then a refresh event
is fired to tell the client to refresh just that one row.
> If so, that doesn't seem like
> a scalable table, and seems like a design decision that will hit some pretty
> hard brick walls eventually, but perhaps I misunderstand.
I think you misunderstood. :-)
> As I recall, KTable seemed to create 1 canvas for the size of the client area,
> and abstract away the concept of cells. This minimizes memory use (only draw
> to 1 small canvas) and maximize visual speed, by offloading the logic of what
> to redraw to the cpu and only visually update that which needs to be updated.
This works well on Windows, but I would be concerned about performance
on X-Windows based platforms because you would be pushing a *ton* of
drawing operations through the network pipe between the X client and X
server for *each* scrolling operation. Basically, each scrolling
operation would force a redraw of the whole canvas.
By making each row a separate Composite, the X server or GDI driver can
move an entire row in a single operation--an operation that is normally
optimized by the GPU on modern graphics hardware.
> The scrollbars are virtual, nothing physically scrolls, only the dataset and
> the view of that dataset on the canvas.
Same with CompositeTable, except that CompositeTable uses one
canvas/Composite per row.
> Using that as a starting point, adding more logic to create static rows or
> header rows, like the "industrial strength" QicsTable
> http://www.ics.com/support/docs/qicstableapi/index.html
CompositeTable currently supports a single static header row.
> or cells that span multiple columns or rows, or leafs (sub rows),
With CompositeTable, you can easily span multiple columns, but spanning
rows is not so easy because there is a current limitation that all
CompositeTable rows must be the same height.
> or embeded controls
> like wxGrid: http://www.simpol.com/guiimages/wxgrid.jpg
> or wxSheet: http://www.lehigh.edu/~jrl1/wxwidgets/screenshots/wxsheetdem o.png
With CompositeTable, you design the row object. It can be literally any
SWT control you can write.
This row control can embed any other SWT control, including more
CompositeTables if you want. The easiest way to see what I mean is to
read the snippets:
http://www.eclipse.org/nebula/widgets/compositetable/snippet s.php
Note especially the first and last CompositeTable snippet.
> would be done by adding more logic to the concept of abstracted cells, while
> maintaining a constant visual and interactive speed for both small and
> large/complex datasets.
This is where you have to be careful with CompositeTable. When the row
object has a lot of embedded SWT controls, then performance can start to
drag. The solution is to make your row object extend Canvas and to do
your own drawing--kind of a compromise compared with the way KTable does it.
But you can still get quite complex. Try running the DayEditor snippet.
DayEditor is basically the Outlook/PalmOS week view calendar built
on top of CompositeTable.
> I'm not sure how the other nebula grids are implemented or if they could
> handle all of the above (and more), but the above seems to make the most sense
> to me. I'll try to find time to test them out, but that's why I originally
> was looking for an information table that compared them all (how they
> fundamentally work -- are they more for small or large datasets -- how
> configurable are they compared to other offerings from other toolkits).
I'm pretty sure Chris's Grid can do a lot of the above, but I just don't
know how it handles virtual table semantics. I hope he jumps in here
and clarifies.
Regards,
Dave Orme
|
|
|
| Re: Nebula components questions [message #22310 is a reply to message #22278] |
Thu, 04 January 2007 20:58 |
| Eclipse User |
|
|
|
Originally posted by: spoon.bender.org
Thanks for the information. I didn't know about that concern on X-Windows.
I'd be interested in knowing what is most efficient on OSX as well.
A quick followup: What happens in a 25 column table when only row 5, column 5
needs updating? Is the full row 5 updated, or only the cell? Is it still 1
composite per row or 1 per cell?
And what about re-sorting? If the user wants the table sorted by a certain
column ($), and the stock price($) is constantly changing, is compositeTable
going to be efficient and quick when moving the rows up and down based on the
constantly resorting model with a large data set?
I will take a look at the samples soon. (I am really in need of a tree
though).
"David J. Orme" <djo@coconut-palm-software.com> wrote in message
news:enjoda$oca$1@utils.eclipse.org...
> Yuri Geller wrote:
>> With CompositeTable, if I have 3 columns and 100 rows visible, does that
>> mean I have 300 composites created?
>
> That depends on how many Composites your row object contains. CompositeTable
> itself only requires 1 Composite per row. So if your screen can fit 100
> rows, you'll have 100 Composites.
>
>> If I scroll down and view 100 more rows, does that mean 300 more composites
>> now sit in memory?
>
> No, you'll only ever have Composites for what can be displayed (in this
> example, 100 Composites).
>
> Each time you scroll by one row, the visible Composites are shifted up or
> down by one position. But the Composite that would have been scrolled off
> the top or bottom is reused. It is moved into the empty space created by
> shifting the other Composites, and then a refresh event is fired to tell the
> client to refresh just that one row.
>
>> If so, that doesn't seem like a scalable table, and seems like a design
>> decision that will hit some pretty hard brick walls eventually, but perhaps
>> I misunderstand.
>
> I think you misunderstood. :-)
>
>> As I recall, KTable seemed to create 1 canvas for the size of the client
>> area, and abstract away the concept of cells. This minimizes memory use
>> (only draw to 1 small canvas) and maximize visual speed, by offloading the
>> logic of what to redraw to the cpu and only visually update that which
>> needs to be updated.
>
> This works well on Windows, but I would be concerned about performance on
> X-Windows based platforms because you would be pushing a *ton* of drawing
> operations through the network pipe between the X client and X server for
> *each* scrolling operation. Basically, each scrolling operation would force
> a redraw of the whole canvas.
>
> By making each row a separate Composite, the X server or GDI driver can move
> an entire row in a single operation--an operation that is normally optimized
> by the GPU on modern graphics hardware.
>
>> The scrollbars are virtual, nothing physically scrolls, only the dataset
>> and the view of that dataset on the canvas.
>
> Same with CompositeTable, except that CompositeTable uses one
> canvas/Composite per row.
>
>> Using that as a starting point, adding more logic to create static rows or
>> header rows, like the "industrial strength" QicsTable
>> http://www.ics.com/support/docs/qicstableapi/index.html
>
> CompositeTable currently supports a single static header row.
>
>> or cells that span multiple columns or rows, or leafs (sub rows),
>
> With CompositeTable, you can easily span multiple columns, but spanning rows
> is not so easy because there is a current limitation that all CompositeTable
> rows must be the same height.
>
>> or embeded controls
>> like wxGrid: http://www.simpol.com/guiimages/wxgrid.jpg
>> or wxSheet:
>> http://www.lehigh.edu/~jrl1/wxwidgets/screenshots/wxsheetdem o.png
>
> With CompositeTable, you design the row object. It can be literally any SWT
> control you can write.
>
> This row control can embed any other SWT control, including more
> CompositeTables if you want. The easiest way to see what I mean is to read
> the snippets:
>
> http://www.eclipse.org/nebula/widgets/compositetable/snippet s.php
>
> Note especially the first and last CompositeTable snippet.
>
>> would be done by adding more logic to the concept of abstracted cells,
>> while maintaining a constant visual and interactive speed for both small
>> and large/complex datasets.
>
> This is where you have to be careful with CompositeTable. When the row
> object has a lot of embedded SWT controls, then performance can start to
> drag. The solution is to make your row object extend Canvas and to do your
> own drawing--kind of a compromise compared with the way KTable does it.
>
> But you can still get quite complex. Try running the DayEditor snippet.
> DayEditor is basically the Outlook/PalmOS week view calendar built on top of
> CompositeTable.
>
>> I'm not sure how the other nebula grids are implemented or if they could
>> handle all of the above (and more), but the above seems to make the most
>> sense to me. I'll try to find time to test them out, but that's why I
>> originally was looking for an information table that compared them all (how
>> they fundamentally work -- are they more for small or large datasets -- how
>> configurable are they compared to other offerings from other toolkits).
>
> I'm pretty sure Chris's Grid can do a lot of the above, but I just don't
> know how it handles virtual table semantics. I hope he jumps in here and
> clarifies.
>
>
>
> Regards,
>
> Dave Orme
|
|
|
| Re: Nebula components questions [message #22383 is a reply to message #22278] |
Thu, 04 January 2007 22:32 |
Chris Gross
Messages: 253
Registered: July 2009 |
Senior Member |
|
|
Grid currently does not support a virtual mode. I do plan to add that
feature in the future.
-Chris
David J. Orme wrote:
> Yuri Geller wrote:
>> With CompositeTable, if I have 3 columns and 100 rows visible, does
>> that mean I have 300 composites created?
>
> That depends on how many Composites your row object contains.
> CompositeTable itself only requires 1 Composite per row. So if your
> screen can fit 100 rows, you'll have 100 Composites.
>
>> If I scroll down and view 100 more rows, does that mean 300 more
>> composites now sit in memory?
>
> No, you'll only ever have Composites for what can be displayed (in this
> example, 100 Composites).
>
> Each time you scroll by one row, the visible Composites are shifted up
> or down by one position. But the Composite that would have been
> scrolled off the top or bottom is reused. It is moved into the empty
> space created by shifting the other Composites, and then a refresh event
> is fired to tell the client to refresh just that one row.
>
>> If so, that doesn't seem like a scalable table, and seems like a
>> design decision that will hit some pretty hard brick walls eventually,
>> but perhaps I misunderstand.
>
> I think you misunderstood. :-)
>
>> As I recall, KTable seemed to create 1 canvas for the size of the
>> client area, and abstract away the concept of cells. This minimizes
>> memory use (only draw to 1 small canvas) and maximize visual speed, by
>> offloading the logic of what to redraw to the cpu and only visually
>> update that which needs to be updated.
>
> This works well on Windows, but I would be concerned about performance
> on X-Windows based platforms because you would be pushing a *ton* of
> drawing operations through the network pipe between the X client and X
> server for *each* scrolling operation. Basically, each scrolling
> operation would force a redraw of the whole canvas.
>
> By making each row a separate Composite, the X server or GDI driver can
> move an entire row in a single operation--an operation that is normally
> optimized by the GPU on modern graphics hardware.
>
>> The scrollbars are virtual, nothing physically scrolls, only the
>> dataset and the view of that dataset on the canvas.
>
> Same with CompositeTable, except that CompositeTable uses one
> canvas/Composite per row.
>
>> Using that as a starting point, adding more logic to create static
>> rows or header rows, like the "industrial strength" QicsTable
>> http://www.ics.com/support/docs/qicstableapi/index.html
>
> CompositeTable currently supports a single static header row.
>
>> or cells that span multiple columns or rows, or leafs (sub rows),
>
> With CompositeTable, you can easily span multiple columns, but spanning
> rows is not so easy because there is a current limitation that all
> CompositeTable rows must be the same height.
>
>> or embeded controls
>> like wxGrid: http://www.simpol.com/guiimages/wxgrid.jpg
>> or wxSheet:
>> http://www.lehigh.edu/~jrl1/wxwidgets/screenshots/wxsheetdem o.png
>
> With CompositeTable, you design the row object. It can be literally any
> SWT control you can write.
>
> This row control can embed any other SWT control, including more
> CompositeTables if you want. The easiest way to see what I mean is to
> read the snippets:
>
> http://www.eclipse.org/nebula/widgets/compositetable/snippet s.php
>
> Note especially the first and last CompositeTable snippet.
>
>> would be done by adding more logic to the concept of abstracted cells,
>> while maintaining a constant visual and interactive speed for both
>> small and large/complex datasets.
>
> This is where you have to be careful with CompositeTable. When the row
> object has a lot of embedded SWT controls, then performance can start to
> drag. The solution is to make your row object extend Canvas and to do
> your own drawing--kind of a compromise compared with the way KTable does
> it.
>
> But you can still get quite complex. Try running the DayEditor snippet.
> DayEditor is basically the Outlook/PalmOS week view calendar built on
> top of CompositeTable.
>
>> I'm not sure how the other nebula grids are implemented or if they
>> could handle all of the above (and more), but the above seems to make
>> the most sense to me. I'll try to find time to test them out, but
>> that's why I originally was looking for an information table that
>> compared them all (how they fundamentally work -- are they more for
>> small or large datasets -- how configurable are they compared to other
>> offerings from other toolkits).
>
> I'm pretty sure Chris's Grid can do a lot of the above, but I just don't
> know how it handles virtual table semantics. I hope he jumps in here
> and clarifies.
>
>
>
> Regards,
>
> Dave Orme
|
|
| | |
| Re: Nebula components questions [message #23783 is a reply to message #23400] |
Sat, 20 January 2007 21:32 |
| Eclipse User |
|
|
|
Originally posted by: spoon.bender.org
"David J. Orme" <djo@coconut-palm-software.com> wrote in message
news:eopj91$1np$1@utils.eclipse.org...
> Sorry for the brief delay in replying.
>
> Yuri Geller wrote:
>> Thanks for the information. I didn't know about that concern on X-Windows.
>> I'd be interested in knowing what is most efficient on OSX as well.
>>
>> A quick followup: What happens in a 25 column table when only row 5, column
>> 5 needs updating? Is the full row 5 updated, or only the cell? Is it still
>> 1 composite per row or 1 per cell?
>
> That depends on how you program it. If you're using JFace Data Binding with
> CompositeTable, only the cell will be updated.
>
>> And what about re-sorting? If the user wants the table sorted by a certain
>> column ($), and the stock price($) is constantly changing, is
>> compositeTable going to be efficient and quick when moving the rows up and
>> down based on the constantly resorting model with a large data set?
>
> CompositeTable will at most refresh all visible rows. If you have 25
> visible rows, that will be 25 refreshes.
>
> CompositeTable has efficient internal API for moving rows around. I haven't
> figured out a reasonable way to expose that as external API so folks can
> take advantage of those capabilities to implement efficient sparse sorting
> behavior (where only a few rows actually move). I'd be interested in
> feedback on this part of the API.
That sounds interesting, but I've no suggestion for the API at this time.
>> I will take a look at the samples soon. (I am really in need of a tree
>> though).
>
> Great!
I have tried out all the nebula snippets on win32. Unfortunately
CompositeTable was noticably slower to scroll than Grid, but perhaps is
faster/better suited on GTK? I can see it being useful for containing and
scrolling large things like the Name/Address/City block snippet.
The CTableTree had noticable lag when resizing the header, which just "felt
weird". I guess there are limitations when combining a native table header
with a custom grid. I hope SWT can make available the TableHeader controls so
they can be seamlessly integrated some day.
Since I need a Tree-table, the Grid definitely was the most promising, but it
really needs Virtual support for large datasets or it, too, slows down. I'm
not sure if it supports easy resorting and updating only the rows that change
("sparse sorting behavior" as described above), but it did crash with column
drag&drop when gdi support wasn't available. (minor bug). The ability to make
it look more native on win32 and OSX is also quite important since it just
didn't "look right" on OSX. I really do look forward to its future
development.
Thanks for all the help.
|
|
|
| Re: [CompositeTable] Nebula components questions [message #29142 is a reply to message #22194] |
Sun, 18 February 2007 23:55 |
| Eclipse User |
|
|
|
Originally posted by: h2.miegel.org
> I'd love to have help adding tree capabilities to it. :-)
CompositeTable already supports trees, almost. It just needs to allow each
row to be a different height by using the actual preferred height of each
row control. The child items would be put in a table control which is in the
row control. (The table control inside the row control could be a
CompositeTable, a Table, a Tree, or whatever). If you want expand/collapse
support, just put a toggle button in each row control which shows or hides
the nested table.
It would be hard to make such nested tables look like a single native tree
control. The obvious way to do that is to have a native tree control and
CompositeTree would create and move the row controls to match the tree
control. There will be quite a few problems here, both from an
implementation point of view and in deciding on exactly what is supported.
As far as my requirements are concerned, the nested table approach meets my
needs very well.
(It would be nice if I could make a drop down table extend below the bottom,
or extend above the top, of the row containing the table. This might look a
little nicer in my application than increasing the height of the row. But I
can do without this unless there is a clean way of implementing it).
- Nigel Westbury
|
|
|
| Re: Nebula components questions [message #573515 is a reply to message #21612] |
Tue, 02 January 2007 19:52 |
Jeremy Dowdall
Messages: 181
Registered: July 2009 |
Senior Member |
|
|
Just a quick note here to point out that CTableTree does use a native
SWT table for its header. The screenshot shows it running on GTK with
the ClearLooks theme - the table contained in the cell (col 3, row 5)
shows an actual native table for comparison.
The toggle is not native, but does change to try and emulate three major
platforms as best it can (carbon, gtk, win32)
Yuri Geller wrote:
> I am wondering if there is an online table that compares the features of Grid,
> CTableTree and CompositeTable? I'm not sure which is the right one to use or
> the features/limitations of each.
>
> I'm also wondering if Nebula components have their API javadoc online
> somewhere, like other packages?
> http://help.eclipse.org/help32/nftopic/org.eclipse.platform. doc.isv/reference/api/index.html
>
> Finally, I wonder if these nebula components can use native headers so they
> look native on different OSes? I notice in the screenshots the headers are
> not native. Is there a way to use the XP looking TableHeaders on XP, and the
> MacOSX ones on OSX and GTK theme aware ones on GTK? Maybe this requires SWT
> to make a Tableheader class (will this be in 3.3? Will nebula offer options to
> use it?)
>
> I'm particularly looking for the right control to use for a stock tracking
> tree grid, which updates very regularly, has a lot of rows and leaves, and
> re-sorts very regularly, so all these updates need to be fast and smart
> without excess screen redraws (don't redraw things that don't move due to
> re-sort every second, just the things that do). Also, are SWT-Tree features
> like a header sort indicator and sorted column colors, alternating row colors
> (like OS native which really help readability) supported on any of these
> controls?
>
> Thanks
>
>
|
|
|
| Re: Nebula components questions [message #573551 is a reply to message #21612] |
Tue, 02 January 2007 22:26 |
Dave Orme
Messages: 424
Registered: July 2009 |
Senior Member |
|
|
Yuri Geller wrote:
> I am wondering if there is an online table that compares the features of Grid,
> CTableTree and CompositeTable? I'm not sure which is the right one to use or
> the features/limitations of each.
Not yet.
Maybe the three authors could meet at EclipseCon and hash this out? I
can see that being useful to folks.
> I'm also wondering if Nebula components have their API javadoc online
> somewhere, like other packages?
> http://help.eclipse.org/help32/nftopic/org.eclipse.platform. doc.isv/reference/api/index.html
Not online, but each download includes a JavaDoc folder with the JavaDoc
HTML files already built.
> Finally, I wonder if these nebula components can use native headers so they
> look native on different OSes? I notice in the screenshots the headers are
> not native. Is there a way to use the XP looking TableHeaders on XP, and the
> MacOSX ones on OSX and GTK theme aware ones on GTK? Maybe this requires SWT
> to make a Tableheader class (will this be in 3.3? Will nebula offer options to
> use it?)
CompositeTable would require SWT to make a Tableheader class. If SWT
supplied a TableHeader class, you could use it with CompositeTable right
now. (With CompositeTable, the header and row are defined by arbitrary
SWT controls that you supply, which could include a TableHeader class.)
> I'm particularly looking for the right control to use for a stock tracking
> tree grid, which updates very regularly, has a lot of rows and leaves, and
> re-sorts very regularly, so all these updates need to be fast and smart
> without excess screen redraws (don't redraw things that don't move due to
> re-sort every second, just the things that do). Also, are SWT-Tree features
> like a header sort indicator and sorted column colors, alternating row colors
> (like OS native which really help readability) supported on any of these
> controls?
If you need tree capabilities, CompositeTable can't (currently) help.
But if you just need a table that only asks for data that is actually
visible, CompositeTable might be right for you.
Best regards,
Dave Orme
|
|
|
| Re: Nebula components questions [message #573961 is a reply to message #21612] |
Thu, 04 January 2007 16:30 |
Chris Gross
Messages: 471
Registered: July 2009 |
Senior Member |
|
|
Just a question... why not use the normal SWT Table or Tree?
-Chris
Yuri Geller wrote:
> I am wondering if there is an online table that compares the features of Grid,
> CTableTree and CompositeTable? I'm not sure which is the right one to use or
> the features/limitations of each.
>
> I'm also wondering if Nebula components have their API javadoc online
> somewhere, like other packages?
> http://help.eclipse.org/help32/nftopic/org.eclipse.platform. doc.isv/reference/api/index.html
>
> Finally, I wonder if these nebula components can use native headers so they
> look native on different OSes? I notice in the screenshots the headers are
> not native. Is there a way to use the XP looking TableHeaders on XP, and the
> MacOSX ones on OSX and GTK theme aware ones on GTK? Maybe this requires SWT
> to make a Tableheader class (will this be in 3.3? Will nebula offer options to
> use it?)
>
> I'm particularly looking for the right control to use for a stock tracking
> tree grid, which updates very regularly, has a lot of rows and leaves, and
> re-sorts very regularly, so all these updates need to be fast and smart
> without excess screen redraws (don't redraw things that don't move due to
> re-sort every second, just the things that do). Also, are SWT-Tree features
> like a header sort indicator and sorted column colors, alternating row colors
> (like OS native which really help readability) supported on any of these
> controls?
>
> Thanks
>
>
|
|
|
| Re: Nebula components questions [message #574006 is a reply to message #22107] |
Thu, 04 January 2007 17:12 |
| Eclipse User |
|
|
|
Originally posted by: spoon.bender.org
I have tried Ktable and it scrolled much faster than a real table, and was
much more smooth than Table especially on GTK, but seems unsupported now and
did not offer tree functionality. I don't think a real tree can ever have the
speed of a (well written) custom drawn tree. Even with a virtual tree, SWT
populates the items and leaves them populated while scrolling down and images
are left im memory. A truely virtual one would be much smarter about this.
I am looking for static headers that don't scroll off screen, leaves that
expand+hide very quickly, and all around top performance and more advanced
features than SWTTree will ever offer. Performance is king. A Table-Tree done
right, like the other toolkits have.
http://www.delphi-gems.com/VirtualTreeview/ is king I think, or like QT's.
It seems with 3 different ones, nebula is going broad, rather than deep with 1
implementation to rule them all, but I don't know where they all plan to go in
the future.
"Chris Gross" <chris.gross@us.ibm.com> wrote in message
news:enja2j$doc$5@utils.eclipse.org...
> Just a question... why not use the normal SWT Table or Tree?
>
> -Chris
>
> Yuri Geller wrote:
>> I am wondering if there is an online table that compares the features of
>> Grid, CTableTree and CompositeTable? I'm not sure which is the right one
>> to use or the features/limitations of each.
>>
>> I'm also wondering if Nebula components have their API javadoc online
>> somewhere, like other packages?
>> http://help.eclipse.org/help32/nftopic/org.eclipse.platform. doc.isv/reference/api/index.html
>>
>> Finally, I wonder if these nebula components can use native headers so they
>> look native on different OSes? I notice in the screenshots the headers are
>> not native. Is there a way to use the XP looking TableHeaders on XP, and
>> the MacOSX ones on OSX and GTK theme aware ones on GTK? Maybe this
>> requires SWT to make a Tableheader class (will this be in 3.3? Will nebula
>> offer options to use it?)
>>
>> I'm particularly looking for the right control to use for a stock tracking
>> tree grid, which updates very regularly, has a lot of rows and leaves, and
>> re-sorts very regularly, so all these updates need to be fast and smart
>> without excess screen redraws (don't redraw things that don't move due to
>> re-sort every second, just the things that do). Also, are SWT-Tree
>> features like a header sort indicator and sorted column colors, alternating
>> row colors (like OS native which really help readability) supported on any
>> of these controls?
>>
>> Thanks
|
|
|
| Re: Nebula components questions [message #574028 is a reply to message #22151] |
Thu, 04 January 2007 17:29 |
Dave Orme
Messages: 424
Registered: July 2009 |
Senior Member |
|
|
CompositeTable is designed from the ground up to meet your kind of
performance requirements.
For example, each visible row is an SWT control. Scrolling down is
implemented by shifting each control up one position, moving the top
control to the bottom, and firing a refresh event on *just* the bottom
control.
CompositeTable just doesn't care about anything that is invisible.
I'd love to have help adding tree capabilities to it. :-)
Best regards,
Dave Orme
Yuri Geller wrote:
> I have tried Ktable and it scrolled much faster than a real table, and was
> much more smooth than Table especially on GTK, but seems unsupported now and
> did not offer tree functionality. I don't think a real tree can ever have the
> speed of a (well written) custom drawn tree. Even with a virtual tree, SWT
> populates the items and leaves them populated while scrolling down and images
> are left im memory. A truely virtual one would be much smarter about this.
>
> I am looking for static headers that don't scroll off screen, leaves that
> expand+hide very quickly, and all around top performance and more advanced
> features than SWTTree will ever offer. Performance is king. A Table-Tree done
> right, like the other toolkits have.
>
> http://www.delphi-gems.com/VirtualTreeview/ is king I think, or like QT's.
>
> It seems with 3 different ones, nebula is going broad, rather than deep with 1
> implementation to rule them all, but I don't know where they all plan to go in
> the future.
>
> "Chris Gross" <chris.gross@us.ibm.com> wrote in message
> news:enja2j$doc$5@utils.eclipse.org...
>> Just a question... why not use the normal SWT Table or Tree?
>>
>> -Chris
>>
>> Yuri Geller wrote:
>>> I am wondering if there is an online table that compares the features of
>>> Grid, CTableTree and CompositeTable? I'm not sure which is the right one
>>> to use or the features/limitations of each.
>>>
>>> I'm also wondering if Nebula components have their API javadoc online
>>> somewhere, like other packages?
>>> http://help.eclipse.org/help32/nftopic/org.eclipse.platform. doc.isv/reference/api/index.html
>>>
>>> Finally, I wonder if these nebula components can use native headers so they
>>> look native on different OSes? I notice in the screenshots the headers are
>>> not native. Is there a way to use the XP looking TableHeaders on XP, and
>>> the MacOSX ones on OSX and GTK theme aware ones on GTK? Maybe this
>>> requires SWT to make a Tableheader class (will this be in 3.3? Will nebula
>>> offer options to use it?)
>>>
>>> I'm particularly looking for the right control to use for a stock tracking
>>> tree grid, which updates very regularly, has a lot of rows and leaves, and
>>> re-sorts very regularly, so all these updates need to be fast and smart
>>> without excess screen redraws (don't redraw things that don't move due to
>>> re-sort every second, just the things that do). Also, are SWT-Tree
>>> features like a header sort indicator and sorted column colors, alternating
>>> row colors (like OS native which really help readability) supported on any
>>> of these controls?
>>>
>>> Thanks
>
>
|
|
|
| Re: Nebula components questions [message #574071 is a reply to message #22194] |
Thu, 04 January 2007 19:46 |
| Eclipse User |
|
|
|
Originally posted by: spoon.bender.org
With CompositeTable, if I have 3 columns and 100 rows visible, does that mean
I have 300 composites created? If I scroll down and view 100 more rows, does
that mean 300 more composites now sit in memory? If so, that doesn't seem like
a scalable table, and seems like a design decision that will hit some pretty
hard brick walls eventually, but perhaps I misunderstand.
As I recall, KTable seemed to create 1 canvas for the size of the client area,
and abstract away the concept of cells. This minimizes memory use (only draw
to 1 small canvas) and maximize visual speed, by offloading the logic of what
to redraw to the cpu and only visually update that which needs to be updated.
The scrollbars are virtual, nothing physically scrolls, only the dataset and
the view of that dataset on the canvas.
Using that as a starting point, adding more logic to create static rows or
header rows, like the "industrial strength" QicsTable
http://www.ics.com/support/docs/qicstableapi/index.html
or cells that span multiple columns or rows, or leafs (sub rows), or embeded
controls
like wxGrid: http://www.simpol.com/guiimages/wxgrid.jpg
or wxSheet: http://www.lehigh.edu/~jrl1/wxwidgets/screenshots/wxsheetdem o.png
would be done by adding more logic to the concept of abstracted cells, while
maintaining a constant visual and interactive speed for both small and
large/complex datasets.
I'm not sure how the other nebula grids are implemented or if they could
handle all of the above (and more), but the above seems to make the most sense
to me. I'll try to find time to test them out, but that's why I originally
was looking for an information table that compared them all (how they
fundamentally work -- are they more for small or large datasets -- how
configurable are they compared to other offerings from other toolkits).
"David J. Orme" <djo@coconut-palm-software.com> wrote in message
news:enjdhr$r0m$1@utils.eclipse.org...
> CompositeTable is designed from the ground up to meet your kind of
> performance requirements.
>
> For example, each visible row is an SWT control. Scrolling down is
> implemented by shifting each control up one position, moving the top control
> to the bottom, and firing a refresh event on *just* the bottom control.
>
> CompositeTable just doesn't care about anything that is invisible.
>
> I'd love to have help adding tree capabilities to it. :-)
>
>
> Best regards,
>
> Dave Orme
>
> Yuri Geller wrote:
>> I have tried Ktable and it scrolled much faster than a real table, and was
>> much more smooth than Table especially on GTK, but seems unsupported now
>> and did not offer tree functionality. I don't think a real tree can ever
>> have the speed of a (well written) custom drawn tree. Even with a virtual
>> tree, SWT populates the items and leaves them populated while scrolling
>> down and images are left im memory. A truely virtual one would be much
>> smarter about this.
>>
>> I am looking for static headers that don't scroll off screen, leaves that
>> expand+hide very quickly, and all around top performance and more advanced
>> features than SWTTree will ever offer. Performance is king. A Table-Tree
>> done right, like the other toolkits have.
>>
>> http://www.delphi-gems.com/VirtualTreeview/ is king I think, or like QT's.
>>
>> It seems with 3 different ones, nebula is going broad, rather than deep
>> with 1 implementation to rule them all, but I don't know where they all
>> plan to go in the future.
>>
>> "Chris Gross" <chris.gross@us.ibm.com> wrote in message
>> news:enja2j$doc$5@utils.eclipse.org...
>>> Just a question... why not use the normal SWT Table or Tree?
>>>
>>> -Chris
>>>
>>> Yuri Geller wrote:
>>>> I am wondering if there is an online table that compares the features of
>>>> Grid, CTableTree and CompositeTable? I'm not sure which is the right one
>>>> to use or the features/limitations of each.
>>>>
>>>> I'm also wondering if Nebula components have their API javadoc online
>>>> somewhere, like other packages?
>>>> http://help.eclipse.org/help32/nftopic/org.eclipse.platform. doc.isv/reference/api/index.html
>>>>
>>>> Finally, I wonder if these nebula components can use native headers so
>>>> they look native on different OSes? I notice in the screenshots the
>>>> headers are not native. Is there a way to use the XP looking
>>>> TableHeaders on XP, and the MacOSX ones on OSX and GTK theme aware ones
>>>> on GTK? Maybe this requires SWT to make a Tableheader class (will this
>>>> be in 3.3? Will nebula offer options to use it?)
>>>>
>>>> I'm particularly looking for the right control to use for a stock
>>>> tracking tree grid, which updates very regularly, has a lot of rows and
>>>> leaves, and re-sorts very regularly, so all these updates need to be fast
>>>> and smart without excess screen redraws (don't redraw things that don't
>>>> move due to re-sort every second, just the things that do). Also, are
>>>> SWT-Tree features like a header sort indicator and sorted column colors,
>>>> alternating row colors (like OS native which really help readability)
>>>> supported on any of these controls?
>>>>
>>>> Thanks
>>
|
|
|
| Re: Nebula components questions [message #574094 is a reply to message #22238] |
Thu, 04 January 2007 20:34 |
Dave Orme
Messages: 424
Registered: July 2009 |
Senior Member |
|
|
Yuri Geller wrote:
> With CompositeTable, if I have 3 columns and 100 rows visible, does that mean
> I have 300 composites created?
That depends on how many Composites your row object contains.
CompositeTable itself only requires 1 Composite per row. So if your
screen can fit 100 rows, you'll have 100 Composites.
> If I scroll down and view 100 more rows, does
> that mean 300 more composites now sit in memory?
No, you'll only ever have Composites for what can be displayed (in this
example, 100 Composites).
Each time you scroll by one row, the visible Composites are shifted up
or down by one position. But the Composite that would have been
scrolled off the top or bottom is reused. It is moved into the empty
space created by shifting the other Composites, and then a refresh event
is fired to tell the client to refresh just that one row.
> If so, that doesn't seem like
> a scalable table, and seems like a design decision that will hit some pretty
> hard brick walls eventually, but perhaps I misunderstand.
I think you misunderstood. :-)
> As I recall, KTable seemed to create 1 canvas for the size of the client area,
> and abstract away the concept of cells. This minimizes memory use (only draw
> to 1 small canvas) and maximize visual speed, by offloading the logic of what
> to redraw to the cpu and only visually update that which needs to be updated.
This works well on Windows, but I would be concerned about performance
on X-Windows based platforms because you would be pushing a *ton* of
drawing operations through the network pipe between the X client and X
server for *each* scrolling operation. Basically, each scrolling
operation would force a redraw of the whole canvas.
By making each row a separate Composite, the X server or GDI driver can
move an entire row in a single operation--an operation that is normally
optimized by the GPU on modern graphics hardware.
> The scrollbars are virtual, nothing physically scrolls, only the dataset and
> the view of that dataset on the canvas.
Same with CompositeTable, except that CompositeTable uses one
canvas/Composite per row.
> Using that as a starting point, adding more logic to create static rows or
> header rows, like the "industrial strength" QicsTable
> http://www.ics.com/support/docs/qicstableapi/index.html
CompositeTable currently supports a single static header row.
> or cells that span multiple columns or rows, or leafs (sub rows),
With CompositeTable, you can easily span multiple columns, but spanning
rows is not so easy because there is a current limitation that all
CompositeTable rows must be the same height.
> or embeded controls
> like wxGrid: http://www.simpol.com/guiimages/wxgrid.jpg
> or wxSheet: http://www.lehigh.edu/~jrl1/wxwidgets/screenshots/wxsheetdem o.png
With CompositeTable, you design the row object. It can be literally any
SWT control you can write.
This row control can embed any other SWT control, including more
CompositeTables if you want. The easiest way to see what I mean is to
read the snippets:
http://www.eclipse.org/nebula/widgets/compositetable/snippet s.php
Note especially the first and last CompositeTable snippet.
> would be done by adding more logic to the concept of abstracted cells, while
> maintaining a constant visual and interactive speed for both small and
> large/complex datasets.
This is where you have to be careful with CompositeTable. When the row
object has a lot of embedded SWT controls, then performance can start to
drag. The solution is to make your row object extend Canvas and to do
your own drawing--kind of a compromise compared with the way KTable does it.
But you can still get quite complex. Try running the DayEditor snippet.
DayEditor is basically the Outlook/PalmOS week view calendar built
on top of CompositeTable.
> I'm not sure how the other nebula grids are implemented or if they could
> handle all of the above (and more), but the above seems to make the most sense
> to me. I'll try to find time to test them out, but that's why I originally
> was looking for an information table that compared them all (how they
> fundamentally work -- are they more for small or large datasets -- how
> configurable are they compared to other offerings from other toolkits).
I'm pretty sure Chris's Grid can do a lot of the above, but I just don't
know how it handles virtual table semantics. I hope he jumps in here
and clarifies.
Regards,
Dave Orme
|
|
|
| Re: Nebula components questions [message #574124 is a reply to message #22278] |
Thu, 04 January 2007 20:58 |
| Eclipse User |
|
|
|
Originally posted by: spoon.bender.org
Thanks for the information. I didn't know about that concern on X-Windows.
I'd be interested in knowing what is most efficient on OSX as well.
A quick followup: What happens in a 25 column table when only row 5, column 5
needs updating? Is the full row 5 updated, or only the cell? Is it still 1
composite per row or 1 per cell?
And what about re-sorting? If the user wants the table sorted by a certain
column ($), and the stock price($) is constantly changing, is compositeTable
going to be efficient and quick when moving the rows up and down based on the
constantly resorting model with a large data set?
I will take a look at the samples soon. (I am really in need of a tree
though).
"David J. Orme" <djo@coconut-palm-software.com> wrote in message
news:enjoda$oca$1@utils.eclipse.org...
> Yuri Geller wrote:
>> With CompositeTable, if I have 3 columns and 100 rows visible, does that
>> mean I have 300 composites created?
>
> That depends on how many Composites your row object contains. CompositeTable
> itself only requires 1 Composite per row. So if your screen can fit 100
> rows, you'll have 100 Composites.
>
>> If I scroll down and view 100 more rows, does that mean 300 more composites
>> now sit in memory?
>
> No, you'll only ever have Composites for what can be displayed (in this
> example, 100 Composites).
>
> Each time you scroll by one row, the visible Composites are shifted up or
> down by one position. But the Composite that would have been scrolled off
> the top or bottom is reused. It is moved into the empty space created by
> shifting the other Composites, and then a refresh event is fired to tell the
> client to refresh just that one row.
>
>> If so, that doesn't seem like a scalable table, and seems like a design
>> decision that will hit some pretty hard brick walls eventually, but perhaps
>> I misunderstand.
>
> I think you misunderstood. :-)
>
>> As I recall, KTable seemed to create 1 canvas for the size of the client
>> area, and abstract away the concept of cells. This minimizes memory use
>> (only draw to 1 small canvas) and maximize visual speed, by offloading the
>> logic of what to redraw to the cpu and only visually update that which
>> needs to be updated.
>
> This works well on Windows, but I would be concerned about performance on
> X-Windows based platforms because you would be pushing a *ton* of drawing
> operations through the network pipe between the X client and X server for
> *each* scrolling operation. Basically, each scrolling operation would force
> a redraw of the whole canvas.
>
> By making each row a separate Composite, the X server or GDI driver can move
> an entire row in a single operation--an operation that is normally optimized
> by the GPU on modern graphics hardware.
>
>> The scrollbars are virtual, nothing physically scrolls, only the dataset
>> and the view of that dataset on the canvas.
>
> Same with CompositeTable, except that CompositeTable uses one
> canvas/Composite per row.
>
>> Using that as a starting point, adding more logic to create static rows or
>> header rows, like the "industrial strength" QicsTable
>> http://www.ics.com/support/docs/qicstableapi/index.html
>
> CompositeTable currently supports a single static header row.
>
>> or cells that span multiple columns or rows, or leafs (sub rows),
>
> With CompositeTable, you can easily span multiple columns, but spanning rows
> is not so easy because there is a current limitation that all CompositeTable
> rows must be the same height.
>
>> or embeded controls
>> like wxGrid: http://www.simpol.com/guiimages/wxgrid.jpg
>> or wxSheet:
>> http://www.lehigh.edu/~jrl1/wxwidgets/screenshots/wxsheetdem o.png
>
> With CompositeTable, you design the row object. It can be literally any SWT
> control you can write.
>
> This row control can embed any other SWT control, including more
> CompositeTables if you want. The easiest way to see what I mean is to read
> the snippets:
>
> http://www.eclipse.org/nebula/widgets/compositetable/snippet s.php
>
> Note especially the first and last CompositeTable snippet.
>
>> would be done by adding more logic to the concept of abstracted cells,
>> while maintaining a constant visual and interactive speed for both small
>> and large/complex datasets.
>
> This is where you have to be careful with CompositeTable. When the row
> object has a lot of embedded SWT controls, then performance can start to
> drag. The solution is to make your row object extend Canvas and to do your
> own drawing--kind of a compromise compared with the way KTable does it.
>
> But you can still get quite complex. Try running the DayEditor snippet.
> DayEditor is basically the Outlook/PalmOS week view calendar built on top of
> CompositeTable.
>
>> I'm not sure how the other nebula grids are implemented or if they could
>> handle all of the above (and more), but the above seems to make the most
>> sense to me. I'll try to find time to test them out, but that's why I
>> originally was looking for an information table that compared them all (how
>> they fundamentally work -- are they more for small or large datasets -- how
>> configurable are they compared to other offerings from other toolkits).
>
> I'm pretty sure Chris's Grid can do a lot of the above, but I just don't
> know how it handles virtual table semantics. I hope he jumps in here and
> clarifies.
>
>
>
> Regards,
>
> Dave Orme
|
|
|
| Re: Nebula components questions [message #574183 is a reply to message #22278] |
Thu, 04 January 2007 22:32 |
Chris Gross
Messages: 471
Registered: July 2009 |
Senior Member |
|
|
Grid currently does not support a virtual mode. I do plan to add that
feature in the future.
-Chris
David J. Orme wrote:
> Yuri Geller wrote:
>> With CompositeTable, if I have 3 columns and 100 rows visible, does
>> that mean I have 300 composites created?
>
> That depends on how many Composites your row object contains.
> CompositeTable itself only requires 1 Composite per row. So if your
> screen can fit 100 rows, you'll have 100 Composites.
>
>> If I scroll down and view 100 more rows, does that mean 300 more
>> composites now sit in memory?
>
> No, you'll only ever have Composites for what can be displayed (in this
> example, 100 Composites).
>
> Each time you scroll by one row, the visible Composites are shifted up
> or down by one position. But the Composite that would have been
> scrolled off the top or bottom is reused. It is moved into the empty
> space created by shifting the other Composites, and then a refresh event
> is fired to tell the client to refresh just that one row.
>
>> If so, that doesn't seem like a scalable table, and seems like a
>> design decision that will hit some pretty hard brick walls eventually,
>> but perhaps I misunderstand.
>
> I think you misunderstood. :-)
>
>> As I recall, KTable seemed to create 1 canvas for the size of the
>> client area, and abstract away the concept of cells. This minimizes
>> memory use (only draw to 1 small canvas) and maximize visual speed, by
>> offloading the logic of what to redraw to the cpu and only visually
>> update that which needs to be updated.
>
> This works well on Windows, but I would be concerned about performance
> on X-Windows based platforms because you would be pushing a *ton* of
> drawing operations through the network pipe between the X client and X
> server for *each* scrolling operation. Basically, each scrolling
> operation would force a redraw of the whole canvas.
>
> By making each row a separate Composite, the X server or GDI driver can
> move an entire row in a single operation--an operation that is normally
> optimized by the GPU on modern graphics hardware.
>
>> The scrollbars are virtual, nothing physically scrolls, only the
>> dataset and the view of that dataset on the canvas.
>
> Same with CompositeTable, except that CompositeTable uses one
> canvas/Composite per row.
>
>> Using that as a starting point, adding more logic to create static
>> rows or header rows, like the "industrial strength" QicsTable
>> http://www.ics.com/support/docs/qicstableapi/index.html
>
> CompositeTable currently supports a single static header row.
>
>> or cells that span multiple columns or rows, or leafs (sub rows),
>
> With CompositeTable, you can easily span multiple columns, but spanning
> rows is not so easy because there is a current limitation that all
> CompositeTable rows must be the same height.
>
>> or embeded controls
>> like wxGrid: http://www.simpol.com/guiimages/wxgrid.jpg
>> or wxSheet:
>> http://www.lehigh.edu/~jrl1/wxwidgets/screenshots/wxsheetdem o.png
>
> With CompositeTable, you design the row object. It can be literally any
> SWT control you can write.
>
> This row control can embed any other SWT control, including more
> CompositeTables if you want. The easiest way to see what I mean is to
> read the snippets:
>
> http://www.eclipse.org/nebula/widgets/compositetable/snippet s.php
>
> Note especially the first and last CompositeTable snippet.
>
>> would be done by adding more logic to the concept of abstracted cells,
>> while maintaining a constant visual and interactive speed for both
>> small and large/complex datasets.
>
> This is where you have to be careful with CompositeTable. When the row
> object has a lot of embedded SWT controls, then performance can start to
> drag. The solution is to make your row object extend Canvas and to do
> your own drawing--kind of a compromise compared with the way KTable does
> it.
>
> But you can still get quite complex. Try running the DayEditor snippet.
> DayEditor is basically the Outlook/PalmOS week view calendar built on
> top of CompositeTable.
>
>> I'm not sure how the other nebula grids are implemented or if they
>> could handle all of the above (and more), but the above seems to make
>> the most sense to me. I'll try to find time to test them out, but
>> that's why I originally was looking for an information table that
>> compared them all (how they fundamentally work -- are they more for
>> small or large datasets -- how configurable are they compared to other
>> offerings from other toolkits).
>
> I'm pretty sure Chris's Grid can do a lot of the above, but I just don't
> know how it handles virtual table semantics. I hope he jumps in here
> and clarifies.
>
>
>
> Regards,
>
> Dave Orme
|
|
| | |
| Re: Nebula components questions [message #575233 is a reply to message #23400] |
Sat, 20 January 2007 21:32 |
| Eclipse User |
|
|
|
Originally posted by: spoon.bender.org
"David J. Orme" <djo@coconut-palm-software.com> wrote in message
news:eopj91$1np$1@utils.eclipse.org...
> Sorry for the brief delay in replying.
>
> Yuri Geller wrote:
>> Thanks for the information. I didn't know about that concern on X-Windows.
>> I'd be interested in knowing what is most efficient on OSX as well.
>>
>> A quick followup: What happens in a 25 column table when only row 5, column
>> 5 needs updating? Is the full row 5 updated, or only the cell? Is it still
>> 1 composite per row or 1 per cell?
>
> That depends on how you program it. If you're using JFace Data Binding with
> CompositeTable, only the cell will be updated.
>
>> And what about re-sorting? If the user wants the table sorted by a certain
>> column ($), and the stock price($) is constantly changing, is
>> compositeTable going to be efficient and quick when moving the rows up and
>> down based on the constantly resorting model with a large data set?
>
> CompositeTable will at most refresh all visible rows. If you have 25
> visible rows, that will be 25 refreshes.
>
> CompositeTable has efficient internal API for moving rows around. I haven't
> figured out a reasonable way to expose that as external API so folks can
> take advantage of those capabilities to implement efficient sparse sorting
> behavior (where only a few rows actually move). I'd be interested in
> feedback on this part of the API.
That sounds interesting, but I've no suggestion for the API at this time.
>> I will take a look at the samples soon. (I am really in need of a tree
>> though).
>
> Great!
I have tried out all the nebula snippets on win32. Unfortunately
CompositeTable was noticably slower to scroll than Grid, but perhaps is
faster/better suited on GTK? I can see it being useful for containing and
scrolling large things like the Name/Address/City block snippet.
The CTableTree had noticable lag when resizing the header, which just "felt
weird". I guess there are limitations when combining a native table header
with a custom grid. I hope SWT can make available the TableHeader controls so
they can be seamlessly integrated some day.
Since I need a Tree-table, the Grid definitely was the most promising, but it
really needs Virtual support for large datasets or it, too, slows down. I'm
not sure if it supports easy resorting and updating only the rows that change
("sparse sorting behavior" as described above), but it did crash with column
drag&drop when gdi support wasn't available. (minor bug). The ability to make
it look more native on win32 and OSX is also quite important since it just
didn't "look right" on OSX. I really do look forward to its future
development.
Thanks for all the help.
|
|
|
| Re: [CompositeTable] Nebula components questions [message #578550 is a reply to message #22194] |
Sun, 18 February 2007 23:55 |
Nigel Westbury
Messages: 15
Registered: July 2009 |
Junior Member |
|
|
> I'd love to have help adding tree capabilities to it. :-)
CompositeTable already supports trees, almost. It just needs to allow each
row to be a different height by using the actual preferred height of each
row control. The child items would be put in a table control which is in the
row control. (The table control inside the row control could be a
CompositeTable, a Table, a Tree, or whatever). If you want expand/collapse
support, just put a toggle button in each row control which shows or hides
the nested table.
It would be hard to make such nested tables look like a single native tree
control. The obvious way to do that is to have a native tree control and
CompositeTree would create and move the row controls to match the tree
control. There will be quite a few problems here, both from an
implementation point of view and in deciding on exactly what is supported.
As far as my requirements are concerned, the nested table approach meets my
needs very well.
(It would be nice if I could make a drop down table extend below the bottom,
or extend above the top, of the row containing the table. This might look a
little nicer in my application than increasing the height of the row. But I
can do without this unless there is a clean way of implementing it).
- Nigel Westbury
|
|
|
Goto Forum:
Current Time: Fri Dec 13 17:38:44 GMT 2024
Powered by FUDForum. Page generated in 0.07086 seconds |