- Upgrading to the newly released SWT 4.19
- Revising scaffolding to generate proper-Ruby-namespaces for Model and View just as done in the recent Tetris sample (instead of just models/views non-namespace directories like Rails does), thus better adhering to the Ruby way of simply relying on require statements in establishing dependencies (distancing itself from the often decried Rails way of autoloading)
- Supporting `c_combo`, `c_tab_folder`, and `c_tab_item` variations on the `combo`, `tab_folder`, and `tab_item` widgets to permit further customizations to font/background/foreground/height and display of an unlimited number of tabs with a dropdown.
- Adding two new samples "Hello, C Tab!" and "Hello, C Combo!"
- Finally addressing the slow startup time of the `glimmer` command, which used to start jruby twice, the first time to determine what options were most appropriate depending on the platform you are on (e.g. Mac requires the -X-JstartOnFirstThread switch) and then running jruby again to start the glimmer app. That ended up wasting a lot of startup time, which fortunately Glimmer packaged (released) apps did not suffer from (they do not rely on the glimmer command given they are native-executable packaged). Also, obviously this was not a truly serious issue given that software engineers could always run glimmer apps directly with jruby anyways, yet just a minor inconvenience. Thankfully, this has been eliminated by relying on JRuby environment variables to set options at gem setup time (it now has a new command `glimmer-setup` for the Mac only where needed), cutting down the glimmer command startup time across the board in half (from about 20 seconds to 10 seconds on an old 2015 MacBook Pro... should be much faster on newer machines)
About the last point, a further thing to note is there are many solutions to reduce the jruby startup time or even eliminate it in Glimmer apps during both development and production. I have been relying on such solutions even if I did not blog about them before, which is what has been keeping me pumping out Glimmer DSL for SWT apps at light speed as everyone would attest by reading my frequent blog posts.
Please keep in mind first of all that for most business apps, it is not a true issue since users tend to start the app and leave it on all day long, and Glimmer DSL for SWT performance via JRuby is very fast after app startup. Glimmer DSL for SWT productivity, maintainability, and extensibility benefits way outweigh any costs associated with startup time in the enterprise.
That said, in development, it would be useful to reduce the feedback cycle or even eliminate it, and in production, it would be nice to bring up an app instantly if a user uses it often and shuts it down immediately afterwards (still, that is not the common case in the enterprise, which is why I have not given this much attention before).
Regarding development, here are your options:
- Use Gladiator (Glimmer Editor), which enables you to run any Ruby file instantly (with zero delay) via CMD+R, including Glimmer GUI DSL code. You can see a demo of that on the Gladiator project page (included below).
- If you prefer another Ruby based Editor/IDE (e.g. Redcar or Arcadia), write a plugin to preload the Glimmer DSL for SWT library (and start with -X-JstartOnFirstThread on the Mac) if needed (should not be needed with Redcar since it runs on SWT too). That way, you should be able to run Glimmer GUI apps instantly as well.
- Run your code in the included Glimmer Meta-Sample editor, which starts it instantly.
- Use GIRB (Glimmer IRB), which enables trying out snippets of Glimmer GUI DSL code and seeing app GUI materialize instantly. GIRB is mostly well suited for running small snippets, so it is great for experimentation and learning with the Glimmer GUI DSL.
- Try passing the `--dev` JRuby option to the `glimmer` command (can accept any jruby option and passes it through), which according to JRuby command documentation, prioritizes startup time over long term performance.
Otherwise, concerning production, you have these options:
- Build your app as a system tray app (Tray is featured in SWT Widgets). That way, the app stays in the background at all times even if its main window is closed, and can be brought back up instantly.
- Build your app as a daemon app (aka service or server/client architecture) so that if you close the GUI, the app merely closes the client window while continuing to run in the background. When you start the app again, you have a shell runnable or C executable (can be generated for free with Platypus) that simply alerts the daemon to show its window instantly. The communication mechanism can vary, including DRb (aka druby or distributed ruby run via C Ruby to start fast and connect to the JRuby daemon) or file-based communication (dropping a file somewhere in the user directory). I have tried the DRb approach successfully in the Glimmer Timer sample "glimmer-app-type-client-server" branch
- Use Nailgun, which provides similar daemon support to the last idea, but at the JVM level (I have successfully conducted an experiment with this)
- Use Drip, which spins an extra JVM ahead of time when you start an app and keeps it running for the following run, which starts instantly (I have not tried this yet, but if you try it yourself, please blog about your experience and share here in a comment).
- Consider contributing to the new Glimmer DSL for Tk early alpha project, which aims to bring Glimmer DSL for SWT niceties to C Ruby (aka MRI) and thus has a much faster startup time than the JVM, albeit keep in mind the trade-offs of Tk like being less enterprise-grade than SWT and requiring Ruby recompilation on every platform, but nothing could stop a highly motivated open-source software engineer from changing that, I'm sure of it.
In any case, here are the new Hello Samples for `c_combo`, `c_tab_folder`, and `c_tab_item`
If you ever have questions concerning Glimmer DSL for SWT, do not make assumptions as it is always a better idea to contact me via Gitter, Blog Comments, or GitHub Issues given my deep experience and expertise with desktop development, JRuby, SWT, and Glimmer/Glimmer DSL for SWT.