=== fta_ is now known as fta [05:41] 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] maco, "what do you intend to do with the data" is usually the best first question [06:02] 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] because it is a pain in the rear to have to gimp up new gradients every time i change theme [06:02] ah, so you're writing an xml document with a simple svg gradient. [06:02] yeah [06:03] in that case you can probably get away with regular expressions [06:03] i made a sort of barebones svg for it [06:03] hehe thats what i was going to do [06:03] I don't blame you [06:03] 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] yeah, it is a hack, but it works [06:04] especially for something as simple as that.. make the fields something easy to catch like %GRADIENT_FIELD% and tada. [06:04] they were doing this: O_o when i said i spent 2 hours that morning playing with regular expressions... [06:05] meanwhile you're writing about 10 lines instead of the 200 you'd probably need to muck with the xml properly [06:05] riiiight ok then [06:05] trust me, it gets nasty very fast.. [06:05] 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] glib has a regex library compatible with perl's [06:06] yeah, ive messed with xml using python before. it makes for oddly long scripts [06:06] (might be the same one actually, now that I think about it) [06:06] ok thanks [06:06] glib also has a simple xml interface, but I still wouldn't recommend it for something as simple as that [06:12] 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] probably easier to make it as needed [06:17] you mean just write out a file for it each time, rather than modifying an old-and-maybe-b0rked one? [06:17] yeah [06:17] mmk [06:18] 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] it's about 30 lines, if you put newlines after each property [06:19] which is probably far south of a kilobyte... [06:19] 718k [06:19] for 30 lines? [06:19] er, not k [06:20] ah, ls -lh is confusing [06:20] hah, that's better then [06:20] 718 char, so 718 bytes, i guess [06:20] my point is that amount of memory is more than readily available and won't change load times, etc. [06:20] ok === fta_ is now known as fta === MenZa_ is now known as MenZa [13:55] 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? === Zdra is now known as xclaesse === xclaesse is now known as Zdra === Zdra is now known as xclaesse [14:43] seb128, bug 301691 [14:43] Launchpad bug 301691 in cairo "Please sponsor cairo 1.8.4" [Undecided,New] https://launchpad.net/bugs/301691 [14:43] fta2: thanks! === xclaesse is now known as Zdra === MenZa is now known as MenZa_Aries === MenZa_Aries is now known as MenZa [19:15] pitti: ping [19:16] tedg: pong [19:17] pitti: The UDS desktop track is looking really full. Is it worth writing up new things or is it packed? [19:17] I really wanted a GDM session and perhaps a discussion on DevKit/DevKit-power. [19:18] 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] tedg: I freed the Monday 11:00 double session [19:20] pitti: Cool, thank you. [19:20] tedg: ah, scratch that; it's now wednesday 11:00 [19:20] tedg: the online services auth had a people conflict, so I moved that to MOnday [19:20] I need to create blueprint and nominate them for Jaunty, right? [19:20] tedg: can you see the preiliminary schedule on http://summit.ubuntu.com/uds-jaunty/desktop/ ? [19:21] tedg: for uds-jaunty, yes [19:21] hmm [19:21] tedg: for gdm probably a blueprint, yes [19:21] 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] pitti: Cool, I was looking day-by-day, the track view is much better :) [19:24] Well, hughsie is now planning on having GPM 2.24 be HAL and GPM 2.26 be DKP. [19:25] So I'm not sure if there is discussion about what we want to do with GPM. [19:25] A roundtable would probably be fine. [19:28] tedg: if that's determined by upstream, we won't have much choice anyway [19:28] pitti: Well we have the choice to stay with 2.24 for Jaunty. [19:29] tedg: unless 2.26 brings new API which other GNOME parts depend on, perhaps [19:30] 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] Of course, he doesn't control everyone else :) [19:30] tedg: oh, good to know [19:31] 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] another reason is that deferring it would mean that more stuff would use DK in GNOME 2.28 (hopefully) [19:32] 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] pitti: https://blueprints.launchpad.net/ubuntu/+spec/gdm-upgrade [19:37] pitti: Should I make a GPM/DevKit-power one? [19:37] tedg: can't hurt, please do === espacious_ is now known as espacious