The JetBrains suite (ie IntelliJ, Datagrip etc) while not open source, are a testament to what can be done with JVM based GUI applications.
Have you ever used the merge tools? So dang cool.
Have you ever used the merge tools? So dang cool.
If the UI toolkit can't get a button right, it is completely broken IMO. Even including intelliJ products, I have never used a Java GUI which was good.
Part of them because i didn't fully understand Swing when i began the project and partly because synchronizing GUI's to another live process is a quite error prone task.
A debugger process is almost certainly not living in the same thread as the Swing UI of IDEA so this almost surely more of a thread synchroniztion issue rather than Swing issue. (You really don't watch to do any cross-thread touching with Swing apart from for a very limited set of components built for this).
In intelliJ it was like whenever the UI was not immediately responding to mouse events, it would often just lose the event instead of it being correctly processed once the UI thread was freed up.
In the case of IntelliJ there is probably some of their code accepting the event and then probably has some ad-hoc message passing by setting a field that is polled by the receiver thread under the assumption that the receiver always runs faster than a human can act, however as soon as that assumption is broken by some pause you get what you describe.
OK - it's loading so that's not unexpected. However my previous experience was that the same thing would happen to the UI at all sorts of surprising moments when other processes were ongoing, such as linting or using the debugger. Kind of hard to reproduce without a large project at hand though.
Then I had to stop testing and SIGKILL it because the whole application got into an infinite loop of NPEs in the UI event loop of all places!
I too experienced using intelliJ for many years and this seems largely in line with what I remember.
I have it configured as my git mergetool
The only problem is it takes absolutely ages to start up, which is maybe a JVM thing
I wish there was a way to have git pass all of the conflicting files in a merge to the mergetool at once. Instead of having to wait for JetBrains to load up for each individual file and close after each one :(
How are you doing this? I haven't seen any merge tool, let alone a standalone one, in the JetBrains toolbox. What am I missing?
IDEA is slow(ish) to start because it's an IDE so it's loading tons of plugins, a project database etc. Though actually recent versions only take a few seconds on my admittedly high end MacBook.
TBH I never got on with PyCharm and still use Sublime Text... but I keep PyCharm installed just for the mergetool!
I.e. the amount of UI problems you have with it when using a tiling wm or wayland (or both) are just sad and make it unusable. Other widely used UI's might also have problems but at least are somewhat usable under wayland and/or tiling wm.
Ironically many of this problems go back/are rooted in to AWT...
In the past Intellij did work if started directly by x (without a wm) which was pretty cool for some very very neach use cases, but sadly (through reasonably) this isn't the case anymore.
Especially the quick command/search menues doesn't work at all and context menues sometimes don't work either.
(Edit: And context/popup menues not working is the main theme of problems with Java GUIs, hence my parent post, also setting the "magic" no-reparenting env variable doesn't fix it)
If the JVM based apps do not yield a significant performance benefit then there is no point in going after that.
Through tbh. I don't see much reason to spend time for a Java UI framework, Java for desktop is just kinda annoying and somewhat even more dead then Java for servers (which isn't really dead tbh).
Through I guess idea/Intellij would love to replace the low level parts with something which works more reliable.
Also I don't think the desktop app market for java is small in any way. But if there's no difference between electron and JVM UIs then there is no incentive for teams to switch.
>The second is the DOM. It is a horrible collection of hacks that make simple things hard and hard things impossible. I have thought many times “if only was I drawing this control/layout directly, I would’ve finished hours ago.”
As a user of electron apps there are clearly limitations on what the UI can do as a result and the style of rendering it is clearly webish.
Another issue I keep on seeing with web based apps, moreso on android, is they seem utterly incapable of dealing with the slightest network non-connectivity. The UI tends to freeze.
I do take your point entirely on the fact that perhaps java's inherent performance limitations might result in a fairly comparable poor experience however.