Re: redesign of layers?

On Friday 05 Aug 2011 23:05:06 Hans Breuer wrote:
At 05.08.2011 12:43, Arigead wrote:
[...] So one female banana might be on 5 "pages/layers" as it's
connected to 5 different circuits. It's only shown on the master diagram
once with a lot of interconnections but for clarity you can view just
the "page/layer" you're interested in to figure out what you're looking

The big problem with the above in terms of Dia is that it is the complete
opposite of the hierarchy of the Dia data structure when saved to file

Yes, it sounds like turning everything upside down. Does not look very
feasible to me.

At present the<objects>  of the diagram are children of the
<layer>. So layer one has five children objects.

<dia:layer name="Background" visible="true" active="true">

     <dia:object type="Circuit - Vertical Resistor" version="1" id="O0">
     <dia:object type="Circuit - Vertical Resistor (European)"




The way I'm talking the object is the parent and has a list of layers on
which it can be seen:

<dia:object type="Circuit - Vertical Resistor" version="1" id="O0">

       <dia:attribute name="layers">
           <dia:layer val="background"/>
           <dia:layer val="Heating Circuit"/>

That is a major change in how things are done, and humans hate change.

That change would break a lot of things. Not only forward/backward
compatibility of exisiting diagrams. But also drawing order, layer specific
selections, ...

Forward/backward compatibiliy of diagrams could easily be handled by code. For 
all its simplicity code can be very flexible. Dia could easily read both 
formats and perhaps either save to a newer format or to the existing format. 
If the format is locked in stone then Dia is inflexible and not really future 
proof. Things change and most file formats have changed over time. Well apart 
from ".txt".

I'm not sure what you mean by drawing order, or don't see how this is 

I'm new
here so I'm not seeing the bigger picture. There is obviously a reason
why things are the way that they are, even if I'm too green to see it.
In addition there might well be a very good reason why what I have
suggested is complete madness in a drawing package like Dia.

I would not even design it that way if starting from scratch for your use
case. If I understand correctly there are only some objects which would be
available on every (or many) layers. In a multi layer circuit board the
circuit pathes are on a dedicated layer. Only at some spots there would be
a connection between layers.

Good example, a multi layer PCB is composed of a number of layers but for the 
thing to work there has to be some communication, or crossover, between 
layers. Yes this only occurs at a number of specific points in the circuit but 
it does happen. At present Dia's layers are completely seperate drawings and 
serve no other purpose then to unclutter a complicated overall diagram. 

I'd be interested in hearing the experts opinions. I've not started
looking into the code to see how much would have to be changed. I'd
imagine a fair bit but it's not going to effect the core of the Dia
drawing code.

Dia is drawing it's layers from bottom to top and not by global object
order so the core (and plugin drawing code would be affected.

The load and
save routines which read and write the ".dia" files and the code for
viewing layers. Instead of a layer having a list of visable objects the
code would have to check all objects to see if they're on a visable
layer. Slower I know but hopefully not too slow.

Maybe you should grep the Dia source for 'layer' to adjust your

As an aside when I think of my "pages" I think a tabbed window of the
pages might be logical. That's another days work though ;-)

Sorry I don't get why you call the layers "pages". What's wrong with layers
[ ]

Layers is fine I have no problem with semantics of it at all. My problem is 
the functionality and flexibility of layers as currently implemented. I haave 
no doubt that the changes would be major but that's not a reason not to do 
something, if it leads to a more flexible solution, in my mind. Yes it will be 
difficult to change the code from one way of working to another but you've not 
given me a reason why it should not be changed. Compatability could be coded 
for and difficult is not really a reason.

I can well understand the resistance to changing things. I'm only trying to 
apply Dia's functionality to a specific problem. I'll think over it some more 
and see if I can bend Dia to a solution. 

Thanks a million for getting back to me, and taking the time to respond. I'll 
mull over things with a coffee.

-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to
get along without it.                -- Dilbert
dia-list mailing list
dia-list gnome org
FAQ at
Main page at

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]