Ideas for Free

Problem: Testing GUIs tends to be hard.

Writing a reasonable test for GUIs usually involves contortions to find the correct widget and values. For example, a test might want to confirm that “the font is now bold for the third text field, named system_danger_level, in the hbox in the floating frame in the second panel in the third tab bar in the dialog box”. Figuring out how to tell if the test passed is usually difficult.

Solution: Add a function in the GUI framework that returns a single large data structure for the state of the GUI. Use standard Python programming to navigate it.

The test becomes:

assert(gobject.dump(”system_danger_level”)["font"]["style"] == “bold”)

This is one of my poorly researched ideas: it came up while talking with Shandy before Mark Shuttleworth’s talk last night. All GUI frameworks are inherently a bit crufty and hard to navigate. On the other hand, the data types in Python are rich: dictionaries, arrays, nested structures, etc. While handing such a data structure to PyGTK to modify the GUI might require a lot of writing, asking PyGTK to disgorge such a data structure is far easier.

Consider adding it the the GObject functions. Call a new gobject.dump_main_context() and get a huge Python data structure back. It might have lots of redundant methods of finding the same data. For example, a tree of all the contexts or dialog boxes and the usual tree objects inside that are grabbed by tools like Guitar’s GUI Ripper. It might also have a handy hash of object id’s and their associated sub-records, like an index into the big tree.

While some may decry the memory and time cost of creating this tree might have the legitimate wish for a second function known simply as gobject.dump(). It would take a single identifier tag and return a single object from that tag ‘downwards’ in detail. A well published heuristic would have it “do the right thing” when given a tag that exists in multiple places.
This feels like a “implement it first and then see if its useful” type of hack.

Problem: Font chooser are boxes cause more load as one has more fonts.

Font choosing options have barely evolved from the very first days of the Lisa where a user could choose between *gasp* five fonts. Now, there are thousands of fonts and the font chooser boxes look the same.

Solution: Visualize fonts spatially according to useful categoriztions

There exist various categorization methods for fonts: technical, quantitative, typographical, and subjective. Pick some within the list: measured reading speed (quantitative), bitmap versus stroke based (technical), or rankings (subjective); then map the fonts onto a sphere, fictional map (the isle of bitmaps), or plain old grid. That way, a user can pick a font from among other fonts that share the sameessential characteristics, e.g., slow reading speed.

Ah, but were ideas code.

… at least more than Microsoft products. Still, silly bugs are everywhere:

So, that’s a 29 Gigabyte partition, with 65.9 Gigabytes used, leaving 23.0 Gigabytes free of the original 27.5 Gigabytes. New math.