Shall we merge the filters branch into trunk? I've never done this before, but I suspect that it works something like this. Inside of a working copy of trunk type:
svn merge -r 12093:HEAD https://svn.sourceforge.net/svnroot/inkscape/inkscape/branches/svg-filters
and then commit after fixing any conflicts. Does taht sound about right? Should this happen now-ish?
Aaron Spike
i vote yes times infinity
On 6/21/06, Aaron Spike <aaron@...749...> wrote:
Shall we merge the filters branch into trunk? I've never done this before, but I suspect that it works something like this. Inside of a working copy of trunk type:
svn merge -r 12093:HEAD https://svn.sourceforge.net/svnroot/inkscape/inkscape/branches/svg-filters
and then commit after fixing any conflicts. Does taht sound about right? Should this happen now-ish?
Aaron Spike
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 6/20/06, Aaron Spike <aaron@...749...> wrote:
Shall we merge the filters branch into trunk?
I think it's a good idea. One of the conditions of filter development is to not break any existing functionality, and ensuring that is much easier in the trunk which is daily tested by many people.
However, the final decision is up to the developers. Niko and Hugo, what do you think? Is there some kind of milestone after which we can merge the development in the trunk in such a way that it does not affect anything else and allows you to work on your part?
In general, I would like to see more communication from you. Can you write a brief summary of where you're at, what are your plans for the immediate future, and how it all goes in general? Please send it to the developers list, not just to me, so that others can see your progress as well.
(As an aside: Google SoC's goal is not only to help the open source projects, but to help students integrate into the open source process - that is, to get them communicating, not only coding. So, don't miss out on communication - it's a big part of the open source fun :)
On Tue, 20 Jun 2006 19:19:32 -0400 "bulia byak" <buliabyak@...400...> wrote:
However, the final decision is up to the developers. Niko and Hugo, what do you think? Is there some kind of milestone after which we can merge the development in the trunk in such a way that it does not affect anything else and allows you to work on your part?
This idea of merging came up on inkscape jabber channel yesterday. It seems so, that the merge could be done just fine.
Ted has a good point about submitting our code to Google at the end of summer. Though, it seems to me that we already have gone past the point, where we could just grab a diff from the branch and submit that - the branch does contain code from two SoCers and some code from Bulia, too.
In general, I would like to see more communication from you. Can you write a brief summary of where you're at, what are your plans for the immediate future, and how it all goes in general? Please send it to the developers list, not just to me, so that others can see your progress as well.
Well, overall status is as follows: * SPFilter objects get built from svg <filter> -elements - Hugo knows more about what this includes. * SPStyle recognises filter-property in objects and fetches a SPFilter accordingly (though does not seem to pay any attention to filters defined inside style-property) * Paths, groups and texts can handle filter-property in style and set the NRFilter pointer in NRArenaItem, if the object has filter - The NRFilter set still pays no attention to SPFilter properteries, at the moment I am designing an interface for this - In other words: if an object has a filter defined for it, that information is passed on to renderer * Gaussian blur renderer works quite well. It also needs an interface for setting its parameters.
So my plans are quite clear for some time from now: first I design those two interfaces and then I start implementing the functionality provided by them.
Hi there,
Sorry for the late reply... I had voted yes for the merging before on Jabber. It seems it's been done already anyway. I don't think there will be much unstabl
On 6/21/06, bulia byak <buliabyak@...400...> wrote:
On 6/20/06, Aaron Spike <aaron@...749...> wrote:
Shall we merge the filters branch into trunk?
I think it's a good idea. One of the conditions of filter development is to not break any existing functionality, and ensuring that is much easier in the trunk which is daily tested by many people.
However, the final decision is up to the developers. Niko and Hugo, what do you think? Is there some kind of milestone after which we can merge the development in the trunk in such a way that it does not affect anything else and allows you to work on your part?
In general, I would like to see more communication from you. Can you write a brief summary of where you're at, what are your plans for the immediate future, and how it all goes in general? Please send it to the developers list, not just to me, so that others can see your progress as well.
(As an aside: Google SoC's goal is not only to help the open source projects, but to help students integrate into the open source process
- that is, to get them communicating, not only coding. So, don't miss
out on communication - it's a big part of the open source fun :)
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On Tue, 2006-06-20 at 17:16 -0500, Aaron Spike wrote:
Shall we merge the filters branch into trunk? I've never done this before, but I suspect that it works something like this. Inside of a working copy of trunk type:
svn merge -r 12093:HEAD https://svn.sourceforge.net/svnroot/inkscape/inkscape/branches/svg-filters
and then commit after fixing any conflicts. Does taht sound about right? Should this happen now-ish?
The only thing that makes me a little nervous about this is that part of the requirements from Google is that the code they work on gets submitted to Google. Google has agreed to take patches. So, I think working on a branch makes that much easier.
--Ted
Ted Gould wrote:
On Tue, 2006-06-20 at 17:16 -0500, Aaron Spike wrote:
Shall we merge the filters branch into trunk?
The only thing that makes me a little nervous about this is that part of the requirements from Google is that the code they work on gets submitted to Google. Google has agreed to take patches. So, I think working on a branch makes that much easier.
Oh, is that a new requirement? And will google provide a fancy tool for making that happen? :-) I would think this could be difficult for a bunch of open source projects to provide. By the very nature of open source, contributions are somewhat difficult to separate out. Now would it be possible for us to shell script a little tool that will create a series of patches labeled according to which repository revision they should be applied to? Would that satify Google?
Still I don't think you have provided a reason against merging the branch into trunk. A merge will not stop the branch from ending. A merge will just get their code a little much needed testing. Work can continue on the branch if that is desired, right?
If they do continue work on the branch it would be helpful to the students if trunk was merged back into the branch too. Does this invalidate the usefullness of the branch? How does the branch help with separating out the work of two SoCers from each other?
I still vote "merge". I think we will have some difficulties to address either way. But I think there is a large benefit to having the code in trunk.
Aaron
Aaron wrote
Still I don't think you have provided a reason against merging the branch into trunk. A merge will not stop the branch from ending. A merge will just get their code a little much needed testing. Work can continue on the branch if that is desired, right?
Exactly.
I still vote "merge". I think we will have some difficulties to address either way. But I think there is a large benefit to having the code in trunk.
The goal of that rule is met with a text file containing every commit of the SoC student in unified diff form, cat'ted together. It is likely that this mega-patch can be reduced by applying it and diffing it again.
To get this need not be difficult.
Pro merge.
ralf
On Wed, 21 Jun 2006, Aaron Spike wrote:
Ted Gould wrote:
The only thing that makes me a little nervous about this is that part of the requirements from Google is that the code they work on gets submitted to Google. Google has agreed to take patches. So, I think working on a branch makes that much easier.
Oh, is that a new requirement? And will google provide a fancy tool for making that happen? :-) I would think this could be difficult for a bunch of open source projects to provide. By the very nature of open source, contributions are somewhat difficult to separate out. Now would it be possible for us to shell script a little tool that will create a series of patches labeled according to which repository revision they should be applied to? Would that satify Google?
I was thinking that maybe we could do something like that. They said that a diff is okay, but they didn't say anything about multiple diffs.
Still I don't think you have provided a reason against merging the branch into trunk. A merge will not stop the branch from ending.
Yes, I agree. I wasn't trying to say "don't do it", more just "be aware of this".
--Ted
On Tue, 20 Jun 2006 17:16:47 -0500 Aaron Spike <aaron@...749...> wrote:
Shall we merge the filters branch into trunk? I've never done this before, but I suspect that it works something like this. Inside of a working copy of trunk type:
svn merge -r 12093:HEAD https://svn.sourceforge.net/svnroot/inkscape/inkscape/branches/svg-filters
and then commit after fixing any conflicts. Does taht sound about right? Should this happen now-ish?
The svg-filters branch is now merged back to head. There is a short wiki page describing the status of filters and how to test them: http://wiki.inkscape.org/wiki/index.php/Filter_Effects
Hi all,
when consulting the release notes, i've been a bit surprised by the following paragraph : "* A button was added to fit the canvas to the current selection or, if there's no selection, to the entire drawing. The button resizes the canvas and, if necessary, moves the drawing into place. It is now very easy to size the canvas to an illustration after it is ready." (in http://wiki.inkscape.org/wiki/index.php/Release_Notes#Document_Properties_.2... )
When I compare this to the behavior of Inkscape, I feel this is wrong : in fact on my systems (Linux and Win), the Page is resized, and the Canvas is not modified at all. Am i doing something wrong ? is it a bug ? or did I simply misinterpreted the release notes ?
Regards
matiphas
matiphas@...8... wrote:
the Page is resized, and the Canvas is not modified at all.
Please explain what you mean by this. I'm having trouble trying to figure out the difference between the terms "Page" and "Canvas". Maybe a before and after screenshot would help.
Aaron Spike
matiphas@...8... wrote:
the Page is resized, and the Canvas is not modified at all.
Please explain what you mean by this. I'm having trouble trying to figure out the difference between the terms "Page" and "Canvas". Maybe a before and after screenshot would help.
Sure : I interpret the - Canvas as a (potentially) infinite area, of which an arbitrary part (depending on the zoom level and the origin point) is displayed in the Inkscape window. - Page, as a zone of the Canvas with dimensions and position arbitrary choosen by the user. (highlighted by its border is this option is checked).
Now when playing with this functionnality, check the display page border option (the behavior will be more "visual"), draw a few objets and select them, and ask Inkscape to fit selection : the Canvas is not modified, but the page parameters (dimensions) are.
Regards,
matiphas
PS : see also footnote #4 in Tavmjong's Guide to Inkscape ( http://tavmjong.free.fr/INKSCAPE/MANUAL/html/ch02s01.html#ftn.id3033078 ) where he points out that Inkscape does not separate very well those two notions.
matiphas@...8... wrote:
matiphas@...8... wrote:
the Page is resized, and the Canvas is not modified at all.
Please explain what you mean by this. I'm having trouble trying to figure out the difference between the terms "Page" and "Canvas". Maybe a before and after screenshot would help.
Sure : I interpret the
- Canvas as a (potentially) infinite area, of which an arbitrary part (depending
on the zoom level and the origin point) is displayed in the Inkscape window.
- Page, as a zone of the Canvas with dimensions and position arbitrary choosen
by the user. (highlighted by its border is this option is checked).
Now when playing with this functionnality, check the display page border option (the behavior will be more "visual"), draw a few objets and select them, and ask Inkscape to fit selection : the Canvas is not modified, but the page parameters (dimensions) are.
Well, then the Release Notes are blatently wrong. You are correct. It modifies only the Page. Sorry for being so loose with terminology.
Aaron Spike
Selon Aaron Spike <aaron@...749...>:
matiphas@...8... wrote:
matiphas@...8... wrote:
the Page is resized, and the Canvas is not modified at all.
Please explain what you mean by this. I'm having trouble trying to figure out the difference between the terms "Page" and "Canvas". Maybe a before and after screenshot would help.
Sure : I interpret the
- Canvas as a (potentially) infinite area, of which an arbitrary part
(depending
on the zoom level and the origin point) is displayed in the Inkscape
window.
- Page, as a zone of the Canvas with dimensions and position arbitrary
choosen
by the user. (highlighted by its border is this option is checked).
Now when playing with this functionnality, check the display page border
option
(the behavior will be more "visual"), draw a few objets and select them,
and
ask Inkscape to fit selection : the Canvas is not modified, but the page parameters (dimensions) are.
Well, then the Release Notes are blatently wrong. You are correct. It
OK, i'm modifying it in the wiki right now. Thanks.
modifies only the Page. Sorry for being so loose with terminology.
You must not be sorry : you've implemented very nice (and useful) features !
Regards,
matiphas
participants (11)
-
unknown＠example.com -
Aaron and Sarah Spike -
Aaron Spike -
Andy Fitzsimon -
bulia byak -
Hugo Rodrigues -
Joshua A. Andler -
MenTaLguY -
Niko Kiirala -
Ralf Stephan -
Ted Gould