kicad-developers team mailing list archive

[Jeff Young <jeff@xxxxxxxxx>]

There’s some great stuff in here though on some of the topics we are doing.  I’m not sure how best to work in to the email discussions that are bound to come up, but I’ve flagged it in my email inbox.

Cheers,
Jeff.

Oh, and for what it’s worth, our main UI guy spent 25 years at Adobe, and uses JetBrains for Kicad development. ;)

> On 2 Dec 2019, at 18:56, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
> 
> Hi Ruth,
> 
> Feedback is always welcome.  For V6, I'm trying to keep us on track for
> the road map items as they stand.  Rehashing these goals at the moment
> would be counter productive but I'm certainly willing to entertain your
> suggestion once we've released V6.  For future reference, please post
> one email per topic.  I know this is more work from your perspective but
> there is no way to manage an email thread covering every topic you
> mentioned.
> 
> Thanks,
> 
> Wayne
> 
> On 11/29/19 1:28 PM, Ruth Ivimey-Cook wrote:
>> Hi,
>> 
>> On 29/11/2019 13:56, Wayne Stambaugh wrote:
>>> It's not as up to date as it should be but it's pretty close
>>> 
>>> https://docs.kicad-pcb.org/doxygen/v6_road_map.html
>> 
>> I'm hoping some feedback on these goals would be welcomed:
>> 
>> 
>>>    User Interface Modernization
>>> 
>>> *Goal:*
>>> 
>>> Give KiCad a more modern user interface with dockable tool bars and
>>> windows. Create perspectives to allow users to arrange dockable
>>> windows as they prefer.
>>> 
>> Even though v5.1 is better than v5, and v5 better than v4, this is welcomed.
>> 
>>> *Task:*
>>> 
>>>  * Take advantage of the advanced UI features in wxAui such as
>>>    detaching and hiding.
>>> 
>> The Adobe tools (Photoshop, InDesign et al) have the idea of preset
>> workspaces, which are not prescriptive and do not imply anything about
>> the way the product works, but are simply arrangements of windows, etc,
>> that make sense for the named tasks. I find them helpful when I want to
>> "switch mode", whereas I'm happy to do manual changes inline as I work.
>> I would encourage KiCad to explore this idea too.
>> 
>>>  * Develop a global shortcut manager that allows the user assign
>>>    arbitrary shortcuts for any tool or action.
>>> 
>> Definitely looking forward to this as well. Can I suggest, as for
>> workspaces, that keymaps can be grouped and labelled and easily switched
>> between, so that we can have the legacy keymap for those who don't want
>> to change, the new keymap, and named custom keymaps. This will make life
>> so much easier for users and devs alike.
>> 
>> I would most *definitely recommend* anyone doing UI work on either of
>> these topics to explore the JetBrains tools, some of which (e.g.
>> PyCharm) have free editions. I very much like their way of setting up
>> Keymaps (Preferences), and of being able to search for an action by name
>> and invoke it immediately and/or see where it is in the menu (Help
>> menu). I also really like the "search for setting" implementation in the
>> Preferences window.
>> 
>> I'm not so keen on the JetBrains implementation of floating / docked etc
>> windows, which I think was much better done in Visual Studio
>> (traditional version). Adobe does several things right in this area as
>> well, and IMO it's not clear whether Visual Studio or Photoshop has the
>> better "docking window" implementation.
>> 
>> See:
>> 
>>  * https://www.jetbrains.com/pycharm/download/  (PyCharm Community ed.
>>    is free to use).
>>  * https://visualstudio.microsoft.com/  (Visual Studio Community 2019)
>>  * https://www.adobe.com/uk/products/photoshop/free-trial-download.html  (Adobe
>>    Photoshop CC free trial download)
>> 
>> 
>>>    Implement Sweet (S-Expression) Symbol Libraries  / + / 
>>>    S-Expression File Format
>>> 
>>> *Goal:*
>>> 
>>> Make schematic file format more readable, add new features, and take
>>> advantage of the s-expression parser and formatter capability used in
>>> Pcbnew.
>>> 
>> Just a comment about the file format: *please*, please ensure that there
>> is a defined order for writing 'things' in a collection to file.
>> 
>> This is so that loading a project, making some change, and then saving
>> it again only changes lines in the output file(s) directly related to to
>> change. This so that source control tools like git can track actual
>> differences, without being obscured by other, inconsequential ones.
>> 
>> I say this because it seems to me that v5 reads into an unordered
>> collection and therefore writes it out unordered, so writing the "same"
>> file again may change 90% of it by "chance".
>> 
>> To do this, I think the various file writer implementations must:
>> 
>>   - for every collection/list/set/group, the order of things read in
>> from a file must be retained when written out.
>> 
>>   - even when there is flexibility in the file format to reorder data
>> chunks, that once a file is read in this order does not change when
>> written again (of course, it could be the same order every time).
>> 
>>   - items in the file should not be labelled with transient IDs (e.g.
>> the component reference numbers are ok, but a number that is just a
>> sequence number for this save is not). This so that inserting something
>> doesn't result in every item after that being "changed" because its
>> sequence number is now incremented. User-visible changes (reference
>> numbers) would be ok: you really are changing lots of things from the
>> user perspective.
>> 
>>   - where possible, line breaks should be inserted so that user-visible
>> properties that change can be diffed showing just that change and not
>> the whole entity. E.g. if the type of a component changes but nothing
>> else, you see a diff of the form:
>> 
>>    - type: old name
>> 
>>    + type: new name
>> 
>> There may be more, but those are the basics.
>> 
>> 
>>>    Allow Use of System Fonts
>>> 
>>> *Goal:*
>>> 
>>> Currently the schematic editor uses the stroke drawn fonts which
>>> aren't really necessary for accurate printing of schematics. Allow the
>>> use of system fonts for schematic text.
>>> 
>>> *Task:*
>>> 
>>>  * Determine which library for font handling makes the most sense,
>>>    wxWidgets or freetype.
>>>  * Add support for selecting text object fonts.
>>> 
>> I would suggest freetype2, on the basis that it is widely portable and
>> used widely as well, unless using "native" wxWidgets provides a
>> significant integration advantage.
>> 
>> I would be interested to know why it is not possible/good to use
>> "normal" outline fonts (ttf, otf et al) on a PCB.... what are the issues?
>> 
>>> 
>>>    Custom Wire and Bus Attributes
>>> 
>>> *Goal:*
>>> 
>>> Allow for wires and buses to have different widths, colors, and line
>>> types.
>>> 
>> Would this mean that we could have named "wire styles", which we can
>> draw on the diagram and the properties of the drawn wire are taken from
>> the style definition? I'm thinking something like "character styles" on
>> a wordprocessor defining things like font and colour.
>> 
>> The advantage: if you use one wire style for e.g. power, one for e.g.
>> RF, you can easily change them.
>> 
>> Bonus points to be had if a style change to e.g. width could cause the
>> router to rejiggle the wires to fit!
>> 
>> [Thought applies to both Schematic and PCB editors]
>> 
>> 
>>>    ERC Improvements
>>> 
>>> *Goal:*
>>> 
>>> Improve ERC test coverage and other ERC usability features.
>>> 
>>> *Task:*
>>> 
>>>  * Add missing ERC tests to improve coverage.
>>>  * Save ERC settings in project file.
>>>  * Add mechanism to allow import and export of ERC settings.
>>>  * ERC user interface improvements.
>>> 
>> Could we have a method to mark particular rule violations as being
>> acceptable, where it has been determined that although the rule has been
>> broken that in this case there is no problem?  Not sure how the UI
>> should work. Probably mostly UI thing - the checker can still flag
>> these, and then some are suppressed.
>> 
>> 
>>>  Pcbnew: Circuit Board Editor
>>> 
>>> This section covers the source code of the board editing application
>>> Pcbnew.
>>> 
>>> 
>>>    Push and Shove Router Improvements
>>> 
>>> *Goal:*
>>> 
>>> Add finishing touches to push and shove router.
>>> 
>>> *Task:*
>>> 
>>>  * Delete and backspace in idle mode
>>>  * Differential pair clearance fixes.
>>>  * Differential pair optimizer improvements (recognize differential
>>>    pairs)
>>> 
>> Might this include being able to select two traces and tell it "those
>> are supposed to be DPs"?
>>> 
>>>  * Respect trace/via locking!
>>>  * Keep out zone support.
>>>  * Microwave tools to be added as parameterized shapes generated by
>>>    Python scripts.
>>>  * BGA fan out support.
>>>  * Drag footprints with traces connected.
>>> 
>> I'm not sure if it's been dealt with already but one of the issues I
>> struggle with is that component boundaries are the enclosing box, and
>> components cannot (AFAIK) be marked as not selectable. For example, I
>> have a "component" which is the outline of a daughterboard (for a BB
>> Black). The component ensures the relation between the edge cuts and the
>> connector footprint is maintained. However, on more than one occasion I
>> have messed up the board badly by moving the board component without
>> realizing it.
>> 
>> I have two requests from this situation:
>> 
>> 1.  I would /really/ like to be able to lock components in place,
>> preventing them from being moved (or even selected) until unlocked. Lock
>> = select and "Lock", Unlocking might be done with a separate list of
>> locked items, or with a UI action that unlocks anything in a drawn area,
>> or by an Unlock All action.
>> 
>> 2.  I would like the selection code to prefer selecting items by visible
>> artefact, e.g. a line or some text, and only if there is no such
>> artefact under the cursor to consider things nearby. I'm particularly
>> thinking here of clicking on an component placed beside e.g. an IC
>> footprint, though not on it. If the component is under the cursor then
>> that should be selected directly even if the cursor is also within the
>> bounding box of the IC.
>> 
>> 
>>>    Design Rule Check (DRC) Improvements.
>>> 
>>> *Goal:*
>>> 
>>> Create additional DRC
>>> <https://docs.kicad-pcb.org/doxygen/classDRC.html> tests for improved
>>> error checking.
>>> 
>> As for ERC, a way to mark specific violations as acceptable.
>> 
>>> 
>>>    Track Refining
>>> 
>>> *Goal:*
>>> 
>>> Add support for teardrops and automatically updating length tuning
>>> meandering.
>>> 
>>> *Task:*
>>> 
>>>  * Draft specification for track refining.
>>>  * Implement support for teardrops.
>>>  * Implement support for changing tuned length meandering.
>>> 
>> Could this include annotating track lengths onto the tracks -- that is,
>> include the length of a track next to the net label?
>> 
>> Would it be possible to have a view mode that highlighted EMR from track
>> shapes? E.g. for a sharp bend it would annotate the 'point' of the bend.
>> I'm a bit out of my depth on what is possible but I hope you get the
>> idea. The overall purpose is to show where any EM problems are likely to be.
>> 
>> It would also be interesting to see some sort of heat map view - that
>> is, take the specified track width and thickness and colour-map the
>> traces with the predicted resistance (and possibly, given info about
>> voltages somehow, current).
>> 
>> 
>>>    Groups and Rooms
>>> 
>>> *Goal:*
>>> 
>>> Support grouping board objects into reusable snippets.
>>> 
>> Is this the pcb editor's equivalent of the schematic editor's
>> possible-but-difficult to arrange multiple-linking of one circuit onto a
>> parent, so I can have one schematic of, e.g. a preamp and use that
>> several times, one for each channel? That would be cool!
>> 
>> Can we have a nice UI for it in schematic as well?
>> 
>> Is there scope for "exceptions" -- the layout is repeated except for
>> this component or that trace? E.g. a multiband filter that has a
>> resistor defining the frequency, or E.g. channel linking traces go
>> "here" to join up, except for the end one, which goes "there".
>> 
>> 
>> *Related*:
>> 
>> What is the status of multi-board projects (e.g. main + daughter board).
>> 
>> What is the status of defining off-board links, e.g. where the project
>> board signals link in some way on the main board, but the main board is
>> not in the project? This is more about ERC/DRC checks than anything else.
>> 
>> 
>>>    Thermal Relief Improvements
>>> 
>>> *Goal:*
>>> 
>>> Allow for custom thermal reliefs in zones and custom pad shapes.
>>> 
>> I have seen cases where automatic thermal reliefs interact badly with
>> board traces to create nice sharp corners and etching holes. It would be
>> good if the TR code could check for such issues and possibly fix them.
>> 
>>> 
>>>    3D Model Improvements
>>> 
>>> *Goal:*
>>> 
>>> Add opacity to 3D model support and convert from path look up to
>>> library table to access 3D models.
>>> 
>>> *Task:*-
>>> 
>>>  * Add opacity support to footprint library file format.
>>>  * Add library table 3D model support to footprint library file format.
>>>  * Create remapping utility to map from path look up to library table
>>>    look up.
>>>  * Add user interface support for 3D model opacity.
>>>  * Add user interface support accessing 3D models via library table.
>>> 
>> Any chance of being able to view-time modify 3d models parameters, e.g.
>> the colour of metal or plastic, or its reflectance? It would be nice to
>> be able to get a white plastic connector representing a part when the
>> standard model was black, for example.
>> 
>> 
> 
> _______________________________________________
> 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