Sunday, 13 August 2017

On GUI's in Python and D…

I recently wrote a forum post regarding my experience with finding a suitable GUI in which to build a small toolkit.  My primary need, was for something I could hit the ground running on (because I already had a partially built application, but was wasting too much time fighting the toolkit), and which I could dump on a friend to just click and run.  Not the best of selection criteria, nor did I do a particularly exhaustive search for options (some very good ones of which were pointed out by other posters on that forum), but these things happen out there in the real world — sometimes your selection is legacy, and/or even just plain comes down to "the devil you know", though I don't think that was the majority case in this instance.  Anyhow, I'm going to re-post that post here, more or less…

Anyhow, here goes:

I've just recently gotten back into building applications with GUI's myself, after a 20 year lull.  Back then, it was Linux with GTK2; GTK3 and Glade were pretty new and a little too flaky to be worth the effort.  Now, just a couple weeks ago, I found myself wanting to throw together a small Modding GUI toolkit for a friend who's, well, not the most technically minded.

So I started with what they already have installed, Python and its Tkinter…  Well, that was a horrendous experience.  The Python→TCL→TK hop-skip-and-jump routine is, frustrating, and at the end of it, TK's not exactly the most capable of GUI's.  Don't get me wrong, I love TCL, it's a fantastic language, which I was very deeply into back in Uni, getting right into the guts of the language.  But TK…  While it kind of works in TCL, it's frustrating as heck in Python.  Take for example, checking to see if a tree item is hidden, and it returns a '0'.  Not a boolean, or even a number, it returns it as a string.  If you forget to explicitly cast it to an int, you get True (in TCL, it's a number with an optional string representation, and it'll do an implicit cast if necessary in any numeric context, but when translating it to Python, you just get the string rep, which is True if not empty).  As for the other Python GUI options, both myself and my friend are presently in Windows and, well, getting many of them to actually install cleanly was… problematic.  And if I had trouble getting those toolkits to install…

So I started looking for better options.  And I came across one I think well worth mentioning.  GtkDD really is a better C/C++ (I remember being rather disappointed when a YouTube'r I follow dismissed D offhand as merely — not a quote, the real quote would be shorter — "D is just a C++ as C plus 1 makes D, pointless naming rubbish", seemingly without actually looking at the language itself); it's an absolutely beautiful under-rated language, IMHO, which pretty much covers the useful parts of C#, without feeling like the proverbial "everything and the kitchen sink" that's all too common with Microsoft frankencreations (don't get me wrong, I use their OS, and some things they do are absolutely brilliant.  It's just that, some, well, go a little overboard, and/or just plain miss the mark entirely).  And paired with GtkD (which has a few minor gaps still, but nothing serious) bringing with it GTK3/Glade, has been a comparative delight to work in.  I did miss GTK, but I didn't miss C (though it was certainly educational in the ways of OOP back in the day), and this combination is just delightful.

Now, I think I'd rather be using Dgui — I'm pretty sure it would be far more effective — rather than GTK through a layer of D wrappers (where all that CTFE goodness has very little to chew on), though it's also a much younger GUI (which might or might not matter), and when I was poking around for options which just work so I could get on with re-implementing that toolkit, it was throwing page fulls of errors with the basic Hello World example, and very little idea what the problem was.  Plus I don't know if it had a GUI builder, though I think there may have been something to do with Visual Studio — which I'm not using mostly on account of it's rather large install size (gvim is my present IDE at the moment).  But, I needed something I could get up and running with now, and more importantly, that just worked for my friend, too.  I'll have a look at Dgui again later, because I'm sticking with D for my personal projects now, but GtkD was the easiest option to get going in again; partly due to my prior familiarity to GTK, and I just had to give my friend the GTK3 runtime installer, along with my compiled binary (a shared Dropbox folder would work wonders, down the line, until I have either reason or inspiration to sort out something better), and they were good to go.

I Made A Blinky! — Version 2

So, finally pulled together the pocket cash, and sent off my orders for the necessary bits and bobs.
The second revision of the board (which I introduced here) cost about $8.50 (US$6.50 + a crappy AU$ exchange rate), with some minor layout improvements, space for a push button (because taking the battery out all the time was getting to be a pain), I removed the positive copper fill on the battery side because I considered that a bad idea when the negative terminal of the battery is scraping over the solder mask on every insertion and removal, and a little piece of test art (the profile graphic I use here on this blog).

Removing the positive fill on the battery side I think was good, I had considered moving the negative fill to the back instead, since the negative terminal of the battery gets pressed against the board, but during insertion of the battery it's likely the positive terminal that does the scraping (since it wraps over and around the battery), so although it should be clear once inserted, there could potentially be an issue in the meantime.  Just not having a copper fill on that side at all is, I think, the better choice.  One big slip-up however, was my misreading of the shop description on the on/off switch I chose; I thought "on/off switch" meant press to turn on, press to turn off.  No.  It means (it appears) that the internals of the switch have a clicky mechanism that makes a nice solid on state when pressed, and a nice solid off when released, rather than the wishy-washy you get with carbonised rubber on PCB style buttons.  Lesson learnt.  It's also the minimum of what I need for this project, since that "switch" is simply sitting between the battery and the rest of the circuit — press it, the circuit has power, release it, it doesn't — so being a toggle (what I'd wanted), or a momentary action (what I got), at least the on/off part is right, plus the added bonus that the extra buttons will come in handy for other projects anyhow.  Again, if this were a real project where it really mattered, acquiring some samples would have been on the cards, or finding someone who already knew, etc. — but this is pure learning experience ground, it was the first component footprint I've drawn up by hand, and it fit first go, so I still consider it a win.

Components for the board, namely the push buttons and SMT LED's (which I totally forgot to put in the order first time around, so the first board has a big ol' through-hole LED attached sideways), came to about $10 — mostly the push buttons, which were minimum 10 quantity, so I have plenty of spares!

But talking about those LED's, they're the most hideous things to solder!  (Even worse than the capacitor.)  One fell apart on me, the second one just would not sit straight while I soldered it, and then there's the whole issue of installing it in the right direction — just trying to figure out which end was the cathode was a nightmare in itself; a quick search on the web yielded several marking options, with the caveat that some manufacturers do it the other way around, so mostly useless anyhow.  But even then, none of the markings I saw described were on the ones I'd bought, instead they just had a bevelled top edge on one end (and the notch that was suggested as a common marking, well, they had a notch kind of thing at both ends!).  I'd tested the board by tacking down a regular LED again, so I knew the board worked, and figured if I could just hold the SMT LED to the pads, I should be able to determine it's orientation.  But, that didn't work.  Not entirely sure why, whether it just wasn't making contact, or whether my metallic tweezers I have were bridging the terminals, or what, but I couldn't get an indication that way.  In the end, I just took a punt, and soldered it down.  And after fighting to get that thing soldered down reasonably, it didn't work.  Neither, did holding a regular LED over the ends, which seemed rather disturbing (had I accidentally damaged something else on the board?).  So all I could do was take it off, and try again with a new LED, hoping that bevelled edge was, at least, the cathode.  And it was, and it worked!  I now had a working Blinky v2!!!  New and (ever so slightly) improved (assuming you don't mind holding down the button)!

That wasn't the end of my purchases, though.  Along with those $10 parts, was another $60 in extras, most notably a much needed flux pen, and one of those nifty "helping hands" gizmo's with the little gripper claws and an attached magnifying glass.  Awful lot better than taping the board to the tabletop with double-sided tape, as I did the first time around — although next time I might still tape down the helping hands gizmo itself.  There's also a lot of other very basic gear I still have to get, like cutters, non-metallic tweezers, a decent soldering iron… but I'll pluck that stuff off my wishlist with each successive purchasing round as I go along.  The important part, is that progress was made!