Do not auto-start the python applet

[Martin Pitt]

Binary package hint: system-config-printer

s-c-p is the only Python process in a GNOME session, and it runs all the time, for a comparatively little job (essentially, doing nothing most of the time). The startup costs of firing up a Python interpreter are pretty high.

It wouldl be nice if the applet would start on demand, i. e. when the user starts a print job or a printer is connected.

Rewriting the entire applet is perhaps a bit big, but it should not run all the time. It could be called from gnome-settings-daemon or started in libgtk's print module. Or it could have a very small C stub which just listens to the D-Bus interface and brings up the Python applet on demand.

Quoting Tim Waugh:

"It only needs to use D-Bus. Yes, using D-Bus session activation would be a good way to do it.

The small stub process would just need to listen to the system D-Bus for CUPS D-Bus signals indicating that there are jobs to watch, and for NewPrinterNotification D-Bus signals indicating that a printer has been connected. In the latter case it would also need to relay that information to the applet proper so that it knows to display an icon to show that a driver is being sought for the printer."

[Till Kamppeter (till-kamppeter)]

"... or started in libgtk's print module."

This would be a bad idea, as then the applet would only be triggered if a GTK application sends a job to the printing system. The current applet listens to D-Bus messages from the CUPS daemon and from hal-cups-utils. So it gets triggered on jobs from any program, independent which toolkit it uses, if it sends a print job to CUPS all is OK.

[Tim Waugh (twaugh)]

Indeed.

Some careful thinking needs to be done about how exactly this should work, as the NewPrinterNotification interface is actually based on the applet providing a D-Bus service -- although I said "signals" earlier, I was not being specific enough.

I don't think that D-Bus service ownership can be passed from one application to another. Perhaps the small C program needs to stay around all the time, providing the D-Bus NewPrinterNotification service on the system bus, and communicating with the applet over a similar interface on the session bus. In this way it would act as a sort of proxy for the applet.

Does that make sense?

[Martin Pitt (pitti)]

Hello Tim,

Tim Waugh [2009-02-02 14:12 -0000]:
> Some careful thinking needs to be done about how exactly this should
> work, as the NewPrinterNotification interface is actually based on the
> applet providing a D-Bus service -- although I said "signals" earlier, I
> was not being specific enough.

Oh, this in fact might make things much easier. D-Bus activation
provides exactly that -- if something tries to call a method on that
service, and it's not running, it will start the service.

Thus if we are *only* concerned about method calls, we can use d-bus
activation as it is. But if we *also* need to react to signals sent by
cups/hal, etc., then we need something running already, since d-bus
activation doesn't trigger on signals.

[Tim Waugh (twaugh)]

I'm not so sure it's a simple as that. The method is called for the object on the *system* bus, but the program providing the service needs to run in the graphical session for the user running at the console. Can D-Bus really do that?

For clarification, the applet performs two D-Bus functions:

1. The NewPrinterNotification *service*, which it provides.

2. Listening for D-Bus *signals* from CUPS, currently using the com.redhat.PrinterSpooler interface.

so there will still need to be some small C program listening out for D-Bus signals from CUPS.

[Ev Kontsevoy (biz-kontsevoy)]

> 1. The NewPrinterNotification *service*, which it provides.

I don't think that incurring high startup cost associated with Python interpreter and consuming 10M RAM *all the time* is too much cost for providing that service.

Essentially I believe that new printer notification service must be re-written in C and not be a part of the Python applet. You simply cannot afford to have 10MB daemons, even on 4GB machines. I am updating the importance of this bug accordingly.

[Lars Karlitski (larsu)]

Fixed with the introduction of indicator-printers.

system-config-printer-applet autostart was removed in 1.3.8+20120201-0ubuntu2.

[Masaki (masaki-tux)]

Thx, but I switched to mac :)

2012/2/17 Lars Uebernickel <email address hidden>

> Fixed with the introduction of indicator-printers.
>
> system-config-printer-applet autostart was removed in
> 1.3.8+20120201-0ubuntu2.
>
> ** Changed in: system-config-printer (Ubuntu)
> Status: In Progress => Fix Released
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/323322
>
> Title:
> Do not auto-start the python applet
>
> Status in “system-config-printer” package in Ubuntu:
> Fix Released
>
> Bug description:
> Binary package hint: system-config-printer
>
> s-c-p is the only Python process in a GNOME session, and it runs all
> the time, for a comparatively little job (essentially, doing nothing
> most of the time). The startup costs of firing up a Python interpreter
> are pretty high.
>
> It wouldl be nice if the applet would start on demand, i. e. when the
> user starts a print job or a printer is connected.
>
> Rewriting the entire applet is perhaps a bit big, but it should not
> run all the time. It could be called from gnome-settings-daemon or
> started in libgtk's print module. Or it could have a very small C stub
> which just listens to the D-Bus interface and brings up the Python
> applet on demand.
>
> Quoting Tim Waugh:
>
> "It only needs to use D-Bus. Yes, using D-Bus session activation
> would be a good way to do it.
>
> The small stub process would just need to listen to the system D-Bus
> for CUPS D-Bus signals indicating that there are jobs to watch, and
> for NewPrinterNotification D-Bus signals indicating that a printer has
> been connected. In the latter case it would also need to relay that
> information to the applet proper so that it knows to display an icon
> to show that a driver is being sought for the printer."
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/system-config-printer/+bug/323322/+subscriptions
>

--
Sincerely,
Eugene V. Matveyev

[Tormod Volden (tormodvolden)]

Great, thanks. Out of curiosity, what is the (idle) memory consumption of indicator-printers?

[Lars Karlitski (larsu)]

Around 2.8 megs according to gnome-system-monitor, which is a bit more than the other indicators and about the same as indicator-messages.

I wonder where that comes from, indicator-printers is really only listening to some d-bus messages and shows a menu in the panel. I'll have a look at it.