[08:26] <klattimer> yawn
[08:26] <klattimer> morning all
[08:26] <sense> good morning klattimer
[08:26] <klattimer> sense hey
[08:27] <klattimer> y'know those menu signal bugs are starting to appear in quite a few places
[08:27] <klattimer> :/
[08:32] <sense> klattimer: Strange. :S
[08:32] <sense> klattimer: Where have you seen them so far?
[08:47] <klattimer> sense: the bluetooth indicator seems to have related problems
[08:48] <sense> klattimer: Ah, the always troublesome bluetooth indicator.
[08:48] <klattimer> and there was another bug that came up in my inbox which seems to be the same thing
[08:48] <klattimer> can't seem to find it right now
[08:49] <klattimer> here; https://bugs.launchpad.net/bugs/608219
[08:49] <klattimer> this seems to be related too
[08:49] <klattimer> that seems closer to the bluetooth bug than the ibus problem
[08:49] <klattimer> but it still seems to be related to signals in the indicators
[08:50] <sense> klattimer: I'm working on that.
[08:50] <sense> klattimer: There were issues with AppInd not being signalled when a submenu would be added later, but I added signals for that to GTK+, since the child-added signal, which was listened to before, was used for other things, but not for submenus.
[08:52] <davidbarth> klattimer: hi Karl
[08:53] <davidbarth> klattimer: do you have a branch with the appindicator patch applied for the keyboard indicator
[08:54] <davidbarth> klattimer: what i'd like to clarify is whether the icon fixes you made make it possible to theme and style the icons so that they do match the panel monochrome style
[08:55] <klattimer> davidbarth: I don't have a branch for it, but I do have a package
[08:55] <klattimer> the problem is in that the icons are addressed by an absolute path
[08:55] <sense> davidbarth: There is also a merge request pending at the moment for Application Indicator that adds the possibility to swap icon theme path during 'runtime'. Do you agree with the proposed changed there, or is that something for when Ted returns?
[08:56] <klattimer> as the icon selection is in python, I can happily, do a splitpath and splitext to split off the important part of the filename and search for that before attempting to use an absolute path
[08:56] <klattimer> which would make the ibus icons themeable
[08:57] <klattimer> it would be harder, but not impossible to fix this in libindicator itself as one of the strategies for resolving the correct icon
[09:04] <davidbarth> klattimer: ted is back
[09:05] <davidbarth> klattimer: i replied to your email in the meantime
[09:05] <davidbarth> klattimer: the main point is to preserve the panel style, maybe let's continue in the email thread to let ted & bratsche catch up more easiliy on that conversation
[09:06] <klattimer> sure
[09:06] <davidbarth> klattimer: but the unit test proposal really caught my attention
[09:06] <klattimer> ?
[09:07] <klattimer> oh, for testing the bug I was just discussing with sense
[09:08] <sense> I need to get the submenus of Deluge working again in my local branch of AppInd after I changed to using my newly created, custom GTK+ signals instead of extra checks in AppInd.
[09:08] <sense> So until then I cannot test if they are sensitive or not.
[09:08] <sense> Behave sensitive, that is.
[09:09] <sense> But I'm spending this morning on triaging.
[09:14] <davidbarth> klattimer: also for avoiding regressions
[09:17] <davidbarth> klattimer: as cody merges the code mainly
[10:33] <sense> What do we think of bug #611011? Is $XDG_DOCUMENTS_DIR indeed a better target directory for "Print to file" than $HOME?
[12:58] <vish> sense: sounds sane to default to documents..
[12:58] <vish> sense: does sbackup work for you?  it seems to do nothing and looks like an ftdau bug..
[12:58] <sense> vish: Haven't tested sbackup.
[12:59] <sense> vish: I'll accept the paper cut then.
[12:59] <vish> sense: try this , after install , set it up and hit "backup now"
[13:00] <vish> it says a process is running  , but does nothing.
[13:00] <vish> if you close the dialogue boxes , it just quits.
[13:00] <sense> strange
[13:00] <sense> vish: I'm sorry, but I don't have time to confirm it right now.
[13:00] <vish> i had used it a while ago and previously it would work fine.
[13:01] <sense> vish: Also, I thought sbackup was abandoned and that it was semi-forked by some other project.
[13:01] <vish> sense: cool , confirm it when you have time
[13:01] <vish> sense: oh! then why have it when it does not do anything :s
[13:02] <vish> sense: i'm not filing the bug right now , since my system got borked , and a few things have been messed up , so not really sure if its the apps fault or my crash here..
[13:02] <sense> Wouldn't know.
[13:03] <sense> vish: About the print-to-$XDG_DOCUMENTS_DIR thing: not sure if that is really what we want. We don't know if users will only be printing documents.
[13:04] <sense> mpt: Mind if I bother you with bug #611011?
[13:04] <vish> sense: its print to file , which prints pdf
[13:05] <sense> You could also argue that $XDG_DOCUMENTS_DIR is for files you've archived there, and when you've printed something you might still have to archive it.
[13:06] <vish> sense: for the acid ripper bug , where are you getting that full description?
[13:06] <vish> SC shows only upto"... automates the process in a number of ways:"
[13:07] <sense> vish: I only have the Dutch translation available here, so I can't comment on that.
[13:13] <mpt> sense, mu.
[13:14] <mpt> I.e., I have no opinion on that. :-)
[13:14] <sense> mpt: ok! :)
[13:15] <sense> vish: You're for, I'm not sure and mpt has no opinion. What shall we decide? Is it worth changing?
[13:16] <vish> sense: anything that goes blindly in Home is craziness ;) , so lets do it :)
[13:16] <sense> vish: Alright, it makes kind of sense, so I'll accept the thing.