Little worried about the ListView/TreeView/TableView classes
Christian Schudt
christian.schudt at gmx.de
Tue Jul 10 11:57:25 PDT 2012
John, I share your worries. During the last two months I reported 13 bugs. 5 of these were targeted for Lombard, 6 are still unscheduled and only 2 were scheduled for 2.2.
Generally speaking I got the impression, that there are more important issues, as can be also seen here in the last comment:
http://javafx-jira.kenai.com/browse/RT-20616 (which is already Priority Major)
I don't know what these priorities are, but in my opinion fixing bugs and stabilizing existing code, should be high priority for a new release, especially if they are a regression from a prior version, like this one:
http://javafx-jira.kenai.com/browse/RT-21936 (worked in 2.1 beta and is now targeted for Lombard, too)
I would appreciate, if the JavaFX Team let the community know, what these priorities for 2.2 are and when it is supposed to be released.
Have you (Oracle?) considered to release further minor 2.x releases until JavaFX 3.0? I worry, that 2.2 won't be stable enough to work with until Q3 2013.
Best regards,
Christian
Am 10.07.2012 um 00:51 schrieb John Hendrikx:
> 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
>
More information about the openjfx-dev
mailing list