diff --git a/assets/css/gtkapplang.css b/assets/css/gtkapplang.css new file mode 100644 index 0000000..5cb0476 --- /dev/null +++ b/assets/css/gtkapplang.css @@ -0,0 +1,53 @@ +#article-header { + background-color: #0d0d0d; + color: white; + text-align: center; + padding: 5pt 0 5pt 0; +} + +#article-header > div { + display: inline-block; + vertical-align: middle; + margin: 5pt; +} + +img#gtk-logo { + width: 50px; +} + +#article-body { + columns: 2; + font: 10pt/1.40 Helvetica, sans-serif; + padding: 5pt; +} + +#article-body p { + text-indent: 2em; +} + +#article-body p:first-child { + margin-top: 0; + text-indent: 0; +} + +/* +span.first-word { + font-size: xx-large; + font-weight: bold; + line-height: 0; +} +*/ + +h1, h2, h3 { + margin: 2pt; + text-align: left; + font-family: Helvetica, sans-serif; +} + +h3 { + font-weight: normal; +} + +.code { + font-family: monospace; +} diff --git a/assets/img/logo-gtk.png b/assets/img/logo-gtk.png new file mode 100644 index 0000000..c45272f Binary files /dev/null and b/assets/img/logo-gtk.png differ diff --git a/pages.yaml b/pages.yaml index e56dd8c..31d6be2 100644 --- a/pages.yaml +++ b/pages.yaml @@ -2,5 +2,7 @@ - cover.html - bouba.html +- gtkapplang-1.html +- gtkapplang-2.html - drivingmissmuni.html diff --git a/pages/gtkapplang-1.html b/pages/gtkapplang-1.html new file mode 100644 index 0000000..f5f8bf1 --- /dev/null +++ b/pages/gtkapplang-1.html @@ -0,0 +1,35 @@ + + +
+ +
+
+ +
+
+

Linux GTK Apps

+

A Language Comparison

+

by P. Michael Cho

+
+
+ +
+ +

A famous hacker once said, "Linux is only free if your time has no value." Well, anyone who knows me knows that my time is about as worthless as a bag of salt. Thus, I really had nothing to lose when I decided to ditch the glitzy, glamorous commercial OS'es and go all-in on Linux this year.

+ +

It's really not that bad in 2025. Maybe it really is the Year of the Linux Desktop. A lot of stuff just works out of the box. You don't have to waste a whole weekend getting sound to work in YouTube videos. X11 isn't really a thing anymore, so fiddling with ancient hieroglyphic Xorg config files is no longer required just to get your anime girlfriend wallpaper desktop to show up on the screen.

+ +

Emboldened with a new sense of optimism for the Linux desktop, I decided to try writing a few native apps to see what the developer ecosystem is like. GTK, formerly known as the GIMP ToolKit, appears to be the de-facto widget toolkit for creating native GUI apps on Linux, so I decided to learn and explore how to develop apps using this toolkit.

+ +

The first problem I encountered was a severe sense of language paralysis. There are many, many choices of programming languages when developing GTK apps, which isn't necessarily a good thing. Apple doesn't always do everything right, but upholding Swift as the one true language for developing macOS and iOS apps reduces a lot of fragmentation for developers. A walled garden keeps the snakes out! Nevertheless, I decided to try and write a few small apps in a variety of different languages to see which one feels the best.

+ +

C (Rating: B-)

+ +

The first language I decided to try is an oldie-but-goodie. Just plain ol' C. Linux guys really like C, and really hate pretty much every other language, and the GTK toolkit itself is implemented in C, so it seemed like a good first choice.

+ +

One cool thing about GTK is that it is based on runtime library called GLib, which implements a bunch of object-oriented design patterns in C. It defines an object model, lifetime semantics, and a bunch of commonly used data structures that you can use in your app. Object-oriented programming is definitely out of style nowadays but I still think it is a solid paradigm for developing user interfaces. For example, it makes sense conceptually for all widgets to inherit from a base class that defines things like screen geometry and parent-child relationships.

+ +

My first couple of hours with C were glorious. The code was just falling out of my hands. The language is so simple, it's nearly impossible to waste any time on design.

+ +
+
diff --git a/pages/gtkapplang-2.html b/pages/gtkapplang-2.html new file mode 100644 index 0000000..448e5ce --- /dev/null +++ b/pages/gtkapplang-2.html @@ -0,0 +1,25 @@ + + +
+
+ +

Unfortunately this honeymoon phase quickly came to an end. Writing in C requires a lot of boilerplate code, and significant use of macros, against which I am generally ideologically opposed. For every "class" type that you define in your app, you have to implement several functions: one that initializes the class itself with the runtime, another for handling dynamic setting of properties, another to handle getting those properties, one for initializing instances of that class, and one for destroying or "finalizing" instances of that class. Confusingly there are two different functions for destroying objects, one called finalize and another called dispose, and I guess this was done to eliminate cycles in the reference counting mechanism implemented by GObject. Big yuck.

+ +

I eventually did finish the app I was writing in pure C, but it was a shitload of code. There are probably a couple of memory leaks too. One great thing about writing in C is that compiling the code is basically instantaneous. I actually started to feel angry and upset thinking about how much time we waste compiling code in newer languages. Do people know that complex C programs take only a few seconds to compile? Debugging was excellent too. GDB just works and I can see everything. Overall a pretty good experience I would say.

+ +

C++ (Rating: C-)

+ +

Linux guys are going to hate me for even mentioning C++, but I of course had to give it a try. Despite its numerous flaws, it's still the best bang for your buck when it comes to offering reasonably good object-oriented features with very fast performance.

+ +

For using GLib and GTK in C++ I decided to use the gtkmm library, which implements a variety of C++ bindings for all of the classes in the toolkit. Along with that I also used glibmm and giomm which are required to use the GLib and GIO dependencies in C++ code.

+ +

I was immediately disappointed to learn that a ton of boilerplate was still required just for defining some basic data types with properties. Properties are an important abstraction in GObject that let you bind data to various widgets, so this isn't something that can be easily avoided. Basically for each data member in your class, you need three accessor functions: two that 'get' and 'set' the data itself, and a third that returns a reference to the Glib::Property object representing that member.

+ +

Another disappointment was the documentation for gtkmm and glibmm. Just atrocious. Looks like autogenerated Doxygen slop. Come on guys, it's not 2008 anymore.

+ +

One positive thing I will say about using C++ is that memory management is a lot more tolerable than C. Using the Glib::RefPtr smart pointer class instead of manually managing GObject lifecycles is a blessing.

+ +

I did end up finishing this project as well and the end result was satisfactory. Overall I didn't really have a lot of fun writing C++, but then again, who does.

+ +
+