21:10: Mobile VisualIDs

Now that I've learned enough Etk to be get hacking, `Mobile VisualIDs' are coming along nicely:

I added a column to libframeworkd-phonegui-efl's contacts-listing GUI, today, and just made it look-up PNG-files generated by mkvisualid for contact-names, in the same way that I currently have Nautilus looking up SVG-files for file-names.

evas doesn't support SVG, so I just need to add an option to libvisualid to output PNG-files (which Cairo supports!) and to resolve input file-names to PNG-icon paths.

Then I'll see where else it makes sense to add VisualIDs in the phone UI; the openmoko-dialer3 `incoming call' (and `active call') UI is pretty sparse, right now--there's a huge empty space where it'd be really nice to have some sort of caller- (or `callee-') -identifying graphic (and where other phones do put such a graphic).

I was able to get the editor running last week, since that (obviously) didn't require learning anything new aside from loading and using an OpenMoko toolchain, which is trivial--my Autoconf ./configure just works if I just pass the right `--host=' option, and my code is apparently free of any byte-sex or word-length issues (there weren't really many \opportunities' for those sorts of bugs in libvisualid, anyway).

While the embedded ARM processor provides enough processing-power to make even real-time editing of VisualIDs reasonably snappy, the `finger-friendliness' is something that I'm going to have to work on:

For one, I never considered that the monitor might not actually be big enough to hold all of the parameters at once. Of course, the ridiculously-high resolution of the FreeRunner means that quite a lot of data can fit on the screen at once--and even be legible..., but good luck pressing a spinbutton that's 2 millimeters wide.

A minor tweak to the GTK+ theme can make the spinbuttons large enough to be touchable, and putting a GtkScrolledWindow (or a MokoFingerScroll from libmokoui2) around the parameter-list would be a way of keeping all of the parameters accessible.

Of course, I'd really like to have a click-and-drag, `direct manipulation' mechanism for parameter-modification, which might make the spinbutton issue less relevant. Though, the funny thing about that is: while click-and-drag WYSIWYG editing works great on a bigger screen, I can see how going that way might make things more difficult on a small, finger-oriented screen. So, where the `list of spinbuttons' UI was supposed to be a stopgap on the desktop, maybe it's actually more like the way to go on the FreeRunner.

[Reply]

13:18: srcinst enlightenment

Yes, srcinst. Wow. Rockin'. Awesome.

srcinst FTW!

Hunh--it's written in Haskell. And it looks pretty short-and-sweet. Maybe I can use srcinst to help me finally get around to learning Haskell.

[Reply]

12:19: apt-get install enlightenment

In order to build libframeworkd-phonegui-efl, I need a native copy of edje_cc. It looks like Debian's starting to bring the whole EFL suite in, but at least some parts (include edje) are still restrained to the experimental distribution. All of the binaries in experimental' are, of course, build against theexperimentalversions of their requisite libraries, which means that the binary packages are *dependent* on experimental library-packages..., which would seem to mean that I basically have to upgrade an arbitrarily-wide swath of my otherwise-perfectly-finelennybox toexperimental--pulling inexperimentalversions of glibc, GTK+, GLib, and maybe even a few *applications* that can run only with the same version of a library as the one with which it was built..., and then upgrading more libraries to satisfy those applications... recursively until it all works out... And maybe it'll continue to \work out' after that, or maybe it won't--maybe something will break at some point and require time-consuming manual intervention.

The thing is, stable (lenny) and experimental are, by definition, not a single cohesive mass--they're two independent universes, and aren't really (really aren't) guaranteed to match up at all with each other in the long run. In other words, there's a reason why experimental is called "experimental". All bets are off.

Well, apt-build to the rescue. apt-build helps us get a source-package from one distribution, rebuild it against our own distribution (thusly replacing the foreign happenstance-dependencies with native happenstance-dependencies), and install it without having to upgrade arbitrarily-wide swaths.

Because, when installing from source, all we need is source-level compatibility, which is a lot easier to get than binary-level compatibility. Open Source FTW.

Actually, since I need to build and install several layers (edje -> evas -> embryo -> ecore ...) of library-packages, maybe I should be looking at srcinst....

[Reply]

00:23: Learning Etk... and why I can't sleep

So, I want to add VisualIDs to my FreeRunner. I've actually already built the base code and run-tested it on-device, and verified that it'll be plenty fast enough even without going through a round of optimisations (even the prototype real-time editor GUI seems sufficiently snappy), so I'm on to actually adding a UI-feature to the existing applications--similarly to how the desktop goal was getting VisualIDs implemented in Nautilus.

I've been running mainly SHR, and it looks like the best path to take is to hack on their libframeworkd-phonegui-efl package, which provides Etk-based GUIs for openmoko-dialer3, openmoko-contacts3, etc.; the alternative seems to be hacking on Zhone, which is a self-acknowledged nightmare and... more on that later..., maybe.

After having spent a day or so (spread out over the past week following receipt of my new, at-least-mostly buzzfixed FreeRunner) wrapping my head around how contacts-listing elements in a a GLib GHashTable could possibly be picked-up by something that appeared to be a native Enlightenment routine, I spent the bulk of today figuring out how to get an image from an image-file into the EtkTree contacts-list--what exactly an Etk_Tree_Model was, what the `image' variant was, and how the latter affected the requirements for arguments passed to etk_tree_row_append(). I think that I've got a grasp on all of this, now (add an Etk_Tree_Model_Image to the tree as a column-model with etk_tree_col_model_add(), and then argument the column-object with the image-file path and also NULL when calling etk_tree_row_append()--because the API really wants a theme-file with a follow-up `key' argument that selects the specific named image in the theme, but it will also accept a `NORMAL' image-file along with a NULL key and figure out that it can create an Etk_Image directly from the image-file. I guess this should actually be obvious from the arguments to etk_image_new_from_file()....

Now that it's late enough that it's not even `today' anymore, I think I've got enough of a grip on things to actually write code and verify my understanding..., but it's most definitely time for bed.

I always have my doubts about my ability to, after waking from a good night's sleep, remember what the hell I was doing before I went to sleep....

[Reply]

00:59: Modulus

Apparently, -1 mod n in C is -1, not n-1.

Contrast with Python, where it's n-1.

That's why that code wasn't working right.

The funny thing is..., I was reading over the code, and I said to myself:

Hunh--clever. I didn't think I would have thought of doing that at that point.

I guess I wasn't quite as smart as I didn't remember being, after all.

[Reply]