Re: Questions on new shapes and new plugins

[Cyrille Chepelov <cyrille chepelov org>]

Le Tue, Jul 20, 2004, Ã  02:11:57PM +1000, Phan Le a écrit:

> From reading code and other how-tos stuff, I have learnt that we 2 
> kinds of plugins in Dia:
>
> 1. Soft: new shapes and sheets are created, put in .dia/shapes & sheets, 
> or put in the source and make modifications in Make files. I called it 
> soft because it does not require us to change the source much.

Well, you need to provide two files (.shape, .png) per shape, one
.sheet.in per sheet, and modify a couple of Makefile.am files (plus
nicely ask Hans to modify his .msc files if applicable).

> 2. Hard: you do this when you need new shapes + new properties, and you 
> need some kind of thing like new dialog showing non-standard properties 
> popped up when double clicking the objects( like in UML). This requires 
> us to add source code in /objects and have to  declare our own drawing, 
> properties getting functions.

You need to pick a suitably similar object definition (one .c, one .h,
one .png file per object), and modify its property definition array 
(a couple of lines) and its draw routine. The result is a derived copyrighted 
work according to the Berne Convention and applicable superceding treaties,
so the GPL must apply to the result if it is to be distributed at all. 
You need to add a .sheet.in file per sheet, one .c file and one
Makefile.am file per library (which you can copy&paste from an existing
object library -- it's mostly boilerplate). That's it.
 
> My question is that is it possible to have the mixture of them? Say, I 
> have the shapes and sheets already exported in svg, I just want to 
> define my own  properties and functions to get the properties displayed 
> nicely in a dialog without declaring my own object drawing function.

The latter is provided by StdProp. You do not, repeat not, need to do
any direct Gtk work to define a new property. See how sane objects don't
even #include <gtk.h>.

<WARNING WARNING WARNING WARNING>

"UML - Class" IS THE WORST EXAMPLE OF A PROGRAMMED OBJECT. DO NOT TRY TO
COPY METHODS FROM THAT SOURCE FILE

thanks

</WARNING WARNING WARNING WARNING>

Now, reading part of a SVG shape definition and rendering that from C
code? Sure, you could try to call stuff from objects/custom/*shape*.c
from your object, but what's the point? The makefile hackery you'd have
to do (and ensure that you don't piss Hans off in the process, he's
compiling using a bizarre autotools-oblivious toolchain called "Visual
C++") is (IMO) much more work than writing a simple SVG->Dia Renderer C
code snippet converter (even if you do it with lashes, vinyl and XSLT
stylesheets). 

I really think this: a small Shape->Programmed object converter, written
in Python+PyXML, which takes a .shape file as input and produces an
equivalent C file as output (to be used as a basis for more complex
modification) would be a truly awesome little project. And probably not 
too hard to do at all (see the few remaining ER or flowchart objects, and of
course the Standard objects, for good examples).

(side note to CS lab instructors: I've seen on this list and privately a
couple messages that seem to indicate that dia is now beginning to be a
popular subject for practical training assignments. Which is really
good, I look forwards to seeing integrable results! If at all possible,
please consider the Shape->C converter project above as a potential
assignment...)

        -- Cyrille

--