Re: redesign of layers?

[Arigead <arigead gmail com>]

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
> > at.
> >
> > 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
> > diagram.dia.
>
> 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>
> >      
> >      <dia:object type="Circuit - Vertical Resistor (European)"
> >      version="1"
> >
> > id="O1">
> >
> >       </dia:object>
> >      
> >      .
> >      .
> >      .
> >
> > </dia:layer>
> >
> >
> > 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"/>
> >        
> >        </dia:attribute>
> >
> > 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 
effected.

> > 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
> expectations.
>
> > 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
> [ http://en.wikipedia.org/wiki/2D_computer_graphics#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
> http://mail.gnome.org/mailman/listinfo/dia-list
> FAQ at http://live.gnome.org/Dia/Faq
> Main page at http://live.gnome.org/Dia