Re: [Inkscape-user] Google Summer of Code (raster functionality)
Why would built-in raster functionality create anything different than what you would get by doing your raster bits inside an external editor (i.e. GIMP) and importing the results into Inkscape?
----- Original Message ----
Raster Functionality in Inkscape by Christopher Brown, mentored by Theodore J. Gould
I'm curious about this one because the writeup basically says this will create things that aren't SVG. Is there a plan to make a new file extension at some point? It would still be mostly SVG, just augmented with extra stuff. The Inkscape-specific extension would be like a warning -- "This is not plain vanilla svg and may not render correctly as such". Kinda like how .ai files are mostly just regular .ps files, but if it doesn't look right in your .ps viewer, you know you should try it in Illustrator.
--bb
Am Donnerstag, den 12.04.2007, 08:41 -0700 schrieb Tony Vigil:
Why would built-in raster functionality create anything different than what you would get by doing your raster bits inside an external editor (i.e. GIMP) and importing the results into Inkscape?
First of all you dont need to fire up an additional program. Editing an image with an integrated editor would be much smother. You could see the complete context your raster images is used in and you dont have to reimport the image after changing it with an external program.
I would also prefer if the functionality of using external editors would improve. For example on linux use inotify to get changes of linked images and reload them.
If it would be possible to embed the gimp into inkscape it would be a really cool thing :) Or the other way around: have an svg as an layer within an gimp file.
Greetings, Florian Ludwig
On Fri, Apr 13, 2007 at 12:56:01PM +0200, Florian Ludwig wrote:
I would also prefer if the functionality of using external editors would improve. For example on linux use inotify to get changes of linked images and reload them.
This sounds interesting - can you explain in more detail how we could use inotify in this manner?
If it would be possible to embed the gimp into inkscape it would be a really cool thing :) Or the other way around: have an svg as an layer within an gimp file.
One way to achieve this cleanly could be to have Inkscape incorporate GeGL (a library for raster stuff), and Gimp to incorporate Cairo (a library for vector stuff).
Having Inkscape depend directly on Gimp, or vice versa, could make for some messy dependencies. However, having them depend on common libraries is a safe, tried and true strategy.
Bryce
Am Freitag, den 13.04.2007, 10:01 -0700 schrieb Bryce Harrington:
On Fri, Apr 13, 2007 at 12:56:01PM +0200, Florian Ludwig wrote:
I would also prefer if the functionality of using external editors would improve. For example on linux use inotify to get changes of linked images and reload them.
This sounds interesting - can you explain in more detail how we could use inotify in this manner?
Hm,
Inotify is a system provided by the kernel (imo 2.6 only) You can say "notify my if file X changed" (and a lot more things are possible, but not interesting in here). So if you open an svg with linked images. Inkscape sets a callback function that gets called by inotify if one of the linked raster images gets changed (though an external program). This function reloads the images from the harddisk and redraw the scene.
From the users view:
Image a (svg) scene with a wall and a poster on it. The poster is an raster image. The user opens an the svg in inkscape. Decides the imported poster needs some fixes and opens gimp (or...). and with gimp the poster and adjusts it. Saves. Switch to inkscape and look at the hole scene with the new poster. (without doing anything in inkscape)
If it would be possible to embed the gimp into inkscape it would be a really cool thing :) Or the other way around: have an svg as an layer within an gimp file.
One way to achieve this cleanly could be to have Inkscape incorporate GeGL (a library for raster stuff), and Gimp to incorporate Cairo (a library for vector stuff).
Having Inkscape depend directly on Gimp, or vice versa, could make for some messy dependencies. However, having them depend on common libraries is a safe, tried and true strategy.
Bryce
i fully agree here. Having those dependents would be overkill.. I think having an flexible system for embedding would be really cool. So that gimp *could* be used as editor for raster images. Just thought if there would be some points of cooperation it may bring some cool stuff. But let see what the gsoc creates / the future brings.
flo
On Apr 13, 2007, at 1:30 PM, Florian Ludwig wrote:
Am Freitag, den 13.04.2007, 10:01 -0700 schrieb Bryce Harrington:
On Fri, Apr 13, 2007 at 12:56:01PM +0200, Florian Ludwig wrote:
I would also prefer if the functionality of using external editors would improve. For example on linux use inotify to get changes of linked images and reload them.
This sounds interesting - can you explain in more detail how we could use inotify in this manner?
Hm,
Inotify is a system provided by the kernel (imo 2.6 only) You can say "notify my if file X changed" (and a lot more things are possible, but not interesting in here). So if you open an svg with linked images. Inkscape sets a callback function that gets called by inotify if one of the linked raster images gets changed (though an external program). This function reloads the images from the harddisk and redraw the scene.
It is interesting, but there are certain issues with inotify. On the other hand, by hooking the callbacks on windows/apps coming forward we could achieve the same net effect by manually checking the "assets" when our app regains attention. Plus that ends up cross- platform.
Hm,
Inotify is a system provided by the kernel (imo 2.6 only) You can say
"notify my if file X changed" (and a lot more things are possible, but
not interesting in here).
So if you open an svg with linked images. Inkscape sets a callback
function that gets called by inotify if one of the linked raster images
gets changed (though an external program). This function reloads the
images from the harddisk and redraw the scene.
It is interesting, but there are certain issues with inotify. On the other hand, by hooking the callbacks on windows/apps coming forward we could achieve the same net effect by manually checking the "assets" when our app regains attention. Plus that ends up cross-platform.
The portability is an issue.. yes. But i would prefer to use it if available. How often do you like to check the "assets" for changes? I think its hard to find a good value of time between the checks. If you check to often its add to much load to the hard disk (though it should get cached by the os but older systems like windows 98 doesnt do this well and anyway it doesnt sounds like a good solution) but if you check less often like once a minute its not that useful for the user.
Imo its worth implementing it with inotify even if there is another portable system for checking (as "fallback").
Florian
On Apr 13, 2007, at 1:50 PM, Florian Ludwig wrote:
The portability is an issue.. yes. But i would prefer to use it if available. How often do you like to check the "assets" for changes? I think its hard to find a good value of time between the checks. If you check to often its add to much load to the hard disk (though it should get cached by the os but older systems like windows 98 doesnt do this well and anyway it doesnt sounds like a good solution) but if you check
Ahh...
well, Emacs, Eclipse, MS DevStudio and others all do the check when you "come back to" their app. So you don't need a time aspect at all. In fact, the workflow in that regard is probably one of the better end-user experiences.
I've often had files open in two or three of those at once, and flipped back and forth. I'd expect the same from graphics apps. I'd "flip over" to the Gimp and do some editing and hit save. Then I'd "flip back" to Inkscape. At that point it would check and then pop up a dialog informing me that files changed on disk and ask if I would like to reload.
I'd "flip over" to the Gimp and do some editing and hit save. Then I'd "flip back" to Inkscape. At that point it would check and then pop up a dialog informing me that files changed on disk and ask if I would like to reload.
Checking for changes if the app gets (back) focus sounds like a reasonable idea! And most common situations should be covered by this. (Still I vote for inotify :)
Florian
On Fri, Apr 13, 2007 at 01:36:51PM -0700, Jon A. Cruz wrote:
It is interesting, but there are certain issues with inotify. On the other hand, by hooking the callbacks on windows/apps coming forward we could achieve the same net effect by manually checking the "assets" when our app regains attention. Plus that ends up cross- platform.
What are the issues?
I ask because aside from this particular functionality (which I agree there may be more cross-platform design solutions), I've also been contemplating inotify for searching/interacting with large local collections of clipart and other stock assets.
Bryce
participants (4)
-
Bryce Harrington -
Florian Ludwig -
Jon A. Cruz -
Tony Vigil