Re: Advanced options for custom shapes

[Hans Breuer <hans breuer org>]

Am 03.11.2014 um 21:03 schrieb Nico Rikken:
> Dear Hans Breuer,
>
> Thanks for your reply.
>
> > This would require some extension to the custom shape specification [1] and
> > the custom shape module [2]. A simple solution could be to define an enum
> > with the shape and use that for conditional rendering of subshapes. This
> > wont give an extra dialog, but just another option with the standard
> > properties.
>
> As I tried to put forward in my email I have experimented with custom
> shapes, although I wasn't aware of the enum functionality.
As I said (or tried to say) neither the specification nor the 
implementations is available yet.

> Observing the UML objects (especially the class) in the source code has
> shown me the incredible number of possibilities for adding options.
Please be aware that the UML - Class object is the last thing you should 
use as an example. It is the last object implementation which does have 
custom GUI code and a lot of that is using deprecated GTK+ stuff.
All other objects get there user interface through the standard properties 
system.

> [...]

> > If I understand correctly this is a special case of 1)? But here one might
> > consider to use the SVG switch element [3], which looks to be too limited
> > for the generic case. But again some specification and implementation
> > updated would be involved.
>
> I wasn't able to find any <switch> statement in the code (grep),
Yes, again I was talking about the design, but one probably to be rejected. 
At least my reading of the SVG specs makes the switch element probably too 
limited for the use case at hand.
BTW: you wont find any of the used SVG tags by greping for e.g. <g> because 
Dia is passing the 'undecorated' tags to the underlying XML library.

> so I
> assume this would imply not only an element for each shape, but also the
> necessary parsing in the code to properly handle this functionality.
> That seems to require to much effort, especially for a questionable
> usability feature.
So no <switch> ;)

> > This kind of flexibility is IMO out of scope for the custom shape
> > mechanism. But an an object implementation in C could achieve something
> > like that. See e.g. "Network - Bus" for an example [4].
>
> Another good example. The Connection point in Electrical would be a more
> simple way of achieving similar drawing capabilities, but the network
> bus with some modifications would be a great alternative.
>
> > Custom shapes are always scaled so the underlying size does not matter
> > match. If you are creating your shapes with the help of Dia's shape
> > exporter typical diagram sizes should be used.
>
> The main reason for asking was the consideration of the relative line
> thickness when designing shapes. Then again line thickness can be
> defined by the user.
This is a known weakness of the current shape specification. I've tried to 
reverse engineer what's currently implemented some while ago:
https://mail.gnome.org/archives/dia-list/2008-July/msg00084.html

But IIRC nothing was changes due to the huge amount of exisiting shapes.

>> [...]
> > If I've understood your requirments correctly some coding woud be
> > inevitable. Don't hesitate to discuss the design on this list first ;-)
>
> Great, I'll start by preparing a set of icons I would like to implement
> and the various options, to better discuss the way of implementing.
Sketching the desired shapes with an annotated diagram looks like a good 
basis for discussion.

Regards,
        Hans

-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to
get along without it.                -- Dilbert