[Printing-architecture] Coding the Common Printing Dialog and its interface

[Till Kamppeter]

Lars Uebernickel wrote:
> Till Kamppeter wrote:
>> Lars Uebernickel wrote:
>>> Till Kamppeter wrote:
>>>>> In this case, storing the configs along with the dialog would be 
>>>>> enough,
>>>>> as it would be cross-referenced against printer queue and application
>>>>> being used.
>>>>>
>>>>> You are right, perhaps the application would want to store it matching
>>>>> against the document being printed. But that could be handled by the
>>>>> dialog too, it would just be another field or even a matter of defining
>>>>> a format for that domain name I talked about, "app[/doc hash]"..
>>>> OpenOffice.org saves printing settings (selected print queue and 
>>>> option settings) in its documents. To not require OOo to change the 
>>>> feature with the introduction of the Common Printing Dialog we should 
>>>> support this in our interface between application and dialog.
>>> I see two possibilities for this problem:
>>>
>>> (1) Applications can enable/disable the saving of the printing options 
>>> via the dialog API. This would mean that OpenOffice can keep its own 
>>> per document settings and other applications can take advantage of the 
>>> dialogs capabilities for that. But, they need to explicitly tell the 
>>> dialog to do so.
>>>
>>> (2) Options are always saved on a per application/document basis by 
>>> the dialog. The saved options are applied _before_ any application 
>>> settings take place. The application will not be notified. Afterwards, 
>>> the application sets its own settings, effectively overwriting the 
>>> saved ones. So OpenOffice's per document options would still work, and 
>>> all other applications would gain the same feature transparently. It 
>>> would also keep the API cleaner.
>> Support both possibilities in a switchable way. Let application 
>> developers choose between option saving/remembering per
>>
>> - Document file (saved in document file)
>> - Document (saved in personal config directory of the dialog)
>> - Application (saved in personal config directory of the dialog)
>> - Globally per user (saved in ~/.cups/lpoptions)
>>
>> Only in the first case option settings which are not 
>> application-specific have to be reported back to the application.
> 
> What I was suggesting with (2), is that there is no need for 
> applications to switch between those possibilities at all. Everything 
> would be handled transparently.
> 
> The dialog would _always_ store all options for the documents and 
> applications. Applications like OpenOffice, which save the options in 
> the documents themselves, would just overwrite the stored settings, 
> because their settings would be applied after the stored ones.
> 
> This way, we'd simplify the API, reducing the amount of work for 
> application developers. Also, users could choose themselves whether they 
> want options stored for applications/documents (IMHO, this shouldn't be 
> decided by the applications anyway). They could even set standard 
> options for specific applications or specific types of documents (eg. by 
> mime type).

OK, you're right, let's do it this way. As long as OOo developers will 
not complain ...

    Till