this year's google summer of code seems to be really productive for kde. past years seem to have had a lower ratio of useful projects. but watching the commits roll in this year is fun and exciting... marble seems to be getting a general purpose way of overlaying data onto the globe; kalzium is getting 3d molecule viewer loving; krdc is rejuvenated; koffice is getting collaborative editting (something that i'd love to see as a kde-wide framework); kbabel is getting a successor; there's an icon cache underway .... and much more. this year's SoC is going to have a noticeable impact on kde, i think. i can also see a large number of the participants sticking around the project after SoC 2k7 is over.
take the icon cache as an example ... lubos lunak and i are co-mentoring rivo on that project and he has been producing some astounding results there. so far he's managed to shave half a second or so off of start up time of apps when using the iconcache and disk caches are cold. i just wanted to see somewhere we could efficiently store runtime rendered icons, so this is a really nice development. rivo's also been working on kwin composite stuff ... so, rock on rivo!
speaking of runtime rendered icons i've got a bit of work to do tomorrow on the icon loader to support some of the new features we need for the icon spec naming (which wants to allow for fallback, so that e.g. if 'media-optical-foo-bar-baz' doesn't exist it may return 'media-optical' instead) as well as to get rid of uglies like all the -mounted icons by properly supporting overlays and emblems.
i also compressed the svg icons in svn resulting in a drop of disk usage from 164mb to 32mb for the svgs. tackat showed me a script he's been using that shaves another 15% off of that; we'll probably run that over the release tarballs as it removes some information from the svg's that make editing them easier in inkscape but which for rendering purposes are completely superfluous.
the kde4 amarok stuff is also rocking. i lent a hand tonight in getting a translucent qgraphicsview overlay in there for jeff who's working on some cool user interaction stuff.
there are going to be some seriously rocking kde4 apps out there, and SoC is helping make that happen.
About Me
Labels
- akademy (3)
- amarok (1)
- appeal (1)
- build system (1)
- community (7)
- crash (2)
- d-bus (1)
- dataengine (1)
- dolphin (2)
- events (1)
- family (1)
- free software (1)
- gnome (2)
- graphics (1)
- guademy (1)
- kde (52)
- kde e.v. (3)
- kde; kdegraphics (1)
- konqueror (1)
- krunner (4)
- libs (5)
- lug radio (1)
- media center (1)
- misc (1)
- openid (1)
- oxygen (2)
- performance (1)
- photos (1)
- plasma (26)
- podcast (1)
- pr (1)
- prose (1)
- release (1)
- social (1)
- solaris (1)
- techbase (6)
- travel (6)
- trolltech (3)
- web2.0 (1)
3 comments:
"It removes some information from the svg's that make editing them easier in inkscape but which for rendering purposes are completely superfluous."
Do you mean it converts an "Inkscape SVG" into a standard SVG? It can be saved as such from Inkscape, but then again we want them to be Inkscape SVGs in SVN for easy editing. I'd be interested to know how this script works. :)
Not wanting to be annoying, but...
Are these under the GPL? Is the Inkscape SVG format the "preferred form for editing"?
Or more practically minded; if someone edits them from these tarballs and then wants to submit them, is this going to cause dataloss?
@Shalken: removing the inkscape/sodipodi tags is one thing it does. yes, you can do that from within inkscape, but it's easier to just run one script over them all at the end since we don't want to lose this information from the versions in svn.
the script also does things like round off all the coordinates to 4 decimal places rather than the usual 8 which inkscape saves. that alone saves nearly as much as getting rid of the inkscape tags.
@anon: yes, they are free software licensed, though not on the gpl (which is to restrictive in this case). svg is the preferred form for editting, and the originals are always available in svn.
btw, this is one reason i really dislike using the gpl or even lgpl for artwork. the intention and wording of those licenses is often quite irrelevant for art.
"is this going to cause dataloss?"
no.
Post a Comment