> Here's a patch to apply after the above patch to get gtk layer > changes support:
Thanks! Does it all work well enough that I can apply our two patches now? > 1) With 1st layer selected, move layer up deletes 1st layer. > > 2) With last layer selected (the one above Silk), moving down does > something strange and deleting it leaves no layer selected. > Actually, the deleted layer is still selected. Probably related to each other. I'll debug it. > 3) Now MAX_LAYER is 16 but there are only 8 LAYERCOLOR and > LAYERSELCOLOR attributes set in the main_attribute_list. I think lesstif just assigns a color to the extra layers as needed. We don't save color information with boards, so we're going to have limitations here until we do. > 4) In the Lesstif version, if you move a layer, it's color is not > changed on the layout. But if you save the file and reload > (revert), the color will be changed. So for now, the gtk version > goes ahead and changes the color when a layer is moved. I think lesstif is wrong, but then, lesstif also doesn't have a layer color editor, so it tends to swap freely beween PCB->* and Settings.*. > Also, shouldn't DEF_LAYER be a setting instead of hardwired to 8? > With it hardwired I can't let the user have the option of setting > his layer groups preference for new layouts. Or I think better, why > not derive the DEF_LAYER value from the default groups string? My thought on this is to replace "new" with something that loads one of N templates stored in ~/pcb or $prefix/share. That way, there don't have to by *any* built-in defaults, aside from incomplete installs. Layer group preferences need to stay symbolic (i.e. "1,2,c:3,4,s:5") until you apply them to a board with a specific number of layers. I have no problem deriving DEF_LAYER from the groups string.
