Second draft of attributes proposal (was Re: Proposal for standard .oafinfo attributes)

[Maciej Stachowiak <mjs eazel com>]

Second draft, based on various feedback.

The main changes are:

* Seperated truly generic attributes from ones that seem more
  bonobo-specific.

* Introduced namespaces.

* Added a more generic concept of name.

* Introduced a concept of namespaces, so that non-generic attributes
  are identified by "namespace:attribute". This will require changing
  the OAF query expression lexer to allow `:' as a character in
  identifiers, which should be trivial. (Should there be a namespace
  even for generic stuff? "oaf:"?)

* Split the nautilus_display_name into two different attributes.

* Added a vertigo-related attribute (I hope to put relevant
  control-center ones here too, when/if Jonathan or someone gives me
  feedback.)

--------------------------------

Proposal for standard .oafinfo file attributes. Not all components
must specify all of these (although I recommend making at least
"repo_ids" and "description" mandatory), but if they are present they
ought to have these standardized meanings.

General

* "repo_ids" (stringv) - all the IDL interfaces this component
implements, including inherited interfaces. If Bonobo::Unknown is one
of the interfaces, this should include all interfaces that can be
query_interface()d for.  Fake interfaces like
IDL:BonoboControl/text-plain:1.0 should _not_ be included.

* "description" (string) - a free text description of the component,
much like the gnorba description field.

* "name" (string) - a short name suitable for display to the end user,
  e.g. in a menu.

Bonobo

* "bonobo:editable" (boolean) - does this component allow editing of its
contents?

* "bonobo:supported_mime_types" (stringv) - a list of mime types this
component understands as input. In addition to specific mime types, it
is possible to include supertypes (e.g. "image/*" or "text/*") or
"*/*" to indicate the component can display any mime type. Specifying
"*/*" is only necessary if "supported_uri_schemes" is not
specified. This only really makes sense if the component implements
one of the following interfaces: Bonobo::PersistStream,
Bonobo::ProgressiveDataSink, Nautilus::View.

* "bonobo:supported_uri_schemes" (stringv) - a list of protocols this
component knows how to handle. This only really makes sense if the
component implements one of the following interfaces:
Bonobo::PersistFile or Nautilus::View

  If "bonobo:supported_uri_schemes" is specified but
"bonobo:supported_mime_types" is not, it is assumed the component can
handle any type of data that might come via that protocol. Some
schemes may not even have an associated mime type for any given URI,
for instance irc: or news:

  If "bonobo:supported_mime_types" is specified but
"bonobo:supported_uri_schemes" is not, the component is assumed to be
able to handle all common URI schemes (possible definition: anything
gnome-vfs can handle).


Nautilus - Content Views

* "nautilus:view_as_name" (string) - a suitable name for use as a view
as name (it will be displayed as "View as <foo>" where <foo> is the
name). This can (and should!) be implemented by any Bonobo Embeddables
or Controls that might be used as Nautilus views.

I am not sure if the following two should be in the nautilus: or
bonobo: namespace; I can see them being useful for other components at
least in theory.

* "nautilus:required_directory_content_mime_types" (stringv) - if the
component is to be activated on a URI with mime type
special/directory, it is only really applicable if the directory
contains one of these mime types. As before, supertypes like "audio/*"
are allowed.

* "nautilus:required_uri_tester" (string) - this specifies the OAFIID
of a component that implements the Nautilus::URITester interface (see
proposal below). If the criteria established by all the other
attributes are satisfied, an object with that OAFIID should be
activated and its is_applicable() method should be called on the URI
to test if it this component _really_, _really_ applies to the given
URI. This should be used as a last resort.

The reason for the "required_uri_tester" attribute is as follows. In
Nautilus, we plan to have custom directory views that express
higher-level semantics about certain directories, but that depend
heavily on the directory contents. For example, there maybe "View as
Version Controlled Directory" or the like which depends on their being
a directory named "CVS/" in the appropriate directory. So in the most
general case, we need to run some code specific to the component to
make sure it is applicable to a given URI. Now, we could just activate
the component, require it to have the URITester interface, do the
test, and then destroy it to find out if it applies. But that might be
quite heavyweight. So intead we specify the OAFIID of a different
component, one which could be very lightweight (shlib or minimal exe
that does not pull gnome/gtk stuff) which does the test and nothing
else.


Nautilus - Meta Views:


* "nautilus:sidebar_panel_name" (string) - a suitable name for use as
a view a sidebar panel label name. This can (and should!) be
implemented by anything that can be used as a Nautilus sidebar (meta)
view.

* "nautilus:recommended_uri_schemes" (string) - the URI schemes this
meta view is most recommended for. If "*" is included, this component
is recommended for all schemes. If omitted, it is not recommended for
any. This is only really applicable for components that implement
Nautilus::MetaView.


Vertigo:

* "vertigo:category" - the name of the category a panel applet falls
  into, for purposes of generating the menu.


General open questions

* How does Bonobo::PersistStorage play into this?

* An "icon" attribute has been proposed for component browser/selector
  purposes. If included it would have to be inline probably
  (base64-encoded png?) since the oafinfo file may not be on the same
  machine as the code doing the browsing or activation.

* How to specify interesting info about applicable components when
  there is no relevant URI? For instance a regular dumb control, or
  something like the gnomines control where there is no relevant
  type. Maybe you only ever want to pick these off a list or activate
  a specific one by IID. Maybe controls that want to be activatable in
  nautilus somehow can just register their own URI scheme, for
  instance `gnome-control-mines:' for the gnomines thing. This seems
  like kind of a hack though.

* Should "description" and the various name attributes be
  internationalized? If so, how? should there be other attributes with
  names like "description_${LANG}"? Someone proposed using
  lang="de"/lang="ru" in the XML tag.

Nautilus-specific open questions

* How do we get a nautilus display name for a component that does not
  specify one?

* Should the user level of a component be an attribute? That lets just
  any component author set the user level instead of centralizing it.

* What queries and sorting criteria should we use? Proposal to come
  later.

* How do user preferences relate to this? I am intentially
  sidestepping this issue for now.

==================


module Nautilus {
        interface URITester {
                boolean is_applicable (string uri);
        }
}

_______________________________________________
gnome-components-list mailing list
gnome-components-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-components-list