Re: [Deskbar] UI for Handlers that, uh... need a hand

[Raphael Slinckx <raphael slinckx net>]

On Fri, 2005-11-18 at 12:37 +1100, Nigel Tao wrote:
> > UI mock-up attached.
> 
> Mock-up implemented (well, mostly - only the bigger highlighted ellipse
> of the previously attached image).
> 
> For example, try the Google Live handler with and without the WSDL or
> Key file in the right places.  Evolution is the only other handler that
> does this at the moment.  In general, I'd like it to be as much "just
> works" as possible
> 

I love it, very clear and concise !
Some remarks, though :
* Do we *really* need that big refresh button ?
*  If we do can't we call it "Check Again" or "Check" something more
precise than refresh (keeping the stock refresh icon) ?
*  Wouldn't be better if the handler checked itself and notified through
a signal or a callback that the requirements are met, so we can throw
away the Check button ?
  Something like, when you select a requirement-enabled handler, you
register a callback in the handler which will be called when the handler
sees the requirements are ok, and when you deselect it, you unregister
from that callback. Internally the handler would, on registration,
regiter to gconf notification if it needs a particular key, or register
through gnomevfs if it needs files, or simply poll the ressource it
needs, and call the callback when changes happen. I think this is the
best approach. When the pref dialog receive the callback, it hides the
info area, or say 'Requirements met', or something.

This would add the following api to handlers who have a requirement
function:
The returned value from "requirements" functions is one of:
HANDLER_IS_HAPPY: nothing happens

(HANDLER_IS_CONFIGURABLE, _short_info, requirements_checker_object,
more_dialog_callback):
The pref dialog then creates the requirements_checker_object(callable)
When deselected the pref dialog calls requirements_checker_object.stop()
The callable is a function the requirements_checker_object should call
when changes are detected.

The pref dialog could pass def callable():
	update_infos_area()

In the handler you have something like:
class RequirementChecker:
	def __init__(callable)
		do_stuff (register gconf, gnomevfs)
	def stop():
		undo_stuff ()

checker = RequirementChecker()
def _check_requirements():
	if deskbar.evolution.num_address_books_with_completion() <= 0:
		return (deskbar.handler.HANDLER_IS_CONFIGURABLE, _("You need to enable
autocomplete in your mail preferences"),
RequirementChecker,
 _on_more_information)


(HANDLER_IS_NOT_APPLICABLE, message), the handler is hidden, and an
informal message is printed on stdin (need not be translated)


The above thing can be refined, for example by providing already made
RequirementsChecker objects for stuff like files and/or gconf, through
usage of lambda functions (of course!) in handler_utils.py:
class UberChecker:
	def __init__(self, files_to_watch_for_creation=[],
keys_to_watch_for_change=[]):
		register_foo()
	def stop(self):
		unregister_foo()

Then the handler can pass as CheckerObject
lambda: deskbar.handler_utils.UberChecker(["foo/bar.txt",
"bar-baz.foo"], [("/apps/uberkey", required_value),
("/apps/applic/hiddensetting", required_value)])

This is all complicated and all, but i think it's worth the effort to
remove that big embarassing 90's refresh button (gnome is all about
instant apply !)

> 
> > Maybe we don't need the "more" in all cases. For example in the
> > evolution handler example, there is nothing more needed.
> 
> The "More..." button is linked to a callback (which can be None), so it
> can be a simple message box (as both above handlers do now), or possibly
> a more intricate dialog box or Yelp can be presented for those Handlers
> that need it. 
> 

* I think you should check if the callback is None, and then show no
"More..." button, unless it already does that :)

* Also it would be nice to have a generic callback implemented in
handler_utils.py, which both our examples could use. The generic More
would be passed the title, and content so we have a consistent UI for
that, and we can change it independently from the handlers. (say if we
want to use gecko or yelp)

You could even return not a callback directly, but an enum, like
MORE_TEXTVIEW_DIALOG MORE_HTML_DIALOG MORE_LABEL_DIALOG MORE_CUSTOM
I don't know if it would be useful though.

* Maybe the more button should be called "Help" with the stock help
icon ?

* Finally it's more a question, why did you move the notification
area/little note about drag and drop to the .py file instead of
the .glade file, isn't it easier to maintain in glade ? (i haven't given
much thought about that one, maybe there is an obvious reason)

Woah, that was a long mail, my fingers are hurting :)
Raf