Planned features

A very rough roadmap of ADG features implementation

Road to unknown

This is the collection of TODOs that could be applied also after the 1.0.0 version has been released. They are usually non-blocking and hard to implement.

  • Hide the CPML APIs accessible from the CpmlPrimitive interface: use a private struct of function pointers to delegate the job to the different primitives.
  • Check if the decentralization of the quote is applicable to the angular dimensions too and if it is worth the effort.
  • The ARROW and TRIANGLE markers should follow the director path that could be a curve. Use the METAPOST solution suggested by John Hobby I don't remember where, that is given angle and size, rotate the path by half angle in both directions, look for intersection with a circle centered at the end of the director path with radius size and close the resulting path.
  • Add connectivity feature to AdgModel: enable dependencies of models to external data. Use libgda as sample data provider.
  • Implement AdgText, a generic text management, using pango.
  • Add self-intersection API for CPML segments.
  • Add datum support: for implementation ideas checkout this draft.
  • Add a CpmlArc primitive and some API to CpmlCurve to be able to check if a curve is an arc approximation. This gives additional information to do some operation, such as a proper radial quote on a Bézier curve.
  • Hunt the TODOs in CPML and fill the missing logic.
  • Improve Bézier offset approximation enabling the choice of approximate a single curve with multiple offset curves.

Road to adg-1.0.0

The commits in the 0.7 branch should be atomics, that is a succesfull built will be added as a prerequisite for each commit, so bisecting with "git bisect" is usable. The API should be considered almost frozen, new additions are still accepted tough. This is a testing branch: the target is to reach a sufficient quality level to make a 1.0.0 release.

These releases should reach the wider audience, accordling to a niche project such as the ADG canvas. This means to build releases also for different platforms, such as *BSD, OpenSolaris and Windows.

Road to adg-0.7.0

The target of the 0.6 branch is to clean up the code and stabilize the API: the 0.7.0 release will probably be a beta release.

  • Provide a document with API guidelines take it as the holy bible! All the APIs must comply with the rules of this document.
  • Resolve the TODOs in the adg/ directory: the only missing logic should come from the CPML library (and there the TODO items are bound to the less common use cases).
  • Create a separate project called lua-adg to host the lua bindings for the ADG project. Provide a demo similar to adg-demo in lua.
  • Add italian localization.
  • Try to cross compile and build a windows binary package. Check out Allin suggestions for hints.
  • Implement a decent "make check" target, basing the check programs on the test framework of glib. Make this an optional feature, as this framework is based on the too young glib-2.16.0.

Road to adg-0.6.0

The target of the 0.5 branch is to provide a usable canvas: with usable it is meant a canvas that can generate fairly completed drawings. The 0.5.x releases leading up to 0.6.0 should add all the missing features needed to generate this drawing.

  • Implement adg_matrix_normalize() to get rid of the scaling component of a matrix: consider the point (0,0) and (1,1) on the identity matrix and force on the matrix to normalize a distance of 1.4142... between the same points by modifying only the xx and yy components.
  • Move the custom get_local_matrix() inside AdgEntity and implement a common way to manage local matrix - entity interaction: for instance, if the model is rotated an AdgToyText should rotate accordling but not scale (usually, at least if it is not a text written on the model).
  • Implement AdgMarker as an abstract entity: it will be the base class for arrows, ticks, squares, dots and so on.
  • Implement AdgArrow as AdgMarker derived entity.
  • Implement AdgArrowStyle directly inside the AdgDimStyle class and provides a way to customize the markers.
  • Rework the style approach by detaching the slot and type concepts: rename slot to dress and let the door opened to future expansion by breaking the one style = one dress equation.
  • Rewrite AdgLDim to use the new marker APIs instead of hardcoding the arrows and calling the deprecated rendering callbacks.
  • Implement the extents infrastructure that computes the bounding box of the entities without rendering them.
  • Implement the outside arrows in AdgLDim.
  • Add AdgADim, the angular dimension.
  • Implement AdgEdges, a model that computes the edges of an AdgTrail model and build a CpmlPath containing all the vertical edges.
  • Add AdgRDim, the radial dimension.
  • Rework styles by using GObject and properties.
  • Implement an abstract AdgFillStyle, abstracting the cairo_pattern_t APIs and providing a way to customize filling, similar to what AdgLineStyle does for stroking.
  • Add AdgRuledFill, an AdgFillStyle implementation that allows to fill with a serie of parallel lines with customizable angle and distance.
  • Add AdgHatch, an entity very similar to AdgStroke but that uses cairo_fill() instead of cairo_stroke().
  • Implement the extents also for the path so the AdgHatch entity can work reliable: check if it is better to add new code in CPML or to directly use the functions provided by cairo. (Implemented in CPML as the arc primitive is not native in cairo and it is the only one with some quirks in the extents computation)
  • Add labeling feature to the models and let AdgDim and children points be expressed as references to those labeled points instead of using explicit coordinates.
  • Add AdgTable, a container for AdgToyText in a framed environment.
  • Add AdgTitleBlock, a complex entity in global space used to frame the sheet and show the general drawing data (title, scale, date and so on).
  • The dressing feature needs more attention: they are still not well polished and always using the "dress" property will likely give name conflicts: a basic mangling is required.
  • Allow the linear dimension to be decentralized by using the pos point as reference and using a dedicated enum instead of a three-state.
  • Sanitize the ADG APIs: the public functions must cope with invalid arguments without segmentation faults (without crossing the limits of the C language and of the common sense).
  • Provide a decent demo program to show the progress so far, including title block, hatches and various dimensions types: update the website with new (and hopefully more impressive) screenshots.

Road to adg-0.5.0

The target of the 0.4 branch is to build the base of the canvas: few user visible changes but a quite stable base code. All the main infrastructures should be in place.

  • Develop a basic demo CPML program to visually check the results.
  • Provide CPML APIs for accessing cairo paths and browse their segments (a contiguous line segment).
  • Provide CPML APIs for accessing segments and browse their primitives (a single line / curve / close path).
  • CPML APIs to offset cairo paths: specifically, a decent approximation for single Bézier curves must be implemented.
  • Implement APIs to get intersection points between different primitives.
  • Provide an abstract API (cpml_segment_intersection?) to compute the intersection points between two segments. To be evaluated the way to return the results (maybe using an argument to specify the maximum number of intersections to return).
  • Generate documentation for CPML.
  • Merge ldim and adg-demo into a single demo program, basing the user interface on GtkBuilder.
  • Implement AdgModel as a bare empty class. Move the actual stuff in AdgTitleBlock.
  • Add model-view interaction by providing signal propagation from AdgModel to the dependent entities, so when a data changes the entities will be automatically updated.
  • Rename AdgPath to AdgStroke, being the latter a stroke representation of a single AdgPath.
  • Implement AdgPath as an AdgModel derived class of a conceptual path. Any AdgPath instance could be referenced by one or more entities.
  • Add arcs in CPML to transparently support, whenever possible, the conversion between arcs and Bézier curves.
  • Add to AdgPath the basic functionality to build a path: basically a bunch of methods emulating the cairo path API but without the need of a yet instantiated cairo context.
  • Add support for the CPML arc feature in AdgPath.
  • Update the demo using the newly implemented AdgPath to deeply test the model/entity interaction.
  • Add a chamfer operation to AdgPath.
  • Add a fillet operation to AdgPath.
  • Change the matrix entity API, using a cleaner approach.
  • Move AdgTranslatable and AdgRotable directly inside AdgEntity.
  • Ensure there are no bitfield flags, as they are not binding friendly.
  • Change building scripts to get the GTK+ dependency optional.
  • Add AdgWidget, a GtkDrawingArea that can accept an AdgCanvas.
  • Optimize the implemented entities applying the 0.4 ADG infractrusture and enable caching where applicable.
  • Use AdgToyText to draw dimenstion quote where applicable.
  • Add a "beyond" property to AdgDimStyle to be used when extending the baseline beyond the extension lines. If not specified, it must default to 3 x arrow size.
  • Add a three-state enum to adg-enums.h: ADG_THREE_STATE_OFF, ADG_THREE_STATE_ON and ADG_THREE_STATE_UNKNOWN.
  • Add the three-state "outside" property to allow forcing an outside quote. In the default state, the outside must be decided by the space between the extension lines: if greather than 3 x arrow size => inside arrows.

Road to adg-0.4.0

The target for the 0.3 branch is to give a shape to the project: build system, docs and a bunch of (probably temporary) basic classes should be enough to give a direction.

  • Split mathematic stuff in its own library. It will be called CPML, that is Cairo Path Manipulation Library.
  • Avoid wrapping of cairo APIs in AdgPath.
  • Implement AdgToyText, a basic text entity using the cairo "toy" text API.
  • Implement AdgTranslatable, a shared interface for entities that can be translated.
  • Implement AdgRotable, a shared interface for entities that can be rotated.
Planned features was last modified by gtk-doc on Sun 21 Feb 2010 10:22:18 PM CET
Hosted by Get Automatic Drawing Generation at SourceForge.net. Fast, secure and Free Open Source software downloads
Search on this domain