Some UI concept screenshots for gschem

For certain known attributes, we can offer the user a way of "picking" the value they want. This will probably launch an external helper program via a guile script. (It could also be internal - if we provide enough hooks and API to build a simple UI.

This is UI example is coded using a libsexy SexyIconEntry.

Another example of offering a "picker".

This example is coded in a similar way to the drop down button on a combo-box, but due to the theme-engine not recognising the widget class, it isn't drawn as seamlessly. Depending on which theme engine is in use, it looks more or less like the standard combo box.

This is what the "..." button should look like if the theme engine were to render it properly (pending future design improvements in GTK probably). for this demo, I hacked the C code of the theme engine to correctly render our widget.

The idea is to provide feedback for known good, known bad, or unknown validity of user input. If we can't validate a particular field, the entry would be white.

An alternative theme would be to put a circular icon of the required colour in the entry (say on the left hand side, for example) using a libsexy SexyIconEntry.

What are the implications for colour blind users?

This aims to give the user a more discoverable concept of multiple open pages. Also present are "Down symbol" and "Down schematic" icons (which admittedly need the love of an icon designer).

This model doesn't work well with a hierarchical list of open pages. Indeed, the hierarchical open page model doesn't work well when the same page or entity is referenced from different places in the design.

A nice compromise is to keep the two "hierarhy down" forms of navigation, but instead of "up" (which can be ambiguous), have a web-browser style "back" (and perhaps "forwards").

A page contents browser could provide a list based access point to objects making up a schematic page. When dealing with a complex design, it may be useful to click on a net by name, and have it highlighted on the schematic. We may also be able to offer attribute editing for items selected in the page browser.

It may be possible to show information not commonly visible (such as embeded / non-embeded status) in a suitably constucted page browser panel.

This mockup (using the page browser for clarity) shows how we might consider doing hierarhical buses.

At each hierarhcy level, we can pull out signals or sub-buses by refering to their names. We might also think about how signal's position within a bus could be its identifying handle.

This extension of the above example shows how it might be possible to pull out a signal lower down in a nested bus hierarchy without first extracting its parent. Whether this is useful or not is unclear as yet.