Merge lp://staging/~alecu/ubuntuone-client/restrain-out-of-space-dialog into lp://staging/ubuntuone-client

I agree with the idea, and the code looks ok to me. I think this is the best solution we can provide currently. I didn't fieldtest it though.

How to test this code:

First let's build the branch:
    cd $HOME/canonical/ubuntuone-client
    bzr branch lp:ubuntuone-client review_restrain-out-of-space-dialog
    cd review_restrain-out-of-space-dialog
    bzr merge lp:~alecu/ubuntuone-client/restrain-out-of-space-dialog
    gnome-autogen.sh && make

now let's make sure that syncdaemon is stopped, because the testing script will take its d-bus spot:
    u1sdtool -q

let's start up the testing script:
    cd gsd-plugin
    ./test-flood.py

The dialog will very quickly go thru three different messages. But since it keeps popping up, changing the messages but keeping popping up, that means that the bug was reproduced. Now let's replace the plugin with the one we just compiled. In a different terminal do:

    cd /usr/lib/gnome-settings-daemon-2.0
    sudo mv libubuntuone.so old.libubuntuone.so
    sudo ln -s $HOME/canonical/ubuntuone-client review_restrain-out-of-space-dialog/gsd-plugin/.libs/libubuntuone.so
    killall gnome-settings-daemon # your gnome settings will melt. Don't worry!
    gnome-settings-daemon --debug --no-daemon

Now go back to the first terminal and run the testing script again. It should now only show each message once every hour! The events should still be logged on the gnome-settings-daemon debug output.

Since we don't want you to waste a whole hour, let's open gconf-editor and change this (newly created) gconf key:
* /apps/gnome_settings_daemon/plugins/ubuntuone/out_of_space_warnings_interval

it should say 3600; let's change it to 10 and test the script again. (no need to restart g-s-d) Now the messages should take turns, but each message won't repeat more than every 10 seconds.

Finally, we can change that value to 0, and if you run the script no new messages should pop up at all.

You may now kill that g-s-d and start it again in the background:
 * killall gnome-settings-daemon ; sleep 3; gnome-settings-daemon

I made a mistake on a line above. Here's how it should look like:

sudo ln -s $HOME/canonical/ubuntuone-client/review_restrain-out-of-space-dialog/gsd-plugin/.libs/libubuntuone.so .

This seems like an overly complex stopgap 'solution' to the issue. I think the proper fix would be simpler code, and it certainly wouldn't require more incorrect usage of gconf.

I would only show the dialog once per session, unless the quota limit has changed since the message was shown. This way, if there are pending uploads, and the user never upgrades, then at most, they should only get shown the dialog once at log-in time; unless their quota was increased and they hit the new limit, or gnome-settings-daemon crashes (which is a larger bug and possibly not ours).

Sigh. :(

The code makes sense though I'm not an experienced gnome dev. Works like a charm.

Part of the problem is also that the dialog is destroyed and shown again, even if it's already shown. Instead it needs to be in a static variable, and if already shown, simply presented again.

rodney: that's for another bug, isn't it?

> Part of the problem is also that the dialog is destroyed and shown again, even
> if it's already shown. Instead it needs to be in a static variable, and if
> already shown, simply presented again.

Now replying the right way ;-)

That's not the issue in this bug. You can add another for that and assign it to alecu or yourself, if you want.

> Part of the problem is also that the dialog is destroyed and shown again, even
> if it's already shown. Instead it needs to be in a static variable, and if
> already shown, simply presented again.

That's a valid point, but it's not something that's being done on this branch.
Would you mind opening a different bug for it?

I'm not sure it's necessarily another bug entirely. Rather, after a little bit more thought, I think it is part of the fundamental flaw in the code that leads to this issue.

With 3000 files say, that would cauase the dialog to appear, instead of just show()ing the same dialog 3000 times, it is instead destroyed and then created again, over and over. This means it creates a state of constant flicker until the last display of the dialog, and the action happens fast enough that the user can't click "Cancel" in the middle. Destroying and creating the dialog so many times and so fast, consumes a lot of resources. While this isn't necessarily the primary fundamental flaw, I think it exposes another flaw. That is the code does not wait for all the events to coalesce, so that only one dialog is shown, at the end of the spam of messages from DBus.

While not necessarily a total fix, I do think it would be better than this patch, and be more of a step in the right direction for the total fix. And since the real target of this fix is an SRU for Maverick, I do think we need to exercise more caution in deciding what goes in, and try to minimize the change set before rushing it in.

Changing this back to disapprove, and marking as rejected, since I proposed a better solution which is now approved.