Re: [Nautilus-list] Proposal for standard .oafinfo attributes

[John Sullivan <sullivan eazel com>]

Comments interspersed below.

on 4/20/00 3:56 AM, Maciej Stachowiak at mjs eazel com wrote:
> 
> CC's because gnome-components-list continues to be kind of slow for
> me.
> 
> Here is a proposal for some standard attributes for .oafinfo files; a
> few proposed bonobo-wide ones, and some that might only be relevant to
> nautilus, or nautilus components. Please comment. I would at the very
> least like to add the "supported_mime_types" attribute mentioned below
> to oafinfo files throughout Bonobo and Nautilus. It seems like a clear
> win.
> 
> I especially want feedback on what other attributes could be useful
> for activating (or browsing) objects, which of the attributes I have
> specified might be ill-conceived, and on the open questions near the
> bottom.
> 
> 
> --------------------------------
> 
> 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.

Who would use this description? (Who uses the gnorba one now?) How long is
it intended to be?

> * "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.
> 
> * "editable" (boolean) - does this component allow editing of its
> contents?
> 
> * "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 "supported_uri_schemes" is specified but "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 "supported_mime_types" is specified but "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 - General
> 
> * "nautilus_display_name" (string) - a suitable name for use as a view
> as name ("View as <foo>") or a sidebar panel label name. This can (and
> should!) be implemented by any Bonobo Embeddables or Controls that
> might be used as Nautilus views.

These two uses of strings are distinct. Nautilus Content Views want a title
describing the contents (e.g. "View as Web Page" or maybe "View as Mozilla
Web Page" but Nautilus "Meta Views" (soon to be renamed "Sidebar Panels")
want a title that describes the component itself (e.g. "Web Search",
"Notes", "History"). Never the twain shall meet. We don't currently have any
components that make sense as either a Content View or a Sidebar Panel, and
maybe we never will, but even so it seems misleading to use one property for
these two distinct cases.
 
> Nautilus - Content Views
> 
> * "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.
> 
> * "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:
> 
> * "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.
> 
> 
> General open questions
> 
> * How does Bonobo::PersistStorage play into this?
> 
> * Is there another concept of a display name other than the
> description and the nautilus display name, perhaps for picking off a
> list?

I was thinking about this yesterday. My latest thought is that the File menu
(and context menu) in Nautilus file views will look something like this
(assuming an HTML document is selected for this example):


    |New Window              |
    |------------------------|
    |Open with Mozilla Viewer|  ------------------
    |Open with             ->| |Mozilla           |
    |Close Window            | |Netscape Navigator| <-- These are programs
    |(...)                   | |Emacs             |
    |                        | |------------------|
    |                        | |Mozilla Viewer    |
                               |GtkHtml Viewer    | <-- These are Bonobo
                               |Text Viewer       |     components
                               |------------------|
                               |Other...          |
                                ------------------

The "Viewer" terminology is for components that will appear in a Nautilus
window. Programs that launch into their own windows don't use "Viewer". So
the Mozilla component, for example, would need to supply a string that goes
with "Viewer", and another string that's used in the "View as <whatever>"
menu. "View as Mozilla" doesn't make sense, though "View as Web Page" may be
too generic since there might be multiple web-page viewers. Maybe "View as
Mozilla Web Page"? It doesn't seem that the same string can serve both
purposes in the general case.

However, I mentioned earlier that the "nautilus-display-name" concept was
overloaded. Maybe the same split I discussed earlier works for these two
cases. "nautilus-display-name-for-component" and
"nautilus-display-name-for-view-type" or something like that.
 
> * An "icon" attribute has been proposed for component browser/selector
> purposes.

This would be useful. For instance, I could use it in the submenu pictured
above, next to the "Viewer" name. We need to figure out how the
icon-specified-by-path concept works with Nautilus's icon themes (there's
already a bug about this issue for the MIME-type-affiliated icons).

> * How to specify interesting info about applicable components when
> there is no relevant URI? For instance a regular dumb control. Maybe
> you only ever want to pick these off a list or activate a specific
> one by IID.
> 
> * Should "description" and "nautilus_display_name" be
> internationalized? If so, how? should there be other attributes with
> names like "description_${LANG}"?

They need to be localizable, of course. I don't have enough knowledge to
have an opinion how.
 
> Nautilus-specific open questions
> 
> * How do we get a nautilus display name for a component that does not
> specify one?

Good question. We could not offer them as choices. We could ask the user for
a name. We could only offer them as choices if they're in some hardwired
table that we invent. We could make up a name based on what it can display
(e.g. "View as Text (37)"). (By the way, this last idea sucks.) If they
don't have a nautilus-display-name, do they still have some other
identifying string? (E.g., the file name?)
 
> * Should the user level of a component be an attribute? That lets just
> any component author set the user level instead of centralizing it.

Perhaps, but it wouldn't exactly be the user level, it would be the "user
level at or above which this component should be included by default". Our
user-level-customizing scheme would allow users to override this default
setting. (Except maybe for Novice users...)
 
> * 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.

I'm pondering these issues even now. My current thinking, which I hope to
elucidate later today, is that the layer you describe is information that's
associated with the component and isn't changed by the user. On top of that
layer will be the user preferences, which will certainly include explicitly
choosing which of the available components do & don't appear in the menus,
and may also include overriding in a non-destructive way some of the
built-in information.


John