date:20140910

On Wed, Sep 10, 2014 at 09:33:52PM +0100, Tim Hutt wrote:
> They're not *that* different. I'd say it's more like using Solidworks if
> you've only used Pro/E. The basics are identical:

> 1. Create component footprint.
> 2. Create component symbol.
> 3. Join them together into a component.
> 4. Repeat for all components.

However just the component library architecture is vastly different from
one package to another. And many details often don't translate between
packages due to architectural differences. Like, kicad has component
libraries and footprint libraries while eagle only as one kind of
library taking both of them. In the meantime IIRC Orcad has 'technology
templates' which neither of the other two has. Zuken has a whole
different component kind for starpoints, kicad has them as an hack,
orcad really I don't know:P

You really can't *explore* these clicking around.

> 5. Place components into schematic and connect them via nets.
> 6. Translate schematic into PCB.

Forward/backward annotation? Automatic annotation? Shared data
structure? tell me how can someone 'intuit' the difference in these
different models?

> 7. Manually or automatically route traces.

... and maybe fight with the SPECCTRA interfaces :P

> 8. Export gerbers.

I think that gerber generation is the more similar step in all the CAD
I've seen around :D

> I think you're thinking of "Tip of the day", in which case you are
> absolutely right - *nobody* reads them! But people read context-sensitive
> popup hints. Every time I've seen one (which isn't often) they've been
> helpful.

Well, if you mean something like "Remember to configure the stackup and
DRC before routing the board" just after importing the netlist for the
first time, these would be useful. But some kind of tutorial (and some
kind of contextual help, like one page for dialog) would be way better.

If you have seen zuken tutorial, they go one chapter at a time with
different starting point (and premade files for the chapter starts).
They do something really simple (IIRC a BJT astable blinker)
with one file with the empty preconfigured board, one other with the
imported packages, one placed but not routed and one routed ready to
export. Then you have chapter 1 with a step-by-step package import (and
libraries premade for the tutorial), chapter 2 explaining how to place
and so on... each chapter tell how to go from one board to the following
one.

Workflow in EDA is *very* important IMHO (in fact every manual usually
starts with a diagram of the data flow between modules); another thing
are the common techniques to be used... in spreadsheet you often see
people doing sums like =A1+A2+A3+A4 instead of =SUM(A1;A4)... and these
are advanced users, common ones don't know what formulas are and do the
sum by hand writing the result in the result cell :D in the same way
when drawing a 10 cm line in pcbnew you could either a) count the dots on the
grid (I've seen that...) or b) press space and move away looking on the
status line.

I think that's the best way to teach a tool like kicad (where the
workflow is *relatively* fixed... backannotating and doing a pinswap
would be advanced techniques:D)

-- 
Lorenzo Marcantonio
Logos Srl

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Usability test.

2014-09-10 Thread Javier Serrano

On Wed, Sep 10, 2014 at 7:54 PM, Tim Hutt  wrote:

> On 10 September 2014 10:25, Javier Serrano <
> javier.serrano.par...@gmail.com> wrote:
>
> if one accepts the premise that KiCad should be very usable by a new user
>
>
> I think this is critical. It already looks like some people disagree! But
> I think they are just making excuses for Kicad.
>

Assuming I have correctly understood what you mean (English is not my
native language) I'd have to disagree with it. All the opinions I have read
here seem to me as coming from people who are genuinely convinced of what
they are saying. Everybody here wants to make KiCad better. I support the
notion that KiCad can and should improve in the usability/friendliness/etc
department because I know your case as a first time user is far from
unique, and I think that's not good for KiCad and first user experiences
could be better without making the experience worse for everybody else.
Now, discussing about these things in a mailing list this size is tricky
because all of us may have strong opinions about something and there is
lots of room for misunderstanding. So respect is key to begin with!

Cheers,

Javier

>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Usability test.

On 10 September 2014 20:57, Lorenzo Marcantonio 
wrote:

> On Wed, Sep 10, 2014 at 06:54:13PM +0100, Tim Hutt wrote:
>
> > 1. Good software has a manual. Great software doesn't need one.
>
> OK, then try set correctly some FPGA timing constraint without reading
> the manual:D Even with all the good explanatory drawing you'll get
> nowhere without the underlying theory :P
>

Well of course there are limits. EDA basics are not FPGA timing constraints
though!

>  it's more like saying "write a program in Pascal without
> reading the instructions"...
>

They're not *that* different. I'd say it's more like using Solidworks if
you've only used Pro/E. The basics are identical:

1. Create component footprint.
2. Create component symbol.
3. Join them together into a component.
4. Repeat for all components.
5. Place components into schematic and connect them via nets.
6. Translate schematic into PCB.
7. Manually or automatically route traces.
8. Export gerbers.

> Do you know someone that actually reads them? :D
>

I think you're thinking of "Tip of the day", in which case you are
absolutely right - *nobody* reads them! But people read context-sensitive
popup hints. Every time I've seen one (which isn't often) they've been
helpful.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Usability test.

On 10 September 2014 20:48, Wayne Stambaugh  wrote:

> On 9/10/2014 1:54 PM, Tim Hutt wrote:
> > On 10 September 2014 10:25, Javier Serrano
> >  > > wrote:
> >
> >  There is a big difference between commercial proprietary
> > applications and FOSS applications with no paid labor
> >
> >
> > Definitely true. I think part of the problem is that FOSS developers
> > generally develop for themselves, and once someone becomes a developer
> > they are hardly a new user! So features for new users don't get much
> > attention.
>
> How are you defining a new user?  Are you talking about someone who has
> no idea how to design and lay out a printed circuit board or are you
> talking about someone who is coming from another electronic design
> application?


Both ideally. The second is much easier of course.


> Judging by some of you comments, it seems like the former.
>  I agree that KiCad usability could be improved but I am opposed to
> adding nagware to the point where all of these things you have proposed
> start getting in the way of me getting work done.


Yeah, I would advocate a "dismiss all hints" button for experienced users
so it doesn't get annoying.

> 1. Good software has a manual. Great software doesn't need one.

>
> I disagree with you on this.  The first thing I look for with any new
> piece of software with a GUI is the list of keyboard short cuts.  If the
> I cannot get to the primary functionality of an application without
> clicking and pointing, that application will have a short life span on
> my computer.  Pointing and clicking are only user friendly to users who
> are stuck in that paradigm.


Sorry, I'm missing what keyboard short-cuts have to do with manuals?


> Every object in the schematic or board editor has a context menu
> (assuming you know what the right mouse button is used for) that
> contains all of the actions that can be performed on that object.
> Embedded in the context menu for an object are the hot keys so you don't
> have to keep using the context menu which is always slower because it
> requires more steps.


As it should be!
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Usability test.

2014-09-10 Thread Jeff Barlow


On 9/10/2014 10:54 AM, Tim Hutt wrote:

On 10 September 2014 10:25, Javier Serrano  
wrote:



if one accepts the premise that KiCad should be very usable by a new user


I think this is critical. It already looks like some people disagree!
But I think they are just making excuses for Kicad. Even complex
software can be usable for new users.


Yes, it's clearly possible. That is not to say it's the best use of very 
limited resources.


Usability (the word itself) is frequently used as a euphemism for 
"newbie friendly". They are NOT the same thing. Conflating the two ideas 
is, I suppose, valid from the point of view of the folks who are trying 
to sell proprietary software. It's important (to them) that newbies are 
not frightened away by the trial version. I think it's far less of a 
priority for kicad.


If new volunteer developers want to come on board and focus on making 
kicad more newbie friendly without negatively impacting experienced 
users that would be just fine. If instead you propose to clutter up the 
screen with a bunch of non optional talking paper clips or slow down 
development of real features I think you will meet with considerable 
resistance.

--
Later,
Jeff

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Usability test.

2014-09-10 Thread Nick Østergaard

I think Simons slide introduciton concept could be usefull. It could
well be used with the new Kicad interface Dick has been talking about
some months ago. (The python one)  But it should not be obstructing to
the normal (the expert?) user.

2014-09-10 17:48 GMT+02:00 Simon Schumann :
> On 10/09/14 11:25, Javier Serrano wrote:
> [snip]
>>
>> Watching 15 minutes of your video has been a very painful experience.
>
> Yes, utterly painful...
>
>> I could not take in the whole 30 minutes. There are clearly things
>> that could be more intuitive. Things which cannot be considered
>> controversial. I think those things could be the object of a detailed
>> work package to be included in the roadmap. Then there is the
>> controversial/religious stuff. How to copy/paste and such. I think
>> that part needs more debate, but it looks to me that if one accepts
>> the premise that KiCad should be very usable by a new user, the
>> *default* behavior for things which are done in a given way in 99% of
>> the graphical applications out there should be that de-facto-standard
>> way. And users who are expert users should know how to customize KiCad
>> in a way that maximizes their productivity. That customization could
>> very well include very fast and efficient ways of cutting, pasting,
>> moving, rotating, etc. Another option would be to try to make the two
>> types of methods co-exist at the same time. It's difficult to discuss
>> how possible this is without getting into a lot of detail. BTW, the
>> fact that KiCad is undergoing major change in several important areas
>> is not helping in the usability/coherence department. Things should be
>> better soon even without major efforts.
>>
>> The good news is that, as you say, the effort to improve in this area
>> is not that great. There is some low-hanging fruit. KiCad is already
>> very powerful, and the work on usability is probably smaller than
>> several of the big work packages people have been taking on lately. I
>> think KiCad should have a usability team as it already has people
>> concerned with libraries, documentation, etc. Same goes for testing
>> BTW. If some people (maybe also from the users list) step up for the
>> task and Wayne thinks it's a good idea, I think it could do a lot of
>> good to the project. If the idea moves forward, you can count on the
>> help of the CERN team in this domain.
>>
>> Many thanks to you and to all KiCad developers. These are exciting times
>> for us.
>>
>> Cheers,
>>
>> Javier
>>
>> [1] Search for "ergonomics" in
>>
>> http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/view/head:/Documentation/development/road-map.md
>>
> I don't think KiCAD's usability is particularly bad. The problem is that by
> simply
> clicking around it is very hard to figure out how stuff works, especially
> since every
> EDA-tool works a little different / has a different concept. In my opinion
> KiCAD
> needs to throw some guidance at the user (not hidden in a menu), otherwise
> people do trial&error and get frustrated very fast..
>
> The project window that opens on startup is pretty empty. So there would be
> plenty of space to offer some guidance. I think making a few online
> slideshows
> to cover the basics and linking them each with a nice picture in the project
> window
> could do the trick. To give you an idea of what I mean, here are a few
> sample/concept slides on how to create schematics:
> https://dl.dropboxusercontent.com/u/19005544/kicad/startersguide_mockup_00/02.html
> (Sorry for potential eye bleed, I'm wether a web developer nor a designer :P
> )
> I think these are the keys to make useful and non boring slides:
>  * Pictures (!), show where to click
>  * Short texts
>  * Embrace some shortcut usage
>
> A few of these like
>  * General workflow (tool order, components separated from footprints, etc)
>  * Small sample project (basic usage of eeschema, cvpcb, pcbnew)
>  * Creating components
>  * Creating footprints
> offered in the project window should make KiCAD rather easy for beginners.
>
> Cheers
> Simon
>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Usability test.

On Wed, Sep 10, 2014 at 06:54:13PM +0100, Tim Hutt wrote:

> 1. Good software has a manual. Great software doesn't need one.

OK, then try set correctly some FPGA timing constraint without reading
the manual:D Even with all the good explanatory drawing you'll get
nowhere without the underlying theory :P

Office suites are more or less similar to each other (because they do
the same things and actually copy one from another). EDA (and CADs in
general) are radically different both in capability and how they do
things... in some you have padstacks, in others flexible layers, in some
the footprint is tied to the component, in others there is a distinct
annotation step; there are netclasses, DRC rules, someone has DRC rules
*between* netclasses... Zuken has a component for each fscking resistor
value in each tolerance in each package so they can boast millions of
component in the library. Word processors have
margins/bold/italic/underline *all of them*. LaTeX doesn't :D Ok, that's
not fair, it's more like saying "write a program in Pascal without
reading the instructions"...

> 2. Even complex software like CAD and EDA can be made so usable it rarely
> requires a manual. Solidworks is a great example. They have clearly put a
> lot of effort into making it user friendly.

Something is user friendly only if there is a standard and conventional
way of doing things. For office suites for example, that's the one
explained in the ECDL books... what if you have a word processors which
is *not* based on the ECDL style? (Wordperfect comes to the mind, but
it's not *so* different... yet is the only program which can format
correctly on italian legal paper). However you *fail* the exam if to cut
you use shift-del or the right click menu instead of doing
menu/edit/cut. I don't know if that's a good thing...

User expectations are also somewhat different sometimes... mainframe
users are used to scroll with F7/F8 (it's a long story). We had to do
javascript to make the browser scroll with these keys. Too bad that you
couldn't intercept the right control key alone (it's the enter key for
these people). And user codes must always be of no more than 12 numeric
digits (no letters) since *everyone* used to note them on the desk
calculator :D

In the same way if you take an autocad user and give him, say, ME10 (I
forgot the name it has these days) he wouldn't even know how to draw
a line... in fact the so called 'user friendly' cad programs are usually
autocad clones (because many users expects that kind of interface, *not*
because autocad is intuitive...)

> 3. You *can* learn well-designed programs by clicking around in the
> interface. It's what most people do (obligatory: https://xkcd.com/627/ )

OK; do a click interface for all the features of emacs. I dare you :D
Easier: take all the commands of an HP-48 calculator. It's something
like 4MB of software. Even if there are menus (and lot of them) they had
to put a catalog (CAT key:D) for finding stuff (and it's actually one of
the best way to use it... the best one is creating your own menu); by
the way to make the HP-49 more 'user friendly' they made it start in
algebraic mode; *everyone* as first thing asked how to put it in RPN.

If you can learn all of them this way then there is too much UI or too
few features, IMHO. Or it's completely broken like LabView :D

> b) Qt "WhatsThis?" buttons. They are better than tooltips IMO because
> they are obviously there, and they more strongly suggest that the developer
> has actually written something useful (not something like "The mangler
> button. If clicked it activates the mangler. See help for more.").

Something like the big buttons I talked about. It's documentation after
all.

> Signpost, when you first run Kicad. There could be periodic different hints
> (and an option to disable them altogether of course).

Do you know someone that actually reads them? :D

I think that for starting up the best way would be some hands-on
tutorial, working on some prepared file... the inkscape one are cute too
(they did the tutorial in the program itself... so you have a page with
like, some example circles and a space aside to practice drawing circles
and instructions above explaining the procedure.

In the same way we could make something like a board with a pair of
components and text beside explaining how to draw tracks and such.
The full details are of course still in the manual (see section # for
complete rules and so on).

-- 
Lorenzo Marcantonio
Logos Srl

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Usability test.

2014-09-10 Thread Wayne Stambaugh

On 9/10/2014 1:54 PM, Tim Hutt wrote:
> On 10 September 2014 10:25, Javier Serrano
>  > wrote:
> 
>  There is a big difference between commercial proprietary
> applications and FOSS applications with no paid labor
> 
> 
> Definitely true. I think part of the problem is that FOSS developers
> generally develop for themselves, and once someone becomes a developer
> they are hardly a new user! So features for new users don't get much
> attention.

How are you defining a new user?  Are you talking about someone who has
no idea how to design and lay out a printed circuit board or are you
talking about someone who is coming from another electronic design
application?  Judging by some of you comments, it seems like the former.
 I agree that KiCad usability could be improved but I am opposed to
adding nagware to the point where all of these things you have proposed
start getting in the way of me getting work done.

> 
> Watching 15 minutes of your video has been a very painful experience.
> 
> 
> Sorry! Though imagine how painful it would have been with Eagle!
>  
> 
> if one accepts the premise that KiCad should be very usable by a new
> user
> 
> 
> I think this is critical. It already looks like some people disagree!
> But I think they are just making excuses for Kicad. Even complex
> software can be usable for new users. I basically 100% agree with what
> you said so I won't repeat it all.
> 
> In particular though, I strongly believe:
> 
> 1. Good software has a manual. Great software doesn't need one.

I disagree with you on this.  The first thing I look for with any new
piece of software with a GUI is the list of keyboard short cuts.  If the
I cannot get to the primary functionality of an application without
clicking and pointing, that application will have a short life span on
my computer.  Pointing and clicking are only user friendly to users who
are stuck in that paradigm.

> 
> 2. Even complex software like CAD and EDA can be made so usable it
> rarely requires a manual. Solidworks is a great example. They have
> clearly put a lot of effort into making it user friendly.
> 
> 3. You *can* learn well-designed programs by clicking around in the
> interface. It's what most people do (obligatory: https://xkcd.com/627/ )

Every object in the schematic or board editor has a context menu
(assuming you know what the right mouse button is used for) that
contains all of the actions that can be performed on that object.
Embedded in the context menu for an object are the hot keys so you don't
have to keep using the context menu which is always slower because it
requires more steps.

> 
> One of the best ways to make a program more newbie-friendly without
> really changing it is to add something like one of the following:
> 
> a) Rich tooltips.
> 
> b) Qt "WhatsThis?" buttons. They are better than tooltips IMO
> because they are obviously there, and they more strongly suggest that
> the developer has actually written something useful (not something like
> "The mangler button. If clicked it activates the mangler. See help for
> more.").
> 
>  c) "Signpost" tooltips.
> 
> Here are some (horribly photoshopped) examples:
> 
> Current tooltip:
> 
> Inline images 2
> 
> Rich tooltip (if the manual is great, why not link to it more from the UI?)
> 
> Inline images 3
> 
> Currently, the help info below is shown in an (actually helpful!)
> tooltip which I honestly only noticed when making this screenshot. If
> you check my video, I didn't notice it when I actually wanted help!
> 
> Inline images 4
> 
> It would be better if the presence of good help is made more explicit
> like this (sorry for my bad art skills):
> Inline images 5
> 
> Signpost, when you first run Kicad. There could be periodic different
> hints (and an option to disable them altogether of course).
> 
> Inline images 6
> 
> Anyway, I'm glad everyone has found this interesting and hopefully
> useful! I may make a "Usability Project" page on the wiki with links to
> particularly glaring usability bugs.
> 
> Cheers,
> 
> Tim
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Usability test.

2014-09-10 Thread Moses McKnight

I would agree with Nick. I hate popups, and checking for a preference is
trivial.

As far as usability in general, a lot of what you are talking about has more to
do with initial expectations based on other software, than actual ease of use.
Maybe "learnability" is a better term? Pressing 'C' for copy is actually easier
than pressing 'Ctrl+C', and having to click on an item before you can manipulate
it is harder than simply putting the mouse over it and pressing a hotkey.

I do think there can be improvements in the "learnability", but a lot of that
has to do with user opinion and expectations. There are also certainly
usability improvements to be made as well.

Moses

On 09/10/2014 01:57 PM, Tim Hutt wrote:

Well, I disagree! Not sure what else to say. Maybe we need polls for these
alternatives.

On 10 September 2014 19:45, Nick Østergaard mailto:oe.n...@gmail.com>> wrote:

Ohh no, never do like that. I hate that. It is not usefull at all, IMHO. I
annoys me on websites with the cookie info box, it annoys me in chrome, it
annoys me in matlab, it annoys me in simulink, it annoys me everywhere. I
rather think, that the user should think; "mmm, I don't like that zoom
method that well, maybe there is an option for it. ". Popups or curtains is not the solution.

Nick

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Rename proposal

On Wed, Sep 10, 2014 at 08:33:24PM +0200, Nick Østergaard wrote:
> Why is it that it is undesireable to have text on the copper layer? I
> have sometimes wanted to embed text in the copper, and have the flood
> fill into wher the text is, and the actual text be no copper. Is this
> a limitation with ERC, for example how to handle islands? I once tried

Yes, it's a problem with DRC. For the same reason you can't (officially)
have lines on a copper layer. The microwave tools create exactly that:P
And it's ugly to do star points with a text editor by hand (electrical
connection between two different networks). At least before you had
a big fat warning telling you "hey, that will not be seen by the DRC,
proceed at your own risk". In that way you could draw star points as
lines in the module editor and the DRC was happy since it didn't see
them :D

For some reason that capability was removed and you can't select the
copper layers anymore in the module editor.

There is another much less important reason: the module in the library lives
outside a board and don't know how many copper layers there are. Of
course that would be only a problem for inner layers (F_Cu and B_Cu are
always available).

If I could choose I'd reactivate the choice (only for F_Cu and B_Cu)
with the big fat warning. So you could add text on copper, too (it
wouldn't be seen by neither the DRC nor the zone filler, but the fat
warning say exactly that...)

-- 
Lorenzo Marcantonio
Logos Srl

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Rename proposal

On Wed, Sep 10, 2014 at 01:41:33PM -0400, Wayne Stambaugh wrote:
> Perhaps we should define the layer behavior for footprint text and
> non-footprint text first and then make the code match the behavior.  It
> seems to me once you have the behavior defined, the code should be
> fairly straight forward.  I guess the real question is do we want to
> keep the current text layer behavior or do we want to design something
> that is more flexible?

I think that the reason behind having reference/values independant from
the silk layer is that often a thick silk hide the trackage so it would
be disabled during routing. However the reference is still useful in
orientating around the board so it's possible to have silk hidden and
references shown. Value behaviour is probably the same for uniformity.
Charras could probably shed more light on that quirk. Anyway I find that
behaviour useful.

The behaviour which we are discussing however is contained in the
collector and in the draw routine, so it's not too difficult to change.
I have this assumption that user module text contains nothing too
important for the normal routing i.e. is documentation and drawing
stuff. Feel free to give a counterexample of course; I have none.
Polarity is usually obvious from the pin name. Also my workflow has all
the 'needed' layers on during placement (silk, courtyard, comments for
keepout and so on) and most stuff disabled during route (I usually keep
assembly or silk on for orientation).

As a working case let's say I have some kind of backward mount
potentiometer (the ones you screw on the board and then solder) which
has maybe some important 'take care' area (maybe for the shaft nut or
something like that). Well, I would actually put a huge supporting
copper pad for the nut, but imagine I simply want to draw a comment (to
some pair of layers F_Comment and B_Comment) to remember that is a bad
place to route stuff for ESD or whatever. That's would be quite complex
component to draw, place and route around. It would contain:

- Pads and the big hole for screwing the thing on

- On the 'front' side (where the body will be): silk for the body,
  courtyard, assembly outline, comment outline; there will be the
  mandatory reference/value fields on F_SilkS (value always hidden with
  the flag), the assembly label on F_Fab (with the to-be-implemented %R
  token) and some text saying "Be Careful Here" inside the comment area.
  Also some other text on F_SilkS to remember which wire goes where.

- On the 'back' side (where the shaft would stick out): courtyard for
  the nut, comment outline for the corresponding area; some text on 
  B_Comment saying "Careful Here, too"

To keep things simple let's say it's placed on the top side (so I'm
seeing the bottom of the pot can and the shaft sticks under the board).

The behaviour which I am implementing is as follows (as usual all
condition are and-ed; if one fails text isn't shown):

- The root of everything is the module, of course; if the modules
  front/back visible is disabled nothing is show for a module placed on
  that side (even if the text would come up on the other side);
  I sometimes would have found useful to selectively hide some module
  but that's another enhancement:P

- Then comes the text front/back visibles: they operate on all the texts
  on that side: so the "text back" would operate on the "Careful Here,
  too" text, while the "text front" on the reference, value, assembly
  label, wire silks and "Be Careful Here"

- At this point the rule is different for reference/value/user text:
  - Reference is controlled by the "References" visible, and takes color
from the "Text Front" visible (since the module is on the front
side)
  - Value is the same but controlled by the "Values" visible
  - User text is controlled by the corresponding layer control, both in
visibility and color

- The last thing is the 'hidden' flag in the text itself; if set the
  text is only visible if the "Hidden Text" visible is set (and takes
  that color);

For example the value would be visible (in Hidden Text color) only when
"Hidden Text", "Text Front" and "Module Front" are enabled. That's
*exactly* how pcbnew works today.

In the same way the "Careful Here, too" text would be shown (in
B_Comment color) only when "Module Front","Text Back" and the B_Comment
layer are enabled.

Philosophical experiment of me routing that component:

Now, let's say I've already placed the thing (with all the layers and
stuff enabled) and I go routing. The silk screen isn't really useful for
orientation since it's only a partial outline, so I turn it off. And the
wire labels disappear; no panic, I have the netlist anyway, that's meant
for the people assembling the board. Even disabling silk the reference
is still shown since it's a special field. So I can still see the name
of what I'm looking at. For orientation it's more useful the assembly
layer (which now has its own label). That's controlled by the assembly

Re: [Kicad-developers] Usability test.

Well, I disagree! Not sure what else to say. Maybe we need polls for these
alternatives.

On 10 September 2014 19:45, Nick Østergaard  wrote:

> Ohh no, never do like that. I hate that. It is not usefull at all, IMHO. I
> annoys me on websites with the cookie info box, it annoys me in chrome, it
> annoys me in matlab, it annoys me in simulink, it annoys me everywhere. I
> rather think, that the user should think; "mmm, I don't like that zoom
> method that well, maybe there is an option for it.  check for that>". Popups or curtains is not the solution.
>
> Nick
>
>
> 2014-09-10 19:59 GMT+02:00 Tim Hutt :
>
>> It's fine to like weird UI options of course, and I would never consider
>> removing the option, but I still think they should be off by default. If
>> you (whoever is in charge!) absolutely insist that they are on by default
>> then a Chrome-style info bar like this is pretty much essential IMO (shown
>> when you first zoom in):
>>
>> [image: Inline images 1]
>>
>> That's how they do it in Simulink.
>>
>>
>> On 10 September 2014 18:37, Moses McKnight  wrote:
>>
>>> I also like the center and warp on zoom, as do others I know that use
>>> kicad. The option for "newbies" to disable it is fine, but please leave it
>>> as the default!
>>>
>>> Another thing the video seemed to not "get" was that you don't have to
>>> select something first to act on it.  I actually find that a good feature
>>> as it speeds things up - even if just a little.  It might be nice to add
>>> the ability to select items as well, but please don't take away the ability
>>> to simply mouse over something and hit a hot-key.  This is one thing I find
>>> to be a regression in the OpenGL canvas.  You must be in the arrow tool,
>>> and select a track in order to delete it.  Not only that but it only
>>> selects a segment and not a track.  So I find it *much* faster to hit F9
>>> for default canvas any time I need to delete a track.
>>>
>>> Moses
>>>
>>> On 09/10/2014 12:14 PM, Lorenzo Marcantonio wrote:
>>>
 On Wed, Sep 10, 2014 at 09:46:07AM -0700, Ouabache Designworks wrote:

> Case in point you mentioned that warp to center on zoom was "weird" and
> that nobody else does it. gEDA also does it and it is really useful
> feature.
>

 Don't *dare* to touch the center warp on zoom :P

 I could write a book on how useful it is... well, I've almost done it
 the last week (see posts on the opengl view)


>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Usability test.

2014-09-10 Thread Nick Østergaard

Ohh no, never do like that. I hate that. It is not usefull at all, IMHO. I
annoys me on websites with the cookie info box, it annoys me in chrome, it
annoys me in matlab, it annoys me in simulink, it annoys me everywhere. I
rather think, that the user should think; "mmm, I don't like that zoom
method that well, maybe there is an option for it. ". Popups or curtains is not the solution.

Nick

2014-09-10 19:59 GMT+02:00 Tim Hutt :

> It's fine to like weird UI options of course, and I would never consider
> removing the option, but I still think they should be off by default. If
> you (whoever is in charge!) absolutely insist that they are on by default
> then a Chrome-style info bar like this is pretty much essential IMO (shown
> when you first zoom in):
>
> [image: Inline images 1]
>
> That's how they do it in Simulink.
>
>
> On 10 September 2014 18:37, Moses McKnight  wrote:
>
>> I also like the center and warp on zoom, as do others I know that use
>> kicad. The option for "newbies" to disable it is fine, but please leave it
>> as the default!
>>
>> Another thing the video seemed to not "get" was that you don't have to
>> select something first to act on it.  I actually find that a good feature
>> as it speeds things up - even if just a little.  It might be nice to add
>> the ability to select items as well, but please don't take away the ability
>> to simply mouse over something and hit a hot-key.  This is one thing I find
>> to be a regression in the OpenGL canvas.  You must be in the arrow tool,
>> and select a track in order to delete it.  Not only that but it only
>> selects a segment and not a track.  So I find it *much* faster to hit F9
>> for default canvas any time I need to delete a track.
>>
>> Moses
>>
>> On 09/10/2014 12:14 PM, Lorenzo Marcantonio wrote:
>>
>>> On Wed, Sep 10, 2014 at 09:46:07AM -0700, Ouabache Designworks wrote:
>>>
 Case in point you mentioned that warp to center on zoom was "weird" and
 that nobody else does it. gEDA also does it and it is really useful
 feature.

>>>
>>> Don't *dare* to touch the center warp on zoom :P
>>>
>>> I could write a book on how useful it is... well, I've almost done it
>>> the last week (see posts on the opengl view)
>>>
>>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Rename proposal

2014-09-10 Thread Nick Østergaard

2014-09-10 19:41 GMT+02:00 Wayne Stambaugh :
> On 9/10/2014 1:12 PM, Lorenzo Marcantonio wrote:
>> On Wed, Sep 10, 2014 at 05:49:27PM +0100, Brian Sidebotham wrote:
>>> Fair enough, I disagree and this just over-complicates things
>>> needlessly in my opinion. You'll have to track all of the layers that
>>> we're going to allow text to appear on in a module and limit the layer
>>> selector to that range and duplicate that in all the functions that
>>> have to deal with this - it's just more assumptions that end in
>>> disaster or limited functionality in the end.
>>>
>>> My opinion - just allow module text on any layer. Give the module
>>> designer flexibility. That way we don't need more special cases, and
>>> functions do what they say on the tin without needing
>>> IgnoreModuleTextsOnFrontIfOnSilkOrFabOrAdhesOrWhatever()
>>
>> After all this... actually we *are* going to allow text in modules on
>> every layer (except for copper probably), so it's going to be as you are
>> saying now.
>>
>> The discussion was *only* for the picker/collector which is initialized
>> by the user view controls (layers and visibles).
>>
>> Practical example: I have a module with text on B_Fab. This module is on
>> the back, so the module's layer is B_Cu. Since it's been flipped the
>> text actually appears on F_Fab.
>>
>> However:
>> - If the user has disabled bottom modules it shouldn't appear/be picked,
>>   since it's from a flipped module;
>> - If the user has disabled front text it shouldn't appear/be picked,
>>   since F_Fab (the resulting layer) is on the front;
>> - If the user has disabled F_Fab it shouldn't appear/be picked since the
>>   text layer is disabled.
>>
>> That's only for *user* text. Rules for reference/value are (in the same
>> use case)
>> - If the user has disabled bottom modules it shouldn't appear/be picked,
>>   since it's from a flipped module; (same as before)
>> - If the user has disabled *back* text it shouldn't appear/be picked,
>>   since B_Silk (the resulting layer flipping the implicit F_Silk) is on
>>   the back;
>> - Even if you disable B_Silk it's still shown... because it always
>>   worked that way :D
>>
>> Reference and value are special enough to have different rules. You can
>> only hide them disabling the corresponding module side or the
>> corresponding module text.
>>
>
> Perhaps we should define the layer behavior for footprint text and
> non-footprint text first and then make the code match the behavior.  It
> seems to me once you have the behavior defined, the code should be
> fairly straight forward.  I guess the real question is do we want to
> keep the current text layer behavior or do we want to design something
> that is more flexible?

In that regard, I wil try my luck throwing in a comment/question. I
will have a hard time contribution any further to the exact dicussion
though.

Why is it that it is undesireable to have text on the copper layer? I
have sometimes wanted to embed text in the copper, and have the flood
fill into wher the text is, and the actual text be no copper. Is this
a limitation with ERC, for example how to handle islands? I once tried
to do that in Altium, but failed to get the fill to work the way I
wanted, instead I got an ugly textbox wiht the text inside. This is
also what I see in Kicad currently. So what I want is kind of an
inverted text, which is able to connect to a filled zone.

I have worked around this issue in kicad once with the
bitmap2component tool, but this is not nice.

Nick

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Usability test.

To be honest I have got used to the mouse warping in DesignSpark, but I
think it is Stockholm syndrome!

On 10 September 2014 18:14, Lorenzo Marcantonio 
wrote:

> On Wed, Sep 10, 2014 at 09:46:07AM -0700, Ouabache Designworks wrote:
> > Case in point you mentioned that warp to center on zoom was "weird" and
> > that nobody else does it. gEDA also does it and it is really useful
> feature.
>
> Don't *dare* to touch the center warp on zoom :P
>
> I could write a book on how useful it is... well, I've almost done it
> the last week (see posts on the opengl view)
>
> --
> Lorenzo Marcantonio
> Logos Srl
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Usability test.

It's fine to like weird UI options of course, and I would never consider
removing the option, but I still think they should be off by default. If
you (whoever is in charge!) absolutely insist that they are on by default
then a Chrome-style info bar like this is pretty much essential IMO (shown
when you first zoom in):

[image: Inline images 1]

That's how they do it in Simulink.


On 10 September 2014 18:37, Moses McKnight  wrote:

> I also like the center and warp on zoom, as do others I know that use
> kicad. The option for "newbies" to disable it is fine, but please leave it
> as the default!
>
> Another thing the video seemed to not "get" was that you don't have to
> select something first to act on it.  I actually find that a good feature
> as it speeds things up - even if just a little.  It might be nice to add
> the ability to select items as well, but please don't take away the ability
> to simply mouse over something and hit a hot-key.  This is one thing I find
> to be a regression in the OpenGL canvas.  You must be in the arrow tool,
> and select a track in order to delete it.  Not only that but it only
> selects a segment and not a track.  So I find it *much* faster to hit F9
> for default canvas any time I need to delete a track.
>
> Moses
>
> On 09/10/2014 12:14 PM, Lorenzo Marcantonio wrote:
>
>> On Wed, Sep 10, 2014 at 09:46:07AM -0700, Ouabache Designworks wrote:
>>
>>> Case in point you mentioned that warp to center on zoom was "weird" and
>>> that nobody else does it. gEDA also does it and it is really useful
>>> feature.
>>>
>>
>> Don't *dare* to touch the center warp on zoom :P
>>
>> I could write a book on how useful it is... well, I've almost done it
>> the last week (see posts on the opengl view)
>>
>>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Rename proposal

2014-09-10 Thread Wayne Stambaugh

On 9/10/2014 1:12 PM, Lorenzo Marcantonio wrote:
> On Wed, Sep 10, 2014 at 05:49:27PM +0100, Brian Sidebotham wrote:
>> Fair enough, I disagree and this just over-complicates things
>> needlessly in my opinion. You'll have to track all of the layers that
>> we're going to allow text to appear on in a module and limit the layer
>> selector to that range and duplicate that in all the functions that
>> have to deal with this - it's just more assumptions that end in
>> disaster or limited functionality in the end.
>>
>> My opinion - just allow module text on any layer. Give the module
>> designer flexibility. That way we don't need more special cases, and
>> functions do what they say on the tin without needing
>> IgnoreModuleTextsOnFrontIfOnSilkOrFabOrAdhesOrWhatever()
> 
> After all this... actually we *are* going to allow text in modules on
> every layer (except for copper probably), so it's going to be as you are
> saying now.
> 
> The discussion was *only* for the picker/collector which is initialized
> by the user view controls (layers and visibles).
> 
> Practical example: I have a module with text on B_Fab. This module is on
> the back, so the module's layer is B_Cu. Since it's been flipped the
> text actually appears on F_Fab.
> 
> However:
> - If the user has disabled bottom modules it shouldn't appear/be picked,
>   since it's from a flipped module;
> - If the user has disabled front text it shouldn't appear/be picked,
>   since F_Fab (the resulting layer) is on the front;
> - If the user has disabled F_Fab it shouldn't appear/be picked since the
>   text layer is disabled.
> 
> That's only for *user* text. Rules for reference/value are (in the same
> use case)
> - If the user has disabled bottom modules it shouldn't appear/be picked,
>   since it's from a flipped module; (same as before)
> - If the user has disabled *back* text it shouldn't appear/be picked,
>   since B_Silk (the resulting layer flipping the implicit F_Silk) is on
>   the back;
> - Even if you disable B_Silk it's still shown... because it always
>   worked that way :D 
>   
> Reference and value are special enough to have different rules. You can
> only hide them disabling the corresponding module side or the
> corresponding module text.
> 

Perhaps we should define the layer behavior for footprint text and
non-footprint text first and then make the code match the behavior.  It
seems to me once you have the behavior defined, the code should be
fairly straight forward.  I guess the real question is do we want to
keep the current text layer behavior or do we want to design something
that is more flexible?

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Usability test.

2014-09-10 Thread Moses McKnight

I also like the center and warp on zoom, as do others I know that use kicad. 
The option for "newbies" to disable it is fine, but please leave it as the default!


Another thing the video seemed to not "get" was that you don't have to select 
something first to act on it.  I actually find that a good feature as it speeds 
things up - even if just a little.  It might be nice to add the ability to 
select items as well, but please don't take away the ability to simply mouse 
over something and hit a hot-key.  This is one thing I find to be a regression 
in the OpenGL canvas.  You must be in the arrow tool, and select a track in 
order to delete it.  Not only that but it only selects a segment and not a 
track.  So I find it *much* faster to hit F9 for default canvas any time I need 
to delete a track.


Moses

On 09/10/2014 12:14 PM, Lorenzo Marcantonio wrote:

On Wed, Sep 10, 2014 at 09:46:07AM -0700, Ouabache Designworks wrote:

Case in point you mentioned that warp to center on zoom was "weird" and
that nobody else does it. gEDA also does it and it is really useful feature.


Don't *dare* to touch the center warp on zoom :P

I could write a book on how useful it is... well, I've almost done it
the last week (see posts on the opengl view)



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Usability test.

On Wed, Sep 10, 2014 at 09:46:07AM -0700, Ouabache Designworks wrote:
> Case in point you mentioned that warp to center on zoom was "weird" and
> that nobody else does it. gEDA also does it and it is really useful feature.

Don't *dare* to touch the center warp on zoom :P

I could write a book on how useful it is... well, I've almost done it
the last week (see posts on the opengl view)

-- 
Lorenzo Marcantonio
Logos Srl

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Rename proposal

On Wed, Sep 10, 2014 at 05:49:27PM +0100, Brian Sidebotham wrote:
> Fair enough, I disagree and this just over-complicates things
> needlessly in my opinion. You'll have to track all of the layers that
> we're going to allow text to appear on in a module and limit the layer
> selector to that range and duplicate that in all the functions that
> have to deal with this - it's just more assumptions that end in
> disaster or limited functionality in the end.
> 
> My opinion - just allow module text on any layer. Give the module
> designer flexibility. That way we don't need more special cases, and
> functions do what they say on the tin without needing
> IgnoreModuleTextsOnFrontIfOnSilkOrFabOrAdhesOrWhatever()

After all this... actually we *are* going to allow text in modules on
every layer (except for copper probably), so it's going to be as you are
saying now.

The discussion was *only* for the picker/collector which is initialized
by the user view controls (layers and visibles).

Practical example: I have a module with text on B_Fab. This module is on
the back, so the module's layer is B_Cu. Since it's been flipped the
text actually appears on F_Fab.

However:
- If the user has disabled bottom modules it shouldn't appear/be picked,
  since it's from a flipped module;
- If the user has disabled front text it shouldn't appear/be picked,
  since F_Fab (the resulting layer) is on the front;
- If the user has disabled F_Fab it shouldn't appear/be picked since the
  text layer is disabled.

That's only for *user* text. Rules for reference/value are (in the same
use case)
- If the user has disabled bottom modules it shouldn't appear/be picked,
  since it's from a flipped module; (same as before)
- If the user has disabled *back* text it shouldn't appear/be picked,
  since B_Silk (the resulting layer flipping the implicit F_Silk) is on
  the back;
- Even if you disable B_Silk it's still shown... because it always
  worked that way :D 
  
Reference and value are special enough to have different rules. You can
only hide them disabling the corresponding module side or the
corresponding module text.

-- 
Lorenzo Marcantonio
Logos Srl

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Rename proposal

On 10 September 2014 17:31, Lorenzo Marcantonio
 wrote:
> On Wed, Sep 10, 2014 at 05:14:43PM +0100, Brian Sidebotham wrote:
>> I don't get that conclusion considering that module "text placed on a
>> front layer" is currently impossible as instead in a module it will be
>> placed on F_Silk!!
>
> Because at the moment there is *no* way to specify another layer for the
> text. Text on a module is *always* on F_SilkS and could be flipped with
> the module to B_SilkS. No other layer is possible. *Definitely* text
> can't go on F_Cu or B_Cu and probably never will for DRC issues. Only
> the module itself can be on F_Cu or B_Cu (and *only* on one of these
> two).
>
>> If you make the changes to those functions to change their behaviour
>> to exclude just module text that is on F_Cu or B_Cu then you'll also
>> need new functions to exclude all module text regardless of layer
>> based on the module being on either the Front or Back of the board and
>> fix MODULE_TOOLS::EnumeratePads.
>
> From comments in the headers and constructors the intended behaviour is
> "exclude text in front/back sides".
>
> So if I set IgnoreTextMFront it would ignore:
>
> - For a module placed on the front (F_Cu on the module)
>   Text on F_SilkS (that's the *only* case possible now) and then F_Fab,
>   F_Adhes, F_Whatever;
>
>   but, also:
>
> - For a module placed on the back: B_SilkS, B_Fab, B_Adhes, B_Whatever
>   since if a module is flipper, back text on the modules actually
>   appears on the front! Currently this situation can't happen but it
>   will in a short time and that's the reason for which you need to check
>   the text layer, not the module one.
>
> As for the pad collector, it sets both so in fact it will ignore text on
> *any* layer (independently from the layer the module is on). So
> compatibility is assured.
>
> --
> Lorenzo Marcantonio
> Logos Srl
>

Fair enough, I disagree and this just over-complicates things
needlessly in my opinion. You'll have to track all of the layers that
we're going to allow text to appear on in a module and limit the layer
selector to that range and duplicate that in all the functions that
have to deal with this - it's just more assumptions that end in
disaster or limited functionality in the end.

My opinion - just allow module text on any layer. Give the module
designer flexibility. That way we don't need more special cases, and
functions do what they say on the tin without needing
IgnoreModuleTextsOnFrontIfOnSilkOrFabOrAdhesOrWhatever()

But as you're in front of the keyboard, good luck! :D

Best Regards,

Brian.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Usability test.

2014-09-10 Thread Ouabache Designworks

Remember, you are only a newbie for a short time but will spend most of
your time as an experienced user. You want the tool to be powerful yet easy
enough to learn so that newbies don't give up before learning the tool.

You can do this with the ability to configure features so that you enable
more powerful features as you gain experience but the trade off there is
that any change requires testing a bazzillion different configurations. Not
easy to do with all volunteers.

There is also the issue that everyone has their own opinion as to what is
useful and what is not.

Case in point you mentioned that warp to center on zoom was "weird" and
that nobody else does it. gEDA also does it and it is really useful feature.

John Eaton
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Rename proposal

On Wed, Sep 10, 2014 at 05:14:43PM +0100, Brian Sidebotham wrote:
> I don't get that conclusion considering that module "text placed on a
> front layer" is currently impossible as instead in a module it will be
> placed on F_Silk!!

Because at the moment there is *no* way to specify another layer for the
text. Text on a module is *always* on F_SilkS and could be flipped with
the module to B_SilkS. No other layer is possible. *Definitely* text
can't go on F_Cu or B_Cu and probably never will for DRC issues. Only
the module itself can be on F_Cu or B_Cu (and *only* on one of these
two).

> If you make the changes to those functions to change their behaviour
> to exclude just module text that is on F_Cu or B_Cu then you'll also
> need new functions to exclude all module text regardless of layer
> based on the module being on either the Front or Back of the board and
> fix MODULE_TOOLS::EnumeratePads.

>From comments in the headers and constructors the intended behaviour is
"exclude text in front/back sides".

So if I set IgnoreTextMFront it would ignore:

- For a module placed on the front (F_Cu on the module)
  Text on F_SilkS (that's the *only* case possible now) and then F_Fab,
  F_Adhes, F_Whatever; 
  
  but, also:

- For a module placed on the back: B_SilkS, B_Fab, B_Adhes, B_Whatever
  since if a module is flipper, back text on the modules actually
  appears on the front! Currently this situation can't happen but it
  will in a short time and that's the reason for which you need to check
  the text layer, not the module one.

As for the pad collector, it sets both so in fact it will ignore text on
*any* layer (independently from the layer the module is on). So
compatibility is assured.

-- 
Lorenzo Marcantonio
Logos Srl

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Rename proposal

On 10 September 2014 16:54, Lorenzo Marcantonio
 wrote:
> On Wed, Sep 10, 2014 at 04:49:55PM +0100, Brian Sidebotham wrote:
>> The world survives on convention. If that is ours, why invent new?
>
> Because *our* convention is Front/Back. The collector itself uses it for
> pads, for example.
>
>> Good, I think we're going round in circles on a very simple couple of
>> functions with clearly defined use. :)
>
> Found the determining function with explains the intended behaviour: the
> collector constructor itself uses the show front text/show back text
> visibles to initialize them.
>
> So the meaning is "text placed on a front layer", not "text in a module
> placed on the front side".

I don't get that conclusion considering that module "text placed on a
front layer" is currently impossible as instead in a module it will be
placed on F_Silk!!

> No risk of breaking anything since, as you said, they are set in pair in
> the only non-default setting.
>
> --
> Lorenzo Marcantonio
> Logos Srl
>

I disagree, but no matter.

If you make the changes to those functions to change their behaviour
to exclude just module text that is on F_Cu or B_Cu then you'll also
need new functions to exclude all module text regardless of layer
based on the module being on either the Front or Back of the board and
fix MODULE_TOOLS::EnumeratePads.

Best Regards,

Brian.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Usability test.

On Wed, Sep 10, 2014 at 05:48:45PM +0200, Simon Schumann wrote:
> I don't think KiCAD's usability is particularly bad. The problem is that by
> simply
> clicking around it is very hard to figure out how stuff works, especially

You don't learn CADs clicking around, sorry :P if only to learn the
relationship in the library entities you need at least a little doc.

> The project window that opens on startup is pretty empty. So ther
> plenty of space to offer some guidance. I think making a few online
> slideshows
> to cover the basics and linking them each with a nice picture in the project
> window
> could do the trick. To give you an idea of what I mean, here are a few

OK, these are tutorials. Tutorials are good :D

Not sure if they have to be in the program, they risk to remember users
of a certain paperclip :P:P

And, by the way, there is a "Getting started" section in the help menu;
that could be expanded and maybe some big buttons could be placed around
in strategic places (like just after a "project new" operation)
referring to this for the novice users.

-- 
Lorenzo Marcantonio
Logos Srl

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Rename proposal

On Wed, Sep 10, 2014 at 04:49:55PM +0100, Brian Sidebotham wrote:
> The world survives on convention. If that is ours, why invent new?

Because *our* convention is Front/Back. The collector itself uses it for
pads, for example.

> Good, I think we're going round in circles on a very simple couple of
> functions with clearly defined use. :)

Found the determining function with explains the intended behaviour: the
collector constructor itself uses the show front text/show back text
visibles to initialize them.

So the meaning is "text placed on a front layer", not "text in a module
placed on the front side".

No risk of breaking anything since, as you said, they are set in pair in
the only non-default setting.

-- 
Lorenzo Marcantonio
Logos Srl

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Rename proposal

On 10 September 2014 16:14, Lorenzo Marcantonio
 wrote:
> On Wed, Sep 10, 2014 at 03:57:51PM +0100, Brian Sidebotham wrote:
>> Yep, I understood all that before I proposed the names.
>
> Then why not IgnoreMTextsOnFront and IgnoreMTextsOnBack ? Cu has no
> relationship with the meaning for the modules, it's only a coding
> artifact/convention.

The world survives on convention. If that is ours, why invent new?

>> Hopefully here you mean IsBackLayer(module->GetLayer()) otherwise
>> you're breaking stuff. I don't really have an opinion about the test
>> for the front or back layer. I don't see any ambiguity in the == F_Cu
>> or == B_Cu test against the module's layer.
>
> No, that was intended. The problem is this: first of all IsBackLayer (or
> IsFrontLayer) on the module layer is wasted since that can only be F_Cu
> or B_Cu; the semantic I asked before is, what of the following ones is
> the intended behaviour:
>
> a) text on a module, where the module is placed on the front/back side
>   (current behaviour)

this one. I mentioned that in each of my mails I think. (b) breaks the
ONLY current use of these settings as far as a quick grep suggested
anyway.

> or
>
> b) text on a module, where the text is on a layer in the front/back side
>   (since a module front mounted can be usefully have text on the back;
>   example: a reverse mount trimmer)
>
> In other words: in the proposed names IgnoreMTextsOnFront and
> IgnoreMTextsOnBack the 'OnFront' and 'OnBack' part refers to the module
> (now) or the text (possibly)?
>
> Both of these could have their use, of course.
>
>> The collector must exclude ALL text in a module (forget about what
>> layer that text is on) when IgnoreMTextsOnCopper() returns true.
>
> Need to look yet at this OnCopper predicate
>
>> If you are getting confused between text layers and module layers then
>> you can further play around with the function name to something like
>>
>> IgnoreTextInModulesOnF_Cu()
>> IgnoreTextInModulesOnB_Cu()
>
> IgnoreTextInModulesOnFront and IgnoreTextInModulesOnBack accurately
> describe the current behaviour (as I said the Cu part makes no sense).
>
> IgnoreFrontTextInModules and IgnoreBackTextInModules describes the other
> behaviour.
>
>> Yep, or at least that's what grep says!
>
> Then I'll look at it and decide the best name :P

Good, I think we're going round in circles on a very simple couple of
functions with clearly defined use. :)

Best Regards,

Brian.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Usability test.

2014-09-10 Thread Simon Schumann

On 10/09/14 11:25, Javier Serrano wrote:
[snip]

Watching 15 minutes of your video has been a very painful experience.

Yes, utterly painful...

I could not take in the whole 30 minutes. There are clearly things
that could be more intuitive. Things which cannot be considered
controversial. I think those things could be the object of a detailed
work package to be included in the roadmap. Then there is the
controversial/religious stuff. How to copy/paste and such. I think
that part needs more debate, but it looks to me that if one accepts
the premise that KiCad should be very usable by a new user, the
*default* behavior for things which are done in a given way in 99% of
the graphical applications out there should be that de-facto-standard
way. And users who are expert users should know how to customize KiCad
in a way that maximizes their productivity. That customization could
very well include very fast and efficient ways of cutting, pasting,
moving, rotating, etc. Another option would be to try to make the two
types of methods co-exist at the same time. It's difficult to discuss
how possible this is without getting into a lot of detail. BTW, the
fact that KiCad is undergoing major change in several important areas
is not helping in the usability/coherence department. Things should be
better soon even without major efforts.

The good news is that, as you say, the effort to improve in this area
is not that great. There is some low-hanging fruit. KiCad is already
very powerful, and the work on usability is probably smaller than
several of the big work packages people have been taking on lately. I
think KiCad should have a usability team as it already has people
concerned with libraries, documentation, etc. Same goes for testing
BTW. If some people (maybe also from the users list) step up for the
task and Wayne thinks it's a good idea, I think it could do a lot of
good to the project. If the idea moves forward, you can count on the
help of the CERN team in this domain.

Many thanks to you and to all KiCad developers. These are exciting times for us.

Cheers,

Javier

[1] Search for "ergonomics" in
http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/view/head:/Documentation/development/road-map.md

I don't think KiCAD's usability is particularly bad. The problem is that
by simply
clicking around it is very hard to figure out how stuff works,
especially since every
EDA-tool works a little different / has a different concept. In my
opinion KiCAD

needs to throw some guidance at the user (not hidden in a menu), otherwise
people do trial&error and get frustrated very fast..

The project window that opens on startup is pretty empty. So there would be
plenty of space to offer some guidance. I think making a few online
slideshows
to cover the basics and linking them each with a nice picture in the
project window

could do the trick. To give you an idea of what I mean, here are a few
sample/concept slides on how to create schematics:
https://dl.dropboxusercontent.com/u/19005544/kicad/startersguide_mockup_00/02.html
(Sorry for potential eye bleed, I'm wether a web developer nor a
designer :P )

I think these are the keys to make useful and non boring slides:
* Pictures (!), show where to click
* Short texts
* Embrace some shortcut usage

A few of these like
* General workflow (tool order, components separated from footprints, etc)
* Small sample project (basic usage of eeschema, cvpcb, pcbnew)
* Creating components
* Creating footprints
offered in the project window should make KiCAD rather easy for beginners.

Cheers
Simon

Re: [Kicad-developers] Rename proposal

On Wed, Sep 10, 2014 at 05:28:23PM +0200, jp charras wrote:
> In fact these names come from French usage:
> the Front or top side of a board is named component side ("coté composant")
> and
> the Back side or bottom side of this board is named copper side or
> solder side ("coté cuivre" or "coté soudure")

I imagined something like that, it's *still* called that way even in
Italy...

> It is not a reference to a copper layer.
> 
> But for English speakers, component side or copper side is not a good name.

Well, I've seen them called Component Side and Copper Side, since when
board where single sided with only THT it was unambiguos. These days
however it's better to call them Top/Bottom or Front/Back since there is
copper (and ofter components, too) on both sides.

IPC by the way call them 'primary access side' and 'secondary access
side', in the D356 standard (for nailbeds or moving probe testers),
probably because since board are easily flipped even front/back is not
clear enough...

-- 
Lorenzo Marcantonio
Logos Srl

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Rename proposal

2014-09-10 Thread jp charras

Le 10/09/2014 08:49, Lorenzo Marcantonio a écrit :
> While inspecting for text module usage, I found a couple of call which
> (for a little) puzzled me :D
> 
> IgnoreMTextsOnCopper and IgnoreMTextsOnCmp in the collector 'guide'
> class. At first I tought the first was referring to actual copper layers :P
> 
> Then I realized they referred to board sides... wouldn't they better be
> called IgnoreMTextsOnFront and IgnoreMTextsOnBack ?
> 
> Also what is their supposed semantic? At the moment since text on
> modules is only on SilkTop the collector simply checks for the module
> side. But the idea is that modules could have text on other layers too,
> possibly on the other side. Is that predicate meant only to act on silk
> text or on other text too?
> 
> Just a design decision. In the meantime I'll add them to the list of
> things to inspect to gleam the *actual* usage. Of course the same
> proposal holds for IgnoreModulesOnCu and IgnoreModulesOnCmp (given how
> many board are dual populated it's difficult to tell the copper side
> from the component side...)
> 


I agree these names are not good:

IgnoreMTextsOnCmp  or IgnoreModulesOnCmp should be
IgnoreMTextsOnFrontSide  or IgnoreModulesOnFrontSide

IgnoreMTextsOnCu  or IgnoreModulesOnCu should be
IgnoreMTextsOnBackSide  or IgnoreModulesOnBackSide

In fact these names come from French usage:
the Front or top side of a board is named component side ("coté composant")
and
the Back side or bottom side of this board is named copper side or
solder side ("coté cuivre" or "coté soudure")

It is not a reference to a copper layer.

But for English speakers, component side or copper side is not a good name.

-- 
Jean-Pierre CHARRAS

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Rename proposal

On Wed, Sep 10, 2014 at 03:57:51PM +0100, Brian Sidebotham wrote:
> Yep, I understood all that before I proposed the names.

Then why not IgnoreMTextsOnFront and IgnoreMTextsOnBack ? Cu has no
relationship with the meaning for the modules, it's only a coding
artifact/convention.

> Hopefully here you mean IsBackLayer(module->GetLayer()) otherwise
> you're breaking stuff. I don't really have an opinion about the test
> for the front or back layer. I don't see any ambiguity in the == F_Cu
> or == B_Cu test against the module's layer.

No, that was intended. The problem is this: first of all IsBackLayer (or
IsFrontLayer) on the module layer is wasted since that can only be F_Cu
or B_Cu; the semantic I asked before is, what of the following ones is
the intended behaviour:

a) text on a module, where the module is placed on the front/back side
  (current behaviour)

or 

b) text on a module, where the text is on a layer in the front/back side
  (since a module front mounted can be usefully have text on the back;
  example: a reverse mount trimmer)

In other words: in the proposed names IgnoreMTextsOnFront and
IgnoreMTextsOnBack the 'OnFront' and 'OnBack' part refers to the module
(now) or the text (possibly)?

Both of these could have their use, of course.

> The collector must exclude ALL text in a module (forget about what
> layer that text is on) when IgnoreMTextsOnCopper() returns true.

Need to look yet at this OnCopper predicate

> If you are getting confused between text layers and module layers then
> you can further play around with the function name to something like
> 
> IgnoreTextInModulesOnF_Cu()
> IgnoreTextInModulesOnB_Cu()

IgnoreTextInModulesOnFront and IgnoreTextInModulesOnBack accurately
describe the current behaviour (as I said the Cu part makes no sense).

IgnoreFrontTextInModules and IgnoreBackTextInModules describes the other
behaviour.

> Yep, or at least that's what grep says!

Then I'll look at it and decide the best name :P

-- 
Lorenzo Marcantonio
Logos Srl

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Rename proposal

On 10 September 2014 14:56, Lorenzo Marcantonio
 wrote:
> On Wed, Sep 10, 2014 at 02:20:48PM +0100, Brian Sidebotham wrote:
>> I think the rename should be done, but I think we should probably end up 
>> with:
>>
>> IgnoreMTextsOnF_Cu
>> IgnoreMTextsOnB_Cu
>>
>> because the constants F_Cu and B_Cu are compared when looking for the
>> layer generally in the same test. For example in collectors.cpp:296
>> and collectors.cpp:299:
>
> BE CAREFUL. On module objects the layer can only be F_Cu and B_Cu, indicating
> that the module is mounted on the front or the back side. It doesn't
> mean "Module texts on Front Copper", it means "Texts on modules mountend
> on the front side". It's a silly overload of the layer slot, but it's
> historic now :D in reality the module IS-NOT-A BOARD_ITEM in the strict
> sense (since it's more like a container), but that's how it's modelled
> at the moment.

Yep, I understood all that before I proposed the names.

>> the F_Cu layer we should ignore it if the IgnoreMTextsOnCmp() function
>> returns true.
>
> My opinion is the same. The condition would change from
> module->GetLayer()==B_Cu to IsBackLayer(textitem->GetLayer()) or
> something similar (to handle modules with text on their back). However
> I'll need to inspect actual usage of these predicate to verify that's
> the intended behaviour.

Hopefully here you mean IsBackLayer(module->GetLayer()) otherwise
you're breaking stuff. I don't really have an opinion about the test
for the front or back layer. I don't see any ambiguity in the == F_Cu
or == B_Cu test against the module's layer.

The collector must exclude ALL text in a module (forget about what
layer that text is on) when IgnoreMTextsOnCopper() returns true.

If you are getting confused between text layers and module layers then
you can further play around with the function name to something like

IgnoreTextInModulesOnF_Cu()
IgnoreTextInModulesOnB_Cu()

Which more accurately describes their meaning. But then I thought the
previous effort was pretty obvious too. :P

Along with this, we can also expand the doxygen text for these
functions to describe their meaning more verbosely such that we're all
aware of their intention.

>> These functions are actually only used when collecting (enumerating)
>> pads anyway and is used to disregard all module text items. So the
>> functionality will break that tool if we change it's meaning to not
>> ignore all module texts.
>
> It used only for that? Easy to check then :D

Yep, or at least that's what grep says!

Best Regards,

Brian.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Rename proposal

On Wed, Sep 10, 2014 at 02:20:48PM +0100, Brian Sidebotham wrote:
> I think the rename should be done, but I think we should probably end up with:
> 
> IgnoreMTextsOnF_Cu
> IgnoreMTextsOnB_Cu
> 
> because the constants F_Cu and B_Cu are compared when looking for the
> layer generally in the same test. For example in collectors.cpp:296
> and collectors.cpp:299:

BE CAREFUL. On module objects the layer can only be F_Cu and B_Cu, indicating
that the module is mounted on the front or the back side. It doesn't
mean "Module texts on Front Copper", it means "Texts on modules mountend
on the front side". It's a silly overload of the layer slot, but it's
historic now :D in reality the module IS-NOT-A BOARD_ITEM in the strict
sense (since it's more like a container), but that's how it's modelled
at the moment.

Also, at the moment module texts simply can't be on F_Cu (and probably
neither tomorrow) but only on F_SilkS (and B_SilkS, but only after
flipping the whole module). So, ATM when a module has layer F_Cu it's
texts are always on F_SilkS; in the same way a module on B_Cu has texts
always on B_Silks. This is *not* ensured as invariant or other; it's
simply that the editor at the moment creates text only on F_SilkS and
the flip code obviously only flip both of them.

Even today you could simply hand edit the file to put the text on
another layer and *almost everything* would work correctly (from what
I've seen till now)

> if( m_Guide->IgnoreMTextsOnCopper() && module->GetLayer()==B_Cu )
> 
> if( m_Guide->IgnoreMTextsOnCmp() && module->GetLayer()==F_Cu )
> 
> Secondly, I think the above tests in the collector should remain true.
> If the PCB item is text and it belongs to a module that is placed on

Careful #2: PCB text items are quite different from module text items (a
whole another class) since they live directly on the board.
However module text IS-A board item (probably because it was easier to
handle) so you are saying a correct thing anyway.

> the F_Cu layer we should ignore it if the IgnoreMTextsOnCmp() function
> returns true.

My opinion is the same. The condition would change from
module->GetLayer()==B_Cu to IsBackLayer(textitem->GetLayer()) or
something similar (to handle modules with text on their back). However
I'll need to inspect actual usage of these predicate to verify that's
the intended behaviour.

> These functions are actually only used when collecting (enumerating)
> pads anyway and is used to disregard all module text items. So the
> functionality will break that tool if we change it's meaning to not
> ignore all module texts.

It used only for that? Easy to check then :D

-- 
Lorenzo Marcantonio
Logos Srl

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Newcomer

2014-09-10 Thread Benoît Roehr

To speak frankly, Altium is looking very good !

It was not really that functionalities were lacking, I just hadn't had the
time to dig into it properly. For what I remember I tried different EDAs at
this time: Eagle, Proteus, KiCad, gEDA. The boss in the company I worked
for decided to stick to Proteus rather than switching to Altium, and KiCad
were not looking better than Proteus or Eagle. I decided to stick to Altium
for my personal projects, waiting for KiCad to improve. Now is the time ;)

A+,
Benoît

2014-09-10 15:06 GMT+02:00 A. V. Dolganoff :

> Salut to fellow Frenchie ;)
>
> Can you elaborate more on what aspects of Kicad you didn't like the
> most the last time?
>
> a+, Alexei.
>
> On Wed, Sep 10, 2014 at 3:02 PM, Benoît Roehr 
> wrote:
> > Hello everyone,
> >
> > First of all I really want to thank you all for the great improvements
> KiCad
> > had recently. The last time I tried to use it (about a year ago) I made
> the
> > decision to return to Altium because of the lake of important features.
> >
> > Now that CERN is also on board, switching to KiCad, helping and following
> > the development sounds really exciting :}
> >
> > A bit about me: I live in Strasbourg and I work for the Strasbourg
> > University in Cronenbourg as an electronic technician since one week.
> Before
> > that I was one of the head hardware designer of Ideovitra, and I worked
> on
> > the sensybee products for two years.
> >
> > My competences are quite wide: schematic capture and routing, board
> > prototyping and repairing, python, LabView and C++... I haven't done a
> lot
> > of code for computers, as I mostly make program for microcontrollers.
> >
> > I would be really glade to participate in the development of KiCad. I
> used
> > Altium a lot and at the moment it is still my favorite EDA, but Altium is
> > far from perfect. For example, the library management is very daunting,
> and
> > of course, it's not free and opensource.
> >
> > These next days, I will think about a project I could realize with KiCad
> to
> > take it on hand and dig into while keeping notes about what could be
> > improved, and/or bugs.
> >
> > Also, if help is needed somewhere else, just tell me what I can do I will
> > help, for sure.
> >
> > Cheers,
> > Benoît
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Rename proposal