Thanks for the positive feedback everyone.
I have a couple of further improvements planned (but not much time atm).
A) left alignment of text (I agree)
B) ability to open footprint selector (perhaps using right-click context
menu). If someone with better knowledge of Kiway wants to do this one,
Hi Oliver,
On 06/05/17 12:13, Oliver Walters wrote:
And it just so happens that in this schematic NO components have
been edited to include these default fields/values, so, they don't
show up in the component table.
I have a patch to fix this now - if a field is empty and a
>
> Perhaps one feature request regarding custom fields would be (if possible)
> to select which field is used for grouping components, instead of just the
> value field. Either a custom field or one of the standard ones like
> footprint name or symbol name. Think editing all 0402 resistors, or
>
> And it just so happens that in this schematic NO components have been
> edited to include these default fields/values, so, they don't show up in
> the component table.
I have a patch to fix this now - if a field is empty and a template value
exists, that is placed there instead.
> Also,
Hi Oliver!
I also tried the new component table viewer, and think that it looks very
promising! I'm switching over from Altium which makes extensive use of List and
Property dock panels, so I would like to provide some feedback:
* There should be a warning if there are uncommitted changes.
Perhaps one feature request regarding custom fields would be (if possible)
to select which field is used for grouping components, instead of just the
value field. Either a custom field or one of the standard ones like
footprint name or symbol name. Think editing all 0402 resistors, or all the
Oliver,
This is one of my components:
http://i.imgur.com/QXyCXXt.png
This is the component table:
http://i.imgur.com/F2WTRC2.png
The MFG, MPN or EQUIVOK fields in the component aren't shown in the table!
And in doing that I worked out my problem :)
I have MFG/MPN/EQUIVOK defined as "Default
Steven,
Unless you mean something different to what I think "custom fields" means,
then this is already the case - any extra fields (beyond REFERENCE /
FOOTPRINT / DATSHEET / VALUE) are preesnt to be edited in the table...
On Fri, May 5, 2017 at 10:51 PM, Strontium wrote:
Hi Oliver,
Just had a chance to check out your component table viewer, its nice.
Great work.
Is it on your roadmap to be able to view/edit a components custom fields?
Regards,
Steven
On 03/05/17 05:35, Oliver Walters wrote:
Wayne,
Thanks for merging!
I will address those points at some
Wayne,
Thanks for merging!
I will address those points at some stage - there are other ideas I have
too but I thought it was better to get the first iteration done and make
incremental improvements.
Regards,
Oliver
On 3 May 2017 03:25, "Wayne Stambaugh" wrote:
> Oliver,
Oliver,
This is looking pretty good so I merged your patches into the master
branch. I do have a few minor changes that I would like you to make at
some point:
* Move the OK and Cancel buttons to the bottom of the dialog using a
wxStdDialogButtonSizer.
* Use dialog style wxDEFAULT_DIALOG_STYLE
I've done a bit of testing on this branch and it works great for me, it cut
the time it takes to release a board to production significantly.
Thanks!
Jose
On Mon, May 1, 2017 at 7:42 AM, Wayne Stambaugh
wrote:
> Hey Oliver,
>
> I just need to find the time to test and
Hey Oliver,
I just need to find the time to test and review your changes. I will
let you know as soon as I can.
Cheers,
Wayne
On 4/30/2017 5:41 PM, Oliver Walters wrote:
> Hi Wayne,
>
> Anything else you need me to do here?
>
> Cheers
>
> On 25 Apr 2017 18:22, "Oliver Walters"
Hi Wayne,
Anything else you need me to do here?
Cheers
On 25 Apr 2017 18:22, "Oliver Walters"
wrote:
> Wayne,
>
> I have reattached all patches including a new one which does the following:
>
> a) Removes BOM export
> b) Removes Save/Cancel dialog as per JP's
Oliver,
Thank you for your understanding on this issue. Once you include the
patch to remove the BOM code, I will merge this into the master branch.
Cheers,
Wayne
On 4/23/2017 5:41 PM, Oliver Walters wrote:
> Wayne,
>
> I tend to agree actually, as I have been developing this the less I
>
Wayne,
I tend to agree actually, as I have been developing this the less I think
having a BoM export is appropriate:
1. Separation of tasks - it's simpler and cleaner just as an editing table
2. Python (etc) is way better at data manipulation
3. External scripts are by design much more flexible.
Oliver,
I finally got a chance to test your patch set and was a bit surprised
what I saw after following the conversation on the mailing list. I was
under the impression that this was a generic component properties
editing grid not a BOM tool which is what it really is. I like the idea
of being
Le 20/04/2017 à 07:59, Oliver Walters a écrit :
> Wayne,
>
> Is the behaviour I have implemented acceptable?
>
> Regards,
> Oliver
Hi Oliver,
I tested your latest patches.
I found 3 issues: a minor one a 2 more annoying.
The minor:
After clicking on OK button the DisplayExitDialog() function
Wayne,
Is the behaviour I have implemented acceptable?
Regards,
Oliver
On Wed, Apr 19, 2017 at 12:13 AM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:
> Wayne,
>
> I have now fixed this such that UNDO actions are pushed to the UNDO stack
> for the associated sheet. All UNDO actions
Wayne,
I have now fixed this such that UNDO actions are pushed to the UNDO stack
for the associated sheet. All UNDO actions for a given sheet are grouped so
a single Ctrl-Z will undo all components changed in the table (for the
given sheet).
Please find patch _007 attached (must be appli ed atop
I have attached two more patches that address issues raised by Tom and JP:
_005:
- Adds OK/CANCEL dialog
- Removes onClose event
- Moves UI updates into onUpdateUI event
_006:
- Fixes editing of "duplicate" components (e.g. components on sheets that
are referenced multiple times)
- Editing one
On 4/18/2017 5:01 AM, Oliver Walters wrote:
> Wayne,
>
> With this in mind, I am unsure how to determine (given a list of
> components) which sheet they originate in.
All of this information is in the SCH_REFERENCE object. You will have
to cross reference the SCH_SHEET_PATH to find the
On 4/18/2017 3:12 AM, jp charras wrote:
> Le 17/04/2017 à 22:51, Nox a écrit :
>> I know that I already suggested that in another context but what about
>> changing the undo/redo
>> semantic to the more common approach to maintain an global undo/redo stack
>> and switch the view
>> accordingly?
I agree with you about the multi file editor behaviour. There it is
natural that the undo/redo works per file. But is this behaviour also
reasonable for a schematic? I just checked the behaviour of visual
studio. There global replacement will be reverted if the stack is in
sync. Else only the
Wayne,
With this in mind, I am unsure how to determine (given a list of
components) which sheet they originate in.
I need a SCH_EDIT_FRAME* for each component, to work out where to push each
undo operation.
I have a list of SCH_REFERENCE objects, is there a way of determining where
each object
Le 17/04/2017 à 22:51, Nox a écrit :
> I know that I already suggested that in another context but what about
> changing the undo/redo
> semantic to the more common approach to maintain an global undo/redo stack
> and switch the view
> accordingly? I know that the "per screen" is the established
The platform shouldn't matter; it's a question of making sure that strings are
handled correctly. What seems to have happened is that a UTF8 string was
handled as if it were an ASCII Latin-1 string; changing the default character
set will change the results. The challenge is working out what went
Cirilo,
Does this mean that the rendering is going to be platform dependent? Is
there a way to enforce consistent rendering?
On Tue, Apr 18, 2017 at 12:05 PM, Cirilo Bernardo wrote:
> This is a UTF8 vs extended ASCII problem. In UTF8, micro is C2 B5;
> in extended
This is a UTF8 vs extended ASCII problem. In UTF8, micro is C2 B5;
in extended ASCII Latin-1, C2 is the circumflex capital A and B5 is micro.
- Cirilo
On Fri, Apr 14, 2017 at 7:51 PM, Nick Østergaard wrote:
> Hmm, another small issue.
>
> When I have a part with a value of
I know that I already suggested that in another context but what about
changing the undo/redo semantic to the more common approach to maintain
an global undo/redo stack and switch the view accordingly? I know that
the "per screen" is the established way in kicad and that it is very
dangerous
On 4/17/2017 4:18 PM, Oliver Walters wrote:
> So how do we proceed here? Is there a 'global' undo stack? If not:
Unfortunately there is no global undo stack. Undo stacks are maintained
for each unique SCH_SCREEN (schematic file) object.
>
> A) don't allow changes made in the component table
So how do we proceed here? Is there a 'global' undo stack? If not:
A) don't allow changes made in the component table viewer to be undone
B) Make an undo entry for each sheet that has changed symbols
A) is easier but the user would need to quit-without-save to undo changes
B) is more difficult
On 4/17/2017 10:21 AM, jp charras wrote:
> Le 17/04/2017 à 04:11, Oliver Walters a écrit :
>> JP, others,
>>
>> After further investigation, I have worked out why the components with
>> duplicated references were
>> displaying incorrectly.
>>
>> Patch_004 is attached, Thomas can you confirm that
Le 17/04/2017 à 04:11, Oliver Walters a écrit :
> JP, others,
>
> After further investigation, I have worked out why the components with
> duplicated references were
> displaying incorrectly.
>
> Patch_004 is attached, Thomas can you confirm that it fixes the display for
> you?
>
> Kind
Hi Oliver,
I can confirm the issue is now fixed.
Some other issues found:
* Please update all duplicated references when someone changes a value,
to show that more than one reference was updated by this edit (as
already done for group edit).
* undo/redo operation of symbols update by your
JP, others,
After further investigation, I have worked out why the components with
duplicated references were displaying incorrectly.
Patch_004 is attached, Thomas can you confirm that it fixes the display for
you?
Kind Regards,
Oliver
On Mon, Apr 17, 2017 at 7:53 AM, Oliver Walters <
JP,
Thanks for the feedback.
In the component table, multi-unit symbols are "compressed" into a single
entry. Change a field value for one and it will change for all units of
that symbol.
For "duplicate" references, perhaps the best approach is to only allow a
certain reference to be added once
Le 16/04/2017 à 15:12, Oliver Walters a écrit :
> It's not KiCad that "knows" to exclude testing points, etc - my Python BOM
> script has a series of
> regex filters that remove a whole swathe of virtual components.
>
> Sometimes you actually want test points to be in the BoM e.g. for loading
>
Thomas, et al,
I have attached _003 patch which now ensures that the "Save" button is
activated when you make changes in the table.
Please apply this on top of the other two and let me know if it fixes that
issue.
Thanks,
Oliver
On Sat, Apr 15, 2017 at 9:33 PM, Thomas Pointhuber
On Fri, Apr 14, 2017 at 7:51 PM, Nick Østergaard wrote:
> Hmm, another small issue.
>
> When I have a part with a value of 10µ in kicad it will render as
> 10µ in the html output (Big a-circumflex) It looks right in the csv.
>
I do not see this -
Thomas,
References are not displayed correctly when using duplicated
> subschematics.
Can you provide some more information? What is a duplicated subschematic?
What does an incorrectly displayed reference look like?
Search functionality (using Ctrl+F) does not work with collapsed
> grouped
Hi Oliver,
nice work, and I hope it get merged into master soon.
Some issues I found so far (using your github branch):
* References are not displayed correctly when using duplicated
subschematics.
* Search functionality (using Ctrl+F) does not work with collapsed
grouped references
* Even when
Hmm, another small issue.
When I have a part with a value of 10µ in kicad it will render as
10µ in the html output (Big a-circumflex) It looks right in the csv.
2017-04-14 11:07 GMT+02:00 Nick Østergaard :
> I can confirmthat the assert I reported is fixed with the second
I can confirmthat the assert I reported is fixed with the second patch.
2017-04-13 23:40 GMT+02:00 Oliver Walters :
> Just a friendly reminder about this, I haven't heard anything since
> attaching the correct patches.
>
> Cheers
>
> On 7 Apr 2017 19:27, "Oliver
Just a friendly reminder about this, I haven't heard anything since
attaching the correct patches.
Cheers
On 7 Apr 2017 19:27, "Oliver Walters"
wrote:
> I am very sorry about this, three mistakes in a row!
>
> It has been pointed out that I have attached the
I get the attached assert on linux in a debug build.
/usr/include/wx-3.0/wx/strvararg.h(456): assert "(argtype &
(wxFormatStringSpecifier::value)) == argtype" failed in
wxArgNormalizer(): format specifier doesn't match argument type
It seems to work quite good, but I wonder who one is actually
Oh, that's embarrassing, it appear that I have attached the inverse of the
patch!
I'll send a new patch later today - sorry!
On Sun, Apr 2, 2017 at 1:15 AM, jp charras wrote:
> Le 01/04/2017 à 14:53, Oliver Walters a écrit :
> > After a long break on this project I have
Le 01/04/2017 à 14:53, Oliver Walters a écrit :
> After a long break on this project I have finally rounded the edges off the
> component table viewer I
> have been working on.
>
> This is a table/spreadsheet view of all the components in the schematic,
> which allows bulk editing,
> grouping
Yes. It is convenient thing
В Суббота, 1 апр. 2017 в 3:53 , Oliver Walters
написал:
After a long break on this project I have finally rounded the edges
off the component table viewer I have been working on.
This is a table/spreadsheet view of all the
OMG YES.
I won't get to test this for a while, but...YES :)
On Apr 1, 2017 08:53, "Oliver Walters"
wrote:
> After a long break on this project I have finally rounded the edges off
> the component table viewer I have been working on.
>
> This is a
50 matches
Mail list logo