I just wanted to make a simple GUI program. You know, one that lives on your computer hard drive and creates, modifies and saves files, then uses that data to do things. Oh, and I wanted it to be cross-platform, meaning it would work on Windows, MacOS and Linux with little or no modification.

Sounds easy, right?

Previously: Everything doesn't have to be a web program

Well, despite the fact that local GUI programs aren't exactly dead — web browsers are GUI programs, for Christ's sake, the average coder is less and less interested in writing programs that run on desktop and laptop computers and almost exclusively interested in creating web apps that run in a browser and that maybe, possibly get magically turned into mobile phone apps through some voodoo with React Native or a similar and massive hunk of code.

"But I don't want to worry about security and establishing a account system for my app, which really should just run as a local program on a local PC," I said.

Read the rest of this post

I got the input_value: bad bigarray kind error in Unison. What I did before I got the error was to change some permissions on files on the server. Unison is not picking those up from the laptop, and the process ends with the error and no file transfers.

This makes my last entry somewhat problematic.

I tried the Windows version of Unison once, and it was permissions trouble that kept me from using it. The Unison files in Cygwin are living in a Windows filesystem, and maybe it's still a problem.

tl;dr: The Windows Subsystem for Linux is shiny and new, and its great when your environment has to be exactly like Ubuntu (or whatever distro your WSL is based on), but if your aim is to use Linux tools on Windows files, Cygwin is a better choice.

Cygwin, the Linux environment for Windows, has been around for a very long time, but I've never used it. Until now.

During the year or so that I've been running Windows 10, I tapped into the Windows Subsystem for Linux (aka Bash on Windows, aka Ubuntu on Windows) as my Linux-in-Windows environment so I could have the best of both worlds, or at least all of one world and a great deal of the other.

When I first started with Windows 10 and the WSL, what I thought I would do with Linux on Windows was manage files and do little sysadmin-style tasks like update this blog via Unison (very doable in the WSL) and back up Windows files (NOT doable in the WSL). I thought I could have a Windows computer but do everything in a Linux shell.

It was not meant to be.

Once I realized that my WSL and Windows filesystems were on two different islands and that using one system to edit the other's files was difficult at best and file-destroying at worse, I abandoned my idea of using WSL Linux tools to manage my Windows environment.

As I say above, I used the WSL as my Windows 10 blog-writing and syncing environment, and it has worked very well for that task, except that my files are all in the WSL filesystem, and I have to do all of my writing in the WSL's Bash shell. That's not a hardship per se. I used the opportunity to improve my Vim skills, and I got even better with Vim when I began using it on the Windows side to do my text processing and editing.

Still, having to transfer text files and images from Windows to Bash/WSL was an extra step. I do have a Bash script that does it for me, but it would be easier if the WSL could work with files anywhere on the Windows drive..

Recently something — and I can't remember what that something was — got me thinking about Cygwin. It has LOTS of Linux packages, including the old version of Unison that I had to pin in Ubuntu WSL so my syncing setup would continue working. And it was made to work in the Windows filesystem.

I downloaded and installed Cygwin, and I began building up my environment. I even added X and the Geany text editor just to see how the GUI works. (It's awkward but usable. Unlike X on the WSL, it is supported.

Unfortunately, while I initially got Cygwin's Unison to work with my Linux shared-hosting account, once I changed some file permissions on the server, the file-synching program stopped working. So I'm back to the WSL for my Unison synching needs. I also installed rsync, and I still hope to be able to use it to back up the Windows side of the laptop.

I've already been using Cygwin instead of the Git Bash shell (which I've been using since I discovered it in my Windows right-click menu) to create files and directories in Windows, though Cygwin's failure to run Unison seamlessly with a Linux server on the other end has somewhat tempered my excitement over having yet another Linux alternative in Windows. Today I just right-clicked into Git Bash to create a few files and directories for my morning news production.

You may be thinking, "If he's so comfortable with Linux tools, why use Windows at all?" That's a fair point. I'm not happy about Cygwin's inability to sync with a Linux server, but I still have the WSL, and I recognize its value.

That was a spectacular SpaceX launch in the skies to the northwest of Los Angeles

A link on Reddit led me to this Soundslice version of a 1993 Ted Greene guitar clinic at the Musicians Institute in Hollywood.

While a lot of human effort from a guy named Jon, who does have a Patreon account, went into transcribing every note in the video, the technology that makes this happen is revolutionary.

Basically you watch the video, and below it, the music unfolds with a line sweeping by every note and chord as Ted plays it. It opens up the harmony right there for you.

Click the image above to see what I'm talking about. Or just watch the video.

I am getting so much more out of the video now that I know every note being played. I'm not saying this is the only way to present an interactive transcription of a music lesson on a video, but it's a pretty great way of doing it. Soundslice should be commended for what they've built here.

It looks expensive as hell to embed on your own website, but it's cheaper to use on their domain, and it's an amazing technology for teaching music.

Watch the video to see what I mean.

Desktop GUI programming used to matter. Just about every programming language offered a way to build a desktop application that wasn't tethered to the terminal.

And many programming languages either ship with or allow the installation of modules that allow for a desktop GUI.

Javascript, unfortunately, didn't do it in a lightweight way. While I've heard rumblings of some kind of React-based way to create a desktop GUI via Node.js (aka Javascript in your local terminal), the language of the web (and now servers everywhere) has latched on to Electron, basically a full Google Chrome browser in a local window.

I just want a GUI to be a GUI. Java has the once-new (wasn't everything) JavaFX, and the still-old Swing, but there's no excitement and few tutorials. That doesn't mean JavaFX isn't one of your best bets in creating desktop GUI software. For better or worse, it is.

The computing world really wants you to write GUI applications in whatever frameworks Microsoft or Apple offer. I want something cross-platform. I'm not interested in Swift, Objective C or C#, though I do have to admit that C# code looks as clear as anything out there.

While I like the apps I see written in QT, which is cross-platform, that just doesn't seem to be my thing. Sure, I've coded in C++, but it's not something I'm hankering to revisit.

I've written a little Perl, but that holds little attraction at this point.

My language of choice at the moment is Ruby. It should be Java (or Clojure, Go, Elixir, Haskell ... you get the idea), but it's Ruby.

Ruby used to have people who were sort of interested in GUIs. There was a RubyFX project at one point. Abandoned.

Ruby Shoes was clear and concise. For some reason it now only runs with JRuby, the Ruby on Java. The MRuby (aka "regular" Ruby) version was abandoned.

There's a GUI that still ships with Ruby. It's the same one that ships with Perl and Python.

It's called Tk.

Tk is old school. I think people cared about it once. It is tied to the TCL programming language. Those ties are close enough that I considered figuring out how TCL works and coding in that.

But Tk still works, and it is sort of, kind of still under development. I think.

The problem is that there are few resources for learning Tk with Ruby or Perl. I have been using the Tkdocs.com website, and I managed to get the first sample GUI program working. It's a simple converter from feet to meters, and I've been able to start hacking together my own program from that shell.

I'd love a book on Tk and Ruby that was published in the past 10 years. I might just have to settle for an old book.

For some reason or maybe a few, I have avoided coding in Python. I might have to change my mind. There is more interest in Tk in the Python world. I think there are even recent books on the Python and Tk. There might even be newer tutorials on the web. I've stumbled across a book from Packt, but I haven't investigated the web resources.

Right now my command-line application -- which is working, by the way -- is written in Ruby. So I'd love to stay in Ruby and figure out Tk.

But I'm at a crossroads. I feel like I'm reinventing the wheel by trying to code a GUI application in Ruby. Maybe I'd have an easier time reimplementing everything in Java. I'm sure I'd be better off going with Python.

I could also do this as an Android app. That way I could use it on my phone and tablet and have a GUI framework (that being Android itself) that isn't mired in the 2000s.

For those who say, "just do it as a web app," I don't want to deal with the security issues of running a web-exposed service. Maybe I should figure that out. This still feels like a desktop GUI application. There's no reason for it to be a browser-controlled, web-based service.

If I stick with Tk, I'm not sure a TCL- or Python-focused book will get me where I need to be. I might have to travel back in time to 2008, when Ruby was hot, and grab whatever Ruby GUI books were out then.

I thought I wanted to make my blogPoster Ruby script more class-based (currently it is 0% toward that goal) and leave the GUI for later. But now I'm thinking GUI first.

I'm reading the excellent "Head First Ruby" book, and that is doing a great job of teaching me how classes work in Ruby. I'm excited about that, and it pulls me in yet another direction.

This is what learning programming and just programming (where you're always learning) are all about. That's what I'm telling myself, anyway.

Whenever I listen to Tuck and Patti, I want to go to Tuck's Corner, where Tuck Andress talks about all of their gear.

But Tuck's Corner doesn't appear on the duo's current web site. It's not gone forever. It lives on the Wayback Machine.

Tuck Andress sounds so great. His tone is unique and not at all what you expect from an archtop guitar, and like all great players, his time is amazing. More than anything, music is about time.