Re: GOffice components

["Robert Staudinger" <robert staudinger gmail com>]

Hi Jean,

On 3/12/06, Jean Bréfort <jean brefort normalesup org> wrote:
[...]
> Here is the relevant part of the API (still very unstable):
>
> * retrieving general information:
>
>
> GSList *go_components_get_mime_types (void);
>
> Gets the list of mime types supported by at least one plugin
>
>
> GOMimePriority go_components_get_priority (char const *mime_type);
>
> Gets the level of support. The returned value is one of the following:
> GO_MIME_PRIORITY_INVALID: an error occurred (this should never happen)
> GO_MIME_PRIORITY_DISPLAY: the component can just display the contents.
> GO_MIME_PRIORITY_PRINT: the component can display and print the
> contents.
> GO_MIME_PRIORITY_PARTIAL: there is some editing capacity, but not all
> features are supported.
> GO_MIME_PRIORITY_FULL: full editing support.
> GO_MIME_PRIORITY_NATIVE: the same as above, but the plugin is provided
> by the application which is associated with the mime type.
[...]

A minor nitpick of course, but is _PRINT really a subset of _PARTIAL
and a superset of _DISPLAY, especially for non-native apps? Sure, the
(gtk/gnome) world is moving towards cairo and the gtk printing
support, hmm.

What do you think about a more general "export capabilities" approach,
since printing in my limited view of things is essentially postscript
export (on the app side, the rest should be handeled by the platform).
E.g. something along the lines of:
GList *mime_list = go_component_get_export_mimetypes (GOComponent*);
This would let apps use components for converting files.

Not sure if that makes much sense, of course the above two suggestions
are not mutually exclusive.

Best,
Rob