Re: Usability study was: Think Java, not Electron! was: Apache HTML/Java UI

On Thu, 5 Apr 2018 at 11:55 wrote: > on platforms without javafx the project needs to be created using the > maven -> Create from archetype wizard, as the regular wizard won't run > here. > So, is the HTML-based wizard hidden or does it redirect somewhere else? Sorry if

Re: Usability study was: Think Java, not Electron! was: Apache HTML/Java UI

Hi Toni, On Thu, 5 Apr 2018 at 09:59 wrote: > Working on solving these issues. I've created a PR to change the category > and description as proposed here. I'm also trying to improve the "first > contact" when somebody tries the wizard out of curiosity without knowing >

Re: Usability study was: Think Java, not Electron! was: Apache HTML/Java UI

On Mon, 19 Mar 2018 at 21:18 Toni Epple wrote: > Yes, with java 9 and the jlink tool you can get jvms as small as 13mb. > Yes, that doesn't surprise me, given it's similar to compact profiles of Java 8. But that JavaFX can work with that and is that small surprised me

Re: Usability study was: Think Java, not Electron! was: Apache HTML/Java UI

I agree. With swing/javafx you have a quite complete set of basic ui controls and a small niche market of third party components. With html/css you have a small/incomplete set of controls, but a huge market of free and commercial component libraries. If you want a component suite, you could

Re: Usability study was: Think Java, not Electron! was: Apache HTML/Java UI

Yes, with java 9 and the jlink tool you can get jvms as small as 13mb. Your experiment sounds like alot of fun :) Von meinem iPad gesendet > Am 19.03.2018 um 20:52 schrieb Neil C Smith : > >> On Mon, 19 Mar 2018 at 14:24 Toni Epple wrote: >> >>

Re: Usability study was: Think Java, not Electron! was: Apache HTML/Java UI

> On Mar 19, 2018, at 1:13 PM, Neil C Smith wrote: > > On Mon, 19 Mar 2018 at 16:40 Scott Palmer wrote: > >> Toni, (replying off-list as this really isn’t about NetBeans) >> ... >> Can you point me to one of those third party components that can do

Re: Usability study was: Think Java, not Electron! was: Apache HTML/Java UI

On Mon, 19 Mar 2018 at 16:40 Scott Palmer wrote: > Toni, (replying off-list as this really isn’t about NetBeans) > ... > Can you point me to one of those third party components that can do what > JTable or TableView already does? > As didn't quite manage off-list ;-) A

Re: Usability study was: Think Java, not Electron! was: Apache HTML/Java UI

Toni, (replying off-list as this really isn’t about NetBeans) I’m not even at the “large data set” point yet. I’m talking about the basics - a table with data that scrolls independently of column headings. So far anything I’ve found that tries to get the table headings to align with the data

Re: Usability study was: Think Java, not Electron! was: Apache HTML/Java UI

There‘s no standard control that is usable for large data sets, but plenty of data grid components from different third parties, and it‘s not hard to roll your own if you have special requirements. I did that for a customer, and it took me about a day. —-Toni Von meinem iPad gesendet > Am

Re: Usability study was: Think Java, not Electron! was: Apache HTML/Java UI

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

Re: Usability study was: Think Java, not Electron! was: Apache HTML/Java UI

> On Mar 19, 2018, at 10:25 AM, John Kostaras wrote: > > *"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

Re: Usability study was: Think Java, not Electron! was: Apache HTML/Java UI

*"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

Re: Usability study was: Think Java, not Electron! was: Apache HTML/Java UI

On linux a natively packaged JavaFX application is about 40mb (without webview). I don‘t think we need any of the Electron / NodeJS APIs when we use our HTML/Java APIs, since we have access to the complete Java API. We’ve been developing reasonably large applications with it, and we didn‘t miss

Re: Usability study was: Think Java, not Electron! was: Apache HTML/Java UI

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: >

Re: Usability study was: Think Java, not Electron! was: Apache HTML/Java UI

On Mon, 19 Mar 2018 08:05:13 +0100, Toni Epple wrote: But I‘d love to replace JavaFX WebView which is a 49mb Java 9 module with chromium content module, Which is about 40-50 mb and has better features. If we want HTML5 for Java UIS, I believe this is the way to

Re: Usability study was: Think Java, not Electron! was: Apache HTML/Java UI

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. But I‘d love to replace JavaFX WebView which is a 49mb Java 9 module with chromium content module, Which is about 40-50 mb and has better features. Von meinem

Re: Usability study was: Think Java, not Electron! was: Apache HTML/Java UI

Wow, I just read the blog post and I have to say… wow…… this blog really speaks the truth. We have JS engine embedded into the JVM. Is it unusable? — Kirk > On Mar 18, 2018, at 9:15 PM, Kirk Pepperdine wrote: > > >> On Mar 18, 2018, at 2:57 PM, Neil C Smith

Re: Usability study was: Think Java, not Electron! was: Apache HTML/Java UI

I did not read all the e-mails in this long thread, and I'm probably somewhat late to answer. 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:

Re: Usability study was: Think Java, not Electron! was: Apache HTML/Java UI

> On Mar 18, 2018, at 2:57 PM, Neil C Smith wrote: > > Hi Kirk, > > On Sun, 18 Mar 2018 at 08:12 Kirk Pepperdine wrote: > >> There are entire classes of applications that cannot be easily managed in >> HTML today. HTML/JS simply doesn’t scale in it’s

Re: Usability study was: Think Java, not Electron! was: Apache HTML/Java UI

Which is funny to me because when I was working most of the time with Swing (the IDE and platform apps), I focused mainly on responsive UIs. I think a lot of it comes down to specifying specifically what we are talking about. Given a specific UI of form components, making a responsive and

Re: Usability study was: Think Java, not Electron! was: Apache HTML/Java UI

Hi Kirk, On Sun, 18 Mar 2018 at 08:12 Kirk Pepperdine wrote: > There are entire classes of applications that cannot be easily managed in > HTML today. HTML/JS simply doesn’t scale in it’s current incantation. > Without Swing/FX there are no good alternatives in Java. > This

Re: Usability study was: Think Java, not Electron! was: Apache HTML/Java UI

On Thu, 15 Mar 2018, 20:08 Jaroslav Tulach, wrote: > Hello Dmitry, > thanks a lot for trying it out! > > 2018-03-15 2:50 GMT+01:00 Dmitry Avtonomov : > > > I find it incredible that Jaroslav is saying "... people aren't willing > to > >

Re: Usability study was: Think Java, not Electron! was: Apache HTML/Java UI

There are entire classes of applications that cannot be easily managed in HTML today. HTML/JS simply doesn’t scale in it’s current incantation. Without Swing/FX there are no good alternatives in Java. Regards, Kirk > On Mar 18, 2018, at 12:38 AM, Gili T. wrote: > > I

Re: Usability study was: Think Java, not Electron! was: Apache HTML/Java UI

Hi Toni, I was referring exclusively to Swing's ability to resize components in response to changes in the container size. What makes it "even better" is the ability to specify the desired behavior more directly. Contrast this with HTML where you need to use voodoo magic to center text and

Re: Usability study was: Think Java, not Electron! was: Apache HTML/Java UI

Gili, Are we talking about the same concept of responsiveness? In UI development this term is used for guis that adapt to a wide variety of screen sizes and resolutions by applying different layouts, resizing and replacing, rearranging or showing/hiding components depending on size, pixel

Re: Usability study was: Think Java, not Electron! was: Apache HTML/Java UI

I humbly disagree. Last time I played with Swing layouts I remember them being able to do responsive UIs even better than HTML. The only thing that web does better is more existing layouts out of the box. That's just a matter of people not technology. Gili On Sat, Mar 17, 2018, 07:39

Re: Usability study was: Think Java, not Electron! was: Apache HTML/Java UI

"All I'm saying is that with the last N years of unprecedented attention the web technologies have leaped light years ahead of everything else in terms of basic UI." As far as I can tell, that is a a false statement. Web UIs are still severely behind for complex layout and even something as

Re: Usability study was: Think Java, not Electron! was: Apache HTML/Java UI

On Sat, 17 Mar 2018, 07:34 Dmitry Avtonomov, wrote: > ​All I'm saying is that with the last N years of unprecedented attention > the web technologies have leaped light years ahead of everything else in > terms of basic UI. > ... > All I need is a good framework on

Re: Usability study was: Think Java, not Electron! was: Apache HTML/Java UI

​All I'm saying is that with the last N years of unprecedented attention the web technologies have leaped light years ahead of everything else in terms of basic UI. 90% of the time all I want is: - A text label that's attached to a text field (maybe with a set of allowed characters and special

Re: Usability study was: Think Java, not Electron! was: Apache HTML/Java UI

Oh, I'm sorry. I was under the impression that with JS you had to write functions to do all those things. My ignorance showing On Fri, Mar 16, 2018 at 2:28 PM, Dmitry Avtonomov < dmitriy.avtono...@gmail.com> wrote: > @Chuck > Yes and no. I mean HTML+JS+CSS. I'm still struggling with

Re: Usability study was: Think Java, not Electron! was: Apache HTML/Java UI

@Chuck Yes and no. I mean HTML+JS+CSS. I'm still struggling with something like the attached image (hopefully the attached image won't get cut out). There's mig layout that sort of comes close, but overall my experience with swing (including its layouts) is that it's fine as long as I need to

Re: Usability study was: Think Java, not Electron! was: Apache HTML/Java UI

P.S. And JavaFX layouts are an order of magnitude better than Swing layouts. On Fri, Mar 16, 2018 at 11:50 AM, Chuck Davis wrote: > Dmitry, that is the whole purpose of Swing layouts. HTML tables cannot > compare with the functionality of layouts. > > > I also constantly

Re: Usability study was: Think Java, not Electron! was: Apache HTML/Java UI

Dmitry, that is the whole purpose of Swing layouts. HTML tables cannot compare with the functionality of layouts. I also constantly find myself struggling with creating forms in swing that > are just used to represent parameters for command line programs, it's > always tricky for me to make

Re: Usability study was: Think Java, not Electron! was: Apache HTML/Java UI

I'm talking about on the order of ~1Gb data used in the view. I have data from scientific instruments, when an interactive view is fully zoomed out showing all of the data at once I basically have to have it all in memory to maintain decent performance. Here's a video of the app in use: