[09:05] <klattimer> seb128: in lp:ubuntu/maverick/ibus the old app indicators patch has been applied
[09:05] <klattimer> even though the patch still exists in the debian/patches folder
[09:08] <klattimer> seb128: in fact, my patch has been applied and then modified
[09:09] <seb128> klattimer, hi
[09:09] <seb128> to be honest I didn't check what the guy who did the update do
[09:10] <klattimer> :/
[09:10] <seb128> he probably just used the patch we had in lucid
[09:10] <klattimer> seb128: no, it's weirder than that
[09:10] <klattimer> the old patch is in the debian/patches folder
[09:10] <seb128> well feel free to drop the patch and see if your version applies or need update
[09:10] <klattimer> but, the new patch has been applied to the code and checked in
[09:10] <seb128> no
[09:11] <klattimer> ?
[09:11] <seb128> would be very surprising
[09:11] <seb128> I think it's just the new source format
[09:11] <klattimer> it's been modified from what I wrote too
[09:11] <seb128> the patch is in the debian dir but already applied when unpacking the source
[09:11] <klattimer> and a comment added saying Icon from filename not supported yet for app indicator
[09:12] <klattimer> seb128: it's all different
[09:12] <seb128> hum
[09:12] <seb128> so maybe he tried to take the work in progress version you had at the time he did the update
[09:12] <klattimer> like the patch in lp:ubuntu/maverick/ibus is different to what's already been applied to the code and different to my ibus patch
[09:12] <seb128> the guy who did the update is not a hacker
[09:13] <klattimer> :(
[09:13] <seb128> he tried to make some of the patch apply without conflict
[09:13] <klattimer> all that needed to be done is change the 05_appindicator.dpatch
[09:13] <seb128> well, just drop everything in that version and make your change apply to the new version
[09:13] <klattimer> grr, this is going to be hard to unpick now
[09:13] <seb128> don't bother about packaging
[09:13] <seb128> unpick?
[09:14] <klattimer> well, unless I can get a clean unpatched/broken version of ibus?
[09:14] <seb128> well
[09:14] <klattimer> what would the lp: address be for that?
[09:14] <seb128> tar xzf orig.tar.gz
[09:14] <seb128> apt-get source ibus
[09:14] <klattimer> right but, I think the orig might have these same hacks in it
[09:14] <klattimer> will the source be the new version you mentioned?
[09:15] <seb128> it would mean that upstream commit some appindicator support?
[09:15] <klattimer> no
[09:16] <seb128> do apt-get source ibus
[09:16] <seb128> rm the dir
[09:16] <seb128> and untar the orig tarball
[09:16] <klattimer> seb128: I'll create a bzr branch for the packager to use, perhaps?
[09:20] <seb128> re
[09:20] <seb128> klattimer, you can probably use the current source, I'm not sure to get the issue
[09:20] <seb128> klattimer, does running "quilt pop" in the source does what you want?
[09:21] <klattimer> I think I've got it ok now thanks for your help
[09:21] <seb128> just run it a bunch of time to unapply the patches
[09:21] <klattimer> I'll create a bzr branch and push it up somewhere so the packager can use it
[09:21] <seb128> it's that the source you get has patches applied
[09:21] <seb128> quilt pop unapply those
[09:21] <seb128> you should get back to a source without the debian patches this way
[09:23] <klattimer> quilt pop 06_show_menuitem.dpatch does not remove cleanly :/
[09:23] <seb128> weird
[09:24] <klattimer> I think he's checked it in after it's failed to patch or something
[09:24] <seb128> hum
[09:24] <klattimer> because 05, 02,01 all patch -R -p1 < patch
[09:24] <klattimer> so I can reverse everything except 06
[09:24] <seb128> can you try to "apt-get source ibus"
[09:24] <seb128> cd ibus-1.3.7
[09:25] <seb128> quilt pop
[09:25] <seb128> if you get an error copy it there
[09:25] <seb128> do it twice
[09:25] <seb128> quilt pop
[09:26] <klattimer> getting source gets me 1.2.0 not 1.3.7?!
[09:26] <seb128> sudo apt-get update
[09:27] <klattimer> ok now I have a clean source tree
[09:27] <klattimer> I'll generate my ibus patch for this updated ver
[09:29] <seb128> klattimer, thanks
[09:44] <klattimer> seb128: updated patch has been uploaded to bug #564034
[09:44] <klattimer> which isn't that bug
[09:45] <klattimer> https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/564034
[09:45] <seb128> klattimer, thank you and sorry for the trouble
[09:45] <klattimer> np
[09:45] <klattimer> these things happen :)
[11:56] <davidbarth> bratsche: https://code.launchpad.net/~kamstrup/libindicator/robust-icon-loading/+merge/32566
[11:57] <davidbarth> bratsche: do you know why ted had all of the explicit icon loading this way; kamstrup found that gicon currently uses the same scaling algorithm
[12:01] <bratsche> I'm not sure what his reason for this was.
[12:06] <davidbarth> bratsche: nevermind, the fix works; we'll check with him later today
[12:12] <thorwil> nice example of assumptions vs testing: http://ignorethecode.net/blog/2010/08/13/opinions_vs__data/
[12:26] <aday> thorwil: interesting. google are well known for having a testing-led design process. there's advantages and disadvantages to that, of course...
[12:31] <aday> thorwil: http://stopdesign.com/archive/2009/03/20/goodbye-google.html
[12:31] <aday> "that data eventually becomes a crutch for every decision, paralyzing the company and preventing it from making any daring design decisions."
[12:31] <thorwil> aday: yeah, i had to think of that article when you mentioned disadvantages :)
[12:32] <aday> thorwil: not that i think f/oss is in danger of an over-reliance on user testing ;)
[12:34] <thorwil> aday: large improvements could be had with proper design methods or even just expert reviews that are then translated into changes. all before even testing, which could then bring to a further level up
[12:35] <aday> thorwil: yeah, we're getting better at that, but there's a long way to go
[12:35] <aday> thorwil: had some amazing results yesterday with a gsoc student, actually
[12:38] <thorwil> aday: what worries me a bit is that i think some deep changes would be required for some real ux improvements. for example getting to a point where hierarchical filesystems either don't exist anymore, or are something a user absolutely never has to care about
[12:40] <aday> thorwil: yeah, document management is *the* thing that needs fixing. i've talked about this with designers in the past, but we've never managed to get very far. we're all too busy fixing what we already have
[13:57] <Cimi> davidbarth: received your mail
[14:06] <davidbarth> Cimi: hi
[14:06] <Cimi> davidbarth: I've just finished replying to the bugs
[14:07] <Cimi> davidbarth: I didn't know about "the thursday window"
[14:08] <Cimi> I was not at the pc because otto was busy with other tasks and told me to take some relax waiting him to come back on radiance ;)
[14:08] <Cimi> but since yesterday we are finishing radiance
[14:13] <davidbarth> Cimi: ok, cool
[14:13] <Cimi> davidbarth: I know you love radiance, and you're gonna love this more
[14:13] <davidbarth> Cimi: no worries, the upload window is an internal DX thing, but it does help to streamline the flow of changes between us and the desktop guys
[14:13] <Cimi> I really like the new colors
[14:14] <davidbarth> Cimi: hehe, have a screenshot?
[14:14] <Cimi> yes but I want to share it when it will be perfect ;)
[14:14] <davidbarth> Cimi: ok, i'll wait then
[14:24] <seb128> klattimer, the ibus indicator doesn't seem to work there
[14:24] <seb128> ibus-daemon --verbose gives
[14:24] <seb128> "/usr/share/ibus/ui/gtk/main.py", line 61, in __init__
[14:24] <seb128>     self.__notify.attach_to_status_icon (self.__panel.get_status_icon())
[14:24] <seb128> TypeError: Notify.Notification.attach_to_status_icon() argument 1 must be gtk.StatusIcon, not None
[14:24] <klattimer> seb128: ugh
[14:24] <klattimer> maybe some of the patch corrupted
[14:24] <klattimer> I didn't rebuild the package as the patch seemed to apply OK with offsets
[14:25] <klattimer> can you try and select quit from the menu
[14:25] <seb128> can you try to install it and see if it works for you?
[14:25] <seb128> I've no menu or indicator displayed at all
[14:25] <klattimer> I got a problem 1 out of 5 times that it breaks all the menu signals
[14:25] <klattimer> oh!?
[14:25] <klattimer> that's very strange
[14:25] <klattimer> I'll take a look at it
[14:25] <seb128> thanks
[14:26] <klattimer> can you make sure you have m17n-db installed
[14:26] <seb128> I don't
[14:26] <klattimer> that's the package the icons come with
[14:26] <klattimer> so you should probably install that
[14:26] <seb128> installing
[14:26] <klattimer> ... that /should/ already be a dep
[14:26] <klattimer> :/
[14:27] <seb128> it's not
[14:27] <klattimer> :/
[14:27] <seb128> $ apt-cache rdepends m17n-db
[14:27] <klattimer> well, it's always depended on it
[14:27] <seb128> Reverse Depends:
[14:27] <seb128>   scim-m17n
[14:27] <seb128>   m17n-contrib
[14:27] <seb128>   libm17n-0
[14:27] <klattimer> as in, always required the icons from there
[14:28] <seb128> doesn't make a difference
[14:28] <seb128> do you get the error with ibus-daemon --verbose?
[14:28] <klattimer> have you tried restarting ibus?
[14:28] <klattimer> hold on, I have to rebuild the package
[14:28] <seb128> yes
[14:28] <seb128> I killall ibus-daemon between tests
[14:29] <seb128> well I'm trying by running ibus-daemon --verbose now
[14:29] <seb128> "/usr/share/ibus/ui/gtk/main.py", line 61, in __init__
[14:29] <seb128>     self.__notify.attach_to_status_icon (self.__panel.get_status_icon())
[14:29] <seb128> TypeError: Notify.Notification.attach_to_status_icon() argument 1 must be gtk.StatusIcon, not None
[14:29] <seb128> still getting that
[14:30] <klattimer> I don't think that should be the case
[14:30] <klattimer> so I'm gonna try and see what could be doing it
[14:31] <seb128> I might be lacking a depends
[14:31] <seb128> I tried to install some ibus-* to get input methods listed
[14:36] <klattimer> seb128: i'm having trouble building
[14:36] <klattimer> it's erroring on gir stuff
[14:36] <klattimer> IBus-1.0.gir exists in debian/tmp but is not installed anywhere
[14:36] <klattimer> ...
[14:37] <seb128> klattimer, edit the rules
[14:37] <seb128> dh_install
[14:37] <seb128> drop the fail if missing thing
[14:37] <seb128> that's because you have gir build requirements installed
[14:38] <klattimer> k
[14:40] <seb128> you can "debuild binary"
[14:40] <seb128> to avoid rebuilding from start
[14:49] <klattimer> seb128: yeah I see
[14:49] <klattimer> another file changed between 1.2.0 and 1.3.7 and now relies on the status icon
[14:49] <klattimer> I'll rework it
[14:49] <klattimer> and update the patch
[14:51] <seb128> klattimer, thanks
[14:54] <klattimer> seb128: patch fixed testing now
[15:19] <klattimer> seb128: I've fixed the patch
[15:19] <klattimer> however another problem exists in that I can no longer add new input methods
[15:19] <klattimer> and I think that's related to the ibus-m17 package no-longer existing in 1.3.7
[15:19] <seb128> just install random ibus-..
[15:19] <seb128> apt-cache search ibus
[15:20] <seb128> I installed the latex one for testing
[15:21] <klattimer> seb128: i still can't add input methods
[15:21] <klattimer> but if you can check out my patch on the bug
[15:21] <seb128> ok will do
[15:21] <klattimer> https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/564034
[15:21] <klattimer> and see if it works for you
[15:22] <seb128> you can't select those in the combo box in the second tab?
[15:22] <klattimer> I'm sure something went wrong in the packaging now that the ibus-m17 package is gone :/
[15:22] <seb128> it's a bit non obvious
[15:22] <klattimer> I can't press the add button
[15:22] <seb128> you need to open the combo, select one and then click add
[15:22] <klattimer> oh
[15:22] <klattimer> nm
[15:22] <klattimer> my fault
[15:23] <klattimer> seb128: just tested and it works fine
[15:23] <klattimer> :)
[15:23] <seb128> excellent
[15:24] <seb128> will review and upload that
[16:11] <defreng> good evening guys :)
[16:12] <defreng> I'm the developer of the gm-notify application and just wanted to ask if there are major API changes for since lucid, so I can adapt these into the application?
[16:12] <defreng> I just scanned the wiki but couldn't find something really new
[16:14] <defreng> *API changes since
[16:44] <kirohtoli> hi, y wanted to ask djsiegel a few simple questions about ubuntu unity, but he's not on line. can please anyone else help me with this?
[16:45] <kirohtoli> sorry about the bad english :(
[16:47] <kirohtoli> ok, thanks anyway, bye!
[20:20] <fR_> hey are any of the KDE folks around? I was wondering if someone could update the qt package in the dx-team PPA, currently the kubuntu PPA is newer so appmenu breaks.
[20:21] <ScottK> fR_: The one in the Maverick archive should be current.
[20:24] <fR_> ScottK: ah, and that includes the appmenu patches? are there plans to backport this to lucid?
[20:24] <ScottK> Probably not.
[20:26] <fR_> okay, thanks for the info.
[20:28] <ScottK> We may have it in a PPA somewhere.  Let me check.
[20:29] <fR_> oh, thanks. i have the kubuntu beta ppa which does include 4.7b2, but just not the appmenu patch.