*"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 <[email protected]> wrote: > On Mon, 19 Mar 2018 at 00:52 Victor Williams Stafusa da Silva < > [email protected]> 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 <[email protected]> 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 <[email protected]> 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 >
