I wrote a „big table“ control for a customer who uses the html/java APIs a while ago, so I think it would work.
I know that OutlineView has issues with huge data sets, since it’s simply not meant for this, but it‘s surprising that JTable has such issues. I used it a lot for huge datasets in the past, and the performance and stability was really good. When I switched to JavaFX this was the control I missed most, because JavaFX TableView is horrible (Slow, buggy and it’s hard to modify simple things like focus traversal and editing) —Toni Von meinem iPad gesendet > Am 19.03.2018 um 15:25 schrieb John Kostaras <jkosta...@gmail.com>: > > *"This is the bit I don't understand. Why would you want to do that? > In every Swing component I can think of you wouldn't render an entire > large data set in the view in one go or it would grind to a halt - you'd > render a subset/summary/coalesced view of the model surely? The point of > this approach, at least as I understand it, is to still do all the data > set interaction, filtering and calculation on the JVM."* > > This is why we need components that retrieve only the data that need to be > rendered in their window and be smart enough to retrieve/cache the data the > user will request next. Like others here, our application needs to render a > lot of data in an OutlineView (or JTable) and be responsive when the user > moves this scrollbar. Not only, these data are updated constantly and we > had bugs in the past with all these listeners. Not to mention, that with > many data that change all the time, it can become unresponsive. > > Eclipse provides this Nattable <https://www.eclipse.org/nattable/>, I don't > know how good it is, but it advertises itself as a high performance SWT > data grid. Personally, I 'd love to have this ported in NetBeans. If this > could be achieved with HTML4Java is fine with me too. > > Regard, > > John. > >> On 19 March 2018 at 11:51, Neil C Smith <neilcsm...@apache.org> wrote: >> >> On Mon, 19 Mar 2018 at 00:52 Victor Williams Stafusa da Silva < >> victorwssi...@gmail.com> wrote: >> >>> But since people are/were talking about electron >>> (or other replacements for Swing/AWT/JavaFX), let's give a look at this >> and >>> not commit the same mistakes: >>> https://josephg.com/blog/electron-is-flash-for-the-desktop/ >>> >> >> That Electron apps can be resource hogs I don't think is in dispute >> (although everyone seems to use Slack as the example - maybe it's just >> them! ;-) ) >> >> However, I think we're playing with the assumption, which might prove to be >> incorrect, that it is the backend part of these (and the interesting >> blocking behaviour) that's most of the problem. So doing all the >> application logic still on the JVM mitigates that. If it's actually the >> embedded Chromium that's the problem ... >> >>> On Mon, 19 Mar 2018 at 07:05 Toni Epple <toni.ep...@eppleton.de> wrote: >>> >>> I have no plans to embed electron as it would be overkill. A HelloWorld >> is >>> 115 mb and contains nodejs and desktop APIs we don’t need. >>> >> >> How big is a native packaged JavaFX Hello World then? ;-) >> >> I agree with you about nodejs, but some of those desktop APIs are useful. >> Assuming a fully HTML UI application, surely we'd need those from >> somewhere? I guess my thinking is more launcher, Chromium content, desktop >> API's and minimal profile headless JVM. >> >>> On Sun, 18 Mar 2018 at 20:16 Kirk Pepperdine <k...@kodewerk.com> wrote: >>> >>> A large part of the problem is the translation of the data set to HTML as >>> sometimes it’s difficult to know what is immediately needed. >>> >> >> This is the bit I don't understand. Why would you want to do that? In >> every Swing component I can think of you wouldn't render an entire large >> data set in the view in one go or it would grind to a halt - you'd render a >> subset/summary/coalesced view of the model surely? The point of this >> approach, at least as I understand it, is to still do all the data set >> interaction, filtering and calculation on the JVM. >> >> Best wishes, >> >> Neil >> -- >> Neil C Smith >> Artist & Technologist >> www.neilcsmith.net >> >> Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
