GSoC08: Tech Drawing ideas (comments very welcome)
Hi,
unfortunately I haven't yet received any response to my other emails, so I don't know if there is a potential mentor for any of them or if they are suitable for a SoC project at all.
In any case, I have written up some thoughts regarding the facilitation of geometric constructions/tech drawing in Inkscape. They can be found here:
http://www.rzuser.uni-heidelberg.de/~malbert/tech_drawing/
It's a draft and not complete yet (but all I could manage alongside studying for my graduation exam). I would very much appreciate any input/comments/suggestions/criticism. Would any of the potential mentors be willing to supervise such a project?
Thank you very much in advance for any feedback, Max
P.S.: I'd still love to elaborate on my 3D-related ideas but I feel they are much less straightforward to implement so I'd need advice from more experienced developers regarding feasibility/desirability and on which things to concentrate before going into more detail.
On Wed, Mar 26, 2008 at 10:10 AM, Maximilian Albert <Anhalter42@...173...> wrote:
unfortunately I haven't yet received any response to my other emails, so I don't know if there is a potential mentor for any of them or if they are suitable for a SoC project at all.
Of course they are! Don't get discouraged by a lack of response - I guess everyone is just too busy with 0.46 rollout :)
I would love to be your mentor on the 3D box project, of course. There's lot of work still to do, and it must be done, otherwise it looks a bit unfinished. Your ideas for that are excellent, though I might add a few things, for example subdividing a box into halves/thirds/etc in one of the three planes or duplicating a box along an axis. I think you should concentrate on 3D trackball rotation first as the most complex part of it. Once it's there, the rest is easy.
The tech drawing proposal is also interesting - I love and use KSEG which implements all this, and it would be interesting to see this working in Inkscape. From what I see, most if not all of these features can be implemented as LPEs and thus be sufficiently orthogonal to everything else. Still, while it's up to you of course, I think I would prefer you to continue working on the 3D box simply because there are so many loose ends there :)
bulia byak schrieb:
On Wed, Mar 26, 2008 at 10:10 AM, Maximilian Albert <Anhalter42@...173...> wrote:
unfortunately I haven't yet received any response to my other emails, so I don't know if there is a potential mentor for any of them or if they are suitable for a SoC project at all.
Of course they are! Don't get discouraged by a lack of response - I guess everyone is just too busy with 0.46 rollout :)
Yeah, sorry. I know everyone is busy as hell (myself included, though for other reasons :)). I certainly didn't want to nag. Probably the lurking exam was making me too nervous.
@Johan: Special apologies to you. Of course you replied (and I was grateful for your comments) but I was anxious about possible mentors having interest, and unfortunately you can't be one of them. :)
I would love to be your mentor on the 3D box project, of course. There's lot of work still to do, and it must be done, otherwise it looks a bit unfinished. Your ideas for that are excellent, though I might add a few things, for example subdividing a box into halves/thirds/etc in one of the three planes or duplicating a box along an axis. I think you should concentrate on 3D trackball rotation first as the most complex part of it. Once it's there, the rest is easy.
I'm not 100% sure about this. Depending on what unexpected pitfalls turn up with 3D-LPEs they may be just as complex. And I haven't yet completely made up my mind whether the trackball thingy or providing 3D-LPEs (in conjunction with 3D layers, for example, as in Pierr-Luc Auclair's mockup) would be the bigger usability improvement.
But I guess you are right that it may be best to tackle the trackball stuff first. My only concern is that it may be really non-trivial to figure out how that should work with our approach to perspectives (although I have some vague ideas). And even if in the end it does work mathematically correctly, it could "feel" very weird (from a user's point of view) when applied to distorted perspectives. I'm a bit worried that I may spend a lot of time on the algorithms (abstinent from real coding) but the visible end result turns out nonsatisfying. I would have preferred to at least provide a proof of concept but I'm afraid this is not possible in my current situation. On the other hand, I'm quite sure that 3D layers and 3D-LPEs would work out pretty well and be very handy in everyday work.
Anyway, I don't know if I can find the time somewhere but since I'd love to work on it, too, I will see if I can hack up a proposal for 3D box related features. No promise, though, it will be tough. :-/ Your idea with subdividing boxes is also very good and probably quite easy to implement (how do you imagine it UI-wise?). But in the main proposal I'm probably going to focus on the big tasks, like the trackball and 3D layers (as a second and more remote goal). Perhaps I can add a separate section with small improvements that can be done if there is time in the end (otherwise they can be done after the summer since it's easy to work on them part-time only).
The tech drawing proposal is also interesting - I love and use KSEG which implements all this, and it would be interesting to see this working in Inkscape. From what I see, most if not all of these features can be implemented as LPEs and thus be sufficiently orthogonal to everything else. Still, while it's up to you of course, I think I would prefer you to continue working on the 3D box simply because there are so many loose ends there :)
Yep, that's my feeling as well. But as I said, they are much less straightforward to figure out, and I don't really want to submit a half-baken or not thoroughly thought-through proposal. I'm going to try my best but maybe it's "only" going to be tech drawing due to lack of time.
BTW, last but certainly not least many thanks to everyone for their feedback on the tech drawing stuff! Very much appreciated.
Max
On Thu, Mar 27, 2008 at 01:07:00AM +0100, Maximilian Albert wrote:
BTW, last but certainly not least many thanks to everyone for their feedback on the tech drawing stuff! Very much appreciated.
Even if you do decide not to do the tech drawing one, it would be great if you could upload that as a blueprint (blueprints.launchpad.net/inkscape).
Bryce
bulia byak schrieb:
The tech drawing proposal is also interesting - I love and use KSEG which implements all this, and it would be interesting to see this working in Inkscape. From what I see, most if not all of these features can be implemented as LPEs and thus be sufficiently orthogonal to everything else.
Actually, due to my infamilarity with LPEs I hadn't realized that these would indeed be very well suited for this purpose. I had considered it necessary to introduce a new kind of "tech drawing" object, together with appropriate SVG attributes. But LPEs should provide (almost) all the framework that is needed.
Just to be sure: You are proposing to use them only internally, right? We would still need a well-designed UI to make working with geometric constructions easy and powerful. It would be awkward IMHO if the user were obliged to choose a LPE from the menu each time (s)he wants to do such a construction. BTW, would it be possible to avoid displaying these new LPEs in the menu, since they would be accessible otherwise?
What I'm wondering is how "geometric points" would be represented with the LPE approach. For example, when constructing the parallel to a line which passes through a given point, it should be possible to specify this point by clicking on the canvas (and possibly dragging it afterwards). Would this point be an additional parameter to the LPE? It shouldn't be present as an *ordinary* SVG element because it's only a "virtual" kind of data. But it should be draggable, and the parallel should follow, similar to how resizing a linked offset works.
Could a LPE display such a handle and react on it being dragged? How many "input objects" can a LPE have anyway? I think Johan added some functionality in this area recently. Would it be possible, e.g., to have _two_ lines as input for a single LPE? Something like this would be needed for angle bisectors.
Sorry if these are noob questions but I haven't used LPEs myself yet. But the more I think about it the more I like this approach. In particular, it looks much easier to do than I originally imagined. Great. :)
Max
P.S.: Johan, I'm CC-ing you because you are most familiar with LPE internals. Hope this is okay.
On Sat, Mar 29, 2008 at 7:10 PM, Maximilian Albert <Anhalter42@...173...> wrote:
Just to be sure: You are proposing to use them only internally, right? We would still need a well-designed UI to make working with geometric constructions easy and powerful.
Of course. The UI for all LPEs is kinda being born right now. It's not like we have a rule to make all LPEs use exactly the same UI. Whatever makes most sense for each particular one.
It would be awkward IMHO if the user were obliged to choose a LPE from the menu each time (s)he wants to do such a construction. BTW, would it be possible to avoid displaying these new LPEs in the menu, since they would be accessible otherwise?
I'm not sure we'd want to really remove them from the LPE dialog. Maybe make the menu sectionalized and put them all into a section. Still, I'd like them to be there because this dialog offers a low-level view of an effect. Something like an XML editor for LPEs where nothing is hidden, but which by itself is rarely necessary thanks to all the on-canvas controls.
What I'm wondering is how "geometric points" would be represented with the LPE approach. For example, when constructing the parallel to a line which passes through a given point, it should be possible to specify this point by clicking on the canvas (and possibly dragging it afterwards). Would this point be an additional parameter to the LPE? It shouldn't be present as an *ordinary* SVG element because it's only a "virtual" kind of data. But it should be draggable, and the parallel should follow, similar to how resizing a linked offset works.
Of course. Think of it this way: of the data that defines such a line, one part has to be its "source path". It is natural to choose the point for that role. So, at the source level, we will have a path with one node and an LPE that uses a href to link to the path to which it is parallel. Two other params, editable by draggable knots, define the start/end of the line. Of course the user won't have to create such one-node path and then apply the LPE - all this will be done by a single command.
Could a LPE display such a handle and react on it being dragged? How many "input objects" can a LPE have anyway? I think Johan added some functionality in this area recently. Would it be possible, e.g., to have _two_ lines as input for a single LPE? Something like this would be needed for angle bisectors.
I think so - just two params linked to two paths.
Hi,
I just committed to SVN a proof-of-concept "tech drawing LPE" wich allows constructing a circle with adjustable center and radius. Apply it to any path and it will draw a circle whose center is the starting point and whose circumference passes through the end point of this path (intermediate points will be ignored). Dragging the points of the original path will make the circle move/resize accordingly.
(Aside: Despite my current time constraints I just couldn't help giving this a try since the LPE aproach sounded so tempting. @Johan: This is nothing short of awesome!! Your framework is sooo easy to use and a pleasure to work with.)
The good news is: This shows that my tech drawing proposal is absolutely accomplishable. However, now that I have seen how easy to do it actually is I almost feel ashamed for proposing this as a whole GSoC project. ;-) I coded this in a few hours, and most of the work was actually wading through the 2geom Path class definitions in order to find out how it works. So the various constructions I propose in [1] should be implementable within a week or so (say 2 weeks for other ones that pop up as desired).
On the other hand, special care must be taken in the implementation of an intuitive and easy-to-use yet powerful user interface. I suppose that this may in fact require the bulk of the coding time since we have to provide a linkage between on-canvas actions and LPE parameters. Telling from the other LPE files there seems to be basic support for this but I guess it would have to be considerably expanded and unified.
Still, even if I anticipate a whole month for the UI work I'm concerned that this is overall too easy a project to propose for GSoC. On the other hand, according to the following thread on the GSoC mailing list:
it would be possible to change the project even after the end of the application period (in case a student is chosen and the mentoring organization agrees). So would it be an option for me to finish my application for the tech drawing project but during SoC actually work on the 3D features which I proposed in a separate thread? I have a first draft for such a proposal, too, but am concerned it will not get finished in time for the application deadline.
Any comments from possible mentors?
In any case, I will try to get my tech drawing proposal finished and will post it to this list later today to allow for review and critical comments.
Many thanks in advance, Max
[1] Draft for the Tech Drawing proposal:
Maximilian Albert schrieb:
Still, even if I anticipate a whole month for the UI work I'm concerned that this is overall too easy a project to propose for GSoC. On the other hand, according to the following thread on the GSoC mailing list:
it would be possible to change the project even after the end of the application period (in case a student is chosen and the mentoring organization agrees). So would it be an option for me to finish my application for the tech drawing project but during SoC actually work on the 3D features which I proposed in a separate thread?
Addendum: Of course, only if this is regarded to be of greater benefit to the Inkscape project. The bug tracker contains many RFEs for both CAD-like and further 3D functionality, and I can't tell the need for which is more pressing. I would love to work on either of them but in case I am accepted for SoC I'd leave it to the more experienced developers to decide which one would be better to do.
Max
Maximilian Albert wrote:
The good news is: This shows that my tech drawing proposal is absolutely accomplishable. However, now that I have seen how easy to do it actually is I almost feel ashamed for proposing this as a whole GSoC project. ;-)
I think it is absolutely fantastic to see the LPE system be used in this way. I was dreaming of just this sort of thing when Mental, Bbyak and I were brainstorming this on IRC: using LPE as a generic framework to unify lots of disparate tools. I don't think you should in any way be ashamed of proposing a project that is accomplishable. You found last year that even though you completed your project successfully there were and remain a number of things that could still be polished. This project satisfies a number of long standing feature requests. And with a slightly diminished scope this could allow you to really make it shine within the summer's time constraints.
Aaron Spike
On Sun, Mar 30, 2008 at 5:23 PM, Aaron Spike <aaron@...749...> wrote:
I think it is absolutely fantastic to see the LPE system be used in this way. I was dreaming of just this sort of thing when Mental, Bbyak and I were brainstorming this on IRC: using LPE as a generic framework to unify lots of disparate tools.
Speaking of which... we have a disproportionate amount of bug reports on the linked offset and dynamic offset features. They predate LPEs, have many issues, and are ripe for conversion. Anyone feels like reimplementing them via LPEs and 2geom (instead of a separate SPObject and livarot) so that the old code could be dropped?
bulia byak schrieb:
On Sun, Mar 30, 2008 at 5:23 PM, Aaron Spike <aaron@...749...> wrote:
I think it is absolutely fantastic to see the LPE system be used in this way. I was dreaming of just this sort of thing when Mental, Bbyak and I were brainstorming this on IRC: using LPE as a generic framework to unify lots of disparate tools.
Speaking of which... we have a disproportionate amount of bug reports on the linked offset and dynamic offset features. They predate LPEs, have many issues, and are ripe for conversion. Anyone feels like reimplementing them via LPEs and 2geom (instead of a separate SPObject and livarot) so that the old code could be dropped?
It would be a fantastic opportunity to do this in the context of my proposal. Playing with linked offset yesterday, I found its UI to be precisely the kind that would be needed for many of the geometric constructions. So I would work on integrating this with LPEs anyway. Then I can just as well replace the old offset code and reimplement it using 2geom (which has great support for offsetting paths, AFAICT from the corresponding toy). Awesome. :)
Max
Maximilian Albert wrote:
bulia byak schrieb:
Speaking of which... we have a disproportionate amount of bug reports on the linked offset and dynamic offset features. They predate LPEs, have many issues, and are ripe for conversion. Anyone feels like reimplementing them via LPEs and 2geom (instead of a separate SPObject and livarot) so that the old code could be dropped?
It would be a fantastic opportunity to do this in the context of my proposal. Playing with linked offset yesterday, I found its UI to be precisely the kind that would be needed for many of the geometric constructions. So I would work on integrating this with LPEs anyway. Then I can just as well replace the old offset code and reimplement it using 2geom (which has great support for offsetting paths, AFAICT from the corresponding toy). Awesome. :)
This gives you major refactoring kudos in my book. :-)
Aaron Spike
On Sun, Mar 30, 2008 at 07:06:09PM +0200, Maximilian Albert wrote:
Hi,
I just committed to SVN a proof-of-concept "tech drawing LPE" wich allows constructing a circle with adjustable center and radius. Apply it to any path and it will draw a circle whose center is the starting point and whose circumference passes through the end point of this path (intermediate points will be ignored). Dragging the points of the original path will make the circle move/resize accordingly.
(Aside: Despite my current time constraints I just couldn't help giving this a try since the LPE aproach sounded so tempting. @Johan: This is nothing short of awesome!! Your framework is sooo easy to use and a pleasure to work with.)
The good news is: This shows that my tech drawing proposal is absolutely accomplishable. However, now that I have seen how easy to do it actually is I almost feel ashamed for proposing this as a whole GSoC project. ;-) I coded this in a few hours, and most of the work was actually wading through the 2geom Path class definitions in order to find out how it works. So the various constructions I propose in [1] should be implementable within a week or so (say 2 weeks for other ones that pop up as desired).
Whoa, that's awesome. Very glad to hear it was so easy to do, and that this could allow a broader range of features to be attempted.
On the other hand, special care must be taken in the implementation of an intuitive and easy-to-use yet powerful user interface. I suppose that this may in fact require the bulk of the coding time since we have to provide a linkage between on-canvas actions and LPE parameters. Telling from the other LPE files there seems to be basic support for this but I guess it would have to be considerably expanded and unified.
I suspected this may be the case. But I think it would be time very well invested. Inkscape built a lot of success on top of simply having a convenient and intuitive UI for editing nodes. Having a convenient and intuitive UI for doing these extremely basic tech drawing functionalities could give us a powerful foundation to build on.
Still, even if I anticipate a whole month for the UI work I'm concerned that this is overall too easy a project to propose for GSoC. On the other hand, according to the following thread on the GSoC mailing list:
it would be possible to change the project even after the end of the application period (in case a student is chosen and the mentoring organization agrees). So would it be an option for me to finish my application for the tech drawing project but during SoC actually work on the 3D features which I proposed in a separate thread? I have a first draft for such a proposal, too, but am concerned it will not get finished in time for the application deadline.
Any comments from possible mentors?
Perhaps organize your proposal into 3 phases, one being the core basic stuff, second being a follow-on advanced functionality phase, and third being some optional stretch goals (such as the 3D tools).
Here are some additional technical drawing objectives that may be appropriate for the advanced functionality phase:
* Superset xfig functionality. xfig is an extremely old drawing tool, that most people consider to be obsoleted by inkscape, however xfig still has some technical drawing capabilities we don't. E.g.: - Measure Angle - Measure Length (we have this as an extension) - Measure Area - Add Tangent/Normal to curve
* Markers (arrowheads) improvements (something forever on my todo list) - Change marker color - Change marker point alignment - Additional improvements
* Document units scaling. So can specify that 1cm in document represents 500m. Necessary for doing scale drawing.
* Direct data entry - to make it easier to type in the x,y values of drawing elements.
And of course launchpad is full of other ideas. I think the above would address a pretty huge chunk of the most popular requests. If we had all of the above, Inkscape would become a quite convenient technical drawing tool.
Bryce
A very quick reply.
-----Original Message----- From: Bryce Harrington [mailto:bryce@...1798...] Sent: maandag 31 maart 2008 8:24 To: Maximilian Albert Cc: bulia byak; inkscape; Engelen, J.B.C. (Johan)
- Markers (arrowheads) improvements (something forever on my
todo list)
- Change marker color
- Change marker point alignment
- Additional improvements
We could make a "marker shortening LPE": makes the input path just that bit shorter so the tip of the marker lines up perfectly with the end of the path.
- Document units scaling. So can specify that 1cm in document represents 500m. Necessary for doing scale drawing.
A must have for me!! :P (the other way around though: 1cm being 1um :-)
On Sun, Mar 30, 2008 at 1:06 PM, Maximilian Albert <Anhalter42@...173...> wrote:
I just committed to SVN a proof-of-concept "tech drawing LPE" wich allows constructing a circle with adjustable center and radius. Apply it to any path and it will draw a circle whose center is the starting point and whose circumference passes through the end point of this path (intermediate points will be ignored). Dragging the points of the original path will make the circle move/resize accordingly.
Actually it's not quite a circle, but other than that, cool :)
it would be possible to change the project even after the end of the application period (in case a student is chosen and the mentoring organization agrees). So would it be an option for me to finish my application for the tech drawing project but during SoC actually work on the 3D features which I proposed in a separate thread? I have a first draft for such a proposal, too, but am concerned it will not get finished in time for the application deadline.
Any comments from possible mentors?
I really don't know. Lots of great projects. I guess I'll have to choose to mentor not the project that I like the most, but the project where I can help the most :)
Hello, First of all, nice to see someone working on technical drawing. I think many of inkscape users actually use it for little scientific work. Even if it's not its purpose, we must admit this software is so easy to use that we use it for everything.
When you first started to talk about technical drawing, I have been immediately thinking about real time helpers.
When you practice traditional technical drawing you need to be very accurate for each line you draw, then you use rulers and compass. For the moment, in inkscape, there is snapping (to grid or to objects) and guidelines. I have some experience in technical part design. I use the software Catia and I think its 2d editor is worth looking at.
In Catia, when you are in path creation mode, there are plenty of helpers very useful : perpendicularity, parallelism, same length or alignment. Let's take an example : (this is grid independent, I could have disabled it in my screenshots) 1 I start with a segment (not horizontal or vertical) 2 I want my next segment to be perpendicular to this one. When my pointer comes near to a invisible perpendicular line, it snaps to it (see http://steren.giannini.googlepages.com/screen1.png) 3 Then I want my next segment parallel to the first one. When my pointer comes near to a parallel, snap ! (see http://steren.giannini.googlepages.com/screen2.png) 4 It actually also does length comparison (see http://steren.giannini.googlepages.com/screen3.png) 5 or alignment detection (see http://steren.giannini.googlepages.com/screen4.png)
This kind of help would be very useful in inkscape for technical drawings, scientific schemes, icons but also for ordinary art. I hope this will inspire you for your "Technical drawing Inkscape GSoC"
Steren
Hi,
besides all the mentioned things I believe that from a technical point of view it would be really useful if one was able to set up pattern parameters precisely with the keyboard. For example, a typical sketch includes different hatches (currently stripes in Inkscape 0.46). Here one would usually like to set up line width, angle and the distance between lines (scale).
All this is already possible to achieve with the on-canvas editing (or by editing XML editor, but here one has to calculate transformation matrix etc.), but this is not a really good way for technical drawings, since it's really hard to set up these things precisely. I guess this feature would basically only need a UI where you could simply change parameters. A simple mockup for the UI could be maybe something like this: http://tinyurl.com/23h6v4
Rok
On Tue, Apr 1, 2008 at 12:25 AM, Steren Giannini <steren.giannini@...400...> wrote:
Hello, First of all, nice to see someone working on technical drawing. I think many of inkscape users actually use it for little scientific work. Even if it's not its purpose, we must admit this software is so easy to use that we use it for everything.
When you first started to talk about technical drawing, I have been immediately thinking about real time helpers.
When you practice traditional technical drawing you need to be very accurate for each line you draw, then you use rulers and compass. For the moment, in inkscape, there is snapping (to grid or to objects) and guidelines. I have some experience in technical part design. I use the software Catia and I think its 2d editor is worth looking at.
In Catia, when you are in path creation mode, there are plenty of helpers very useful : perpendicularity, parallelism, same length or alignment. Let's take an example : (this is grid independent, I could have disabled it in my screenshots) 1 I start with a segment (not horizontal or vertical) 2 I want my next segment to be perpendicular to this one. When my pointer comes near to a invisible perpendicular line, it snaps to it (see http://steren.giannini.googlepages.com/screen1.png) 3 Then I want my next segment parallel to the first one. When my pointer comes near to a parallel, snap ! (see http://steren.giannini.googlepages.com/screen2.png) 4 It actually also does length comparison (see http://steren.giannini.googlepages.com/screen3.png) 5 or alignment detection (see http://steren.giannini.googlepages.com/screen4.png)
This kind of help would be very useful in inkscape for technical drawings, scientific schemes, icons but also for ordinary art. I hope this will inspire you for your "Technical drawing Inkscape GSoC"
Steren
Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Tue, Apr 1, 2008 at 8:20 AM, Rock Star <rockstar1707@...400...> wrote:
good idea, please file a wishlist item on launchpad, attaching this
I filled it as a "bug" #210442 ( https://bugs.launchpad.net/inkscape/+bug/210442). I've also wrote an explanation and I've attached a mockup of the UI.
Rok
On Tue, Apr 1, 2008 at 7:05 PM, bulia byak <buliabyak@...400...> wrote:
On Tue, Apr 1, 2008 at 8:20 AM, Rock Star <rockstar1707@...400...> wrote:
good idea, please file a wishlist item on launchpad, attaching this
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
bulia byak schrieb:
On Sun, Mar 30, 2008 at 1:06 PM, Maximilian Albert <Anhalter42@...173...> wrote:
I just committed to SVN a proof-of-concept "tech drawing LPE" wich allows constructing a circle with adjustable center and radius. Apply it to any path and it will draw a circle whose center is the starting point and whose circumference passes through the end point of this path (intermediate points will be ignored). Dragging the points of the original path will make the circle move/resize accordingly.
Actually it's not quite a circle, but other than that, cool :)
Yes, that's because I still need to get up to full speed with 2geom. It's fixed now.
Max
-----Original Message----- From: inkscape-devel-bounces@lists.sourceforge.net [mailto:inkscape-devel-bounces@lists.sourceforge.net] On Behalf Of Maximilian Albert Sent: zondag 30 maart 2008 0:11 To: bulia byak Cc: inkscape; Engelen, J.B.C. (Johan) Subject: Re: [Inkscape-devel] GSoC08: Tech Drawing ideas (comments verywelcome)
What I'm wondering is how "geometric points" would be represented with the LPE approach. For example, when constructing the parallel to a line which passes through a given point, it should be possible to specify this point by clicking on the canvas (and possibly dragging it afterwards). Would this point be an additional parameter to the LPE? It shouldn't be present as an *ordinary* SVG element because it's only a "virtual" kind of data. But it should be draggable, and the parallel should follow, similar to how resizing a linked offset works.
Could a LPE display such a handle and react on it being dragged? How many "input objects" can a LPE have anyway? I think Johan added some functionality in this area recently. Would it be possible, e.g., to have _two_ lines as input for a single LPE? Something like this would be needed for angle bisectors.
LPEs can have an unlimited number of input parameters. All LPE parameters are what you call "virtual" data, not SVG elements, but Inkscae:SVG elements. (in the <defs> section). The handles that you need is a PointParam, which is on-canvas editable! However, you do need some contraints on dragging the pointparams. This is possible, but needs some basic work as well to enable it; at the moment none of the LPEs use it, but it would be very nice if constraints on parameters are done well. Please have some thought about how to do this once you are familiar with LPE framework. I can give you some pointers as well.
Sorry if these are noob questions but I haven't used LPEs myself yet. But the more I think about it the more I like this approach. In particular, it looks much easier to do than I originally imagined. Great. :)
:) Just have a look at some of the effects and see how little extra effort is needed other than the actual effect.
Really, look at this wiki page: http://wiki.inkscape.org/wiki/index.php/MakingLivePathEffects If anything is too brief, incomplete or unclear, please add text to the page! (or tell me to expand specific things)
Maybe we can think of a way to apply an LPE more natural than selecting the original path, etc etc. For the angle between two lines, it is much more intuitive to select the two lines and then press "do angle LPE". This should then create a new single node svg:path and put it in sensible location, and set the two path parameters to link to the two lines.
Cheers, Johan
On Wed, Mar 26, 2008 at 02:10:39PM +0100, Maximilian Albert wrote:
unfortunately I haven't yet received any response to my other emails, so I don't know if there is a potential mentor for any of them or if they are suitable for a SoC project at all.
I'm sure it's just that people are just overwhelmed by the sudden rush of great ideas being posted. :-)
I personally won't be mentoring this time around (I'm going to be limited in my time again this year, and want to focus into the 0.47 release, drupal, and if I have extra time refactoring), but I absolutely love the idea of adding technical drawing capabilities to Inkscape so will try to give you some comments on this one.
In any case, I have written up some thoughts regarding the facilitation of geometric constructions/tech drawing in Inkscape. They can be found here:
I wonder if perhaps some of the underlying geometrical math for this is provided by 2geom? If you haven't already, I'd recommend investigating this, and outlining how 2geom fits into the picture (esp. if there is missing functionality that'd need added to 2geom.)
I would suggest starting with the straight line constructions - parallel, perpendicular, angular constraints, etc. These are very basic and will have general utility beyond technical drawing. I also suspect getting the UI right for this will require some experimentation.
For circles, I'd suggest a different UI approach. Defining points and then inserting a shape is a standard UI technique for CAD tools, but for inkscape I think it'd fit better to use a UI style more like stars or rounded rectangles: With those, you draw a rough version of the shape and then use the "handles" to adjust the corner radius or star spokes. Similarly, with this circle, you'd have three handles which could be moved (and maybe snapped to intersections, lines, etc.) to adjust the radius.
Along these lines, it'd be nice to have a "center point and radius" style for circles. In tech drawing you're often needing to put circles at intersections of lines, or end points of lines, or tangential to lines, so being able to place or snap the center point and a radius would serve the purpose here.
Another useful function would be able to snap a circle tangential to a line (for some reason I thought this could be done already, but I'm not able to get it to do it - maybe it's just broken?)
Note that there is already a 'measure path' effect, under Effects > Visualize Path > Measure Path. It does not do point-to-point measure, but does create a nice text label and allow for selecting units.
Hope this helps, Bryce
On Wed, Mar 26, 2008 at 9:56 PM, Bryce Harrington wrote:
Along these lines, it'd be nice to have a "center point and radius" style for circles. In tech drawing you're often needing to put circles at intersections of lines, or end points of lines, or tangential to lines, so being able to place or snap the center point and a radius would serve the purpose here.
Maybe an optional display of objects base points also? This would be useful for snapping.
Alexandre
-----Original Message----- From: inkscape-devel-bounces@lists.sourceforge.net [mailto:inkscape-devel-bounces@lists.sourceforge.net] On Behalf Of Maximilian Albert Sent: woensdag 26 maart 2008 14:11 To: inkscape Subject: [Inkscape-devel] GSoC08: Tech Drawing ideas (comments very welcome)
Hi,
unfortunately I haven't yet received any response to my other emails, so I don't know if there is a potential mentor for any of them or if they are suitable for a SoC project at all.
!!!! I replied! :(
In any case, I have written up some thoughts regarding the facilitation of geometric constructions/tech drawing in Inkscape. They can be found here:
http://www.rzuser.uni-heidelberg.de/~malbert/tech_drawing/
It's a draft and not complete yet (but all I could manage alongside studying for my graduation exam). I would very much appreciate any input/comments/suggestions/criticism. Would any of the potential mentors be willing to supervise such a project?
Thank you very much in advance for any feedback, Max
I've been using Cadence for the last couple of days. What I like a lot is the "ruler" tool that creates rules that stay on-canvas until you press the 'remove all rulers' key. It snaps to rulers aswell. Very handy to construct things! Basically the tool works like the pen tool: click somewhere, then move the pointer and a ruler will be drawn from the clicked point to the mouse pointer, immediately showing values along it. You can set the ruler to 'all angles' or only 'diagonal' (0, 45, 90, ... degrees), and even orthogonal but i don't know how that works, I guess orthogonal to the object selected when you click on a point that touches that path...? Clicking again will fixate the ruler on canvas from the 1st to the 2nd clicked point. Then you can draw a second ruler if you'd like. If you are interested and don't understand what I am saying, I can make a quick mockup of what I mean.
The second thing was already mentioned in another context on this list: move nodes while maintaining angles. Consider a rectangle. When dragging one node, it changes the angles of the rectangle right? What if the other nodes would move, so that moving the dragged node to the new position would *not* change the angles? For a rectangle this means that the 2 nodes left and right of the dragged node move along with it, such that the object stays a rectangle. This can be very handy for polygons with angled lines and things. Again, I can make a small mockup. I don't know if there is mathematic papers or things to be found on this topic, as solving for all nodes can become complex maybe, or maybe in the very general case, it still only concerns the two nodes left and right of the dragged node......... As you can read, I haven't thought about this too much.
The ruler tool I really like and use a *lot* and start to miss it in Inkscape... I think you can 'copy' most of the code of the pentool, and scratch all the code to make bezier things, because you only need straight lines!
Cheers, Johan
On Wed, Mar 26, 2008 at 4:50 PM, <J.B.C.Engelen@...1578...> wrote:
The ruler tool I really like and use a *lot* and start to miss it in Inkscape... I think you can 'copy' most of the code of the pentool, and scratch all the code to make bezier things, because you only need straight lines!
So why a new tool? Can't you just add this functionality to Pen tool if you need it?
-----Original Message----- From: bulia byak [mailto:buliabyak@...400...] Sent: woensdag 26 maart 2008 21:22
On Wed, Mar 26, 2008 at 4:50 PM, <J.B.C.Engelen@...1578...> wrote:
The ruler tool I really like and use a *lot* and start to
miss it in Inkscape...
I think you can 'copy' most of the code of the pentool,
and scratch all the code to make bezier things, because you only need straight lines!
So why a new tool? Can't you just add this functionality to Pen tool if you need it?
I think it is strange to add this to the pen tool where a user would not search it. Furthermore, the tool I propose does not draw ruler paths in SVG. Only an item on-canvas. They stay when switching to other tools, and are removed when pressing some special button/shortcut to remove them (all rulers at once). I meant more that it will not have to be implemented from scratch, as it seems the pen tool does some things that are necessary for the ruler tool (react on clicking on-canvas, drawing a line from clicked point to mouse pointer); I usually try to find functionality already coded in Inkscape, copy it and modify it.
I really find this a very useful tool for technical drawing. Checking dimensions, without counting grid squares, etc. Snapping to the ruler is also very nice, they sort of work like guidelines in that respect. Yes, that's it: see it as short guidelines that are temporary :-) (one shouldn't save them in the file for example)
-johan
Picture of the ruler tool in action: http://www.et.byu.edu/groups/ece451web/cadence-help/tutA3.html
Picture of 'preserving angles' is attached.
J.B.C.Engelen@...1578... wrote:
Snapping to the ruler is also very nice, they sort of work like guidelines in that respect. Yes, that's it: see it as short guidelines that are temporary :-) (one shouldn't save them in the file for example)
In many 3D mechanical CAD programs they have something similar, called "construction lines" (for example in Unigraphics). These lines are only used to construct sketches, they are not a part of the path and are not being used to create the 3D model. They're only there for aligning, trimming to, dimensioning, etc and have a distinct stroke or color. Indeed, like "short guidelines". They should be permanent IMO, and not be discarded when the file is closed!
The other thing is lines being perpendicular / parallel / aligned etc. When applying such constraints in 3D CAD, they're associative and actively maintained, which would be quite uncommon for a vector graphics program. In vector drawing these constraints are usually only used when initially creating the objects, or when manually applying the constraint. This is much easier to code I guess, because making the constraints associative requires some kind of solver. If we would have associative constraints though, it would really give Inkscape a unique position, wouldn't it?
Max, I didn't read your proposal yet, but you sure got some feedback now ;-)
Diederik
Snapping to the ruler is also very nice, they sort of work like guidelines in that respect. Yes, that's it: see it as short guidelines that are temporary :-) (one shouldn't save them in the file for example)
In many 3D mechanical CAD programs they have something similar, called "construction lines" (for example in Unigraphics). These lines are only used to construct sketches,
In place of this I often use the trim/extend feature. After I dont need the line anymore, I simply delete it. This method is simple, and straightforward.
I never really understood the goal of the construction lines in autocad, when there is simple and easy replacement. (just drawing a line and extend it)
As for your proposal Max, I think any tech drawing related improvement is useless without *numerical input*. So defining a circle through three point is usefull only, if you can specify the three point numerically. If it is not the case, it is only a yet another artistic tool.
I cant say anything as developer (because im not), but as a user, I would be really thankful if you choose the tech drawing proposal. I really miss some tech drawing capabilities from inkscape.
Anyway, sorry for the noise, and best wishes for your proposal!
Best regards, Khiraly
participants (10)
-
unknown＠example.com -
Aaron Spike -
Alexandre Prokoudine -
Bryce Harrington -
bulia byak -
Diederik van Lierop -
khiraly -
Maximilian Albert -
Rock Star -
Steren Giannini