Re: [Kicad-developers] LOCALE_IO sucks

[José Ignacio]

Please go ahead, it makes the code hard to read when instancing an object
in the middle of a function causes a global change in the application.
Encoding should be encapsulated in the streams themselves. Without that,
the ugly hack is the only way to make the even uglier global locale setting
hack be exception safe.

On Mon, Jul 17, 2017 at 7:44 PM, Chris Pavlina 
wrote:

> If I somehow found the time to strip LOCALE_IO completely out of the
> footprint parser without changing the behavior, would anyone have any
> religious objections or otherwise mourn the loss?
>
> --
> Chris
>
> ___
> 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] LOCALE_IO sucks

[Chris Pavlina]

If I somehow found the time to strip LOCALE_IO completely out of the
footprint parser without changing the behavior, would anyone have any
religious objections or otherwise mourn the loss?

-- 
Chris

___
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] Ugly hack in LIB_VIEW_FRAME

[Chris Pavlina]

On Mon, Jul 17, 2017 at 04:29:44PM -0400, Wayne Stambaugh wrote:
> On 7/17/2017 4:15 PM, Chris Pavlina wrote:
> > The following is in LIB_VIEW_FRAME (viewlib_frame.h specifically):
> > 
> > // TODO(hzeller): looks like these members were chosen to be static to 
> > survive different
> > // instances of this browser and communicate it to the next instance. 
> > This looks like an
> > // ugly hack, and should be solved differently.
> > static wxString m_libraryName;
> > 
> > static wxString m_entryName;
> > 
> > Is this a feature anyone needs? I can't see why the browser has to
> > remember its list selection across instances. Will anyone miss this if I
> > just make them non-static?
> > 
> 
> Given that the kiface does not actually destroy the library viewer top
> level window but rather hides it,

I am not so sure about this. If I set a breakpoint on the constructor,
it fires every time I call up the dialog. It looks like there may be an
unnecessary call to Destroy(), I'll look into that.

> defining these variables normally
> shouldn't make any difference in the behavior.  I believe this behavior
> goes back to the pre-kiface days when closing the library viewer would
> actually destroyed the viewer top level window.  I like the fact that
> the viewer comes back to the same point as I left it.  One thing you
> might want to do if you change this is confirm that the behavior of the
> viewer in the stand alone mode is the same as the single app mode.  It
> should be but there are some subtle differences when running apps in the
> stand alone mode versus the single app mode.
> 
> ___
> 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] Ugly hack in LIB_VIEW_FRAME

[Wayne Stambaugh]

On 7/17/2017 4:15 PM, Chris Pavlina wrote:
> The following is in LIB_VIEW_FRAME (viewlib_frame.h specifically):
> 
> // TODO(hzeller): looks like these members were chosen to be static to 
> survive different
> // instances of this browser and communicate it to the next instance. 
> This looks like an
> // ugly hack, and should be solved differently.
> static wxString m_libraryName;
> 
> static wxString m_entryName;
> 
> Is this a feature anyone needs? I can't see why the browser has to
> remember its list selection across instances. Will anyone miss this if I
> just make them non-static?
> 

Given that the kiface does not actually destroy the library viewer top
level window but rather hides it, defining these variables normally
shouldn't make any difference in the behavior.  I believe this behavior
goes back to the pre-kiface days when closing the library viewer would
actually destroyed the viewer top level window.  I like the fact that
the viewer comes back to the same point as I left it.  One thing you
might want to do if you change this is confirm that the behavior of the
viewer in the stand alone mode is the same as the single app mode.  It
should be but there are some subtle differences when running apps in the
stand alone mode versus the single app mode.

___
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] Ugly hack in LIB_VIEW_FRAME

[Chris Pavlina]

The following is in LIB_VIEW_FRAME (viewlib_frame.h specifically):

// TODO(hzeller): looks like these members were chosen to be static to 
survive different
// instances of this browser and communicate it to the next instance. This 
looks like an
// ugly hack, and should be solved differently.
static wxString m_libraryName;

static wxString m_entryName;

Is this a feature anyone needs? I can't see why the browser has to
remember its list selection across instances. Will anyone miss this if I
just make them non-static?

-- 
Chris

___
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] I'm back, and component chooser stuff

[Chris Pavlina]

On Mon, Jul 17, 2017 at 09:38:12AM -0400, Wayne Stambaugh wrote:
> 7/15/2017 10:46 PM, Chris Pavlina wrote:
> > Hey, I'm finally back after a long absence, and haven't been paying
> > attention to the mailing list since like March - there's been way too
> > much for me to go back and read everything since then. Just fyi, if
> > there's been any important discussion relating to my component chooser
> > dialog, might want to ping me again. I'll get it this time.
> > 
> > Still have a list of bugs assigned to myself on the tracker relating to
> > it, so those are known, going to work on some of them this weekend.
> > 
> 
> Welcome back!  Hopefully this will be your last absence for a while.

I'm actually working on stuff this time! :P As usual, decided to do
something simple to reacquaint myself with the code I was working on,
and wx decided to go and make it ten times harder ;)

> 
> Cheers,
> 
> Wayne
> 
> ___
> 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] I'm back, and component chooser stuff

[Wayne Stambaugh]

7/15/2017 10:46 PM, Chris Pavlina wrote:
> Hey, I'm finally back after a long absence, and haven't been paying
> attention to the mailing list since like March - there's been way too
> much for me to go back and read everything since then. Just fyi, if
> there's been any important discussion relating to my component chooser
> dialog, might want to ping me again. I'll get it this time.
> 
> Still have a list of bugs assigned to myself on the tracker relating to
> it, so those are known, going to work on some of them this weekend.
> 

Welcome back!  Hopefully this will be your last absence for a while.

Cheers,

Wayne

___
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] correct text inside two importantplot windows

[Fabrizio Tappero]

gentle reminder.

cheers
Fabrizio


On Mon, Jul 3, 2017 at 10:45 AM, Fabrizio Tappero <
fabrizio.tapp...@gmail.com> wrote:

> Hi JP,
> thanks for it. I updated my wxformbuilder to the latest (3.6v)
> version. And I fixed the (mm) issue you mentioned.
>
> In attachment the patch.
>
> thank you
> Fabrizio
>
>
> On Sat, Jul 1, 2017 at 8:40 PM, jp charras  wrote:
> > Le 30/06/2017 à 15:34, Fabrizio Tappero a écrit :
> >> Hello,
> >> in attachment the patch reviewed after Wayne comments.
> >>
> >> Best regards
> >> Fabrizio
> >>
> >
> > Hi Fabrizio,
> >
> > I had a look at your last patch, and found a few issues:
> > for instance the change:
> >
> > -   m_defaultLineWidthTitle = new wxStaticText( 
> > sbSizerPlotFormat->GetStaticBox(),
> wxID_ANY,
> > _("Default line thickness"), wxDefaultPosition, wxDefaultSize, 0 );
> > +   m_defaultLineWidthTitle = new wxStaticText( 
> > sbSizerPlotFormat->GetStaticBox(),
> wxID_ANY, _("Line
> > Thickness (mm):"), wxDefaultPosition, wxDefaultSize, 0 );
> >
> >
> > is not good for 2 reasons:
> > - "Default line thickness" is the right title (see a previous Wayne's
> answer)
> > - "Line Thickness (mm):" is incorrect:
> > the units symbol " (mm):" is added a run time, because units can be mm
> or inches.
> > so never change titles like "Value" to "Value (mm):".
> > It creates a wrong title.
> >
> > Besides your wxFormBuilder version is rather old and creates incorrect
> C++ sources: please update it.
> >
> > Thanks.
> >
> > --
> > 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] [PATCH] simplied right click menu icons

[Fabrizio Tappero]

gentle reminder.

cheers
Fabrizio


On Tue, Jul 4, 2017 at 6:03 PM, Fabrizio Tappero  wrote:

> Hello,
> following up on the ongoing effort of reducing kicad icons and making
> kicad UI more usable I am sending this patch.
>
> Essentially this patch simplify several icons of the right click menu
> of both eeschema, pcbnew and lib component SW.
>
> Few minor icon look improvements  are also present.
>
> Cheers
> Fabrizio
>
___
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] More aggressive sheet-selection

[Kristoffer Ödmark]

I fixed up some of the code violations I could see, and applied the 
patch to current master, where the sheet selection is working once again.


- Kristoffer

On 07/12/2017 10:01 PM, Kristoffer Ödmark wrote:
The last working revision I copuld test was: 
2c21c70f46dd3ef444ac4a909434697cce972f4a


Right before the new connectivty algorithm.

After that the sheet-selection is not working anymore. So It would be 
nice if you could file a bug report on it :)


  - Kristoffer

On 2017-07-12 13:33, Kristoffer Ödmark wrote:

No worries!

As an example, If i layout a group of components, all which require
the powerpaths as in they need acess to 3v3 lines that are used in
other areas of the board as well. These 3v3 lines might be a bit 
annoying to route for certain cases.


As the code is now, since these 3v3 lines are used as an outside 
connection of the sheet, they will be ignored, even if they only connect
between pads on the same subschematic. Say that the connection to the 
global 3v3 net is handled later with a via or something like that.


The same logic applies to all pins that connect outside the block, and 
in some cases the layout of the blocks have a non-trivial routing to 
get the signal out of the block "area", which is what i noticed when 
using these. Hope this explanation made it more clear


With this more aggressive change. It is also more visible from the pcb 
side to where this "block" has dependencies, I also find it easier to 
deselect segments manually, than to select them if the block is not 
very trivial.


Regarding the code violations, I will have a look later when I get the 
time as well.


the GND thing must indeed be a bug, which I will look into as well.

On 07/12/2017 10:30 AM, Maciej Sumiński wrote:

Hi Kristoffer,

I apologize for such a long delay. Finally I had to time to look at the
patch. I tried it out with a few boards, but I could not really notice a
difference. I read the code and I think I understand what are you trying
to do, but are you sure it is the right way to go? Hierarchical sheets
are frequently used as rooms/channels/duplicated blocks and in my
opinion selecting items belonging to a sheet should be restricted to
items unique to the sheet. Would you give a use case where the new
behavior gives benefits?

Please pay attention to the code formatting, I see a number of
violations there.

Also, I observed a bug when selecting items belonging to the same sheet.
If you open complex_hierarchy demo and use the select action on P3 or
P5, you will notice that all components with a pad connected to GND are
also selected. I can create a bug report if necessary.

Regards,
Orson

On 07/11/2017 05:36 PM, Kristoffer Ödmark wrote:

Well, the sheet-selection code was all submitted by me in the first
place, It doesnt exist in legacy, so this change to how it works is
according to me more inline with what I wanted in the beginning :)

- Kristoffer

On 2017-07-10 21:06, Wayne Stambaugh wrote:

Kristoffer,

This appears to only effect the GAL canvases.  Would one of our 
resident

tool framework experts please take a look at this an see if it makes
sense?  If no one has time, I will try to get to it by this 
weekend.  It
will take most of the week for me to recover from vacation before I 
can

take a look at it.

Thanks,

Wayne

On 7/10/2017 11:21 AM, Kristoffer Ödmark wrote:

Hello!

Second bump, I guess I might be the only one who uses the
sheet-selection then :) My suggestion is to merge this patch in, It
makes the selection more much more useful!

- Kristoffer

On 2017-06-06 13:44, Kristoffer Ödmark wrote:

Hello again!

I understand that everyone is pretty busy, but I would appreciate if
someone took a quick glance at this and said what they think.

- Kristoffer

On 2017-05-03 15:51, Kristoffer Ödmark wrote:

Hello everyone!

I made a small change to the "select hierarchical sheet" 
function. I

would love if someone tried this and gave some feedback.

Before the function only selected segments belonging to a netlist
unique to that hierarchical sheet. Now it will use the "select
logical connection" to every segment connected to module from the
subsheet as well. presonally I think it is more useful now, but I
want confirmation if possible :)

- Kristoffer


___
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