Hi German,

> Sure, it's a good idea to use the proxy setting as a preference, but my 
> goal is to develop a very simple type of "control center" to use by
> final users in my apps. Don't sure if a final user might deal with all 
> the Preferences, but I'm sure that if the user see the ui already open 
> to set the proxy and Kom services, might be more easy to understand.
> 

Just store the proxy settings as preferences, but use your own ui to 
interact with them[*].  In this way you can use a UI that will adjust to 
your needs, but also it will allow experienced users to access the proxy 
settings from a Browser (besides you get all the other Preference 
features like persistence (the save to disk option) and project localness).

But the point you mention about an end user is a very interesting one. 
For that kind of user I want to develop an special mode of work of the 
PreferenceBrowser.

This feature will allow developers to re-use the PreferenceBrowser 
interface to manage their settings instead of doing its owns. This would 
work by customizing what categories and preferences to show and making 
possible to invoke the Preference Browser as a modal dialog from your 
application.

I don´t think this is hard to do but is far away on my priority list at 
the moment.

*- See at the class Preferences the "add" and "get/set" method 
categories. Instead of storing the proxy settings as instance variables 
use getters/setters that will use Preferences to get/set the values.

Regards,
Hernán