Another Table update

Here is another update to Table.java

  • Support for arbitrary height of rows
  • Option to set alignment within cells (1 child only)
  • More remove*() methods.
  • Rows and cells can carry an Object as a value
  • Methods to get selection by Object (and to set it). This is useful in reselecting rows that you have rebuilt (i.e. new TableCell/TableRow objects, but the same value Object).
  • Scrolling fixes
  • Some more performance fixes (some of these were in previous update, not made it into the plugin yet).

RR

2 Likes

Nice! I’ll get this added either tonight or tomorrow morning. Depends on how my innards hold up today >.<

Hehe thanks. I hope they do! Sounds … messy :S

@rockfire said: Hehe thanks. I hope they do! Sounds .. messy :S

It was… a … different experience. I had no clue what was involved until after.

@rockfire
The new ScrollPanel control still need a tiny bit of work, however… it is far easier to work with than ScrollArea and also has both horizontal and vertical scrolling.

Not sure if you’ll want to update this once it’s finished, but you might… so I thought I’d mention it was available through the repo. I still have to look into text only options and behavior for disabling horizontal scrolling and adding both wheel support and fling scrolling for android… but all in all it’s pretty nice. And simple.

Can be found in tonegod.gui.controls.scrolling:

ScrollPanel.java
ScrollPanelBarH.java
ScrollPanelBarV.java

There is only a single constructor right now (the irritating… erm… verbose one)… that’ll be updated sometime tomorrow I’m sure.

@t0neg0d said: It was... a ... *different* experience. I had no clue what was involved until *after*.

That was probably for the best :\

Regarding the new ScrollPane, this sounds great. I’ll have a proper play with it later today. Table would be a perfect candidate for an upgrade. I have a few questions …

  1. Can it handle both horizontal and vertical at the same time?

  2. When both scrollbars are visible, it would be nice to be able to make use of the unused corner inbetween the bars. Would it be possible to have a “setAccessory” or similar?

  1. Does it have/are there planned any optimisations for keeping elements that are outside of the viewport from rendering as part of the scene (this was discussed in the original table thread).

RR

@rockfire said: That was probably for the best :\n Regarding the new ScrollPane, this sounds great. I'll have a proper play with it later today. Table would be a perfect candidate for an upgrade. I have a few questions ..
  1. Can it handle both horizontal and vertical at the same time?

  2. When both scrollbars are visible, it would be nice to be able to make use of the unused corner inbetween the bars. Would it be possible to have a “setAccessory” or similar?

  1. Does it have/are there planned any optimisations for keeping elements that are outside of the viewport from rendering as part of the scene (this was discussed in the original table thread).

RR

I’ll try and answer these correctly:

  1. Yes
  2. The space is there, but I haven’t done anything with it yet. When you say setAccessory method… would this be the a way of adding an element to the unused space?
  3. Nothing past the shader clip check that discards the pixel instead of trying to render it. Still haven’t found a reliable way of handling this yet… but will!

Couple other notes about the control:

  1. You can nest ScrollPanels 1 level deep
  2. It does cascade the clipping (only one level deep)
  3. The child panel has to be fixed size – automatic when you setAsChildOf etc
  4. A resize of the parent forces scrolToTop / scrollToLeft on the children

But… better than it was before!

Oh… just a thought on how you may be able to handle add/remove outside of the visible space of the ScrollPanel… bare with me here:

Getting info about the ScrollPanel return data that is far more comprehensible than the original… there are methods for returning most everything you need to know about it’s current state. Such as:


// Vertical scrolling:
getScrollableAreaVerticalPosition()
getScrollBoundsHeight()
getScrollableAreaHeight()
getVerticalScrollDistance()
scrollToTop()
scrollToBottom()
scrollYTo(float y)
scrollYBy(float incY)
setVThumbPositionToScrollArea()
setScrollAreaPositionToVThumb()

// Horizontal scrolling:
getScrollableAreaHorizontalPosition()
getScrollBoundsWidth()
getScrollableAreaWidth()
getHorizontalScrollDistance()
scrollToLeft()
scrollToRight()
scrollXTo(float x)
scrollXBy(float incX)
setHThumbPositionToScrollArea()
setScrollAreaPositionToHThumb()

// Configuring as a child scroll panel (of another cscrollpanel)
configureAsChildOfScrollPanel()

Anyways… point being… every bit of data you would need to determin what is in view and what is not is accessible. For instance (v scrolling):


getScrollBoundsHeight() // returns the visual height of the scroll panel
getVerticalScrollDistance() // The number of pixels of overflow the scroll area contains vertically
getScrollableAreaVerticalPosition() // The current Y position of the scroll area…

So… if the visible area is 150, the overflow is 250 and the current Y is -50… you know that the visible portion of the scroll area starts at 50px in and ends at 200px… 50px below are hidden and 200px above are hidden.

It wouldn’t take much to add/remove elements based on this.

Also… I’m not sure how the tree view currently works, but I added a ton of support methods a while back, one being auto-sizing to content. Allowing you to add a bunch of element and then call sizeToContent() on the parent.

I should likely make the reshape method of the scrollarea public so you can force a resize of internal content after calling hide/show on nested elements.

It may simplify how this is currently being done.

And if I can ever get around to getting your layout stuff implemented (seriously feeling like there aren’t enough hours in the day lately) this would potentially auto-collapse the visible components together making expanding/collapsing content a simple method call.