[05:41] <maco> to manipulate an xml file with libxml2, should i use the parser and make it into a tree, or should i use xmlreader, regular expressions, and xml writer...or what?
[05:59] <awalton__> maco, "what do you intend to do with the data" is usually the best first question
[06:02] <maco> awalton__: i want to make gnome-panel able to use a gradient defined by an xml file as the background.  the properties thing for gnome-panel should be able to change the colors, size, and orientation of the image by modifying the svg directly.
[06:02] <maco> because it is a pain in the rear to have to gimp up new gradients every time i change theme
[06:02] <awalton__> ah, so you're writing an xml document with a simple svg gradient.
[06:02] <maco> yeah
[06:03] <awalton__> in that case you can probably get away with regular expressions
[06:03] <maco> i made a sort of barebones svg for it
[06:03] <maco> hehe thats what i was going to do
[06:03] <awalton__> I don't blame you
[06:03] <maco> and then the other cs majors i talked to at school were saying that was a bit of a hack for modifying xml
[06:03] <awalton__> yeah, it is a hack, but it works
[06:04] <awalton__> especially for something as simple as that.. make the fields something easy to catch like %GRADIENT_FIELD% and tada.
[06:04] <maco> they were doing this: O_o when i said i spent 2 hours that morning playing with regular expressions...
[06:05] <awalton__> meanwhile you're writing about 10 lines instead of the 200 you'd probably need to muck with the xml properly
[06:05] <maco> riiiight ok then
[06:05] <awalton__> trust me, it gets nasty very fast..
[06:05] <maco> uh, library i should look at for doing regex in C? i dont suppose calling sed from within gnome-panel would be "normal"
[06:05] <awalton__> glib has a regex library compatible with perl's
[06:06] <maco> yeah, ive messed with xml using python before.  it makes for oddly long scripts
[06:06] <awalton__> (might be the same one actually, now that I think about it)
[06:06] <maco> ok thanks
[06:06] <awalton__> glib also has a simple xml interface, but I still wouldn't recommend it for something as simple as that
[06:12] <maco> awalton__: do you think it would make sense to always have it start from a "fresh" .svg file instead of modifying the existing one in case the user A) deletes it accidentally B) breaks the xml-ness?
[06:17] <awalton__> probably easier to make it as needed
[06:17] <maco> you mean just write out a file for it each time, rather than modifying an old-and-maybe-b0rked one?
[06:17] <awalton__> yeah
[06:17] <maco> mmk
[06:18] <awalton__> it's not like an xml file encoding a gradient is going to be huge, it'd be fine to embed it in the program as a static string
[06:18] <maco> it's about 30 lines, if you put newlines after each property
[06:19] <awalton__> which is probably far south of a kilobyte...
[06:19] <maco> 718k
[06:19] <awalton__> for 30 lines?
[06:19] <maco> er, not k
[06:20] <maco> ah, ls -lh is confusing
[06:20] <awalton__> hah, that's better then
[06:20] <maco> 718 char, so 718 bytes, i guess
[06:20] <awalton__> my point is that amount of memory is more than readily available and won't change load times, etc.
[06:20] <maco> ok
[13:55] <seb128> fta, fta2: hi, I'm looking to your cairo update, there is no need to list the maintainer changes in the changelog, that's systematic for the ubuntu versions, could you quickly open a bug and attach the debdiff for the update using a non ppa version and describing what the lcdfilter do?
[14:43] <fta2> seb128, bug 301691
[14:43] <seb128> fta2: thanks!
[19:15] <tedg> pitti: ping
[19:16] <pitti> tedg: pong
[19:17] <tedg> pitti: The UDS desktop track is looking really full.  Is it worth writing up new things or is it packed?
[19:17] <tedg> I really wanted a GDM session and perhaps a discussion on DevKit/DevKit-power.
[19:18] <pitti> tedg: ah, I already told Scott, I'm happy to move the "fix packages for translation/rosetta import" double session to a spare room
[19:19] <pitti> tedg: I freed the Monday 11:00 double session
[19:20] <tedg> pitti: Cool, thank you.
[19:20] <pitti> tedg: ah, scratch that; it's now wednesday 11:00
[19:20] <pitti> tedg: the online services auth had a people conflict, so I moved that to MOnday
[19:20] <tedg> I need to create blueprint and nominate them for Jaunty, right?
[19:20] <pitti> tedg: can you see the preiliminary schedule on http://summit.ubuntu.com/uds-jaunty/desktop/ ?
[19:21] <pitti> tedg: for uds-jaunty, yes
[19:21] <dobey> hmm
[19:21] <pitti> tedg: for gdm probably a blueprint, yes
[19:21] <pitti> tedg: for DK, it might alternatively become a roundtable, depending on whether it's just discussion, or something to actually implement in jaunty
[19:21] <tedg> pitti: Cool, I was looking day-by-day, the track view is much better :)
[19:24] <tedg> Well, hughsie is now planning on having GPM 2.24 be HAL and GPM 2.26 be DKP.
[19:25] <tedg> So I'm not sure if there is discussion about what we want to do with GPM.
[19:25] <tedg> A roundtable would probably be fine.
[19:28] <pitti> tedg: if that's determined by upstream, we won't have much choice anyway
[19:28] <tedg> pitti: Well we have the choice to stay with 2.24 for Jaunty.
[19:29] <pitti> tedg: unless 2.26 brings new API which other GNOME parts depend on, perhaps
[19:30] <tedg> pitti: Well hughsie in his mail specifically mention that some distros may want to use 2.24 -- so I don't think that's in his plan.
[19:30] <tedg> Of course, he doesn't control everyone else :)
[19:30] <pitti> tedg: oh, good to know
[19:31] <pitti> tedg: TBH, for jaunty I welcome everything which avoids large structural changes, since we want to put as much effort as possible into bug fixing
[19:31] <pitti> another reason is that deferring it would mean that more stuff would use DK in GNOME 2.28 (hopefully)
[19:32] <tedg> Yeah, none the less, I think we should spend sometime going over the pros and cons at UDS.  I don't care if it's a roundtable or a session.
[19:36] <tedg> pitti: https://blueprints.launchpad.net/ubuntu/+spec/gdm-upgrade
[19:37] <tedg> pitti: Should I make a GPM/DevKit-power one?
[19:37] <pitti> tedg: can't hurt, please do