gnome-print API (was Re: GnomePrinterSelector private?)

[Chema Celorio <chema ximian com>]

> I have been wanting to declare the API of gnome-print stable [*1], 

[*1] 

This are my current _thoughts_ on the API status of gnome-print. I will
be sending a mail to desktop-devel-list gnome org this month (or early
Feb.) with an official statement on the gnome-print API.

- We _have_ to say something publicly about it, people need to know what
to expect
- I'm very happy with most of the current API 
- I'd like to do is declare what parts of it that are frozen, limit the
parts that are not with a _DISABLE_DEPRECATED guard.
- Things that might require breaking the API fall mostly in 3
categories:

 	A) Stuff that we left on the headers by mistake or without
	thinking about it. 

        This are not a real problem because the functionality
        is not being removed, just that we are exposing function calls
        that we should not have and that apps should not be using
        anyways. This are used internally.
	
	- gnome_print_context_create_transport
        - gnome_print_job_render
        - gnome_print_job_render_page
	- gnome_print_config_dump

        B) Stuff that needs some thought
	
	- gnome-print-paper.h

	I'd like to think about/investigate how and if someone is using
        this. Paper size selection is handled by GnomePrintConfig &
        GnomePrintJob, apps can embed widgets to allow users to
        select/view paper sizes. 
	
        C) Fonts

	All the fonts stuff, we should be moving as much as this and
	recommend app developers to use Pango for this. To nail this
	it is required that the Pango port be complete and that we play
	with the API that apps end up with (pango & gnome-print) and
	make sure it makes sense and we like it. We can deprecated this
	part of the API slowly with _DISABLE_DEPRECATED guards. There
	will be no urgent need for apps to move to the new API, but
	a number of good reasons to do so.

	The key here is that until this is thought out and some playing
	happens with the code, we won't know what is the right API or
	what needs changing.

- There will be a number of new functions added. There is more
functionality in the library than what we are exposing to applications
and that they would want to use.

regards,
Chema