Please do not reply to this email- if you want to comment on the bug, go to the URL shown below and enter your comments there.
Changed by [EMAIL PROTECTED] http://bugzilla.ximian.com/show_bug.cgi?id=79822 --- shadow/79822 2006-11-10 06:49:36.000000000 -0500 +++ shadow/79822.tmp.8025 2006-11-10 09:00:14.000000000 -0500 @@ -63,6 +63,23 @@ Yep, the new gtk printing backend caches the list of printers but doesn't use cupsGetDests to get the printer list. So the heart of the problem is, when should the printer list get updated ? I mean, caching some strings, removing and adding them, is not a big problem. + +------- Additional Comments From [EMAIL PROTECTED] 2006-11-10 09:00 ------- +My suggestion is to stop using the PrintingServices* classes as +singletons. We'll have 1 global one to handle the static +PrinterSettings.InstalledPrinters, but the PrinterSettings instances +as well as the PrintDialog instances should be talking to an instance +(preferably the same) of PrintingServicesUnix. It'll be created as +its needed and shared amongst the other objects. + +cupsGetDests is a time consuming call to be sure, as are the other +cups calls made by PrintingServicesUnix. We can make the list code +async by firing off the async request when a new PrintingServicesUnix +is created and populate the dialog with those results. But the main +problem is that we seem to be invoking those same synchronous cups +calls multiple times when bringing up the print dialog and futzing +with things. We need to cache the return values at least for the +lifetime of the print dialog. No other caching should be necessary. _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
