panel_applet_get_preferences_key ()
panel_applet_add_preferences (schema_dir)

Are these two the one we should use ?
The doc on gtk.org website[1] says nothing about the above functions, what do
they do ? how should they be used ? is there any example in gnome-applets of
such usage ?

[1] http://developer.gnome.org/doc/API/2.0/panel-applet/panelapplet.html

It looks like there is a page missing from the online API documentation. In the
copy of the reference manual I have in devhelp (available if you install
Ubuntu's libpanel-applet-doc or similar) there is a page entitled "Panel Applet
GConf Utilities".

You'll be looking for function calls like panel_applet_gconf_get_* and
panel_applet_gconf_set_*. They are all in the C header panel-applet-gconf.h. I
thought they were bound in Python also.

The other thing you should do is have the entry that will be matched if you
press Enter appear selected after the cursor (like most other programs that do
autocomplete). I think you can do this with GtkEntryCompletion (I think they
call it inline completion). For example, if I type 'dev', the top match is
'devhelp'; the entry bar should display 'dev|[help]' (where | is my cursor and
the [] represents highlighted text).

With per-applet gconf stuff, things might be a bit tricky if we still also want
to support windowed (-w) mode, where is no GnomeApplet to lean on.  I know that
in version 0.4, each applet could have its own width, but I'm not 100% convinced
with the way I went about it.  I'll chew on it a bit more (albeit from a library
computer, since my ISP decided to choke last Friday)...

With the inline completion thing, it may be appropriate for applications, but
maybe not so for web bookmarks or e-mail addresses, where I want to be able to
start typing from word boundaries (e.g. "gno" will find "Planet GNOME") rather
than the start of the match.  An alternative interface is tab-completion.

Each applet may be placed entirely differently, so having its own width may be
crucial.

I thought about inline completion after I wrote this. Following a discussion
with Raphael, I realised what I really wanted was a handler to match on my own
history.

You need to preserve that common history between all of the applets between
applet restarts, else it becomes a little bit pointless.

Additionally, the selected handlers don't seem to update properly between
multiple instances of the applet. Even though they are shared. This is a pain in
the neck. They also seem to be randomly changing the order that I've selected.

So, in summary:
Width information is currently shared, and shouldn't be
Selected handlers is currently shared (it should be) but doesn't properly update
between instances
History does not seem to get stored and is not properly shared between instances

It is worth noting that things which are global (besides having entries in
/apps/deskbar) can use global state variables inside the factory. This is useful
for handler registration and the like. You only need to store things which are
local into the applet object.

Width/Expand settings are now per-applet.

Hitsory is not stored, because i didn't settle for a way to do it properly yet.
And selected handlers were not meants to update properly in a multi-appletted
setting, since i do not listen for changes, this needs to be changed.

Part 2 is now solved too, activated handlers should be shared and correctly
updated when changed in another instance.

Remains part 3 about history to close this bug.

Testing today's CVS. The saving of the width per instance seems to act a bit
strangely. Sometimes it affects the wrong one. Not entirely sure on the set of
error conditions here.

Right, what's happening is that the setting only affect the last opened instance
of deskbar.

I'm not sure why this happens, but i guess the global variable i use is
overwritten by the last launched instance.

I'm going to fix that.

Ok the part 2 is really fixed now in CVS.

About the history thing, and more generally speaking, should we use per-applet
settings for everything, or not.

I see one use case where having two deskbars would be useful: i set one deskbar
on top of my screen to search in programs and emails, another one in the bottom
panel that only uses beagle. In that case i want of course a separate history.
That casse also needs separate activated handlers.

Is there a use case for shared history+enabled handlers ?

The behavior can be changed easily now, but i don't know which is best, i prefer
the first one, unless you have a good counter-example ?

I think that the use case is having two monitors, and wanting a deskbar on each.
 History & handlers shared, width separate.

I comitted in CVS shared history and history persistance across restarts.

Can you comment on this feature ?

Should we have per-instance history instead ?

This stuff seems to be working nowadays.