Creating a Linux Desktop App with Ruby | Hacker News Reader

Creating a Linux Desktop App with Ruby

iridakos.com

134 pointslazaru_s52 comments

For people interested in Python / Qt, I had a related Show HN this week.

Discussion: https://news.ycombinator.com/item?id=16318677

From my reading of the following I your README, I think your understanding of the GPL might be slightly wrong

> This project is licensed under the GPL. In simple terms, this means you can use it for free in open source projects that are also licensed under the GPL. If on the other hand you want to use the project for a proprietary app where you don't want to open source the code, then you need a commercial license. The price for one developer is EUR 79 if you purchase before Feb 11, 2018, EUR 99 after. One year of updates is included. To obtain a license, click here.

If I understand what you are saying, you say that to use the output of your program one needs to GPL everything, which is not usually how GPL is interpreted.

For example I can use GIMP to create graphics that I can use without any form of restrictions. The GPL applies to GIMP itself, not its outputs.

However, since your product builds executables then if the resulting installer file was built from GPLed code then you are partially correct IMO -- users would be required to distribute the installer source in compliance with GPL. However, while I have not looked into how the build process works for your product I have a hard time imagining that the GPL would require users to GPL the installation target source, since those are a separate set of files.

IANAL

IANAL either but believe you are right with the GIMP example. However, my project doesn't just produce an output similarly to how GIMP saves images. It also requires you to link to some of my project's code at runtime. That is where the need for a commercial license comes from.

i read it as saying it's for programming projects. And the output of a programming project is code. And you can't use this project if you don't reduce the code of your own (programming) project - in that case you would need a commercial license.

Over the years I have seen some strange performance issues in GTK, specifically PyGTK, that make me not want to use it any more, and was just wondering if others have encountered these?

- Highly variable window load and startup times

- Random slowdowns

- WebkitGTK has some serious memory leaks

Otherwise I'd consider GTK to be fantastic :/

These days pygobject seems to be the way to go

There's also http://visualruby.net/

I was always fond of wxWidgets. Multi-platform, multi-language bindings.

http://wxwidgets.org/

It still uses Gtk or Motif on Linux/Unix. Here's a diagram with all the layers:

http://wxd.sourceforge.net

For simple apps Shoes!(http://shoesrb.com/) is very nice

Very cool! The DSL reminds me of Red/Rebol.

Oh wow... Didn't know Shoes was under active development. Nice to see the community picked it up.

If it is under active development they should update their photos. It hardly inspires confidence when all of their screen shots are from at least 4 versions of OSX ago.

I gather that most of the development effort is going into Shoes 4, which doesn't have a stable release yet.

Edit: Huh. The Shoes 3 development blog is actually really active! https://walkabout.mvmanila.com/

I'm not a Ruby guy at all so forgive me if I'm missing something here but what would the benefit of using GTK+ be over using JRuby and utilizing JavaFX or even Swing?

JavaFX is not native, it renders closer to Electron than WinForms/GTK/native

That said JavaFX controls feel very nice. Like a foreign GUI, but a nice one

Ah ok I didn't know that.

Most linux desktops have GTK installed already, and ruby. So, you can create a quite small performant GUI this way. JRE is falling out of fashion in my experience as a default install. It's huge, slow to startup, and creates a larger install size.

The JRE has just become modular with Java 9 and it even has AOT compilation these days, plus it has tools to create packages for all OSes.

As for slow startup, just be careful with library selection.

Well, at least unlike Electron, you need a single JRE instance for all your apps.

> It's huge, slow to startup, and creates a larger install size.

I think these tradeoffs are okay for backend services, but I agree that they don't belong in user-facing applications if it can be avoided.

Also, GTK is the "native" GUI toolkit on most Linux distros, whereas a Java-based one is almost guaranteed to look out of place.

Java uses GTK bindings on Linux.

I just ran my old swing app for years ago and it still displays using its own toolkit.

I think you're thinking for SWT (the toolkit used by Eclipse) which will use native components for each OS.

SWT is kinda difficult to use and last time I checked, all the Scala bindings/wrappers were crap or non-existant, making it a non-starter for me.

Starting with Java 9,

JEP 283: Enable GTK 3 on Linux

http://openjdk.java.net/jeps/283

Opening paragraph "Java on Linux currently uses GTK 2. This raises several issues:"

The problem are the ones too lazy to call,

        UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());

https://docs.oracle.com/javase/tutorial/uiswing/lookandfeel/...

What problems would it cause if the runtime just called that automatically?

The usual traditional backwards compatibility story of Java, if I remember correctly.

When it was introduced they didn't want to break the L&F of AWT applications, then they also added multiple ways of enabling it.

So a good application should respect the system wide or user specific settings if available, instead of just blindly use whatever L&F it feels like.

Also although many complain about how Swing looks like, the API is actually quite powerfull and skinnable, even if it requires some graphic programming skills to achieve it, for example see JGoodies or UltraMixer DJ.

I don't know about JavaFX, but I'm almost certain Swing uses its own UI components and doesn't use the native GTK ones, unless that has changed very recently.

It changed when Java moved from AWT to Swing.

https://docs.oracle.com/javase/tutorial/uiswing/lookandfeel/...

    ---------------------------------------------------------
    |Platform                               | Look and Feel |
    ---------------------------------------------------------
    |Solaris, Linux with GTK+ 2.2 or later  | GTK+          |
    |Other Solaris, Linux                   | Motif         | 
    |IBM UNIX                               | IBM*          | 
    |HP UX                                  | HP*           |
    |Classic Windows                        | Windows       |
    |Windows XP                             | Windows XP    |
    |Windows Vista                          | Windows Vista |
    |Macintosh                              | Macintosh*    |
    ---------------------------------------------------------

Apparently not many bother to learn how to take advantage of Swing APIs.

That's what `SystemLookAndFeel` is, which is not the default Look and Feel in the JRE; `MetalLookAndFeel` is, which is what people think of when they think of Java applications. (1) Most Java applications don't set the LAF, (2) most distros don't set the default LAF (in /etc/profile.d/), and (3) most users don't know to set the default LAF.

And saying all applications should set it to SystemLookAndFeel would be wrong, as they should respect the user's settings if they exist.

    _JAVA_OPTIONS='-Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel'

Hence my remark,

> Apparently not many bother to learn how to take advantage of Swing APIs.

Hence my remark,

> saying all applications should set it to SystemLookAndFeel would be wrong

Knowing when to set SystemLookAndFeel is part of "learn how to take advantage of Swing APIs."!

GTK is indeed native

That's a great article, but it rather proves the point that the GTK API is a PITA.

Still, you get a lot of benefit from Ruby's flexibility.

GTK's API is really quite nice, all things considered. I have never felt so sane writing GUI code in a good long time

IMO there's a more general problem with how easy it is to extend widgets in a toolkit when you make use of a scripting layer on top of the toolkit. Even with a nice API, it's difficult to cover all the edge cases when the C/C++ vs high level language barrier exists.

The only non-trivial Ruby based GUI I've built has ended up with a custom toolkit as a result of trying to avoid these sorts of API barriers. The building a new toolkit without the API barrier does result in some lost functionality, some NIH syndrome, but it does provide a bunch of extra flexibility.

Not to criticise the (very well written) article, but IMHO the best solution for rapidly prototyping cross platform GUI applications in Ruby is Electron[1] + Hyperloop[2].

GTK applications look very outdated/out-of-place anywhere outside linux, and especially on OS X.

While electron has its issues (large bundle size, memory footprint), it is a really flexible solution for cross platform desktop applications. It will still not have native appearance, but a modern L&F is quite easy to arrive at using CSS and libraries like react-desktop.

Relying on the browser runtime ensures that most of the form widget interactions work as users would expect them to on their own platform.

Opal[3] is a really good ruby to javascript compiler which can be used to target electron. This is particularly promising given that the hyperloop [2] ecosystem has significantly matured. Hyperloop provides a full fledged component oriented client-side development framework powered by best of breed frontend technologies/patterns like virtual DOM (through react integration [4]) and flux stores.

---

[1] https://electronjs.org

[2] https://github.com/ruby-hyperloop

[3] https://github.com/opal/opal

[4] https://github.com/ruby-hyperloop/hyper-react

Hell no, get that Electron garbage out of here. It produces slow, ugly applications using a framework that has no place on the desktop.

Also, excessive transpilation is something people should really look down upon. Learn to work with the framework that runs, don't go and come up with CoffeeScript or w/e

GTK doesn't look dated, it just looks simple

IMO, they both feel very out of place. One just eats 10x the memory of the other. Not sure that is a better trade off. If an electron app is pretending to be native, it's pretty much a giant sign telling me to look elsewhere.

I get the ease of development argument, but it always feels like garbage even when done "well" like Slack. VS Code is about the only thing that pulls things off OK, but even that is notably slower than alternatives and I blame nobody for sticking with Sublime.

It is not about a ui pretending to look native. It is more about form interaction patterns that users are subconsciously habituated to.

For example:

- Pressing enter submits a form. - Clicking on a label focusses the input box. - In OS X readline style shortcuts are available in all input boxes, eg. Ctrl+a takes you to beginning to line, Ctrl+e takes you to the end etc.

When these things don't behave the way you expect them to, it really destroys the user experience. Building on browser runtime gives a lot of these platform specific accessibility features to you for free - which may not be very trivial to arrive at through cross platform native gui libraries.

Why bother with Electron? Qt is lightweight, has Ruby bindings, and looks native on everything. Use Furoshiki to build distributable binaries for each platform.

I started down the electron path and will probably back out. So many get-started things in electron are just massive boiler-plate. Electron-vue is awful boiler plate with so much pre-made crap I don't understand how any of it fits together and some really simply stackoverflow questions have gone forever without being answered:

https://stackoverflow.com/questions/48337401/unable-to-test-...

Not to mention electron apps are massive (Slack is 90M+ for a fucking chat client. Audium/Pidgin anyone?)

Electron is a huge step backwards really. I don't see why people praise it so much.

So you picked an "awful boilerplate" where you "don't understand how any of it fits together" and that's a failing of Electron?

They're all awful boilerplate. Almost every single toolkit or getting started example I looked at involved cloning something of boilerplate, including React, Vue, etc. I couldn't even find decent clean examples, and as I tried putting them together, there was just a total lack of documentation and frustrating amounts of searching and finding dead/unanswered fourm and stackoverflow posts.

As a fan of Qt I've gotta disagree there. Qt looks native on X11 systems but looks really out of place on OSX.

Electron has more permissive licensing. I'm open to suggestions for a light weight alternative to Electron has an equally permissive license and still looks good. I've done some research and I'm not sure what I can legally do using Qt without open-sourcing my app. This may sound like FUD, because it is, I am uncertain what the legal situation is, can't get a straight answer, and fear I might end up facing a lawsuit or $500 a month in licensing fees. I'm just looking to experiment with a side project and a little passive income, I'm not doing anything that would justify $500 a month.

The QT licencing is confusing because different components have different licences. However Qt is used successfully in commercial projects by sticking to the LGPL licenced components:

https://www1.qt.io/licensing-comparison/

I think I don't know enough about lower level programming to know if I'm dynamic linking or not. I feel like I have a casual understanding of it, but not enough to take on personal liability.

I just recently started experimenting with Qt and it is an actual charm to work with. I haven't tried out any bindings or languages outside of C++ with it yet, and haven't built anything serious, but I understand the love some people have for it better after trying it.

Is this the Furoshiki project you are referring to?

https://github.com/shoes/furoshiki

I'm just wondering since it says it is alpha and only supports Shoes.

Oh, whoops. I knew it was mostly used with Shoes apps right now; I didn't realize it literally didn't work with non-Shoes apps.

Reply on news.ycombinator.com