5 ms·
> To maintain parity across the codebases, we had to implement and design the same features twice. If we ever wanted to add Linux support, we’d have to do it al
by MarkMc 9y ago
> To maintain parity across the codebases, we had to implement and design the same features twice. If we ever wanted to add Linux support, we’d have to do it all a third time....Now we can share our logic and UI across all platforms, which is fantastic
I wonder whether they considered Java with SWT. For the past 10 years I've been developing an accounting application for Windows and Mac using SWT, and it's been a blessing to have such a simple, stable, cross-platform UI library.
It's also possible to implement plaform-specific behaviour. For example, standard SWT doesn't allow a native toolbar on Mac, but with a few 'if (mac)' statements I made my application look exactly like all other Mac apps:
http://imgur.com/a/l83yI http://imgur.com/a/l83yI
I'd say about 95% of my UI code is platform independent.
- DaiPlusPlus 9y agoI haven't touched Java UIs since university - back then we were taught about AWT and Swing. I remember being unhappy with AWT because it never worked right and was inflexible - and I was equally unhappy with Swing because it never looked or felt native - and for some reason window resize redrawing was done slowly. I first heard about SWT more recently and it brought back my faith in the native desktop, but I've never used it. In your experience, how well does SWT handle the differences between platforms (fundamental things like macOS vs Windows' menu-bars, to smaller things such as the arrangement of buttons in a dialog)? What is the graphics performance like too?
- MarkMc 9y agoYes AWT/Swing was bloated, buggy and slow - Sun's poor UI implementation really doomed Java on the desktop. But then IBM came along and did it right: SWT is super fast and lightweight because it simply calls underlying native API like Cocoa or Win32. It's always been super fast even when I started 10 years ago. Layout of components on screen is straightforward and much easier than Swing. (Just use GridLayout 90% of the time). I have to specify different margins and fonts for Mac and Windows and you will need to change the order of the OK/Save and Cancel buttons, but that's not a big problem. (In fact there is a library called JFace which can do alot of this stuff for you, but it comes with a lot of baggage so you may just be better off with pure SWT). The difference in menu bars is perfectly handled by SWT, and it includes Mac-specific menu options like having the Preferences and Quit menu item in the application menu. You may notice a loss of fidelity here and there - for example, on Mac my error messages don't look exactly like a standard Mac error dialog: http://imgur.com/a/znehj http://imgur.com/a/znehj I'm sure I could fix this with 'if(mac)' and breaking out to the native OS, but in 10 years it's never been a high priority for me. -------------------------- By the way, here's a juicy story about why IBM developed SWT: http://www.mail-archive.com/jug-discussion@tucson-jug.org/msg00355.html http://www.mail-archive.com/jug-discussion@tucson-jug.org/ms... A few choice quotes: "At IBM we hated Swing from day one. Big, buggy, and looks crap" "All of the IBM developers are the same crowd who used to work with Smalltalk, and we reluctantly under management orders built our WebSphere Studio tools using Swing. It was a terrible, buggy, monster. In our initial previews when it was demo'd against Microsoft Visual Studio products all our users hated it just because of how it looked, never mind what it let you do" "Swing was so badly broken deep down in the way it reads windows events...they read their event queue in a way that can leave memory holes so we had to have our own loop polling the windows event queue to do this correctly.....We tried over and over to get Sun to fix this but Amy just didn't understand this" "Swing is like Java deciding not to do native IO using the operating system, but instead to use the disk motor arm API and read and write the disk data segments themselves."
- lacampbell 9y agoThe UI situation for Java is so confusing. Why are you using SWT and not JavaFX or Swing or...? In 2017, where do you start?
- pjmlp 9y agoJavaFX is the way to go. If you also need to target Android, then it is a bit harder. Yes there is now a port of OpenJavaFX to it but it was still a bit of work in progress, specially since it requires Java 8. Probably the best way is to use MVVM and have separate views for JavaFX and Android.
- Scarbutt 9y agoI think having to install a JRE is no go for lots of devs, unless you bundle the JRE but still lots of devs will complain because Java. I wonder how Jetbrains manage to handle all the anti-JVM/Java crowd. BTW, where can I trial your software?
- MarkMc 9y agoYes I bundle the JRE with the download. In the old days I created a custom JRE with all the cruft stripped out but these days it's not too much to ask uses to download 50Mb. Hopefully with Jigsaw I can easily produce much smaller JREs in future. You can try it here: https://www.solaraccounts.co.uk/ https://www.solaraccounts.co.uk/
- tonyedgecombe 9y agoOff topic but did you ever get round to supporting multiple currencies?
- MarkMc 9y agoNot yet. A workaround is to set up a second business with a second currency.
- stephenr 9y ago> I wonder how Jetbrains manage to handle all the anti-JVM/Java crowd Im definitely anti-jvm. I'm also a daily user of IDEA. Nothing else comes close to the same level of functionality with the breadth of language support available, on macos.
- kodfodrasz 9y agoAs one who has experience with multiple UI frameworks, and 2 years of SWT i can only say that it is on par with Gtk+/C Gui development experience. It is terrible, with those int constants all around the API, not groupped in any intuitive way, to communicate what should be Or-able with what. The widgets are stupid, as to be native everywhere they usually provide only the common features. Swing is way better choice, if you are on Java and want nice, feature rich, and somewhat (screen size) responsive UI. I don't know JavaFx, but it may be worth a try also.