Well, while I’m waiting on a subversion command to finish (on another project), I may as well flush my train of thought, in between wondering how any large project can bare to use subversion lol.

One of my open loops is a component called the “Data Browser”, it’s meant to provide a view into data extracted from a projects source code, and present that data to the user: while bridging that browser interface into the rest of this programs peers. In less abstract English, it’s a tags browser. Go figure.

Something I love about programming, you can often express a notion in 3 words of code, what would take 10 words of English to describe. How that works? You can reduce the English word count with the use of insider jargon, but being a programming language, outsider is redefined as those who can’t read the language rather than those who don’t comprehend the associated tech speak. There fore the word count falls significantly.

My present train of thought however, is concerned with how the data should be presented: what is most suitable for the user. The fact that the program is designed first and foremost for my own convenience is aside the point :-o.

In search of the holy grail of user interfaces: I’ve found this the most optimal method.

+---------------------------------+
|  [-] Classes                    |
|      [+] Foo                    |
|      [-] Bar                    |
|            someMethod()         |
|            ....                 |
|      [+] ....                   |
|  [+] Functions                  |
|  [+] Macros                     |
|  and so on                      |
|                                 |
+---------------------------------+

where as much information about the individual items has been omitted for the sake of brevity ^.

Properly expanding the tree for a given type of data should display information unique to it. I.e. what is most pertinent to *that* type of data, rather than a common subset that applies to everything.

Columns for a methods display might look like:

| name | signature | return value | visibility |

where as the columns for classes, as opposed to ‘Bar’, might look something like this:

| name | visibility | in namespace | 

.

In a perfect world we could do this over a sandwich without much coding. Using the GTK+ TreeView widget and friends, grepping the manuals suggests that life is just going to be waaay easier if each element (Classes, Functions, Macros, etc) of the tree becomes a separate tab holding a specialised treeview as part of a Notebook widget! I’ll look into it closer when I have more time for that.

Now of course the tree view could simply show the lowest common denominator for info, and rely on a “Properties” button to show the individual details for the currently selected item, or we could (barf) just have expanding the trees spawn a new window customised to that type. But nether are to my taste.

Enough rambling, time to get a move on while subversion continues to (ab)use my networks bandwidth.