[10:57] <SiDi> http://bazaar.launchpad.net/~sidi/notify-osd/xfconf-experimental/diff/375/373?remember=373 MacSlow this should be the patch for gconf/xfconf & for color/text size/opacity settings. You can have a look if you want but i still need to do some testing and to improve the autotools part before proposing it for a merge
[10:58] <MacSlow> SiDi, atm I'm working on backlog support
[10:58] <MacSlow> SiDi, current plan is to address gconf/xconf in two weeks (depending how fast I'll get other stuff sorted)
[10:59] <MacSlow> SiDi, gconf/xconf are low-impact (side-effect wise) imo... so I'll rather do them at the end (close to feature-freeze)
[11:00] <MacSlow> gee... lp is slow today
[11:01] <SiDi> MacSlow: no problem as long as it goes in karmic :)
[11:01] <SiDi> we need it for xubuntu
[11:01] <MacSlow> SiDi, argl... please no renaming of #defines
[11:02] <SiDi> i can revert that if you want. They were not actually needed anymore as they were defined, but some fallback ones were needed. I renamed them to make it more clear what they were used for
[11:05] <MacSlow> SiDi, unit-tests should be done also
[11:06] <SiDi> Can they be shell scripts ?
[11:06] <MacSlow> they could but that would be the easy/lazy way :)
[11:06] <MacSlow> they need to be properly integrated into "make check", "make test"
[11:06] <SiDi> Using gconf/xfconf is much much much nicer via CLI than with C (especially gconf :d)
[11:07] <SiDi> ok. it'll take me some time to figure how to do this :/
[11:07] <MacSlow> yeah
[11:07] <SiDi> MacSlow: would you like me to write a template of configuration framework, too ?
[11:08] <MacSlow> unit-tests are unpleasant I know
[11:08] <MacSlow> what do you mean by "template" thereß
[11:08] <MacSlow> ?
[11:09] <SiDi> a defaults-template.c/h file, defining the conf_* functions that are needed (which would return some random values), so that if someone wanna write configuration with a file parser or another conf storage utility, they have a template to get started with
[11:09] <MacSlow> SiDi, nah don't bother
[11:10] <SiDi> Okey
[11:10] <MacSlow> SiDi, that  would best be done the GObject-way ... for consistency reasons
[11:10] <SiDi> I don't think i understand more than 1% of gobject, MacSlow :)
[11:11] <MacSlow> and regarding the tweaking-capability we would not over-commit
[11:12] <MacSlow> SiDi, don't worry... your in good company... at least I can understand any possible "pain" from trying to wrap your brain around it if you tried before :)
[11:12] <MacSlow> especially if one is used to OO coming from C++ or Python
[11:14] <SiDi> Yeh... if i really want efficient OO i prefer writing some Vala or some C++ (even if im not a fan of C++ at all). Gobject is way too tortuous
[11:17] <SiDi> is './configure' || './configure --with-xfconf' acceptable or should i try to get something like './configure --conf-storage=gconf||xfconf' MacSlow ?
[11:20] <MacSlow> --with-gconf or --with-xconf (while being mutually exclusive)
[11:20] <SiDi> ok
[11:25]  * MacSlow -> lunch
[12:50] <njpatel> SiDi: ping -- do you have a bug to track your progress with the gconf work? Some bugs against notify-osd are easily solved with these options, so I'd like something to mark them duplicates of :)
[12:51] <SiDi> njpatel: i've got 3 bugs
[12:51] <SiDi> one for color/opacity, one for text size, one for xfce
[12:52] <SiDi> 394432 335383 331949
[12:52] <SiDi> and there is a branch, lp:~sidi/notify-osd/xfconf-experimental
[12:52] <SiDi> i'm clearing the autotools and writing unit tests now, then it'll be ready for review, njpatel 
[12:52] <njpatel> SiDi: awesome, I'll start marking some of these bugs as dups, then
[12:53] <SiDi> as you wish :)
[13:17]  * SiDi waves at dashua 
[13:22] <dashua> Hey SiDi :)
[13:22] <dashua> You are a coding animal lately.
[13:24] <dashua> https://updown.ubuntuone.com/d286d58c-6db6-4d06-b34f-956c3f069af4
[13:24] <dashua> Polished theme if anyone cares to test :)
[13:25] <SiDi> dashua: i'm a dev after all :P
[13:25] <SiDi> blergh, ubuntuone is broken with xfce Q_Q
[13:25] <dashua> Ah bah
[13:27]  * SiDi hates makefiles and autotools
[13:34] <dashua> SiDi, http://www.speedyshare.com/616120880.html
[13:37] <dashua> I know you're not a fan of the titlebar gradient, but I think it works in this case subtly
[13:37] <SiDi> blargh, remember i run xfwm :P
[13:38] <SiDi> which reminds me i have to refresh several themes for karmic @(^_^)@
[13:39] <SiDi> (btw, im still using Alvaro, dashua ;) )
[13:41] <dashua> Oh nice
[13:44] <dashua> http://www.ubuntu-pics.de/bild/22305/screenshot_005_e6sgtG.png
[13:44] <dashua> I should polish up Alvaro's metacity
[13:44] <dashua> I haven't worked on it in some time
[13:44] <dashua> Your screenies look very nice on the Exaile page
[13:54] <dashua> This may compliment the new sexxy GDM somewhat.  Iteration is nice.
[14:10] <SiDi> thanks dashua :)
[14:10] <SiDi> the new progress bar owns in this screenshot dashua 
[14:11] <SiDi> and the metacity is actually quite cool. Did you try with a cream color such as tooltips' instead of white for metacity ?
[14:12] <mac_v> hehe... dashua has disk errors , palimpsest disk fail?
[14:16] <dashua> mac_v, Ha yeah, that gnome-disk-utility is sensitive
[14:17] <dashua> SiDi, cream for the text?
[14:17] <mac_v> dashua: you can turn it off , once you realize its not fatal
[14:18] <dashua> I don't where this utility appeared from.  Never had it before.
[14:18] <dashua> Ah cool.
[14:20] <mac_v> dashua: its a new karmic "feature" , you can turn it off from the startup apps , when Bug #412152 is properly fixed you can turn it back ON ;)
[14:20] <ubot4> Launchpad bug 412152 in gnome-disk-utility "gnome-disk-utility nags me too much that my disk is failing" [Medium,Triaged] https://launchpad.net/bugs/412152
[14:20] <dashua> mac_v, Thx :)
[14:25] <dashua> mac_v, I'm happy about this.  -> http://www.ubuntu-pics.de/bild/22309/screenshot_006_51bYiB.png
[14:26] <SiDi> (the bottom gradient looks weird ^.^)
[14:26] <SiDi> (how do the ooo menus look like ?)
[14:28] <dashua> Bah not good
[14:28] <dashua> OOo is my theming nemesis
[14:29] <dashua> Oh the bottom is part of the metacity
[14:30] <SiDi> http://imagebin.ca/img/JDL1f6Kl.png huh
[14:37] <mac_v> dashua: looks great , but the bottom could be thinner ;) no pun intended
[14:38] <dashua> Ha ok.  Thx for the feedback.
[14:39] <dashua> Remove the bottom gradient, you think altogether?
[14:41] <mac_v> dashua: i'm not sure about removing , but generally a thinner border would be better 
[14:41] <SiDi> remove :P
[14:41] <dashua> Alright ;)
[14:43] <mac_v> dashua: i really like the new scrollbars :) , awesome , link to the updated theme pls
[14:44] <SiDi> MacSlow: any idea why gconf_client_get_float returns 0.0 and doesnt set error if the gconf key doesnt exist ? :x
[14:45] <dashua> mac_v, bzr branch lp:hanso
[14:45] <MacSlow> SiDi, check the GError
[14:46] <SiDi> its NULL
[14:46] <mac_v> ah... nice
[14:46] <MacSlow> SiDi, not the returned value... 0.0f can be returned if the requested gconf-key didn't exists
[14:46] <dashua> The sexxy scale and progressbar through were removed as it uses nodoka
[14:47] <MacSlow> SiDi, use the GError... don't irgnore it by just passing NULL to it in gconf_client_get_float()
[14:47] <SiDi> MacSlow: i mean the error var is still null after the call to gconf_client_get_string
[14:48] <MacSlow> SiDi, from the GConf ref.-manual: "the value of key, or 0.0 if no value is obtained"
[14:48] <SiDi> oh
[14:48] <SiDi> so 0.0 is another error case :/
[14:48] <MacSlow> SiDi, are you talking about gconf_client_get_float() or gcon_client_get_string()?
[14:49] <SiDi> get_float
[14:49] <SiDi> http://paste.ubuntu.com/255134/ MacSlow 
[14:50] <SiDi> returns : "before 0.8 | after 0.0 | returns 0.0", and never goes inside the "error set" part
[14:54] <MacSlow> SiDi, see what you get as error http://paste.ubuntu.com/255139/
[14:57] <SiDi> MacSlow: my problem is that, while there is an error (the key isnt set), the "error" var is still NULL after the gconf call
[14:57] <SiDi> it doesnt initialize it as it should. and gconf-editor does not show the gconf key, im sure it doesnt exist
[14:58] <MacSlow> SiDi, do you have your branch somewhere public I can pull from?
[14:59] <SiDi> lp:~sidi/notify-osd/xfconf-experimental
[15:03] <dashua> mac_v, SiDi, http://www.ubuntu-pics.de/bild/22310/screenshot_007_dX39ZY.png
[15:05] <mac_v> dashua: hehe , i can see the disabled options having a problem , notice the forward , i had the problem while hacking Dust and dropped it since ti was too much work
[15:06] <MacSlow> SiDi, I'm on a conf-call atm
[15:06] <SiDi> MacSlow: okey
[15:07] <MacSlow> SiDi, conf as in conference... not x/gconf :)
[15:07] <SiDi> MacSlow: crap, was gonna use xfconf-query on you
[15:08] <dashua> mac_v, The nodoka elements?
[15:08] <dashua> It was too hard to support the theme when the engine is not packaged
[15:10] <mac_v> dashua: yeah , its tough to get the disabled option the right shade for  OOo and the rest , else it would look more like a highlighted item , rather than a dimmed one
[15:10] <dashua> Ah yeah. I see what you mean.
[15:16] <SiDi> MacSlow: dont bother with that bug, i workarounded it by using fallback value if the opacity is set to 0.0..
[16:29] <djsiegel3> DanRabbit: ping
[17:02] <SiDi> MacSlow: what the hell should the unit tests actually do ? :/
[17:02] <SiDi> should i change the keys via gconf/xfconf and check that bubbles' properties have the good value ?
[17:03] <MacSlow> SiDi, test every introduced call with wrong keys and verifiing that they return default values (thus notify-osd continues to run and display stuff properly)
[17:03] <MacSlow> SiDi, and then test each gconf/xconf value properly (depending on what system your running on)
[17:04] <SiDi> okey
[17:04] <SiDi> im completely failing to find out how to build my test file, not to mention checking bubbles' properties :D
[17:04] <MacSlow> SiDi, as an example/template look at... notify-osd/tests/test-notification.c how to do it
[17:04] <SiDi> okey
[17:05] <MacSlow> SiDi, the initial problem is to design the code in a way so it can easily be unit tested
[17:05] <MacSlow> SiDi, sometimes it's simple... sometimes it's less than obvious
[17:05] <MacSlow> e.g. stuff like DBus or gconf/xconf make unit-testing less obvious
[17:05] <SiDi> MacSlow: i dont see how i could properly know that my bubble has finished redrawing after i used gconf or xfconf to change a value
[17:06] <MacSlow> SiDi, no... no need fo rthat
[17:06] <MacSlow> SiDi, just make sure (test) for the expected values (or fallback-values)
[17:06] <MacSlow> you'll probably only have to setup and query class Defaults I think
[17:06] <SiDi> in defaults, then ?
[17:06] <MacSlow> yes
[17:06] <SiDi> okey
[17:07] <MacSlow> automatic testing/verification of rendered output is very hard to test against
[17:08] <MacSlow> SiDi, you'll probably have to #ifdef some of the tests depeding of wether you compiled with xconf or gconf
[17:08] <MacSlow> SiDi, that's actually bad... but I don't currently see how to avoid that
[17:09] <MacSlow> SiDi, apart from forcing anybody wanting to run "make test" to install gconf and xconf (+ dependecies)
[17:09] <MacSlow> which would/will annoy a certain kind of people ;)
[17:10] <MacSlow> SiDi, unit-tests are dull and boring... but a very good way to thoroughly ensure all your written API-code is solid and bullet-proof
[17:11] <SiDi> MacSlow: i was thinking of test-xfconf & test-gconf.c, and choosing which to use with Makefile.am
[17:11] <MacSlow> SiDi, that's why unit-test-cases should also pass "crap" to calls to verify it does crash/blowup or so
[17:12] <MacSlow> SiDi, don't you think it's simpler to just add to test-defaults.c?
[17:12] <MacSlow> SiDi, that'll save you some setup and figuring out
[17:12] <SiDi> now that i know this file exists, yes, MacSlow :D
[17:12] <MacSlow> SiDi, if you want to run just your (the unit-test for class Defaults)
[17:12] <MacSlow> do
[17:12] <MacSlow> cd notify-osd/tests
[17:13] <MacSlow> ./test-modules -p /defaults
[17:13] <SiDi> okey
[17:13] <MacSlow> that'll speed up your turn-around cycles while working on your unit-tests
[17:14] <MacSlow> SiDi, I'll be going offline in a few minutes... so should you have further questions... either email them to me ot try to catch me later (in 3 hours) here
[17:16] <SiDi> MacSlow: sure. thanks for your patience :)
[17:17] <SiDi> btw, can i put the DEFAULT_ defines in default.h instead of default.c ?
[17:17] <SiDi> so i can use them from test-default.c instead of copy/pasting values
[17:17]  * MacSlow scratches head... 
[17:18] <SiDi> at the moment you just repeat the values in test-defaults, which will require not forgetting about updating them when you change the defaults
[17:18] <MacSlow> SiDi, that would introduce no harm... yes... that can be savely done
[17:20] <SiDi> okey
[17:20] <MacSlow> SiDi, you're patch against notify-osd will become pretty large i can imagine... so don't be surprised that I'll will reshuffle things a bit and split it up in smaller (~800 loc) chunks for review later
[17:20] <SiDi> MacSlow: i setup a branch and separated commits a little
[17:21] <MacSlow> SiDi, that's just common practice within our team
[17:21] <SiDi> No problem :)
[17:21] <MacSlow> SiDi, just so that you know how I tick :)
[17:56] <djsiegel1> mac_v: I have a paper cuts task if you want it
[17:56] <mac_v> djsiegel1: hmm... what is it?
[17:57] <djsiegel1> move all paper cuts assigned to ayatana to invalid for ayatana, and tag them "ayatana" instead
[17:57] <djsiegel1> mac_v it's only 17 bugs
[17:58] <mac_v> djsiegel1: huh? move them to where?
[17:58] <mac_v> which project?
[17:58] <djsiegel1> no moving
[17:58] <djsiegel1> mark invalid in ayatana
[17:58] <djsiegel1> and tag them with "ayatana"
[17:59] <mac_v> djsiegel1: ok... but what do you want me to state as the reason for that?
[18:00] <djsiegel1> no reason needed
[18:00] <djsiegel1> ayatana is being deleted and re-created
[18:00] <mac_v> ok.
[18:00] <mac_v> djsiegel1: by when do you want this done ?
[18:01] <djsiegel1> now if you can, otherwise I can do it
[18:01] <mac_v> djsiegel1: ATM , i'm busy ... 
[18:01] <djsiegel1> ok, no prob
[18:17] <SiDi> djsiegel1: why is ayatana being deleted ? :|
[18:17] <djsiegel1> SiDi: it's just being renamed
[18:17] <djsiegel1> it's called ayatana-project, and someone wants it renamed to ayatana
[18:18] <djsiegel1> which means it has to be deleted first...
[18:18] <SiDi> why dont you just ping the LP admins about it ? :P
[18:27] <djsiegel1> SiDi: LP admins are the ones who told me to do this
[18:27] <djsiegel1> mac_v: r7 is also short 1 paper cut
[18:28] <mac_v> djsiegel1: r10 will has a few more than needed , you could pick one you like ;p
[18:28] <djsiegel1> ok, cool
[19:47] <mac_v> djsiegel1: is synaptic being replaced in karmic itself? 
[20:14] <SiDi> mac_v: Oo?
[20:15] <mac_v> SiDi: o.0?
[20:15] <SiDi> is synaptic gonna be replaced ?
[20:17] <mac_v> SiDi: eventually by appcenter ,either karmic or karmic+1
[20:19] <SiDi> i really need to subscribe to ubuntu-devel...
[20:19] <SiDi> how many mails / day does that represent ?
[20:20] <mac_v> SiDi: thats not in devel , i just gave you some top secret info
[20:21] <SiDi> bleh
[20:21] <SiDi> how do you know top secret info ?
[20:21] <mac_v> SiDi: well i have my sources...
[20:22]  * SiDi gently tortures mac_v 
[20:22] <SiDi> I'm listening.
[20:23] <mac_v> SiDi: only if you promise not to tell any one else?
[20:23] <SiDi> Sure.
[20:23] <SiDi> (btw, google appcenter :p)
[20:23] <mac_v> SiDi: https://wiki.ubuntu.com/AppCenter
[20:24] <mac_v> ;p
[22:50]  * SiDi waves @ MacSlow 
[22:50] <SiDi> Was gonna send you an email :P
[22:50] <MacSlow> SiDi, just do it anyway :)
[22:50] <MacSlow> hi btw
[22:51] <SiDi> MacSlow: mirco.mueller@canonical.com ?
[23:01] <MacSlow> SiDi, yes