[11:07] <SiDi> MacSlow: hiya
[11:08] <SiDi> When a defaults value is out of bounds, should i : 1) return without changing anything | 2) set to default | 3) set to nearest bound ?
[11:08] <SiDi> (4) segfault :P)
[11:52] <MacSlow> SiDi, no crashers please :)
[11:53] <MacSlow> SiDi, just spit out a waring on stdout (e.g. g_warning()) and don't change anything
[11:55] <MacSlow> SiDi, it's debatable if you set it to the lowest possbile value if it was attempted be set lower (or the hightest possible value if it was attempted to be set higher)
[11:56] <MacSlow> SiDi, not changing anything and just spitting out a warning on stdout is the safest path
[11:58] <SiDi> MacSlow: okey
[13:26]  * MacSlow -> lunch
[13:48] <SiDi> Purely rethorical question : if i know the data given to a function is ALWAYS good (i test that it'll be good before using it), shall i remove error checking code after i called this function ?
[15:52] <mac_v> djsiegel1: djsiegel3 https://bugs.launchpad.net/notify-osd/+bug/340996/comments/13
[15:52] <ubot4> Launchpad bug 340996 in hundredpapercuts "Notifications should stay on screen longer when there is a lot of text" [Undecided,Confirmed] 
[15:53] <djsiegel3> mac_v yes I saw
[15:55] <MacSlow> djsiegel3, mac_v: I'm pedantic there... but it's a fact... not really a bug fulfilling the papercut-requirements as the involved work is considerable.
[15:56] <djsiegel3> MacSlow: really?
[15:56] <mac_v> djsiegel3: next cycle ,how about minimizing the number of papercuts and expanding the scope?
[15:56] <djsiegel3> it's not just length (message) * MILLISECONDS_PER_CHAR ?
[15:56] <djsiegel3> mac_v, what do you mean?
[15:56] <djsiegel3> expanding the scopr
[15:56] <djsiegel3> you mean, changing the definition of a paper cut to include more things?
[15:57] <mac_v> djsiegel1: like reducing number <100, and taking on bigger bugs?
[15:57] <djsiegel3> like, why don't we just say paper cut = any bug and fix 20 of them? :)
[15:57] <mac_v> djsiegel3: not any bug , but bug with usability issues
[15:58] <MacSlow> djsiegel3, started to work on it (preparing notify-osd with some refactoring) but some priority-shifts have me currently working on another thing in notify-osd
[15:58] <djsiegel3> MacSlow, I'm curious because I wrote a notifications API in GNOME Do for plugins and did time calculations like that based on message length
[15:58] <djsiegel3> it was very simple
[15:58] <djsiegel3> longer messages stayed on screen longer
[15:59] <mac_v> djsiegel3: some usability issues are not pushed since they are a little bigger to fix , like for example the click to rename
[15:59] <MacSlow> djsiegel3 you're formatting, layouting and special cases were not as complex as in the notify-osd spec I imagine
[15:59] <djsiegel3> certainly
[16:00] <djsiegel3> mac_v, that should be a separate project maybe/
[16:00] <djsiegel3> maybe we could do 50 paper cuts, and 10 usability bugs
[16:00] <mac_v> djsiegel3: yeah, that would be good
[16:01] <mac_v> djsiegel3: i fear we'll run out of *minor* things to fix in 2 cycles ;)
[16:01] <djsiegel3> mac_v we can always make more buggy software
[16:01] <mac_v> lol
[16:59] <SiDi> djsiegel3: its true you need to take into account updates + appends + priority of bubbles in the stack
[16:59] <SiDi> + summer holidays :P
[17:00] <djsiegel3> SiDi: and leap years
[17:00] <SiDi> and angriness of kittens in your direct environment.
[17:00] <SiDi> ..no ?
[17:58] <SiDi> MacSlow: any g_warning makes a test fail, right ?
[17:58] <MacSlow> depends on G_DEBUG
[17:58] <MacSlow> afaik
[17:59] <SiDi> i'm running into a very stupid situation
[17:59] <MacSlow> use g_print()
[17:59] <SiDi> i'm trying to set font size to a negative value, my setter of course doesnt modify the value, but it g_warns about the out-of-bound
[18:01] <MacSlow> SiDi, try G_DEBUG=fatal_criticals ./test-modules -p /defaults
[18:01] <MacSlow> that should not make g_warning() abort the test
[18:13] <MacSlow> apparently not
[18:13] <MacSlow> hm...
[18:13] <MacSlow> stick to g_print then