print-manager is now low latency and low CPU demanding

First of all I really want to say a big: Thank You!

For all of you who donated to my fund raising campaign, the goal was reached pretty fast and there was also people sending the money without PayPal, if you are still willing to do the contribution there’s still 5 days left, and if you can’t make a donation I already appreciate the good feedback I receive, you CAN still send patches fill bugs, translate there are lots of ways of contributing.

Back to the topic…

It all started last week when I was trying to hunt down a ghost, yes a ghost!! You don’t believe me? Take a look:

Ghost Job

If you runned our new plasmoid for a while, I don’t know how much time is needed, if suspend/resume has any interference in it, but it turns out a ghost job and printer will show up… Debugging this is really hard because when I put the plasmoid the ghost is not there, so I don’t know how to reproduce it quickly, but I know the cause.

Let me first tell how all print-manager worked before this change

CUPS is like an HTTP server, you create IPP requests, send, and get back a response. So when the application/plasma data-engine started I asked the server for all printers, then I asked for all jobs. This process is a bit CPU consuming because it has to convert Qt types (QString, QStringList..) to C types but also adding then with the proper CUPS flags (ie say a boolean var is bool), and do the opposite when we get a response.

Now when the UI needs to refresh I actually had to do all of that using a timer every 1,5 second, plus update the model/plasma data-engine, and even check if anything changed to avoid refreshing the UI which is increases the CPU usage.

Because of the ghost problem I remembered seeing some DBus interface on printer-applet, so taking a look at the code I found “com.redhat.PrinterSpooler” Interface. Using dbus-monitor I was able to create a new printers data-engine to test how it would work, and turned out that this was a very good change, now instead of refreshing all printers using a timer, I could not only refresh the list when something changed but also only ask CUPS the printer I was interested in.

So say if you click on pause printer immediately a signal is emitted and the UI will refresh, thus creating a very low latency. Now not happy enough I had to do the same with the print jobs, but I found out that “com.redhat.PrinterSpooler” didn’t provide enough signals. Say I cancel a job using http://localhost:631 no signal is emitted resulting on the print-queue thinking the job is still active, you can find this bug on printer-applet.

I decided to try the Gnome Control Center printers module, and yes the bug was there too, so I decided to contact the RedHat guy (Tim Waugh) to see if we could get another CUPS patch, and it turns out that “com.redhat.PrinterSpooler” was not used long ago, and there was a new “org.cups.cupsd.Notifier” interface, which for my surprise Gnome printers  module used.

The new interface is quite different from the old one, instead of just waiting for a signal to arrive, we have to actually register which signals we want to listen, and CUPS returns a subscription ID, this ID has to be renewed from time to time (but surely is much less work than getting all your jobs and printers from time to time).

Reading the CUPS patch that makes this working I found out why the Gnome thing wasn’t working, it didn’t registered to the needed events, so now not only KDE print stuff works better but also Gnome’s 😛

If you read all of the above you are still curious about the ghost, aren’t you?

Well as I said I don’t know when it happens but I sort of know why, the old data-engine had “Printers”, “ActiveJobs”, “AllJobs” entries which didn’t had any valid data, but where used to probe data-engine to update it’s entries. So for some reason these invalid sources showed up on the listing, I even tried to use a DataModel filter but it didn’t resolve.

With the usage of DBus I dropped two features, listing all jobs or completed jobs. The problem is that these lists tend to be too big, and plasmoids start to get slow to fill the data, also to get rid of the ghost entry I removed the invalid entries so there’s no way of telling the data-engine what do you want. The alternative would be to have more two data-engines, but 99,9% of the users will care only about the active jobs which this will fit the need perfectly (the QWidget GUI is also available providing this feature).

To end this post, I have a nice screenshot:

print-manager plasmoid using swicthes

As you can see I’ve changed the plasmoid to use switches to pause/resume printer.

Make sure you make uninstall before testing the new version since the old data-engine was removed.

Enjoy!

 

UPDATE: The above screenshot with a plasmoid smaller and printers grayed when disabled:

print-manager is now low latency and low CPU demanding

25 thoughts on “print-manager is now low latency and low CPU demanding

  1. Lamarque Souza says:

    Yeah, not everybody is fan of switches (I am not) :-/ I still prefer checkboxes, they are easier to distinguish between the two states and checkbox can have a third state too (I use this in Plasma NM’s mobile broadband checkbox).

    1. dantti says:

      I think switches are great for things that have 2 states and are not enabling/disabling features. So IMO it’s perfect to enable/disable printers, also it would be great to enable/disable networking.
      I think we can’t replace checkboxes with switches everywhere, it only makes sense when enabling/disabling a whole system or a device, or an ifrastructure.
      Because they are simply super intuitive, I love enabling/disabling the alarm of my cellphone with switches, it’s just perfect for that case, but I’d surely hate if my gmail app used this to check emails…
      Checkboxes are nice, the third state is used on Apper to show that not all updates where selected, but it’s all about the use cases.
      And plasma switch make it quite clear the on/off state though I think having a ‘I’ and ‘0’ would make it clearer.

      1. Lamarque Souza says:

        I do not agree with the intuitive part. It is very easy to distinguish the states in checkboxes. With switches you need to test and then figure out what the on and off states look like and their look really changes if you change the Plasma theme too. TTPod in my smarthphone uses switches and everytime I use it I need to think for a moment to figure out what the on and off states are. If you are already used to app then you are Ok, but anybody that uses the application for the first time will be in doubt for a moment.

    2. I also think that checkboxes are better, because they integrate better into the desktop. Switches may look great in mobile UIs where everything uses them, but on a desktop, they just look weird.

      1. dantti says:

        But IMO it really doesn’t make sense to put a checkbox on a printer, it would mean select this printer rather than enable/disable it.

  2. zizzfizzix says:

    looks awesome!

    one request, though, could you get rid of the whitespace to the right? It takes too much space on small devices, just like networkmanager plasmoid takes half of my screen:/

    1. dantti says:

      You mean on the jobs list or on the printers list? I think I can make the minimum size of the plasmoid smaller then you grow it if you find the jobs are wasting too much space..

      1. zizzfizzix says:

        I mean on the jobs list, you have an empty margin running top to bottom, would be good if it just took that much space it needs, no more

        Thanks!

      2. dantti says:

        Ok, well to know the perfect size for the list we need to iterate over all items to know their size, quit non-trivial, so I let the plasmoid reduce a bit more, also the jobs list has actions and more info when you click on them so they need to be a bit wider because of that too..
        Take a look at the new screenshot.

  3. Michael Werner says:

    “With the usage of DBus I dropped two features, listing all jobs or completed jobs. The problem is that these lists tend to be too big, and plasmoids start to get slow to fill the data, also to get rid of the ghost entry I removed the invalid entries so there’s no way of telling the data-engine what do you want. The alternative would be to have more two data-engines, but 99,9% of the users will care only about the active jobs which this will fit the need perfectly (the QWidget GUI is also available providing this feature).”

    I disagree to this. For me it’s very important to see todays finished jobs.

    1. dantti says:

      Well you are the 0.1% case, and the problem is that this not only make the loading super slow, but also would bring me a big maintenance problem, there is one alternative that I’ll try for Apper, it that is easy to do maybe I put back the features, otherwise this will make things slow..
      Best

      1. imho the “completed jobs” should be listed in a separate window, maybe a full-fledged “printer management panel”, not in the applet. I do need the applet to be responsive and keep the resource usage low as it may run for long periods of time, but if i want to see detailed info about what my printer does, i have no problem opening a separate window with all the needed data.

  4. igore says:

    well, i like the switches in this case. it makes very clear whether a device is running or stopped.
    in the old version where you have flat stop or run buttons you could misinterpret them. for instance the run icon could mean “this device is running” or “start this device”.

    i find this “ugh, switches” attitude to be hilarious. it’s just people fearing change. switches can be very good in some cases.

    1. dantti says:

      Sure, I think people are quite used to switches it also proved to be a good think on phones, but I’m against replacing all checkboxes with it, as I said for things like enable/disable devices, infrastructure and services it makes perfect sense.

      1. anonymity is great says:

        I totally agree with you, but the problem is that it is not clear which state is the active one. For color-blind people, this is even worse. So the switches should definitely have ‘I’ and ‘O’ on them.

      2. dantti says:

        Ok, well I sort of agree with the on/off distinguish problem I’ll solve this issue like my cellphone does, the items on the list and also the switch will have less opacity, I’ll post an screenshot when I’m done.

Leave a comment