Negativuserland: Update #+1
It seems that there’s a chance that if I write about something I pretend to want to accomplish I might actually achieve some measurable amount of progress. I have a project named negativuserland which is kind of interesting to me but not visible to any members of the public and it should have been finished years ago.
The project is an embedded software system which can be used as a highly usable companion to many existing things that people already own. The goal of the project requires completing a few small applications and a build recipe for an entire root filesystem which will run the applications on cheap hardware.
The first application is a data-providing service, similar in role to something like evolution-data-server but with a different set of requirements. Specifically, it will be responsible for dealing with physical devices, mostly pluggable USB hardware and on-board communications /multimedia/diagnostic hardware and exposing a local D-Bus interface for controlling the service.
The second application is a graphical user interface for controlling the service and displaying its data without touching any files except the D-Bus socket, the display, and some input sources (Touchscreen and GPIO for fixed panel buttons).
If it is known that the data service is expected to handle as many as 100,000 heavyweight media assets (this number will change on-line as data sources are added or removed) then it should be clear that there is a bit of difficulty here in designing a scalable D-Bus interface (or any programmable interface) for providing flexible and responsive searching and browsing through the assets, especially in a memory-constrained environment. In about 2007-2008 I implemented in Vala on top of libgee something containing many of the features available in Guava’s collections library, mainly lazy views of generic iterables that can be filtered with the typical rip-off of the Predicate pattern. I even implemented a libgee iterator for glib’s GList which I found to be quite useful. It provides sort of a zero-copy view to an abstract iterable so at least as a user of some library where you can’t account for its methods of loading data from disks or whatever, you’re doing the best you can to keep memory usage down. And when the data comes from software I’ve written, it should work how I want it to work.
After all of that stuff is figured out, then you can start actually writing a graphical user interface. Originally I used Clutter for this (from the earliest stages of its development) and I have occasionally experimented with GTK+ 2.0 and 3.0. What I found was that both toolkits’ list models were pretty much unusable for my purposes (at least for the way I understood them). I tried implementing a few other partially successful opaque scrollable list views with varying levels of failure. Now, I guess the correct pattern for building a reasonable quality view for these purposes would be to provide 2 pieces of information: a chunk of data for the currently visible items in the list and some hints about the collection (its size and your position, how many pages remain, and some other things I can’t think of right now). Anyway, once those basic problems are at least partially solved it is finally time to take care of actually implementing a user interface that people can use. For me this took lots of experimentation and at the time 3D graphics drivers (ATI and NVIDIA) were really bad for Linux and caused me lots of wasted time. The whole project was implemented in Vala which was pretty good compared to all other solutions at the time but still having a build step in the development process wastes prototyping time and eventually the enthusiasm is lost and the project is forgotten for months at a time.
For the past few weeks I have been using some of my spare time to look for ways to put this project back into some sort of active development. The main requirement is that I do all of the work since it needs to be my property for certain reasons. Mainly I have been evaluating better languages for prototype development of the system. I looked at going back to plain GObject C but that is probably the worst option right now due to the lack of comprehensive code generation tools for this type system (other than Vala which is exactly that). I looked at lgi for lua and PyGObject for python and they both suffer from the same problem, in that the bindings are dynamic so code completion doesn’t work which slows everything down. Luckily there is pretty usable documentation for the pgi version of pygi. I have decided that from now on I will do prototyping in python and will probably use lgi with lua/luajit as a plug-in platform once the development is complete.