Little worried about the ListView/TreeView/TableView classes

[Jonathan Giles]

I'm happy to help work through these issues to try to find fixes (which 
may be able to get into 2.2) or find workarounds, although it is 
probably easier to have a discussion on each of the jira issue pages, 
rather than grouped together in an email (both for ease of discussion, 
and so we can have a record of what was said).

Chances are all these bugs are already assigned to me. If so, lets start 
working through these right away. If not, email me the bug report 
numbers and I'll add myself as a watcher (or take ownership of them as 
they are likely my bugs anyway).

-- Jonathan

On 10/07/2012 10:51 a.m., John Hendrikx wrote:
> My program relies extensively on the *View classes, however, there are 
> numerous little problems with these (JavaFX 2.2b13) that I'm 
> considering rewriting these controls myself to "take control" and 
> being able to fix problems.
>
> Many of the issues I've reported as bugs, which are all in the process 
> of being deferred to JFX3.0 (if I understand correctly), which is 
> scheduled for over a year from now.
>
> Here is a list of problems I've been running into just this past week 
> -- and I've reported several others.  Most of these apply to any of 
> the *View classes, but some may be specific to one of the types.
>
> - Calling requestFocus() behaves differently from clicking with 
> mouse/tabbing when
> using only keyboard navigation:
>
> Left Mouse Click:
> Current focusowner : VirtualFlow[id=virtual-flow, styleClass=]
> Current focusowner : ListView[id=null, styleClass=list-view]
>
> Tabbing to it:
> Current focusowner : ListView[id=null, styleClass=list-view]
>
> Programmatic requestFocus() immediately after ListView added to Scene:
> Current focusowner : ListView at 1966198[styleClass=list-view]
>
> Why is it not the same?  This seems to be causing issues sometimes 
> where the ListView
> is not properly activated and it is not accepting keyboard input 
> (despite being the
> focusowner as printed above).
>
> - Sometimes ListView starts highlighting every Xth cell when scrolling 
> through list
>
> Scrolling through a ListView using the cursor keys one can get the 
> ListView stuck to
> highlighting only the Xth cell (where X seems to be in the range of 
> the number of active
> Cells).  When there is only few items in the list this bug manifests 
> itself as not
> changing the focus of the item at all (ie, the wrong cell is 
> highlighted).  Usually a
> mouse click on a random item fixes this bug again, but sometimes even 
> that doesn't work.
>
> This bug is incredibly hard to reproduce but the frequency of it can 
> be increased
> by using a ScrollBar Skin that breaks the rule that getNode() should 
> always return the
> same item.  It however happens with the default ScrollBar Skin as 
> well, just much much
> rarer.  I have a test case with a contract-breaking ScrollBar Skin 
> that manages to
> reproduce it almost every time.
>
> - Page up broken when used at bottom of ListView
>
> Scroll down fully with page down.  Now page up, notice that it goes up 
> one page, but the
> next page up only goes up one item for a few times (about a page worth 
> of items) before
> starting to act like a real page up again.
>
> - Pressing Cursor Left/Right on an active ListView changes focus 
> despite keys being consumed
>
> Despite having a handler in setOnKeyPressed that consumes the Cursor 
> keys (to do something
> useful with them) the focus still also changes (ie, it triggers my 
> action AND affects
> a focus change).  I can block them with an EventFilter, but would 
> rather allow users of
> my custom control to still being able to register these keys for 
> special purposes...
>
> - Numerous scrollTo bugs
>
> Poor centering when scrolling to an item (sometimes even outside view 
> port); not responding
> at all when called at inoppertune times (right after populating and 
> adding to scene); unable
> to precisely save/restore view position; creating cells for every item 
> from 0 to item being
> scrolled to... and recently (since 2.2betas) completely failure to 
> draw the ListView at all
> (can take various forms, only scrollbars drawn, somtimes the entire 
> container is missing).
> Restores itself on any ListView redrawing activity, like selecting 
> cell, scrolling with cursor
> keys, etc..
>
> - Numerous focus/select bugs
>
> Similar to above, when these things occur in rapid succession 
> (ListView added to Scene,
> populated, correct item selected, scrolled to saved position) it 
> happens frequently that no
> cell gets highlighted at all (or perhaps the wrong one is highlighted 
> but not visible at
> the current scroll position)
>
> - Cells are sometimes a pixel different in height
>
> Haven't been able to find a pattern to this yet, it happens with the 
> default cell renderer
> when it is styled with some fancy borders.  Very noticable when 
> holding cursor down because
> the borders jitter (create a border with an inset of 1 or 2 pixels so 
> there should be a fixed
> gap between the cells, the gap will sometimes be a pixel larger than 
> usual).
>
> It doesn't seem to be content related as a cell that is a pixel too 
> large in the upper half
> of the ListView can appear regular size in the bottom half of the 
> ListView.
>
> ....
>
> There are probably more I forgot to list or already worked around and 
> forgot about (I seem
> to remember constructing a ListView, not adding it to Scene, but 
> populating it and selecting
> an item and calling scrollTo, and THEN adding it to the Scene works 
> very poorly as well).
>
> Anyway... I'm a bit worried that fixes for these are now over a year 
> away... I don't really need
> much (just a scrollbar, some same height, same width custom cells, 
> nicely stacked on top of each
> other reacting to cursor input) but I just keep running into above 
> problems during normal use
> of the app.
>
> Can I help get these debugged or am I on my own?
>
> --John
>