This page contains various missing features in Dia that would be good starting points if somebody wants to contribute code. In short, it's features that we agree should be in Dia, but we haven't had the time to do them ourselves yet. Many of them are taken from bug reports or the mailing list. If you start working on one of these, please move it from here to the Dia/Current Development pages.
This can also function as a list of oft-requested features for triaging Bugzilla bugs.
Showing active pages
It can sometimes be confusing how many pages get printed, since little bits of overlap can cause an extra page to print. Greying out the area that's not due to get printing would clear this up.
In-document LaTeX support
The ability to edit LaTeX directly in an object, with a round-trip to TeX to render a bitmap version for bounding-box purposes. Rob McDonald brought together a number of links to similar code in other programs in a mail. No fundamental problems in this, but handling the execution of TeX with appropriate options could be tricky. There's also a simple renderer called mimeTeX that doesn't need LaTeX to run.
Embedding in Dia files
Several things could be embedded in .dia files: Images, fonts, SVG versions of complex shapes are three obvious things.
See bug 304693 for some talk on embedding images in .dia files. This is probably the most urgent.
Remember dialog directories between sessions
The dialogs remember their directories, but only within a session. This could be saved from session to session with a simple persistence call.
See bug 310843.
A fairly big thing. There's two parts to it: One is that all the renderers must be updated to deal with rotation -- in some cases, they just can't do it, in other cases it may be not quite trivial to map from one to the other. The other problem is to keep track of rotations internally, especially when it comes to groups, autorouting and zigzag-lines.
Some comments on bug 321820.
Properties for size and placement
While the size and position of each object is stored as properties (except for a few complex objects), the user cannot edit them directly. Editability would be useful for precise positioning/sizing and for setting several objects to the same size. However, there are some issues in making sure the properties dialog is updated when the object is updated, and that any constraints (e.g. aspect ratio) are kept.
bug 328200 talks more about this.
A similar feature is found in Gimp: The ability to drag vertical or horizontal helping lines from the rules at the edge of the diagram, for aligning things in specific ways. Could even be magnetic like connection points, maybe.
bug 108838 has the details.
This is where things that may or may not be a good idea can get collected. A number of these are collected from old bugs or mails.
As a basic enhancement properties like fonts should be organized tree-like. The diagram always gives some font and every following object can override this font. So it would be possible to change fonts even for objects having no font dialog, they get it from the diagram. This is also my question: Why it ain't possible to set the diagram's font?
Relatedly, should it be possible to set the default font color separately from setting the foreground/background color?
Halfway done by anthonym, as can be seen in this mail. Just like corners of rectangles can be rounded, so should corners of polygons be able to. Not a bad idea, but the renderer implementations can get icky. I'd want to be convinced that it's not too messy.
Connecting click-point with properties dialog
A suggestion from Jason Alan Smith is that UML class should go to the Attributes tab if double-clicked on the attributes in the object. Apart from extending the dialog code to reverse-map the area (which is non-trivial), this would require letting the dialog code know where it got clicked, which might be useful for other things.