GSoC Tech Drawing proposal (and a question/further suggestion)
Hi all,
here is finally my application for this year's GSoC (still up to minor modifications and slight abridgement; please also note that the website for the proposal is not updated yet, I will do this tomorrow or on Monday). If you have any comments, suggestions or criticism, I'd love to hear them.
Apart from many of the suggestions mentioned on this list (thanks again to everyone, the resonance was overwhelming!), I also included a new idea which struck me tonight but could turn out quite involved (or else rather easy if I'm lucky) so I thought I'd ask whether it is appropriate for inclusion.
Namely, since LPEs are intended to be used as the basis for further tools (or for refactoring existing ones), the need for integrating LPE parameter controls into toolbars is likely to arise sooner or later. Since I need to add a toolbar for the new Tech Drawing tool anyway, I was wondering whether I could set up a general framework that allows LPE parameter controls to be automatically added to certain toolbars and to be activated/toggled visible when the LPE is used by the respective tools. This would eliminate the need to recode toolbar controls over and over again when tools want to make use of functionality provided by a LPE. It would work similarly to how controls are currently added to the various LPE dialogs (but with some extended functionality).
I haven't thought this through yet but at first sight it doesn't seem _too_ difficult to do (since much of Johan's code could probably be reused), yet very convenient and highly desirable, at least from my biased point of view :). Or is it complete nonsense? What do you think?
Max
=== GSoC Proposal: Tech Drawing Abilities for Inkscape ===
== Abstract ==
While Inkscape is very powerful as vector graphics editor, it is mainly suited for artists. Technical drawings and geometric constructions are possible, but they are cumbersome to do and difficult to edit later on, especially if mutual relations like "is parallel to", "passes through", etc., are to be retained. Already a limitation for artistic work, this is a showstopper for people like architects or scientific researchers who wish to use Inkscape for precise drawings in construction plans or academic posters.
I propose a new Tech Drawing tool, combined with a number of related enhancements, that will establish Inkscape as a mature tool for these purposes and further strenghten its status as the leading open source vector graphics editor.
== Deliverables and goals ==
(1) New "Tech Drawing" tool for geometric constructions
(2) UI framework for on-canvas and toolbar adaption of LPE parameters (see below)
(3) Refactoring of code obsoleted by this work
(4) Documentation for the new frameworks
(5) As time permits, implementation of more advanced tech drawing features
=== Details ===
Graphical illustrations, more details and further ideas are provided at the accompanying web page for this proposal. [1]
1) The new tool will comprise a number of "modules" for the most commonly needed geometric constructions, including:
- parallel/perpendicular to a line (at a given distance or through a given point)
- angle/segment bisector
- circle with given center and radius / circle through 3 points
- interactive path mirroring/rotation (for symmetric drawings)
- measurements (distances, angles, possibly path lengths and areas)
All parameters involved in a construction (angles, distances, coordinates, etc.) will be settable both by mouse and via exact numeric keyboard input through toolbar controls.
Internally, the tool will be implemented as a collection of "Live Path Effects" (LPEs) [2]; the algorithms for non-trivial path manipulations are provided by the 2geom library [3]. LPEs are designed as a general framework for new tools in Inkscape and provide excellent low-level support for a unified treatment of these seemingly quite disparate geometric construction modules.
2) Notwithstanding, LPEs lack a good *interactive* user interface for easy on-canvas adaption of their parameters. Moreover, the existing controls are only accessible in a cumbersome way through the LPE dialogs. In view of these limitations and the intended use of LPEs for future tools in Inkscape, I will
- expand the current rudimentary support for on-canvas interaction to a flexible UI
- implement a general framework that allows automatic integration of LPE controls into the toolbars of existing tools (similar to how they are now added to the LPE dialogs) as well as toggling their visibility depending on the LPE being used
The latter will essentially also implement the toolbar of the new Tech Drawing tool and greatly simplify the creation of future tools through LPEs.
3) Some old and heavily buggy cold will become obsolete by my work. This is certainly true for "linked/dynamic offsets" (which 2geom's algorithms and the new UI supersede) but likely applies to other code, too (possibly guidelines). I will look for code that falls into this category and plan my work accordingly, in agreement with the internal refactoring goals of Inkscape's upcoming version 0.47.
4) As a matter of course, the new frameworks will be extensively documented during their implementation (following the excellent example of existing LPE structure [2]).
5) Inkscape's bug tracker lists a huge number of feature requests related to geometric/CAD drawing. If time permits (which I expect), I will implement a suitable number of these. Here is an incomplete collection (visually illustrated and continued at [1]), in rough order of expected difficulty/desirability.
- "Preserve angles" mode for node editing of polygons
- Marker improvements (correct color, direction/point of alignment)
- Improved snapping (in particular, "tangent snapping" of lines/paths to other paths)
- User-defined coordinate origin/axis directions (up vs. down); this should be combined with removing Inkscape's internal usage of two different coordinate systems (an endless source of confusion and bugs)
- Document units scaling (e.g., 1cm = 200m); particularly useful for map creation
- "Real time helpers" such as "dynamic/smart guides" or "interactive rulers"; since the recent addition of temporary canvas items to Inkscape this has become within closer reach
== Timeline ==
Throughout the project I will gather user feedback regarding feature desirability and UI design. The resonance from the community has already been overwhelming during the write-up of this proposal (which also attests the great need for the proposed features).
Coding will start by implementing the above-mentioned geometric construction modules as LPEs. Telling from two proof-of-concept implementations (a "circle construction"-LPE and a "perspective path"-LPE) [4][5] this should be accomplishable within the first week. The next 2-3 weeks will be spent on the UI for on-canvas parameter adaption. Allowing for some time to deal with unexpected problems, this should leave us with a basic but functional tool after about one month.
The second part of my work will focus on implementing the automatic toolbar integration framework as described under item (2) above. I anticipate this phase to take also roughly 4 weeks.
Depending on the remaining time and based on discussion with my mentor and the user community, I will then implement a suitable number of more advanced features such as the ones collected under item (4). Together with whatever work on the documentation still remains at that point, this will easily fill the time until the end of SoC.
== Experience with Inkscape and qualification ==
I started coding for Inkscape during GSoC '07 when I implemented the new 3D box tool which is included in the just released version 0.46. After SoC I considerably refactored the tool to lay the foundation for further 3D features. This has led to a "perspective path LPE" [5] as first payoff with many more things planned. I also worked on numerous bug fixes (code-wise or by providing feedback) and am an active member of the devel mailing list.
My acquaintance with Inkscape's code will allow me to dive into the real work right from the start (unlike last year when getting used to unknown parts consumed a considerable amount of time even at later stages of the program).
For a description of other former coding projects and general open source experience see [1].
== About me ==
I'm a 27-year-old student of mathematics from Heidelberg, Germany. I'm currently in the phase of my final exams which will lead to my graduation in May. Having neither classes nor other obligations in summer, I can devote my full time to the SoC project.
I'm a passionate a-capella singer, performing in various choirs and vocal groups. My resulting experience with organizing concerts and communicating with people will stand me in good stead for this project, too (after all, open source is all about community). I also enjoy sports (running, volleyball), reading, and hanging out with friends. See [1] for my detailed CV.
== Other GSoC applications ==
I have not applied for any other GSoC projects.
[1] http://www.rzuser.uni-heidelberg.de/~malbert/ [2] http://wiki.inkscape.org/wiki/index.php/MakingLivePathEffects [3] http://lib2geom.sourceforge.net/ [4] SVN commit #18177, viewable online at http://tinyurl.com/yvyftz [5] SVN commit #18093, viewable online at http://tinyurl.com/6pkw76
On Apr 5, 2008, at 5:49 PM, Maximilian Albert wrote:
Namely, since LPEs are intended to be used as the basis for further tools (or for refactoring existing ones), the need for integrating LPE parameter controls into toolbars is likely to arise sooner or later. Since I need to add a toolbar for the new Tech Drawing tool anyway, I was wondering whether I could set up a general framework that allows LPE parameter controls to be automatically added to certain toolbars and to be activated/toggled visible when the LPE is used by the respective tools. This would eliminate the need to recode toolbar controls over and over again when tools want to make use of functionality provided by a LPE. It would work similarly to how controls are currently added to the various LPE dialogs (but with some extended functionality).
I haven't thought this through yet but at first sight it doesn't seem _too_ difficult to do (since much of Johan's code could probably be reused), yet very convenient and highly desirable, at least from my biased point of view :). Or is it complete nonsense? What do you think?
If you're going to be looking in that direction, be sure to look at GtkAction, the custom subclasses we have, and the XML used to create most of the toolbars now.
The general plan is to get some publicly visible XML format that will be changed to the internal format needed as it's fed into UIManager functions.
For what you mention, some 'context' might be needed as the intermediate hookup.
Maximilian Albert wrote:
Namely, since LPEs are intended to be used as the basis for further tools (or for refactoring existing ones), the need for integrating LPE parameter controls into toolbars is likely to arise sooner or later. Since I need to add a toolbar for the new Tech Drawing tool anyway, I was wondering whether I could set up a general framework that allows LPE parameter controls to be automatically added to certain toolbars and to be activated/toggled visible when the LPE is used by the respective tools. This would eliminate the need to recode toolbar controls over and over again when tools want to make use of functionality provided by a LPE. It would work similarly to how controls are currently added to the various LPE dialogs (but with some extended functionality).
It just occurred to me that a similar thing might be useful for knotholders (e.g., I wanted the new perspective path LPE to display handles for perspective resizing).
Max
-----Original Message----- From: inkscape-devel-bounces@lists.sourceforge.net [mailto:inkscape-devel-bounces@lists.sourceforge.net] On Behalf Of Maximilian Albert Sent: zondag 6 april 2008 17:35 To: inkscape Subject: Re: [Inkscape-devel] GSoC Tech Drawing proposal (and a question/further suggestion)
Maximilian Albert wrote:
Namely, since LPEs are intended to be used as the basis for further tools (or for refactoring existing ones), the need for
integrating LPE
parameter controls into toolbars is likely to arise sooner or later. Since I need to add a toolbar for the new Tech Drawing tool
anyway, I
was wondering whether I could set up a general framework
that allows
LPE parameter controls to be automatically added to certain
toolbars
and to be activated/toggled visible when the LPE is used by the respective tools. This would eliminate the need to recode toolbar controls over and over again when tools want to make use of functionality provided by a LPE. It would work similarly to how controls are currently added to the various LPE dialogs
(but with some extended functionality).
Great idea!
It just occurred to me that a similar thing might be useful for knotholders (e.g., I wanted the new perspective path LPE to display handles for perspective resizing).
As a first step, it would be very nice if you could C++-ify the knotholder, subclass special knotholders for the existing tools and perhaps subclass NodePath from it too. I found it hard to subclass from the current SPKnotholder to make a special one for lpe-PointParams, so I solved my problem another way. Having Nodepath subclass from Knotholder might solve (or introduce!) some problems in ShapeEditor with having multiple knotholder/nodepaths on-canvas at the same time.
Regards, Johan
participants (3)
-
unknown@example.com
-
Jon A. Cruz
-
Maximilian Albert