SOC 2008 - project - Guidlines feature
Hello
I am interested in the Guidelines features proposed in the SOC 2008 ideas (http://wiki.inkscape.org/wiki/index.php/SpecGuidesImprovement) and I would like to discuss some aspects before submitting my proposal (if this is ok).
I guess this feature fits in the category of projects that doesn't mess much with the base code, since it uses already existing features.
Moreover, I tried to find info about the guidelines: * From a quick search I did I saw that thre is no "guide line" element in SVG 1.1 . * I saw that in svg files the guides are defined as sodipodi:guide element. So, guidelines are Inkscape specific.
* Guidelines are defined in src/sp-guide.cpp . SPGuide handles the svg file info. (Does this mean reading and writing from the file and modifying the svg abstraction?) * The rendering of the guidelines is handled in src/display/guideline.cpp . SPGuideLine holds the guideline info The the sp_guideline_* functions are responsible to deliver to the renderer the correct into? (not sure about this last one). * SnapManager manages the snapping. However, I haven't figured out if snapping and guidelines are directly connected. (However. this isn't relevant with the UI feature)
This is an early search and I am just getting in touch with Inkscape internal. So, if I get something wrong or if you have any hints and directions they are welcome. (I've seen the dev docs you have on the wiki)
As far as the feature specification is concerned, I would like to ask about the Design -> On-canvas editing section. The first 3 actions are already implemented. The last 2 were not implemented for a reason or you simply didn't have the time?
Regards Vangelis Katsikaros __________________________________________________ ×ñçóéìïðïéåßôå Yahoo!; ÂáñåèÞêáôå ôá åíï÷ëçôéêÜ ìçíýìáôá (spam); Ôï Yahoo! Mail äéáèÝôåé ôçí êáëýôåñç äõíáôÞ ðñïóôáóßá êáôÜ ôùí åíï÷ëçôéêþí ìçíõìÜôùí http://mail.yahoo.gr
-----Original Message----- From: inkscape-devel-bounces@lists.sourceforge.net [mailto:inkscape-devel-bounces@lists.sourceforge.net] On Behalf Of Vangelis Katsikaros Sent: donderdag 20 maart 2008 19:10 To: inkscape-devel@lists.sourceforge.net Subject: [Inkscape-devel] SOC 2008 - project - Guidlines feature
Hello
I am interested in the Guidelines features proposed in the SOC 2008 ideas (http://wiki.inkscape.org/wiki/index.php/SpecGuidesImprovement) and I would like to discuss some aspects before submitting my proposal (if this is ok).
Cool!
I guess this feature fits in the category of projects that doesn't mess much with the base code, since it uses already existing features.
I think this is correct. The full spec mentions guides in sets, that would be a change with perhaps backwards compatability issues, beware!
Moreover, I tried to find info about the guidelines:
- From a quick search I did I saw that thre is no "guide
line" element in SVG 1.1 .
- I saw that in svg files the guides are defined as
sodipodi:guide element. So, guidelines are Inkscape specific.
- Guidelines are defined in src/sp-guide.cpp . SPGuide
handles the svg file info. (Does this mean reading and writing from the file and modifying the svg abstraction?)
- The rendering of the guidelines is handled in
src/display/guideline.cpp . SPGuideLine holds the guideline info The the sp_guideline_* functions are responsible to deliver to the renderer the correct into? (not sure about this last one).
All correct. About the last point: SPGuideLine is a 'canvasitem' and must define an update and render function (see guideline.cpp:65-66). It also defines a 'point' function so that Inkscape knows when the cursor is above it. Then an event is sent which is handled by 'sp_dt_guide_event' in desktop-events.cpp.
Seems you grasp the code fine!
- SnapManager manages the snapping. However, I haven't
figured out if snapping and guidelines are directly connected. (However. this isn't relevant with the UI feature)
They are not directly connected. SPNamedview holds a list of all guides, snapmanager polls spnamedview to see which guides are there. Indeed it does not matter for the UI thing. Basically we need a UI to write nicely to XML, than snapping will just work :)
This is an early search and I am just getting in touch with Inkscape internal. So, if I get something wrong or if you have any hints and directions they are welcome. (I've seen the dev docs you have on the wiki)
As far as the feature specification is concerned, I would like to ask about the Design -> On-canvas editing section. The first 3 actions are already implemented. The last 2 were not implemented for a reason or you simply didn't have the time?
It's just a full description of how the endresult should be. The functionality that is already present is apparantly meant to be maintained! :)
Please note that guides cannot be selected. Making them selectable is probably a big task involving changing lots of inkscape's internals, so stay away from it (the spec doesn't want selectable guides which is good :).
Cheers, Johan
Hi and thanks for your response.
I see you are quite involved with guidelines (among others) since I see your name there.
J.B.C.Engelen@...1578... wrote:
I guess this feature fits in the category of projects that doesn't mess much with the base code, since it uses already existing features.
I think this is correct. The full spec mentions guides in sets, that would be a change with perhaps backwards compatability issues, beware!
I hoped that "sp_guide_set" in sp_guide.cpp quietly implemented the sets but I didn't have the time to check. So, I guess the project can break in 2 phases. One for the UI construction and one for the set feature.
All correct. About the last point: SPGuideLine is a 'canvasitem' and must define an update and render function (see guideline.cpp:65-66). It also defines a 'point' function so that Inkscape knows when the cursor is above it. Then an event is sent which is handled by 'sp_dt_guide_event' in desktop-events.cpp.
ok, I see, the object has to inform the renderer in order to redraw.
Seems you grasp the code fine!
Thanks, I try to do my best :)
- SnapManager manages the snapping. However, I haven't
figured out if snapping and guidelines are directly connected. (However. this isn't relevant with the UI feature)
They are not directly connected. SPNamedview holds a list of all guides, snapmanager polls spnamedview to see which guides are there. Indeed it does not matter for the UI thing. Basically we need a UI to write nicely to XML, than snapping will just work :)
I thought so, I just wanted to make sure.
This is an early search and I am just getting in touch with Inkscape internal. So, if I get something wrong or if you have any hints and directions they are welcome. (I've seen the dev docs you have on the wiki)
As far as the feature specification is concerned, I would like to ask about the Design -> On-canvas editing section. The first 3 actions are already implemented. The last 2 were not implemented for a reason or you simply didn't have the time?
It's just a full description of how the endresult should be. The functionality that is already present is apparantly meant to be maintained! :)
Please note that guides cannot be selected. Making them selectable is probably a big task involving changing lots of inkscape's internals, so stay away from it (the spec doesn't want selectable guides which is good :).
This is the only part where I can't follow. What do you mean with "selectable"? Currently you can click on the guide and move it, or pop up a window with double click for its properties. But I think that's not what you mean.
Regards Vangelis Katsikaros
__________________________________________________ ×ñçóéìïðïéåßôå Yahoo!; ÂáñåèÞêáôå ôá åíï÷ëçôéêÜ ìçíýìáôá (spam); Ôï Yahoo! Mail äéáèÝôåé ôçí êáëýôåñç äõíáôÞ ðñïóôáóßá êáôÜ ôùí åíï÷ëçôéêþí ìçíõìÜôùí http://mail.yahoo.gr
-----Original Message----- From: inkscape-devel-bounces@lists.sourceforge.net [mailto:inkscape-devel-bounces@lists.sourceforge.net] On Behalf Of Vangelis Katsikaros Sent: vrijdag 21 maart 2008 16:08
Johan wrote:
Please note that guides cannot be selected. Making them selectable is probably a big task involving changing lots of inkscape's internals, so stay away from it (the spec doesn't want selectable guides which is good :).
This is the only part where I can't follow. What do you mean with "selectable"? Currently you can click on the guide and move it, or pop up a window with double click for its properties. But I think that's not what you mean.
What I mean is, that one cannot click once on a guide to select it like selecting objects. And then move it around with the arrow keys. This is not a very limiting issue, just wanted you to be aware of it. It is for example still possible to click once on a guide and then scroll to that guide in the guide properties dialog. Hmm.. now that I think of it, perhaps it is not as difficult to make guides selectable as I thought.....
In any case, it was sort of off topic because the spec doesn't mention it ;)
Johan
Vangelis Katsikaros schrieb:
Hello
I am interested in the Guidelines features proposed in the SOC 2008 ideas (http://wiki.inkscape.org/wiki/index.php/SpecGuidesImprovement) and I would like to discuss some aspects before submitting my proposal (if this is ok).
Frankly, I was also considering to submit a proposal for this (sent a brainstorming email to this list about a week ago). The reason why I was interested in it is that one of the main missing features in the 3D box tool (which I worked on for last SoC) is draggable perspective lines. I believe that the work on this could quite favorably be combined with refactoring and extending the guidelines code so that it can be used for both purposes. I also had some other functionality in mind that could be used in this context but which it might be wise to abstract out so that it can be reused for (e.g.) geometric constructions (which is another often requested feature); and the envisioned new guidelines dialog gives the impression that it could be very beneficial to merge functionality with how layers are handled to tackle some long-standing feature requests in the same sweep. In any case, even if I don't work on this for SoC I would nonetheless want/need to base the perspective line code on the guidelines code, which would involve some refactoring anyway. So I figured it might be wise to avoid the double overhead and work on unifying it now, together with the other things I mentioned.
But it was just a thought and if you really are committed to doing this and nothing else I certainly don't want to step in the way. Just out of interest - are there other Inkscape-related projects you'd be interested to do, too? Hmm, I was wondering whether it might be possible to split the task between two people (maybe one working on the UI side and the other one on the internals), but probably that's not a good idea.
In any case, welcome to Inkscape and looking forward to hearing from you. (BTW, do other developers have any comments on what I wrote - my last email hasn't got any response so far.)
Cheers, Max
Maximilian Albert wrote:
Frankly, I was also considering to submit a proposal for this (sent a brainstorming email to this list about a week ago). The reason why I was interested in it is that one of the main missing features in the 3D box tool (which I worked on for last SoC) is draggable perspective lines. I believe that the work on this could quite favorably be combined with refactoring and extending the guidelines code so that it can be used for both purposes. I also had some other functionality in mind that could be used in this context but which it might be wise to abstract out so that it can be reused for (e.g.) geometric constructions (which is another often requested feature); and the envisioned new guidelines dialog gives the impression that it could be very beneficial to merge functionality with how layers are handled to tackle some long-standing feature requests in the same sweep.
Hi
I just read your mail. I hadn't seen that you mentioned guidelines too - I had read only the beggining about the 3d box and skipped the rest :)
In any case, even if I don't work on this for SoC I would nonetheless want/need to base the perspective line code on the guidelines code, which would involve some refactoring anyway. So I figured it might be wise to avoid the double overhead and work on unifying it now, together with the other things I mentioned.
But it was just a thought and if you really are committed to doing this and nothing else I certainly don't want to step in the way. Just out of interest - are there other Inkscape-related projects you'd be interested to do, too? Hmm, I was wondering whether it might be possible to split the task between two people (maybe one working on the UI side and the other one on the internals), but probably that's not a good idea.
From my past experience, SOC doesn't accept group projects. Plus, as you mentioned, it would bring difficulties in orginizing things.
I certainly wouldn't want to make you step away from this project. You are by far more experienced than me, as far as the the code base is concerned, and it would be selfish if I tried to do otherwise.
The Transformation Anchors is of interest but Guidelines seemed a more compact project. However I haven't done much of preliminary search for this project and I can't tell for sure. I'll look into that, as well and I'll get back to you during the weekend.
In case you decide not to mix 3d boxes and guidelines, will you be still interested the guidelines or would you choose another project?
Regards Vangelis Katsikaros __________________________________________________ ×ñçóéìïðïéåßôå Yahoo!; ÂáñåèÞêáôå ôá åíï÷ëçôéêÜ ìçíýìáôá (spam); Ôï Yahoo! Mail äéáèÝôåé ôçí êáëýôåñç äõíáôÞ ðñïóôáóßá êáôÜ ôùí åíï÷ëçôéêþí ìçíõìÜôùí http://mail.yahoo.gr
On Fri, Mar 21, 2008 at 05:39:52PM +0200, Vangelis Katsikaros wrote:
But it was just a thought and if you really are committed to doing this and nothing else I certainly don't want to step in the way. Just out of interest - are there other Inkscape-related projects you'd be interested to do, too? Hmm, I was wondering whether it might be possible to split the task between two people (maybe one working on the UI side and the other one on the internals), but probably that's not a good idea.
From my past experience, SOC doesn't accept group projects. Plus, as you mentioned, it would bring difficulties in orginizing things.
We have had one good experience with a paired project (for svg filters). In this case we took care in organizing them such that:
* Both individuals had the same mentor
* Each student's project was distinct and did not depend on the other, so the failure of one student would not hinder the other. The projects just happened to be closely related and synergistic with each other.
* The two students communicated effectively both between themselves, and with the mentor, so issues were resolved swiftly.
* Both student's work could be easily evaluated independently, and had separate goals.
While this can make it complex to organize, paired projects can be effective both from the standpoint of doubling the manpower on the feature, and because the students can share ideas, tips, solutions, code reviewing, and so on. But they need to be treated as distinct, independent projects for GSoC projects, and cannot be interdependent, else it makes it harder to evaluate them.
Bryce
Bryce Harrington wrote:
On Fri, Mar 21, 2008 at 05:39:52PM +0200, Vangelis Katsikaros wrote:
But it was just a thought and if you really are committed to doing this and nothing else I certainly don't want to step in the way. Just out of interest - are there other Inkscape-related projects you'd be interested to do, too? Hmm, I was wondering whether it might be possible to split the task between two people (maybe one working on the UI side and the other one on the internals), but probably that's not a good idea.
From my past experience, SOC doesn't accept group projects. Plus, as you mentioned, it would bring difficulties in orginizing things.
We have had one good experience with a paired project (for svg filters). In this case we took care in organizing them such that:
Both individuals had the same mentor
Each student's project was distinct and did not depend on the other, so the failure of one student would not hinder the other. The projects just happened to be closely related and synergistic with each other.
The two students communicated effectively both between themselves, and with the mentor, so issues were resolved swiftly.
Both student's work could be easily evaluated independently, and had separate goals.
While this can make it complex to organize, paired projects can be effective both from the standpoint of doubling the manpower on the feature, and because the students can share ideas, tips, solutions, code reviewing, and so on. But they need to be treated as distinct, independent projects for GSoC projects, and cannot be interdependent, else it makes it harder to evaluate them.
That would be fine by me! However, I don't have enough Inkscape internals experience, in order to propose a way of splitting.
However, I could submit two applications: 1) Guidelines 2) Transformation Anchors (I have sent a seperate mail about this). In this way, Maximilian can choose guidelines or implement an idea of his own or choose guidelines with 3d box in mind.
In all the above cases I can either do project 1) or 2).
Regards Vangelis Katsikaros
__________________________________________________ �������������� Yahoo!; ���������� �� ���������� �������� (spam); �� Yahoo! Mail �������� ��� �������� ������ ��������� ���� ��� ����������� ��������� http://mail.yahoo.gr
Vangelis Katsikaros <vkatsikaros@...1244...> wrote:
Bryce Harrington wrote:
We have had one good experience with a paired project (for svg filters).
[snip]
While this can make it complex to organize, paired projects can be effective both from the standpoint of doubling the manpower on the feature, and because the students can share ideas, tips, solutions, code reviewing, and so on. But they need to be treated as distinct, independent projects for GSoC projects, and cannot be interdependent, else it makes it harder to evaluate them.
That would be fine by me! However, I don't have enough Inkscape internals experience, in order to propose a way of splitting.
Splitting is indeed an interesting alternative. However, on second thought I'm not sure if it's really worth it in this case. I guess whoever does the guidelines refactoring should simply have other possible use cases in mind. With some guidance and hints from people who have more experience with Inkscape's internals I'm sure Vangelis would do this just as well.
However, I could submit two applications:
- Guidelines
- Transformation Anchors (I have sent a seperate mail about this).
In this way, Maximilian can choose guidelines or implement an idea of his own or choose guidelines with 3d box in mind.
In all the above cases I can either do project 1) or 2).
But this would mean double work for you while making things a lot easier for me. :) I'd certainly be more than grateful for this courtesy of yours. But maybe it's best to wait for a comment from the devs on my other ideas and if none of those turns out to be feasible we can still decide how to split up guidelines and transformation anchors between the two of us (am I correct in assuming that if possible you still would prefer to do guidelines?). Otherwise you can concentrate on a single proposal, which saves you time and energy.
Best, Max
-----Original Message----- From: inkscape-devel-bounces@lists.sourceforge.net [mailto:inkscape-devel-bounces@lists.sourceforge.net] On Behalf Of Maximilian Albert Sent: maandag 24 maart 2008 20:31 To: Vangelis Katsikaros; bryce@...1798... Cc: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] SOC 2008 - project - Guidlines feature
Vangelis Katsikaros <vkatsikaros@...1244...> wrote:
Bryce Harrington wrote:
We have had one good experience with a paired project (for svg filters).
[snip]
While this can make it complex to organize, paired projects can be effective both from the standpoint of doubling the manpower on the feature, and because the students can share ideas, tips,
solutions,
code reviewing, and so on. But they need to be treated as
distinct,
independent projects for GSoC projects, and cannot be
interdependent,
else it makes it harder to evaluate them.
That would be fine by me! However, I don't have enough Inkscape internals experience, in order to propose a way of splitting.
Splitting is indeed an interesting alternative. However, on second thought I'm not sure if it's really worth it in this case. I guess whoever does the guidelines refactoring should simply have other possible use cases in mind. With some guidance and hints from people who have more experience with Inkscape's internals I'm sure Vangelis would do this just as well.
To me the guidelines project is a simple straightforward project (I guess perfect for GSoC, especially if one is new to Inkscape). There is no refactoring needed (perhaps we can switch to cairo rendering to get rid of the ugliness), only add some things to the 'item_handler' and add some widgets to the document properties. The grouping of guides requires adding functionality, but not 'refactoring' perse. Having this view of the project, I find it hard to generalize things without making them just more complex instead of simpler. I guess for generalization, the only thing needed is renaming SPGuideLine to SPCanvasLine; at the moment there is no reason to call it SPGuideLine, so we actually should rename it now. All required functionality is already there (like I said, rendering should be improved, it's just a simple line drawing algorithm I copied from internet as mentioned in the code comment). The magic of the guideline project lies not in the canvas item, but in the guideline specific canvas item handler "sp_dt_guide_event", and in the way SPNamedView handles its childs (for grouping of guidelines), and making it user friendly (!!). Having a some sort of general item handler for the canvasline (to use both for perspective lines and guides) seems difficult looking at the guide specific calls in that item handler.
In short: I think the guidelines project should not be combined with other projects, since (as far as I can see) the overlapping features are already present in Inkscape's code. The guidelines project deals with other things than having a line on canvas.
Regards, Johan
J.B.C.Engelen@...1578... wrote:
To me the guidelines project is a simple straightforward project (I guess perfect for GSoC, especially if one is new to Inkscape). There is no refactoring needed (perhaps we can switch to cairo rendering to get rid of the ugliness), only add some things to the 'item_handler' and add some widgets to the document properties. The grouping of guides requires adding functionality, but not 'refactoring' perse. Having this view of the project, I find it hard to generalize things without making them just more complex instead of simpler. I guess for generalization, the only thing needed is renaming SPGuideLine to SPCanvasLine; at the moment there is no reason to call it SPGuideLine, so we actually should rename it now. All required functionality is already there (like I said, rendering should be improved, it's just a simple line drawing algorithm I copied from internet as mentioned in the code comment). The magic of the guideline project lies not in the canvas item, but in the guideline specific canvas item handler "sp_dt_guide_event", and in the way SPNamedView handles its childs (for grouping of guidelines), and making it user friendly (!!). Having a some sort of general item handler for the canvasline (to use both for perspective lines and guides) seems difficult looking at the guide specific calls in that item handler.
In short: I think the guidelines project should not be combined with other projects, since (as far as I can see) the overlapping features are already present in Inkscape's code. The guidelines project deals with other things than having a line on canvas.
I'll read carefully what you have written above about the implementation details (and probe in the code) but I won't have the time until after this weekend :)
I would also like to ask if somebody has the time and is interested in mentoring this proposal.
Regards, Vangelis Katsikaros
__________________________________________________ ×ñçóéìïðïéåßôå Yahoo!; ÂáñåèÞêáôå ôá åíï÷ëçôéêÜ ìçíýìáôá (spam); Ôï Yahoo! Mail äéáèÝôåé ôçí êáëýôåñç äõíáôÞ ðñïóôáóßá êáôÜ ôùí åíï÷ëçôéêþí ìçíõìÜôùí http://mail.yahoo.gr
participants (4)
-
unknown＠example.com -
Bryce Harrington -
Maximilian Albert -
Vangelis Katsikaros