Add image viewer post.

diff --git a/image-viewer.post b/image-viewer.post
new file mode 100644 (file)
index 0000000..9c7dcd0
--- /dev/null
+++ b/image-viewer.post
@@ -0,0 +1,35 @@
+;;;;;
+title: Image viewers and other systems tools
+tags: lisp,tachikoma
+date: 2015-6-12 16:20:23
+format: md
+;;;;;
+
+After all the trouble I went through with trying to get an image viewer to work
+in CL (due to the used GTK+ 3 library being problematic, that is, unmaintained)
+maybe a different approach is more viable.  It would be possible to use one
+existing program as a front end by calling it via IPC.  So e.g. `feh`, my
+go-to program for that task, already has configurable keybindings; it should be
+a smaller problem to remote control it (even with adding some code).
+
+However, as with all these *nix combinators, it feels like a mish-mash of tools
+intertwined and not-quite the optimal solution.
+
+Consider what happens if you want to add new functionality, i.e. new widgets.
+In that case composability breaks down since `feh` is relatively minimal and
+therefore doesn't have much options in terms of providing different menus,
+input widgets, etc.  Therefore you'd have to find either a different viewer
+with more scripting capabilities (which is counter to the "one-tool" mantra),
+or switch to a more integrated approach to have this component as an internal
+part of your environment.
+
+Obviously now would be the time for either components/CORBA, or a Lisp Machine
+to hack up other programs.
+
+Or switch to Qt.  It seems that the bindings for that framework are more stable
+than the GTK bindings and additionally they (Qt) just have more people working
+on the framework.
+
+Since one of the problems with the GTK bindings is the relatively recent
+upgrade to GTK+ 3, there seems to be a point in using the previous version 2
+instead, considering that even GIMP didn't update yet.