kicad-developers team mailing list archive

[hauptmech <hauptmech@xxxxxxxxx>]

I know the use case is implied in this thread, and the only real need 
before 5 is to fix the blatant bugs, but I thought it might be helpful 
to explicitly state the use case.

A PCB layout has too much information for it to be displayed all 
together on the screen at once. The user (or the workflow) needs to 
limit the displayed info to what is relevant to the job at hand and 
remove the info that obscures or causes confusion.

Tasks to be done (among many) include:

_ solve the topology problem of where to have copper. Beyond simple 
connectivity, there are thermal, inductive, capacitive, and even visual 
design problems to be solved and different people have ways of getting 
their head around this.

_ check for errors or DFM issues. DRC helps but is not yet fine-grained 
enough to do it all. A visual review all manufacturing info is part of 
many peoples process.

_ lay out on-board documentation; typically copper or silkscreen, both 
of which are affected by the mask layer.

_ Add/review design notes for self or others

_ Transfer info from parts to the designer, some of which kicad supports 
(courtyards) and some of which gets hacked in on auxiliary layers 
(manufacturers recommended fanout).

_ Lay out assembly documentation and act as a live view and query system 
during actual assembly

Different users will have different tasks that are important to them, 
and different groups of visibility states that they use for each task.

Ideally each user can set groups of arbitrary visibility states to 
toggle between for each task they have in an easy and intuitive manner. 
Something to consider for 6.

It's been made clear in the discussion so far that different people have 
different ideas about what is useful grouping (linking, locking). I 
don't think there is a way to do it in the current interface that will 
avoid annoying a group of people. Perhaps favor flexibility (no linking 
with the cost of extra check box clicking) over convenience for a subset.




On 19/02/18 09:00, Jon Evans wrote:
> Hi all,
>
> Right now the behavior of the "Layer" and "Render" tabs of the layers 
> widget are confusing to users, resulting in complaints on the forum 
> and some bug reports:
>
> https://bugs.launchpad.net/kicad/+bug/1748181
> https://bugs.launchpad.net/kicad/+bug/1743890
>
> I could take a crack at fixing this (before or after 5.0 depending on 
> what the complexity ends up being) but before I write any code I 
> wanted to propose how I think it should work.
>
> I think the visibility of any object should be the AND of layer 
> visibility and render visibility.
>
> To get there:
>
> 1) In the Render tab, get rid of the distinction between front/back. 
> For example "Pads Back" and "Pads Front" becomes just "Pads"
>
> 2) Change the visibility code so that an object is visible if (a) the 
> associated Render setting is turned on for the type of object, and (b) 
> at least one of the layers the object is on is enabled in the Layers tab.
>
> 3) (optionally) Rename "Render" to something more friendly like 
> "Items" or "Item Types" to make it more clear to the user that this is 
> where they can turn off the display of various types of items as 
> opposed to various layerse
>
> If this plan is OK, I will start working out the details of how to get 
> there.  Right now the Render tab is directly controlling the 
> visibility of certain "GAL Layers" but unfortunately the set of 
> objects that appears on one GAL layer is not always equal to the set 
> of objects that the user would expect to turn on and off, as seen by 
> the bug reports.  So, there will have to be some additional logic 
> created to manage these settings beyond just turning on and off layers 
> in the GAL.
>
> -Jon
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp