
Hi,
Google is doing it again. Here is the link: http://google-code-updates.blogspot.com/2007/02/speaking-of-summer.html
Regards, Tobias

On 2/16/07, Tobias Jakobs <tobias.jakobs@...128...> wrote:
Hi,
Google is doing it again. Here is the link: http://google-code-updates.blogspot.com/2007/02/speaking-of-summer.html
I think we should start planning our participation a little earlier this year. One thing that I think we should do this time is make it obligatory for all participants to have at least one bugfix patch accepted before they are considered.
If there are any eligible people on this list who plan to participate, let's get the discussion going about what projects you might be interested in.

bulia byak wrote:
On 2/16/07, Tobias Jakobs <tobias.jakobs@...128...> wrote:
Hi,
Google is doing it again. Here is the link: http://google-code-updates.blogspot.com/2007/02/speaking-of-summer.html
I think we should start planning our participation a little earlier this year. One thing that I think we should do this time is make it obligatory for all participants to have at least one bugfix patch accepted before they are considered.
I completely agree that a bugfix (or enhancement) patch first seems like a reasonable requirement. My personal feeling is that last year's wasted spot was VERY unfortunate.
As for planning, our wiki page with proposals from last year is at http://wiki.inkscape.org:8080/wiki/index.php/Googles_Summer_Of_Code and it appears that almost all of it still applies. Shall we start updating it for this year? Are last year's mentors still willing to mentor on the topics per the page? Any newer developers that would be willing to mentor?
From an artist's perspective (well, mine at least), more SVG Filters and Live Path Effects would really help boost productivity and cut down on the number of "hacks" and retries to get things right. I also feel that if possible, Cairo should be the one to use a student for PDF (since the core devs are busy with other things). Perhaps we should discuss it with Carl to get his thoughts.
If there are any eligible people on this list who plan to participate, let's get the discussion going about what projects you might be interested in.
Any eligible students or potential mentors, please do speak up.
-Josh

On 2/16/07, Joshua A. Andler wrote:
As for planning, our wiki page with proposals from last year is at http://wiki.inkscape.org:8080/wiki/index.php/Googles_Summer_Of_Code and it appears that almost all of it still applies.
I would note that " H. Inkscape / GIMP Bitmap Editing Integration" seems to be implementable thanks to Verse protocol that is originally developed for Blender (and GIMP).
Alexandre

Alexandre Prokoudine wrote:
On 2/16/07, Joshua A. Andler wrote:
As for planning, our wiki page with proposals from last year is at http://wiki.inkscape.org:8080/wiki/index.php/Googles_Summer_Of_Code and it appears that almost all of it still applies.
I would note that " H. Inkscape / GIMP Bitmap Editing Integration" seems to be implementable thanks to Verse protocol that is originally developed for Blender (and GIMP).
Verse would be fantastic. I think I've mentioned it in the past but never found any interested parties.
Aaron Spike

Joshua A. Andler wrote:
As for planning, our wiki page with proposals from last year is at http://wiki.inkscape.org:8080/wiki/index.php/Googles_Summer_Of_Code and it appears that almost all of it still applies.
I am currently working on the grid code. Hope to get that finished soon. The change includes a new grid class for easier grid implementation, plus the ability to have multiple grids (different views can have different grids aswell). So point "E. New Grids" can be changed. (that is, if you like my implementation :)
Shall we start updating it for this year? Are last year's mentors still willing to mentor on the topics per the page? Any newer developers that would be willing to mentor? [...] Any eligible students or potential mentors, please do speak up.
I have no idea what GSoC actually is, and their site does not really clearify much. I'll try to get onto jabber tomorrow to ask around.
Cheers, Johan

On Sat, 2007-02-17 at 02:04 +0100, J.B.C.Engelen@...1578... wrote:
I have no idea what GSoC actually is, and their site does not really clearify much. I'll try to get onto jabber tomorrow to ask around.
Basically Google hires interns to work on Open Source projects. They pay the intern, and then they give some money to the OS project to reimburse for mentoring. There are a few requirements throughout the summer, like a mid term evaluation, but otherwise they pretty much stay out of the way.
--Ted

bulia byak wrote:
On 2/16/07, Tobias Jakobs <tobias.jakobs@...128...> wrote:
Google is doing it again. Here is the link: http://google-code-updates.blogspot.com/2007/02/speaking-of-summer.html
I think we should start planning our participation a little earlier this year. One thing that I think we should do this time is make it obligatory for all participants to have at least one bugfix patch accepted before they are considered.
I think that is an excellent requirement and it is something that can be easily measured. I'd like to also be sure we factor in community involvement in our selection process. It is less easy to measure generic "community involvement", but anecdotal evidence from past GSoC's have shown that more involved and social students are more successful SoCers. I'd like students to become active on the ML and IRC/Jabber in discussing their plans.
Aaron Spike

On Fri, 2007-02-16 at 12:16 -0400, bulia byak wrote:
If there are any eligible people on this list who plan to participate, let's get the discussion going about what projects you might be interested in.
Ideas I was throwing around, but I haven't fully developed:
-- Integrating the Perl and Python interpreters to run scripts. Basically they wouldn't have to connect to anything in Inkscape, but they'd keep the script parsed while it was being used (handled by the load and unload events).
-- Better bitmap insertion. Basically getting things like DPI information out of bitmaps and having that "just work" for most people. I'd also be nice to integrate a base64 encoder on the load function to embed images on load also. Lastly, I think we should have some way to set up a clipping path on images that have full transparency. This might be an extension though.
-- Imagemagick bitmap operations. I still really like this one, I think that people got confused last year thinking I wanted to convert vector-to-raster and then do an operation on it. No, really, I want to only have operations on things that are already bitmaps. This way you can do the simple bitmap stuff without using The GIMP.
-- PDF import using Cairo and Popler. Anyone know how good Cairo's SVG output is currently? If it's not ready, this project shouldn't be done.
--Ted

On Feb 16, 2007, at 11:01 PM, Ted Gould wrote:
-- Better bitmap insertion. Basically getting things like DPI information out of bitmaps and having that "just work" for most people. I'd also be nice to integrate a base64 encoder on the load function to embed images on load also. Lastly, I think we should have some way to set up a clipping path on images that have full transparency. This might be an extension though.
This is a very good area, and one that I could expand on greatly.
I think I understand a lot of this well, along with both the technical and UI needs. I think we probably have enough in this area for a few proposals, and it is the sort of thing that's modular enough to work well for SoC.

Ted Gould wrote:
-- Better bitmap insertion. Basically getting things like DPI information out of bitmaps and having that "just work" for most people. I'd also be nice to integrate a base64 encoder on the load function to embed images on load also. Lastly, I think we should have some way to set up a clipping path on images that have full transparency. This might be an extension though.
Part one is a great idea. Is it enough work for SoC? And could you offer more detailed explaination of part 2 there? clipping? transparency?
-- Imagemagick bitmap operations. I still really like this one, I think that people got confused last year thinking I wanted to convert vector-to-raster and then do an operation on it. No, really, I want to only have operations on things that are already bitmaps. This way you can do the simple bitmap stuff without using The GIMP.
I think it would be majorly cooler to have right click "edit in gimp" and use Verse for realtime updates in inkscape. But since that hasn't caught on, I think we should push for integrating gegl rather than imagemagick. gegl might be able to offer us things like rendering for svg filters and such too.
Aaron Spike

On Sat, Feb 17, 2007 at 01:25:59PM -0600, Aaron Spike wrote:
Ted Gould wrote: I think it would be majorly cooler to have right click "edit in gimp" and use Verse for realtime updates in inkscape. But since that hasn't caught on, I think we should push for integrating gegl rather than imagemagick. gegl might be able to offer us things like rendering for svg filters and such too.
We also know more gegl developers than imagemagick developers. ;-)
Bryce

On Feb 17, 2007, at 11:25 AM, Aaron Spike wrote:
I think it would be majorly cooler to have right click "edit in gimp" and use Verse for realtime updates in inkscape. But since that hasn't caught on, I think we should push for integrating gegl rather than imagemagick. gegl might be able to offer us things like rendering for svg filters and such too.
I'd say edit in Gimp and suck in changes live (Verse or just file system) would be very good. Not trying to make Inkscape "do" bitmap manipulation is good, but so is making the workflow better.

On Sat, 2007-02-17 at 11:59 -0800, Jon A. Cruz wrote:
On Feb 17, 2007, at 11:25 AM, Aaron Spike wrote:
I think it would be majorly cooler to have right click "edit in gimp" and use Verse for realtime updates in inkscape. But since that hasn't caught on, I think we should push for integrating gegl rather than imagemagick. gegl might be able to offer us things like rendering for svg filters and such too.
I'd say edit in Gimp and suck in changes live (Verse or just file system) would be very good. Not trying to make Inkscape "do" bitmap manipulation is good, but so is making the workflow better.
I guess I don't really feel that we're "doing" bitmap manipulation by using the Imagemagick filters. If nothing else, we wouldn't be doing that much of it. One thing that I think is interesting here, is that probably the largest praise that Xara gets is having some bitmap manipulation inside it! (besides the really fast renderer of course)
--Ted

Am Sonntag, den 18.02.2007, 13:13 -0800 schrieb Ted Gould:
On Sat, 2007-02-17 at 11:59 -0800, Jon A. Cruz wrote:
I'd say edit in Gimp and suck in changes live (Verse or just file system) would be very good. Not trying to make Inkscape "do" bitmap manipulation is good, but so is making the workflow better.
I guess I don't really feel that we're "doing" bitmap manipulation by using the Imagemagick filters. If nothing else, we wouldn't be doing that much of it. One thing that I think is interesting here, is that probably the largest praise that Xara gets is having some bitmap manipulation inside it! (besides the really fast renderer of course)
As far as I know, Xaras bitmap manipulation tool is nice integrated, but it's a single program. That's even the reason, why it is not integrated into the Linux version. Can't we use DBUS instead of Verve? I don't think we need Verves network protocol here, do we?
Regards, Tobias

On Tue, 2007-02-20 at 00:03 +0100, Tobias Jakobs wrote:
As far as I know, Xaras bitmap manipulation tool is nice integrated, but it's a single program. That's even the reason, why it is not integrated into the Linux version. Can't we use DBUS instead of Verve? I don't think we need Verves network protocol here, do we?
I'd have no problem using DBUS, but someone would have to define an API and get the GIMP people to adopt it too. I think that is much larger than a Google Summer of Code project.
It might make an interesting "hackfest" type topic for LGM though. The one thing that I think is tricky (that'd I'd really like to see the protocol support) is a concept of "shared undo". So "undo is undo" no mater what application you made the change it. That could definitely be tricky.
--Ted

SOC time again hey ?... time to pimp my obvious wishlist :-)
External styles ! External styles ! External styles ! External styles ! http://wiki.inkscape.org/wiki/images/Styleseditor.png
Blendmodes ! Blendmodes ! Blendmodes ! Blendmodes ! http://wiki.inkscape.org/wiki/images/Fillstroke2.png

Dan H. wrote:
Yeah... Markers inherit stroke color ! Markers inherit stroke color !
Unfortunately that request doesn't jive well with the SVG spec. See a "marker" isn't just an extension of the stroke. A marker is arbitrary chunks of svg transformed at important spots along a path. So pretend you drew a nice shiney 24 color house complete with gradients and blur, etc. Now you draw a nice thickly stroked black path to represent a winding country road. You can place houses along this road by using your house as mid-markers. Which part of the house would inherit the stroke paint. Notice I said "paint" not "color" because strokes can have gradient paint or pattern paint (patterns again being arbitrary SVG chunks. I haven't researched it much but I've heard that SVG 1.2 has allowances for using inherited colors in markers. But SVG 1.2 hasn't been finalized yet. And as they have been removing portions of the spec it is rather dangerous to implement any of it until it is final (cf. flow text). Now I realize that in the great majority of use cases markers may in fact be just a single color extension of the stroke, but the spec allows for much more. I think it is important that people realize that.
Probably the best we can do is invoke the X in SVG and add some semantic extension elements or attributes that inkscape could use to key in on paints in a marker that could be inherited from the stroke. We could use these marks to enable smarter editing and still generate compliant fully flexible SVG.
Maybe this would indeed be a good SoC task.
Aaron Spike

On Tue, 2007-02-20 at 00:03 +0100, Tobias Jakobs wrote:
Am Sonntag, den 18.02.2007, 13:13 -0800 schrieb Ted Gould:
On Sat, 2007-02-17 at 11:59 -0800, Jon A. Cruz wrote:
I'd say edit in Gimp and suck in changes live (Verse or just file system) would be very good. Not trying to make Inkscape "do" bitmap manipulation is good, but so is making the workflow better.
I guess I don't really feel that we're "doing" bitmap manipulation by using the Imagemagick filters. If nothing else, we wouldn't be doing that much of it. One thing that I think is interesting here, is that probably the largest praise that Xara gets is having some bitmap manipulation inside it! (besides the really fast renderer of course)
As far as I know, Xaras bitmap manipulation tool is nice integrated, but it's a single program. That's even the reason, why it is not integrated into the Linux version. Can't we use DBUS instead of Verve? I don't think we need Verves network protocol here, do we?
Regards, Tobias
Since GEGL is getting mature, it might be nice to have some simple bitmap editor based on GEGL ship along with inkscape even...GEGL is the next-gen gimp core...
Jon

On Sat, 2007-02-17 at 13:25 -0600, Aaron Spike wrote:
Ted Gould wrote:
-- Better bitmap insertion. Basically getting things like DPI information out of bitmaps and having that "just work" for most people. I'd also be nice to integrate a base64 encoder on the load function to embed images on load also. Lastly, I think we should have some way to set up a clipping path on images that have full transparency. This might be an extension though.
Part one is a great idea. Is it enough work for SoC? And could you offer more detailed explaination of part 2 there? clipping? transparency?
Hmm, I'm trying to think of it now, but it seemed like a really good idea at the time. I was thinking that it would change the way filters get applied to it, as the actual "edge" wouldn't include the transparent areas -- but I can't think of a filter now that would make a difference either way...
I'm not sure if it is a full project yet, but I'm sure someone on this mailing list has more ideas to put in this bucket ;)
-- Imagemagick bitmap operations. I still really like this one, I think that people got confused last year thinking I wanted to convert vector-to-raster and then do an operation on it. No, really, I want to only have operations on things that are already bitmaps. This way you can do the simple bitmap stuff without using The GIMP.
I think it would be majorly cooler to have right click "edit in gimp" and use Verse for realtime updates in inkscape. But since that hasn't caught on, I think we should push for integrating gegl rather than imagemagick. gegl might be able to offer us things like rendering for svg filters and such too.
Honestly, I really don't want to be the people pushing GEGL. When GIMP releases a version that gets into distros, then I'm excited about using it. But, until then, I'll wait. GEGL has been on the "it'll be done any moment now" list for too long to make plans around (I do know it is looking better as of late, but I'm still interested in waiting)
I kinda have the same feeling about Verve. When we met the guy doing it at SIGGraph last year he seemed, well, very ambitious about everything it'll do. He didn't specifically mention making toast, but I believe that's just because we didn't talk long enough. I haven't looked at that since though. Have the restricted the scope and released something stable?
Seriously, I'm not trying to be a buzz kill here, but I'm just not interested in riding the cool new thing. I think it's a true shame that Miklos spent more time on fixing Cairo PDF than working in Inkscape. (not that there is a problem with Cairo, but I thought that was going to be the "easy part" of the project).
--Ted

On Sat, 2007-02-17 at 13:25 -0600, Aaron Spike wrote:
I think it would be majorly cooler to have right click "edit in gimp" and use Verse for realtime updates in inkscape. But since that hasn't caught on, I think we should push for integrating gegl rather than imagemagick. gegl might be able to offer us things like rendering for svg filters and such too.
Sorry, I totally missed the "hasn't caught on" when replying to the e-mail originally. I swear, I'll learn read someday. Sorry.
--Ted

On Feb 16, 2007, at 8:16 AM, bulia byak wrote:
If there are any eligible people on this list who plan to participate, let's get the discussion going about what projects you might be interested in.
Definitely put me down for mentor, and also very much in support of getting things going early and well.
One thing I've gotten here and there is that the publication of what it is could go out a little more widely. The more people who become aware, the better for all.
Oh, and also the more getting interested in contributing to Inkscape, the better it is for our project. :-)
participants (12)
-
unknown@example.com
-
Aaron Spike
-
Alexandre Prokoudine
-
Andy Fitzsimon
-
Bryce Harrington
-
bulia byak
-
Dan H.
-
Jon A. Cruz
-
Jon Phillips
-
Joshua A. Andler
-
Ted Gould
-
Tobias Jakobs