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

[Maciej Stachowiak <mjs eazel com>]

Snipped down to relevant bits only

John Sullivan <sullivan eazel com> writes:

> Comments interspersed below.
> 
> on 4/20/00 3:56 AM, Maciej Stachowiak at mjs eazel com wrote:
> > 

> > * "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?

For most things out there now it is a sentence or lengthy noun
phrase. It is not suitable for use as a name. However, the
bonobo-selector widget nontheless uses it.
 
> > 
> > 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.

You are right. I was hoping on avoiding the land mine of what meta
and/or content views will get renamed to. It is true that
theoretically the same component could be both a meta and a content
view. (Maybe someday there will be a nautilus-history: or
nautilus-bookmarks: URI scheme?)
  
> > * 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.

I was thinking the "...-name-for-component" could actually be much
broader than nautilus. It could be used generally to identify
components. Except that (as I said elsewhere) I would
s/Viewer/Component/ in that terminology.

> > * 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).

The hard part of this is figuring out how to specify it. It almost
seems it would have to be inline in the oafinfo file, because the
component might not (in theory) even be on the same machine as the
code querying about it.

> > * 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.

Someone proposed uisng a lang="de" type thing in the XML element. He
claimed XML parsers would automatically grok this. Someone with XML
clues should chime in here.
  
> > 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?)

There is the OAFIID, but that is not human-readable. Maybe if there is
a more generic concept of name, we can more easily force everyone to
have that.

> > * 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...)

So minimum user level. But I am still not sure if the component should
specify it by itself, since it requires a subjective judgement-call
which not all component authors may be good at.

> > * 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.

That sounds like a good plan.

 - Maciej