This site has been retired. For up to date information, see handbook.gnome.org or gitlab.gnome.org.


[Home] [TitleIndex] [WordIndex] 

1. Auric

an integration of mini-commander, the dictionary lookup applet and contact applet (and more!)

Contents

  1. Auric
    1. Background
    2. Use Cases
      1. Case 1
        1. Existing Situation
        2. Auric
      2. Case 2
        1. Existing Case
        2. Auric
    3. Cases not covered above
    4. Architecture
    5. Features
    6. See Also

1.1. Background

At the moment we have three different little bars on the desktop for looking up three separate things. Each one works slightly differently, and if you want all three it's going to take up a lot of real estate. Eventually also, we're going to want a nice easy way to look at Beagle via the Panel, Auric going to solve all those solutions.

1.2. Use Cases

1.2.1. Case 1

1.2.1.1. Existing Situation

Fred wants to execute abiword, he doesn't want to have to navigate the menus to do this. So instead he goes to the mini-commander and types in abi, if he's run it before it will complete at this point, otherwise he will have to type in the whole word. If he had gone to the run dialog it would have autocompleted after abiw.

1.2.1.2. Auric

Fred wants to execute abiword, he goes to the auric bar and types a. All likely programs, contacts are displayed in the dropdown list with icons. Fred can then type bi leaving abiword as the only thing in the list so he can now press enter.

1.2.2. Case 2

1.2.2.1. Existing Case

Alice wants to look up Fred in her address book. She goes to the contact applet and types Fred, all her friends named Fred appear.

1.2.2.2. Auric

This will work pretty mucn identically in Auric, except that she will use the Auric bar. Also installed programs beginning fred will be shown.

1.3. Cases not covered above

How to deal with situations where there are multiple possible actions per item? Two possibilities: either show all the possibilities in the same list ("Item 1 (Action 1)", "Item 1 (Action 2)", etc), or pop up another list of possibilities. The situations where this would be likely include pretty much all the data files (assuming you'd show data files here, I think it would be worthwhile), contacts (unless you depend on contact lookup applet like info window, you'd probably like to show choices like mail, im, etc), shell scripts (launch, edit), directories (open in nautilus, open in terminal, add to archive.)

Anyway, browsing directories would be a pretty interesting use case for this kind of thing. You'd probably have a desktop-wide hotkey to access the applet, so accessing often-used directories by name via this would be faster than navigating there with mouse. This would imply you'd get another list after the first one (or after the second one, assuming you had multiple actions for directories, where first you'd pick the directory, then the "browse" action, then a second directory, etc...)

Pepper (see below) implements some of this stuff. It's not necessarily optimal - it should be considered experimental and some of the design choices are on a shaky ground - but it's one possibility.

1.4. Architecture

It would be nice to base this off the eplugin. Registering new events and hooks for auric. This could be done in the org.gnome.applets.auric namespace. Simplistically, we could have three basic hooks, org.gnome.applets.auric.events with ids search.changed and item.selected as well as org.gnome.applets.auric.config with group target prefs (for hooking things into the preferences).

Plugins will be required to pass a display string, an image and an id unique to that plugin via some data structure. These will then be packed into a GtkListStore with all of the other plugins, something like: 

[PIXBUF]  "org.gnome.applets.auric.contact"  1  "Davyd Madeley <davyd@madeley.id.au>"
[PIXBUF]  "org.gnome.applets.auric.contact"  2  "Mark McLoughlin <mark@skynet.ie>"
[PIXBUF]  "org.gnome.applets.auric.binary"   1  "Abiword Word Processor"

When an item gets selected, we will look at the field indicating the applet it came from and send a item.selected id with the id number that was selected. The plugin will be required to keep state as to what item that id related to.

<!> It would be nice to be able to get asyncronous replies from the applets, so we send the search.changed event and they are free to reply at any time. Need to look in to how easy this will be to do with the architecture.

I think that you can install eplugins with arbitrary namespaces into ~/.eplugin and Evolution will ignore them, but I have to confirm this fact. Updated: this is possible

1.5. Features

1.6. See Also

2024-10-23 10:58