Re: [Kicad-developers] 5.1.4 release - release announcement/blog entry?

[Adam Wolf]

Hi folks!

5.1.4 is up for macOS.  It's in two versions, like last time.  10.12
and 10.13 use 
https://kicad-downloads.s3.cern.ch/osx/stable/kicad-unified-5.1.4-0.dmg,
and 10.14 uses 
https://kicad-downloads.s3.cern.ch/osx/stable/kicad-unified-5.1.4-0-10_14.dmg

The second file is not yet uploaded but should be within an hour or
two... it's uploading, slowly but surely.

Thanks for everyone's patience.  I'll work on getting package uploads
from the build machine for releases--I have to do an extra
download/upload step and that makes it take a lot longer if I'm on
travel--unlike nightlies which upload automatically.

Adam

On Mon, Aug 12, 2019 at 10:29 AM Wayne Stambaugh  wrote:
>
> Adam,
>
> Please ping the mailing list once you get this uploaded so I can get
> everything released.
>
> Thanks,
>
> Wayne
>
> On 8/12/2019 10:04 AM, Adam Wolf wrote:
> > Working on this this morning.  Thanks for your patience all.
> >
> > Adam
> >
> > On Mon, Aug 12, 2019 at 7:56 AM Wayne Stambaugh  
> > wrote:
> >>
> >> Ian,
> >>
> >> Nice catch.  I just pushed the fix.
> >>
> >> Thanks,
> >>
> >> Wayne
> >>
> >> On 8/12/2019 8:47 AM, Ian McInerney wrote:
> >>> Wayne,
> >>>
> >>> There seems to be a typo in the release announcement (line 23), it
> >>> references the 5.1.3 milestone page twice instead of 5.1.3 and 5.1.4.
> >>>
> >>> -Ian
> >>>
> >>> On Mon, Aug 12, 2019 at 2:39 PM Wayne Stambaugh  >>> > wrote:
> >>>
> >>> I just installed 5.1.4_1 on windows 10 and everything seems to be
> >>> working as expected.  I did not see the 5.1.4 macos package.  I will
> >>> hold off updating the website download page and the release 
> >>> announcement
> >>> until that is ready.  Thank you everyone for your efforts.  Hopefully
> >>> the next stable release will go a bit more smoothly.
> >>>
> >>> Cheers,
> >>>
> >>> Wayne
> >>>
> >>> On 8/9/2019 6:01 PM, Nick Østergaard wrote:
> >>> > Please sanity test the windows build and make pr for the website, I
> >>> > won't make commits until sunday. I am travelling.
> >>> >
> >>> > fre. 9. aug. 2019 23.50 skrev Adam Wolf
> >>> mailto:adamw...@feelslikeburning.com>
> >>> >  >>> >>:
> >>> >
> >>> > MacOS is building.  I am out of town and return tomorrow.  If
> >>> there
> >>> > are no issues I should be able to get them uploaded tonight,
> >>> if not,
> >>> > Sunday.
> >>> >
> >>> > On Fri, Aug 9, 2019, 1:21 PM Wayne Stambaugh
> >>> mailto:stambau...@gmail.com>
> >>> > >>
> >>> wrote:
> >>> >
> >>> > I fine with adding the release announcement to the
> >>> changelog.  I'm
> >>> > guessing this will be final blog post url.  The release
> >>> > announcement is
> >>> > already updated and ready to go as soon as the macos and
> >>> windows
> >>> > packages are built, uploaded to the server, and the
> >>> website download
> >>> > links are updated.  As soon as that it done, I will remove 
> >>> the
> >>> > draft tag
> >>> > from the release announcement.  Hopefully I wont be more
> >>> than a
> >>> > few more
> >>> > days.
> >>> >
> >>> > Cheers,
> >>> >
> >>> > Wayne
> >>> >
> >>> > On 8/9/19 3:50 PM, Stefan Brüns wrote:
> >>> > > On Freitag, 9. August 2019 16:45:37 CEST Nick Østergaard
> >>> wrote:
> >>> > >> kicad-doc 5.1.4 has been tagged
> >>> > >
> >>> > > Hi,
> >>> > >
> >>> > > the packages for openSUSE (Tumbleweed and Leap) are
> >>> ready and
> >>> > waiting for
> >>> > > submission to the repos, but I would like to include the
> >>> > release announcement
> >>> > > URL in the changelog.
> >>> > >
> >>> > > Extrapolating past releases, it will likely show up as:
> >>> > > http://kicad-pcb.org/blog/2019/08/KiCad-5.1.4-Release/
> >>> > >
> >>> > > Any reservations for including this URL in the Changelog?
> >>> > >
> >>> > > Kind regards,
> >>> > >
> >>> > > Stefan
> >>> > >
> >>> > >
> >>> > > ___
> >>> > > Mailing list: https://launchpad.net/~kicad-developers
> >>> > > Post to : kicad-developers@lists.launchpad.net
> >>> 
> >>> >  >>> >
> >>> > > Unsubscribe : https://launchpad.net/~kicad-developers
> >>> > 

Re: [Kicad-developers] [kicad-eeschema] Vertical pins with horizontal texts

[Johannes Sprigode]

Howdy Wayne,

no worries. Thanks for the heads up. I'm not surprised at all since this
only makes sense to have.

In the meantime I'll keep it up if viable as a local patch just for
fun-kickers.

Is that feature already progressing? If so, which tag?

Cheers

Johannes

On 13/08/19 7:27 AM, Wayne Stambaugh wrote:
> Johannes,
>
> Once the new schematic and symbol library file formats are complete, you
> will be able orient pin number and name positions freely.  This is
> planned for version 6 which is currently under development so no changes
> will be made to the existing file format to support this.  Thank you for
> offering to help but this already is planned.
>
> Cheers,
>
> Wayne
>
> On 7/15/19 7:18 AM, Johannes Sprigode wrote:
>> Hello there,
>>
>> been using Kicad for a while and have not looked back at eagle except
>> for project imports.
>>
>> However, I found all those vertical texts  in eeschema quite disruptive.
>> So I've done something like in attached screen shot over the last couple
>> of days working off of master under Linux.
>>
>> Would you guys be interest to implement this sort of feature? If so, I
>> would follow through with the nitty gritties since the actual
>> implications are ‘slightly’ more complex then just that.
>>
>> Who would be the best contact to discuss this?
>>
>> I’m quite happy to lay out an implementation scenario.
>>
>> As it stands this ‘add-in’ will not impact on already existing
>> libraries. Going by what is in master there is no such feature except
>> some decent groundwork to build upon.
>>
>> Cheers
>>
>> Johannes
>>
>>
>> ___
>> 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



signature.asc
Description: OpenPGP digital signature
___
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] [RFC] Switch from SyncToolbars to wxUpdateUIEvent

[Jeff Young]

I’m not sure what we’re buying with the wxUpdateUIEvents then.  Context menus 
will still need to run the existing Evaluate() stuff (for visibility and for 
the highlight hacks), at which point it might as well do the enabling/checking 
too. And menu-bar menus will also still have to run menu dispatch (for the 
menu-vs.-accelerator hack).  I suppose it would allow us to remove some of the 
GTK hacks (such as having to resolve the menus immediately after building them).

If we do push down the lamda stuff into ACTION_MENU so that it can bind to 
wxUpdateUIEvents, we should move the menu-bar menus to ACTION_MENU and then 
rename CONDITIONAL_MENU to CONTEXT_MENU.

Cheers,
Jeff.


> On 12 Aug 2019, at 23:06, Ian McInerney  wrote:
> 
> Jeff,
> 
> I was thinking we would only move the update for the enable and check 
> attributes to the wxUpdateUIEvent mechanism and leave the visibility to the 
> conditional menu to deal with in its Evaluate() function as it currently 
> does. There is no way to get wxWidgets to hide items for us in menus (and GTK 
> doesn't even seem to have a mechanism for it, so it will probably never be 
> possible to outsource it to wxWidgets), so we will always need to handle that 
> ourselves and the Evaluate() command seems to be doing a decent job of it.
> 
> -Ian
> 
> On Mon, Aug 12, 2019 at 10:19 PM Jeff Young  > wrote:
> Hi Ian,
> 
> It sounds promising, but there are some potential pitfalls.  wxWidgets only 
> supports two bits: enabled and checked.  CONDITIONAL_MENU supports 2-1/2: the 
> enabled flag means visible if the is_context_menu flag is set.  This is 
> probably a subtlety that does us no good: it would be more direct to just 
> have ACTION_MENU support 3 bits (visible, enabled and checked) and get rid of 
> CONDITIONAL_MENU.
> 
> However, that then begs the question of how do we handle the visible bit 
> through the wxUpdateUIEvent mechanism?  Maybe we just use the wxUpdateUIEvent 
> as a trigger to run the equivalent of Evaluate()?  Or maybe we just have 
> wxUpdateUIEvent handle the two bits, and continue to handle the visible bit 
> through the existing mechanism?  (Note that at least some of the existing 
> mechanism has to stay anyway because we use it to determine if a command is 
> an accelerator or a menu pick.)
> 
> Generally speaking we *could* move everything to ACTIONs.  The stuff that’s 
> still in the old system at present is just the stuff that didn’t look worth 
> moving.  So if there’s anything that needs synchronizing that isn’t currently 
> an ACTION we should just make it an ACTION.  (There are two caveats to this 
> due to wxWidgets crankiness: Quit and Close.  But neither of them need 
> synchronizing.)
> 
> Cheers,
> Jeff.
> 
> 
>> On 12 Aug 2019, at 20:45, Ian McInerney > > wrote:
>> 
>> Following on from the discussion in this merge request 
>> (https://code.launchpad.net/~imcinerney/kicad/+git/kicad/+merge/371156 
>> ), I 
>> thought a little about if the current framework could be adapted to use the 
>> wxUpdateUIEvent handlers to do the synchronization, and I think it can be. 
>> Here is my thinking of how it can be done, and I would appreciate comments 
>> about this idea.
>> 
>> From my understanding there are three classes that will create menu/toolbar 
>> items that need to be synced: ACTION_MENU, ACTION_TOOLBAR, and 
>> CONDITIONAL_MENU. The first change would be to make the Add functions for 
>> all of these classes take a SelectionConditions argument that will be used 
>> to define the enable/checkmark status of the item (currently only 
>> CONDITIONAL_MENU takes these).
>> 
>> First question, do we need to synchronize any items that aren't 
>> action-based? If we will only synchronize action-based items, then only 
>> those Add functions would need to be extended.
>> 
>> The TOOL_MANAGER would then handle the majority of the work. The Add 
>> functions would call into the TOOL_MANAGER requesting an event handler be 
>> created, passing the selection conditions as well.
>> 
>> To create the event handler, the TOOL_MANAGER would do the following:
>> 1) Consult a list that associates actions with their selection conditions 
>> (being on the list would indicate the action already has a handler in the 
>> window containing the tool manager).
>> 2) If the action is on the list, compare the provided selection condition 
>> with what is already in the list, and if they are different from each other, 
>> assert (this will require selection conditions used in multiple places in 
>> the same tool manager for the same action to point to the same object). This 
>> way the code is kept synchronized as well.
>> 3) If it is not on the list, then call Bind and bind an event handler for 
>> the event. The selection condition would be passed into the Bind as the user 
>> data so that it can be used in the handler. This handler 

Re: [Kicad-developers] [RFC] Switch from SyncToolbars to wxUpdateUIEvent

[Ian McInerney]

Jeff,

I was thinking we would only move the update for the enable and check
attributes to the wxUpdateUIEvent mechanism and leave the visibility to the
conditional menu to deal with in its Evaluate() function as it currently
does. There is no way to get wxWidgets to hide items for us in menus (and
GTK doesn't even seem to have a mechanism for it, so it will probably never
be possible to outsource it to wxWidgets), so we will always need to handle
that ourselves and the Evaluate() command seems to be doing a decent job of
it.

-Ian

On Mon, Aug 12, 2019 at 10:19 PM Jeff Young  wrote:

> Hi Ian,
>
> It sounds promising, but there are some potential pitfalls.  wxWidgets
> only supports two bits: enabled and checked.  CONDITIONAL_MENU supports
> 2-1/2: the enabled flag means visible if the is_context_menu flag is set.
> This is probably a subtlety that does us no good: it would be more direct
> to just have ACTION_MENU support 3 bits (visible, enabled and checked) and
> get rid of CONDITIONAL_MENU.
>
> However, that then begs the question of how do we handle the visible bit
> through the wxUpdateUIEvent mechanism?  Maybe we just use the
> wxUpdateUIEvent as a trigger to run the equivalent of Evaluate()?  Or maybe
> we just have wxUpdateUIEvent handle the two bits, and continue to handle
> the visible bit through the existing mechanism?  (Note that at least some
> of the existing mechanism has to stay anyway because we use it to determine
> if a command is an accelerator or a menu pick.)
>
> Generally speaking we *could* move everything to ACTIONs.  The stuff
> that’s still in the old system at present is just the stuff that didn’t
> look worth moving.  So if there’s anything that needs synchronizing that
> isn’t currently an ACTION we should just make it an ACTION.  (There are two
> caveats to this due to wxWidgets crankiness: Quit and Close.  But neither
> of them need synchronizing.)
>
> Cheers,
> Jeff.
>
>
> On 12 Aug 2019, at 20:45, Ian McInerney  wrote:
>
> Following on from the discussion in this merge request (
> https://code.launchpad.net/~imcinerney/kicad/+git/kicad/+merge/371156), I
> thought a little about if the current framework could be adapted to use the
> wxUpdateUIEvent handlers to do the synchronization, and I think it can be.
> Here is my thinking of how it can be done, and I would appreciate comments
> about this idea.
>
> From my understanding there are three classes that will create
> menu/toolbar items that need to be synced: ACTION_MENU, ACTION_TOOLBAR, and
> CONDITIONAL_MENU. The first change would be to make the Add functions for
> all of these classes take a SelectionConditions argument that will be used
> to define the enable/checkmark status of the item (currently only
> CONDITIONAL_MENU takes these).
>
> First question, do we need to synchronize any items that aren't
> action-based? If we will only synchronize action-based items, then only
> those Add functions would need to be extended.
>
> The TOOL_MANAGER would then handle the majority of the work. The Add
> functions would call into the TOOL_MANAGER requesting an event handler be
> created, passing the selection conditions as well.
>
> To create the event handler, the TOOL_MANAGER would do the following:
> 1) Consult a list that associates actions with their selection conditions
> (being on the list would indicate the action already has a handler in the
> window containing the tool manager).
> 2) If the action is on the list, compare the provided selection condition
> with what is already in the list, and if they are different from each
> other, assert (this will require selection conditions used in multiple
> places in the same tool manager for the same action to point to the same
> object). This way the code is kept synchronized as well.
> 3) If it is not on the list, then call Bind and bind an event handler for
> the event. The selection condition would be passed into the Bind as the
> user data so that it can be used in the handler. This handler would be
> bound to the parent of the tool manager.
>
> There would be two handlers, one for checkmark entries and one for
> enable/disable entries, and the correct one would be bound based on the
> type of menu item. These would modify the aEvent object to actually
> check/enable/disable the UI element (like what the original handlers did).
>
> I believe this will remove the need for the SyncToolbars functions (and
> the need for the tool manager to explicitly call this, which had caused
> some issues in the past if I remember correctly). It will also mean that
> the conditional menu's Evaluate function would no longer need to do the
> checking/enabling itself, since that is handled in the event handler.
>
> Thoughts?
>
> -Ian
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : 

Re: [Kicad-developers] [RFC] Switch from SyncToolbars to wxUpdateUIEvent

[Jeff Young]

Hi Ian,

It sounds promising, but there are some potential pitfalls.  wxWidgets only 
supports two bits: enabled and checked.  CONDITIONAL_MENU supports 2-1/2: the 
enabled flag means visible if the is_context_menu flag is set.  This is 
probably a subtlety that does us no good: it would be more direct to just have 
ACTION_MENU support 3 bits (visible, enabled and checked) and get rid of 
CONDITIONAL_MENU.

However, that then begs the question of how do we handle the visible bit 
through the wxUpdateUIEvent mechanism?  Maybe we just use the wxUpdateUIEvent 
as a trigger to run the equivalent of Evaluate()?  Or maybe we just have 
wxUpdateUIEvent handle the two bits, and continue to handle the visible bit 
through the existing mechanism?  (Note that at least some of the existing 
mechanism has to stay anyway because we use it to determine if a command is an 
accelerator or a menu pick.)

Generally speaking we *could* move everything to ACTIONs.  The stuff that’s 
still in the old system at present is just the stuff that didn’t look worth 
moving.  So if there’s anything that needs synchronizing that isn’t currently 
an ACTION we should just make it an ACTION.  (There are two caveats to this due 
to wxWidgets crankiness: Quit and Close.  But neither of them need 
synchronizing.)

Cheers,
Jeff.


> On 12 Aug 2019, at 20:45, Ian McInerney  wrote:
> 
> Following on from the discussion in this merge request 
> (https://code.launchpad.net/~imcinerney/kicad/+git/kicad/+merge/371156 
> ), I 
> thought a little about if the current framework could be adapted to use the 
> wxUpdateUIEvent handlers to do the synchronization, and I think it can be. 
> Here is my thinking of how it can be done, and I would appreciate comments 
> about this idea.
> 
> From my understanding there are three classes that will create menu/toolbar 
> items that need to be synced: ACTION_MENU, ACTION_TOOLBAR, and 
> CONDITIONAL_MENU. The first change would be to make the Add functions for all 
> of these classes take a SelectionConditions argument that will be used to 
> define the enable/checkmark status of the item (currently only 
> CONDITIONAL_MENU takes these).
> 
> First question, do we need to synchronize any items that aren't action-based? 
> If we will only synchronize action-based items, then only those Add functions 
> would need to be extended.
> 
> The TOOL_MANAGER would then handle the majority of the work. The Add 
> functions would call into the TOOL_MANAGER requesting an event handler be 
> created, passing the selection conditions as well.
> 
> To create the event handler, the TOOL_MANAGER would do the following:
> 1) Consult a list that associates actions with their selection conditions 
> (being on the list would indicate the action already has a handler in the 
> window containing the tool manager).
> 2) If the action is on the list, compare the provided selection condition 
> with what is already in the list, and if they are different from each other, 
> assert (this will require selection conditions used in multiple places in the 
> same tool manager for the same action to point to the same object). This way 
> the code is kept synchronized as well.
> 3) If it is not on the list, then call Bind and bind an event handler for the 
> event. The selection condition would be passed into the Bind as the user data 
> so that it can be used in the handler. This handler would be bound to the 
> parent of the tool manager.
> 
> There would be two handlers, one for checkmark entries and one for 
> enable/disable entries, and the correct one would be bound based on the type 
> of menu item. These would modify the aEvent object to actually 
> check/enable/disable the UI element (like what the original handlers did).
> 
> I believe this will remove the need for the SyncToolbars functions (and the 
> need for the tool manager to explicitly call this, which had caused some 
> issues in the past if I remember correctly). It will also mean that the 
> conditional menu's Evaluate function would no longer need to do the 
> checking/enabling itself, since that is handled in the event handler.
> 
> Thoughts?
> 
> -Ian
> ___
> 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] [Patch] Fix some memory leaks

[Wayne Stambaugh]

Sounds like a plan.  If there are not bug reports against this over the
next month, I'll will cherry-pick it into 5.1.

Wayne

On 8/12/19 3:47 PM, Ian McInerney wrote:
> Wayne, lets let this settle in master for a while to make sure that no
> issues due to object lifetime surface.
> 
> -Ian
> 
> On Mon, Aug 12, 2019 at 9:20 PM Wayne Stambaugh  > wrote:
> 
> Ian,
> 
> I merged your patch.  I'm guessing this should be cherry-picked into the
> 5.1 branch.
> 
> Thanks,
> 
> Wayne
> 
> On 8/11/19 4:42 PM, Ian McInerney wrote:
> > I was noticing there were some memory leaks inside the board/module
> > classes that got somewhat extreme in some cases (I saw ~300MB leaked
> > from opening and closing cvpcb in Eeschema when run without a project
> > manager). This patch adds some deletion to the destructors of the
> > board/module classes, so they now will delete their sub items.
> >
> > I believe these classes are the respective owners of those pointers to
> > the sub items, and my testing doesn't show any problems with this, but
> > if anyone can see a case where deleting these sub items on destruction
> > might be an issue, let me know.
> >
> > -Ian
> >
> > ___
> > 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] [Patch] Fix some memory leaks

[Ian McInerney]

Wayne, lets let this settle in master for a while to make sure that no
issues due to object lifetime surface.

-Ian

On Mon, Aug 12, 2019 at 9:20 PM Wayne Stambaugh 
wrote:

> Ian,
>
> I merged your patch.  I'm guessing this should be cherry-picked into the
> 5.1 branch.
>
> Thanks,
>
> Wayne
>
> On 8/11/19 4:42 PM, Ian McInerney wrote:
> > I was noticing there were some memory leaks inside the board/module
> > classes that got somewhat extreme in some cases (I saw ~300MB leaked
> > from opening and closing cvpcb in Eeschema when run without a project
> > manager). This patch adds some deletion to the destructors of the
> > board/module classes, so they now will delete their sub items.
> >
> > I believe these classes are the respective owners of those pointers to
> > the sub items, and my testing doesn't show any problems with this, but
> > if anyone can see a case where deleting these sub items on destruction
> > might be an issue, let me know.
> >
> > -Ian
> >
> > ___
> > 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

[Kicad-developers] [RFC] Switch from SyncToolbars to wxUpdateUIEvent

[Ian McInerney]

Following on from the discussion in this merge request (
https://code.launchpad.net/~imcinerney/kicad/+git/kicad/+merge/371156), I
thought a little about if the current framework could be adapted to use the
wxUpdateUIEvent handlers to do the synchronization, and I think it can be.
Here is my thinking of how it can be done, and I would appreciate comments
about this idea.

>From my understanding there are three classes that will create menu/toolbar
items that need to be synced: ACTION_MENU, ACTION_TOOLBAR, and
CONDITIONAL_MENU. The first change would be to make the Add functions for
all of these classes take a SelectionConditions argument that will be used
to define the enable/checkmark status of the item (currently only
CONDITIONAL_MENU takes these).

First question, do we need to synchronize any items that aren't
action-based? If we will only synchronize action-based items, then only
those Add functions would need to be extended.

The TOOL_MANAGER would then handle the majority of the work. The Add
functions would call into the TOOL_MANAGER requesting an event handler be
created, passing the selection conditions as well.

To create the event handler, the TOOL_MANAGER would do the following:
1) Consult a list that associates actions with their selection conditions
(being on the list would indicate the action already has a handler in the
window containing the tool manager).
2) If the action is on the list, compare the provided selection condition
with what is already in the list, and if they are different from each
other, assert (this will require selection conditions used in multiple
places in the same tool manager for the same action to point to the same
object). This way the code is kept synchronized as well.
3) If it is not on the list, then call Bind and bind an event handler for
the event. The selection condition would be passed into the Bind as the
user data so that it can be used in the handler. This handler would be
bound to the parent of the tool manager.

There would be two handlers, one for checkmark entries and one for
enable/disable entries, and the correct one would be bound based on the
type of menu item. These would modify the aEvent object to actually
check/enable/disable the UI element (like what the original handlers did).

I believe this will remove the need for the SyncToolbars functions (and the
need for the tool manager to explicitly call this, which had caused some
issues in the past if I remember correctly). It will also mean that the
conditional menu's Evaluate function would no longer need to do the
checking/enabling itself, since that is handled in the event handler.

Thoughts?

-Ian
___
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] [kicad-eeschema] Vertical pins with horizontal texts

[Wayne Stambaugh]

Johannes,

Once the new schematic and symbol library file formats are complete, you
will be able orient pin number and name positions freely.  This is
planned for version 6 which is currently under development so no changes
will be made to the existing file format to support this.  Thank you for
offering to help but this already is planned.

Cheers,

Wayne

On 7/15/19 7:18 AM, Johannes Sprigode wrote:
> Hello there,
> 
> been using Kicad for a while and have not looked back at eagle except
> for project imports.
> 
> However, I found all those vertical texts  in eeschema quite disruptive.
> So I've done something like in attached screen shot over the last couple
> of days working off of master under Linux.
> 
> Would you guys be interest to implement this sort of feature? If so, I
> would follow through with the nitty gritties since the actual
> implications are ‘slightly’ more complex then just that.
> 
> Who would be the best contact to discuss this?
> 
> I’m quite happy to lay out an implementation scenario.
> 
> As it stands this ‘add-in’ will not impact on already existing
> libraries. Going by what is in master there is no such feature except
> some decent groundwork to build upon.
> 
> Cheers
> 
> Johannes
> 
> 
> ___
> 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] [Patch] Fix some memory leaks

[Wayne Stambaugh]

Ian,

I merged your patch.  I'm guessing this should be cherry-picked into the
5.1 branch.

Thanks,

Wayne

On 8/11/19 4:42 PM, Ian McInerney wrote:
> I was noticing there were some memory leaks inside the board/module
> classes that got somewhat extreme in some cases (I saw ~300MB leaked
> from opening and closing cvpcb in Eeschema when run without a project
> manager). This patch adds some deletion to the destructors of the
> board/module classes, so they now will delete their sub items.
> 
> I believe these classes are the respective owners of those pointers to
> the sub items, and my testing doesn't show any problems with this, but
> if anyone can see a case where deleting these sub items on destruction
> might be an issue, let me know.
> 
> -Ian
> 
> ___
> 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] [Patch] Another hotkey processing fix

[Wayne Stambaugh]

What is the status of this patch?

Cheers,

Wayne

On 8/8/19 7:16 PM, Ian McInerney wrote:
> In the current framework, if more than one global actions share the same
> hotkey (even if they are not all active in the current tool manager),
> the dispatcher will only choose the final action (in what seems to be
> alphabetical order) to run. I think that the correct behavior should
> instead be to loop through all global actions that have the hotkey until
> one handles it.
> 
> The attached patch implements this change.
> 
> -Ian
> 
> ___
> 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] 5.1.4 release - release announcement/blog entry?

[Wayne Stambaugh]

Adam,

Please ping the mailing list once you get this uploaded so I can get
everything released.

Thanks,

Wayne

On 8/12/2019 10:04 AM, Adam Wolf wrote:
> Working on this this morning.  Thanks for your patience all.
> 
> Adam
> 
> On Mon, Aug 12, 2019 at 7:56 AM Wayne Stambaugh  wrote:
>>
>> Ian,
>>
>> Nice catch.  I just pushed the fix.
>>
>> Thanks,
>>
>> Wayne
>>
>> On 8/12/2019 8:47 AM, Ian McInerney wrote:
>>> Wayne,
>>>
>>> There seems to be a typo in the release announcement (line 23), it
>>> references the 5.1.3 milestone page twice instead of 5.1.3 and 5.1.4.
>>>
>>> -Ian
>>>
>>> On Mon, Aug 12, 2019 at 2:39 PM Wayne Stambaugh >> > wrote:
>>>
>>> I just installed 5.1.4_1 on windows 10 and everything seems to be
>>> working as expected.  I did not see the 5.1.4 macos package.  I will
>>> hold off updating the website download page and the release announcement
>>> until that is ready.  Thank you everyone for your efforts.  Hopefully
>>> the next stable release will go a bit more smoothly.
>>>
>>> Cheers,
>>>
>>> Wayne
>>>
>>> On 8/9/2019 6:01 PM, Nick Østergaard wrote:
>>> > Please sanity test the windows build and make pr for the website, I
>>> > won't make commits until sunday. I am travelling.
>>> >
>>> > fre. 9. aug. 2019 23.50 skrev Adam Wolf
>>> mailto:adamw...@feelslikeburning.com>
>>> > >> >>:
>>> >
>>> > MacOS is building.  I am out of town and return tomorrow.  If
>>> there
>>> > are no issues I should be able to get them uploaded tonight,
>>> if not,
>>> > Sunday.
>>> >
>>> > On Fri, Aug 9, 2019, 1:21 PM Wayne Stambaugh
>>> mailto:stambau...@gmail.com>
>>> > >>
>>> wrote:
>>> >
>>> > I fine with adding the release announcement to the
>>> changelog.  I'm
>>> > guessing this will be final blog post url.  The release
>>> > announcement is
>>> > already updated and ready to go as soon as the macos and
>>> windows
>>> > packages are built, uploaded to the server, and the
>>> website download
>>> > links are updated.  As soon as that it done, I will remove the
>>> > draft tag
>>> > from the release announcement.  Hopefully I wont be more
>>> than a
>>> > few more
>>> > days.
>>> >
>>> > Cheers,
>>> >
>>> > Wayne
>>> >
>>> > On 8/9/19 3:50 PM, Stefan Brüns wrote:
>>> > > On Freitag, 9. August 2019 16:45:37 CEST Nick Østergaard
>>> wrote:
>>> > >> kicad-doc 5.1.4 has been tagged
>>> > >
>>> > > Hi,
>>> > >
>>> > > the packages for openSUSE (Tumbleweed and Leap) are
>>> ready and
>>> > waiting for
>>> > > submission to the repos, but I would like to include the
>>> > release announcement
>>> > > URL in the changelog.
>>> > >
>>> > > Extrapolating past releases, it will likely show up as:
>>> > > http://kicad-pcb.org/blog/2019/08/KiCad-5.1.4-Release/
>>> > >
>>> > > Any reservations for including this URL in the Changelog?
>>> > >
>>> > > Kind regards,
>>> > >
>>> > > Stefan
>>> > >
>>> > >
>>> > > ___
>>> > > 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
>>> 
>>> > >> 

Re: [Kicad-developers] 5.1.4 release - release announcement/blog entry?

[Adam Wolf]

Working on this this morning.  Thanks for your patience all.

Adam

On Mon, Aug 12, 2019 at 7:56 AM Wayne Stambaugh  wrote:
>
> Ian,
>
> Nice catch.  I just pushed the fix.
>
> Thanks,
>
> Wayne
>
> On 8/12/2019 8:47 AM, Ian McInerney wrote:
> > Wayne,
> >
> > There seems to be a typo in the release announcement (line 23), it
> > references the 5.1.3 milestone page twice instead of 5.1.3 and 5.1.4.
> >
> > -Ian
> >
> > On Mon, Aug 12, 2019 at 2:39 PM Wayne Stambaugh  > > wrote:
> >
> > I just installed 5.1.4_1 on windows 10 and everything seems to be
> > working as expected.  I did not see the 5.1.4 macos package.  I will
> > hold off updating the website download page and the release announcement
> > until that is ready.  Thank you everyone for your efforts.  Hopefully
> > the next stable release will go a bit more smoothly.
> >
> > Cheers,
> >
> > Wayne
> >
> > On 8/9/2019 6:01 PM, Nick Østergaard wrote:
> > > Please sanity test the windows build and make pr for the website, I
> > > won't make commits until sunday. I am travelling.
> > >
> > > fre. 9. aug. 2019 23.50 skrev Adam Wolf
> > mailto:adamw...@feelslikeburning.com>
> > >  > >>:
> > >
> > > MacOS is building.  I am out of town and return tomorrow.  If
> > there
> > > are no issues I should be able to get them uploaded tonight,
> > if not,
> > > Sunday.
> > >
> > > On Fri, Aug 9, 2019, 1:21 PM Wayne Stambaugh
> > mailto:stambau...@gmail.com>
> > > >>
> > wrote:
> > >
> > > I fine with adding the release announcement to the
> > changelog.  I'm
> > > guessing this will be final blog post url.  The release
> > > announcement is
> > > already updated and ready to go as soon as the macos and
> > windows
> > > packages are built, uploaded to the server, and the
> > website download
> > > links are updated.  As soon as that it done, I will remove the
> > > draft tag
> > > from the release announcement.  Hopefully I wont be more
> > than a
> > > few more
> > > days.
> > >
> > > Cheers,
> > >
> > > Wayne
> > >
> > > On 8/9/19 3:50 PM, Stefan Brüns wrote:
> > > > On Freitag, 9. August 2019 16:45:37 CEST Nick Østergaard
> > wrote:
> > > >> kicad-doc 5.1.4 has been tagged
> > > >
> > > > Hi,
> > > >
> > > > the packages for openSUSE (Tumbleweed and Leap) are
> > ready and
> > > waiting for
> > > > submission to the repos, but I would like to include the
> > > release announcement
> > > > URL in the changelog.
> > > >
> > > > Extrapolating past releases, it will likely show up as:
> > > > http://kicad-pcb.org/blog/2019/08/KiCad-5.1.4-Release/
> > > >
> > > > Any reservations for including this URL in the Changelog?
> > > >
> > > > Kind regards,
> > > >
> > > > Stefan
> > > >
> > > >
> > > > ___
> > > > 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] 5.1.4 release - release announcement/blog entry?

[Wayne Stambaugh]

Ian,

Nice catch.  I just pushed the fix.

Thanks,

Wayne

On 8/12/2019 8:47 AM, Ian McInerney wrote:
> Wayne,
> 
> There seems to be a typo in the release announcement (line 23), it
> references the 5.1.3 milestone page twice instead of 5.1.3 and 5.1.4.
> 
> -Ian
> 
> On Mon, Aug 12, 2019 at 2:39 PM Wayne Stambaugh  > wrote:
> 
> I just installed 5.1.4_1 on windows 10 and everything seems to be
> working as expected.  I did not see the 5.1.4 macos package.  I will
> hold off updating the website download page and the release announcement
> until that is ready.  Thank you everyone for your efforts.  Hopefully
> the next stable release will go a bit more smoothly.
> 
> Cheers,
> 
> Wayne
> 
> On 8/9/2019 6:01 PM, Nick Østergaard wrote:
> > Please sanity test the windows build and make pr for the website, I
> > won't make commits until sunday. I am travelling.
> >
> > fre. 9. aug. 2019 23.50 skrev Adam Wolf
> mailto:adamw...@feelslikeburning.com>
> >  >>:
> >
> >     MacOS is building.  I am out of town and return tomorrow.  If
> there
> >     are no issues I should be able to get them uploaded tonight,
> if not,
> >     Sunday.
> >
> >     On Fri, Aug 9, 2019, 1:21 PM Wayne Stambaugh
> mailto:stambau...@gmail.com>
> >     >>
> wrote:
> >
> >         I fine with adding the release announcement to the
> changelog.  I'm
> >         guessing this will be final blog post url.  The release
> >         announcement is
> >         already updated and ready to go as soon as the macos and
> windows
> >         packages are built, uploaded to the server, and the
> website download
> >         links are updated.  As soon as that it done, I will remove the
> >         draft tag
> >         from the release announcement.  Hopefully I wont be more
> than a
> >         few more
> >         days.
> >
> >         Cheers,
> >
> >         Wayne
> >
> >         On 8/9/19 3:50 PM, Stefan Brüns wrote:
> >         > On Freitag, 9. August 2019 16:45:37 CEST Nick Østergaard
> wrote:
> >         >> kicad-doc 5.1.4 has been tagged
> >         >
> >         > Hi,
> >         >
> >         > the packages for openSUSE (Tumbleweed and Leap) are
> ready and
> >         waiting for
> >         > submission to the repos, but I would like to include the
> >         release announcement
> >         > URL in the changelog.
> >         >
> >         > Extrapolating past releases, it will likely show up as:
> >         > http://kicad-pcb.org/blog/2019/08/KiCad-5.1.4-Release/
> >         >
> >         > Any reservations for including this URL in the Changelog?
> >         >
> >         > Kind regards,
> >         >
> >         > Stefan
> >         >
> >         >
> >         > ___
> >         > 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
> >
> 
> ___
> 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] 5.1.4 release - release announcement/blog entry?

[Ian McInerney]

Wayne,

There seems to be a typo in the release announcement (line 23), it
references the 5.1.3 milestone page twice instead of 5.1.3 and 5.1.4.

-Ian

On Mon, Aug 12, 2019 at 2:39 PM Wayne Stambaugh 
wrote:

> I just installed 5.1.4_1 on windows 10 and everything seems to be
> working as expected.  I did not see the 5.1.4 macos package.  I will
> hold off updating the website download page and the release announcement
> until that is ready.  Thank you everyone for your efforts.  Hopefully
> the next stable release will go a bit more smoothly.
>
> Cheers,
>
> Wayne
>
> On 8/9/2019 6:01 PM, Nick Østergaard wrote:
> > Please sanity test the windows build and make pr for the website, I
> > won't make commits until sunday. I am travelling.
> >
> > fre. 9. aug. 2019 23.50 skrev Adam Wolf  > >:
> >
> > MacOS is building.  I am out of town and return tomorrow.  If there
> > are no issues I should be able to get them uploaded tonight, if not,
> > Sunday.
> >
> > On Fri, Aug 9, 2019, 1:21 PM Wayne Stambaugh  > > wrote:
> >
> > I fine with adding the release announcement to the changelog.
> I'm
> > guessing this will be final blog post url.  The release
> > announcement is
> > already updated and ready to go as soon as the macos and windows
> > packages are built, uploaded to the server, and the website
> download
> > links are updated.  As soon as that it done, I will remove the
> > draft tag
> > from the release announcement.  Hopefully I wont be more than a
> > few more
> > days.
> >
> > Cheers,
> >
> > Wayne
> >
> > On 8/9/19 3:50 PM, Stefan Brüns wrote:
> > > On Freitag, 9. August 2019 16:45:37 CEST Nick Østergaard wrote:
> > >> kicad-doc 5.1.4 has been tagged
> > >
> > > Hi,
> > >
> > > the packages for openSUSE (Tumbleweed and Leap) are ready and
> > waiting for
> > > submission to the repos, but I would like to include the
> > release announcement
> > > URL in the changelog.
> > >
> > > Extrapolating past releases, it will likely show up as:
> > > http://kicad-pcb.org/blog/2019/08/KiCad-5.1.4-Release/
> > >
> > > Any reservations for including this URL in the Changelog?
> > >
> > > Kind regards,
> > >
> > > Stefan
> > >
> > >
> > > ___
> > > 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
> >
>
> ___
> 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] 5.1.4 release - release announcement/blog entry?

[Wayne Stambaugh]

I just installed 5.1.4_1 on windows 10 and everything seems to be
working as expected.  I did not see the 5.1.4 macos package.  I will
hold off updating the website download page and the release announcement
until that is ready.  Thank you everyone for your efforts.  Hopefully
the next stable release will go a bit more smoothly.

Cheers,

Wayne

On 8/9/2019 6:01 PM, Nick Østergaard wrote:
> Please sanity test the windows build and make pr for the website, I
> won't make commits until sunday. I am travelling.
> 
> fre. 9. aug. 2019 23.50 skrev Adam Wolf  >:
> 
> MacOS is building.  I am out of town and return tomorrow.  If there
> are no issues I should be able to get them uploaded tonight, if not,
> Sunday.
> 
> On Fri, Aug 9, 2019, 1:21 PM Wayne Stambaugh  > wrote:
> 
> I fine with adding the release announcement to the changelog.  I'm
> guessing this will be final blog post url.  The release
> announcement is
> already updated and ready to go as soon as the macos and windows
> packages are built, uploaded to the server, and the website download
> links are updated.  As soon as that it done, I will remove the
> draft tag
> from the release announcement.  Hopefully I wont be more than a
> few more
> days.
> 
> Cheers,
> 
> Wayne
> 
> On 8/9/19 3:50 PM, Stefan Brüns wrote:
> > On Freitag, 9. August 2019 16:45:37 CEST Nick Østergaard wrote:
> >> kicad-doc 5.1.4 has been tagged
> >
> > Hi,
> >
> > the packages for openSUSE (Tumbleweed and Leap) are ready and
> waiting for
> > submission to the repos, but I would like to include the
> release announcement
> > URL in the changelog.
> >
> > Extrapolating past releases, it will likely show up as:
> > http://kicad-pcb.org/blog/2019/08/KiCad-5.1.4-Release/
> >
> > Any reservations for including this URL in the Changelog?
> >
> > Kind regards,
> >
> > Stefan
> >
> >
> > ___
> > 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
> 

___
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