On Wed, 2011-08-31 at 01:12 +0200, Kai-Martin Knaak wrote: > Two more issues: > > * A left-mouse-click on the square toggles the visibility of the > whole layer group on the canvas. But it toggles only the visual state > of this layer, not the state of the squares that correspond to the > other layers in the group. As a result, the state of the squaere > is not necessarily in unison with the visibility of the layers on > the canvas. If this is the case, it would seem that the selector's data model may reside in the wrong place. A quick skim of the new code suggests that the click action is directly updating the row, where it (arguably) should be poking PCB's core (using an API such as ChangeGroupVisibility) then reading back the changed states. While it "probably doesn't", PCB could quite merrily change the layer on / off status from (say), an action in the core, or a plugin we have no control of. Unfortunately, we don't yet have a way to keep track of this happening in the GUI, but perhaps we should grow one. Whilst the definitive source of the underlying data is in PCB's core, the widget ought ideally to be working from that. Since PCB doesn't do signals on changed data, we might have to improve the HID API a little here. The graphics API work I'm doing could remove part of the the need to have the layer on / off status in the core (for rendering at least), but the autorouter(s) use it to determine which layers to route on, and various other bits of code (including object selection) seem to care. Perhaps the easier option would be to contractually ban the core from assigning layer visibilities. That would mean banning or moving some of the misc.c APIs which touch that. Best wishes, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me)
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ geda-user mailing list geda-user@xxxxxxxxxxxxxx http://www.seul.org/cgi-bin/mailman/listinfo/geda-user