On Mon, 2014-11-03 at 23:57 +0100, Hans Breuer wrote:
As I said (or tried to say) neither the specification nor the implementations is available yet.
But I could still make it work by writing objects in code for upstream adoption, rather than just using the customs shapes objects. Just choosing the right licence and offering a 'patch' should do the trick, right? This sheet would then be present in the object directory.
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.
Good to know.
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.
I guess it would have been specified somewhere in the code in XML. Looking for 'switch' only returns programming statements or descriptions of the network elements.
So no <switch> ;)
At least not in an initial version.
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.
That is unfortunate, since it would straighten-out shape definitions. I guess just adjusting all upstream shapes wouldn't be sufficient since users might have custom shapes to work with.
Sketching the desired shapes with an annotated diagram looks like a good basis for discussion.
Great, I'll head to the library of the university soon. Thanks again. Nico Rikken
Attachment:
signature.asc
Description: This is a digitally signed message part