Hi Jon,

Anything that requires access to the schematic objects is going to get
changed so if you don't mind the disruptions to your work then feel work
on things like your autorouter.  If you don't need access to the
schematic objects such as your color selection, then I would think the
probability of conflicts would be low.  Keep in mind during the next
development cycle (version 6), any new tools will have to be ported to
the new toolkit.



On 12/1/2016 10:38 AM, Jon Evans wrote:
> Hi Orson,
> Thanks much for your feedback and news about plans for eeschema.
> I agree that having a common codebase for selection filtering and object
> inspection across the tools is a great idea (especially since the
> roadmap has plans for eventually combining the tools more than they are
> today).
> By "intelligent autorouter" in schematic editor, I meant that some of
> the high-end commercial tools have nicer ways to input wires and buses
> that act somewhat like an autorouter would for a PCB, meaning there are
> certain rules that can be set about how wires/buses should look (i.e.
> must be H/V, must not overlap existing wires, etc), and if you are
> drawing new wires in "auto" mode, you can simply pick two points to wire
> between (i.e. two pins, or a pin and existing wire, etc) and the program
> will draw a wire between them that meets the rules if possible.
> Of course this requires some tuning and tweaking to be user-friendly,
> because the constraints are different -- a PCB autorouter can fail and
> tell the user it isn't possible to route a net.  The schematic wire
> "autorouter" must always place a trace, and the "autorouting" is about
> making it visually the "best" looking.
> I have some more concrete examples in my head, and I think I will try to
> put together some examples to show more about what I mean and how my
> proposal would work in eeschema.  But basically, I think we can get a
> lot closer to the designer saying "I want to connect X to Y" and having
> to spend minimal mental energy on picking each corner of the wire, much
> like the P&S router is designed to reduce mental energy of routing the PCB.
> Best,
> Jon
> On Thu, Dec 1, 2016 at 10:28 AM, Maciej Sumiński
> <maciej.sumin...@cern.ch <mailto:maciej.sumin...@cern.ch>> wrote:
>     Hi Jon,
>     We really appreciate your offer. I am quite positive that most of people
>     here would admit that KiCad begs for some UX improvements.
>     GALifying eeschema is going to be a significant refactor, but it will
>     not happen before v5 release, which is currently planned for Feb 2017.
>     IIRC Wayne works on the new file format. I have in my stash some changes
>     to the symbol library editor (I hope to publish them soon for testing).
>     The on-going work does not seem to collide with your proposal, unless
>     there are other plans I am not aware about.
>     During a recent KiCad hackathon [1] Oswaldo has volunteered [2] to work
>     on the Selection Filter for pcbnew. I wonder if it would be possible to
>     write code generic enough to handle schematic & layout editors or at
>     least have a common base. Combined with the Object Inspector, which is
>     also supposed to work with eeschema at one point, it creates a really
>     powerful toolset.
>     Would you elaborate on the "intelligent autorouter" idea?
>     Regards,
>     Orson
>     1. http://www.ohwr.org/projects/cern-kicad/wiki/Hackathon-ehal
>     <http://www.ohwr.org/projects/cern-kicad/wiki/Hackathon-ehal>
>     2. https://lists.launchpad.net/kicad-developers/msg26722.html
>     <https://lists.launchpad.net/kicad-developers/msg26722.html>
>     On 12/01/2016 02:54 AM, Jon Evans wrote:
>     > Hi all,
>     >
>     > I am an EE and sometimes software developer who has wanted to
>     contribute to
>     > KiCad for a while and finally might have some time to do things. 
>     I am kind
>     > of excited about UI/UX improvement possibilities, and have been
>     compiling a
>     > list of things that I might want to work on at some point or at
>     least just
>     > poke at to get familiar with the codebase.
>     >
>     > I know a big refactor of eeschema is planned/in progress.  Can the
>     people
>     > working on that please advise whether it makes sense for me to
>     work on any
>     > of the things in the following list, or if it would be likely to
>     be wasted
>     > effort based on what will likely change in the refactor?
>     >
>     > - Improvements to wire / bus routing: several bugs here and also some
>     > wishlist items (H/V restriction working in drag mode,
>     > auto-connection/junction creation at points on a wire that aren't the
>     > endpoints, "intelligent autorouter" for schematic wires, fix wires
>     after
>     > drag, etc)
>     > - Selection filtering (select anything vs. only components, wires,
>     text,
>     > etc)
>     > - Color system improvements -- arbitrary color picker, color
>     themes, etc.
>     > - Drag selection mode option -- select anything touching vs.
>     select things
>     > completely enclosed by drag area
>     >
>     >
>     > Thanks,
>     > Jon
> _______________________________________________
> 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

Reply via email to