Re: [Kicad-developers] [RFC] On net ties, microwave tools & custom pad shapes, altogether.

[Strontium]

My 2c.

One of the fantastically useful features of eeschema is components have 
an "arbitrary" list of key:value pairs (fields) attached to them as 
attributes.


Can I suggest that such a feature attached to objects on the PCB would 
be even more powerful/useful.


It would mean that changes like the ones suggested would not require 
further format changes to the pcb file, these attributes can be 
added/deleted at will as they are just a key:value pair. It would also 
make the file format backward/forward compatible, pcbnew wont care what 
the key:values are, it can read/edit/propagate them.  If functionality 
exists to utilise them then it can use it, if not, they are passive, 
just like eeschema.


Further, the key:value pairs in eeschema could be imported into the 
matching pcb objects, so that there is only 1 place that needs to be 
edited to set them (the schematic). (I actually think that should be the 
proper place to set them)


And by objects I mean both components AND nets. At the moment only 
components have "fields" on the schematic, the ability to attach them to 
nets would be mighty handy.


It would also be super useful for python scripting, because you can 
tag/parametrise your objects on the pcb and your scripts can then, 
easily, only do things with the appropriately tagged entities.


FOR EXAMPLE:

On the schematic, a key value pair is added to a net:
IMPEDANCE:50
This attribute is set as visible, so when the schematic is printed its 
OBVIOUS that the net needs to be 50Ohm impedance. (It would be great on 
schematic if the visible flag had 3 states: invisible, value only, 
key+value)


On the PCB, a python script is run "adjust_impedance", it scans all nets 
looking for ones with the "IMPEDANCE" key, and then adjusts the width of 
the trace to have that impedance, as required. And if it can't, it 
generates a list of nets which are not the correct impedance, based on 
the board parameters as set in the schematic.


ALL of the features suggested below would be easier to implement with 
such a unified attribute system between schematic/pcb AND would mean 
that fewer changes need to be made to the file formats long term.


Steven J



On 03/05/16 20:40, Tomasz Wlostowski wrote:

Hi all,

Recently there has been a lot of discussion on these features. Here's a
short proposal how we could hit all three birds with one stone:

Changes to SCH:
- none

Changes to netlist import:
- auto_generate flag for SCH components - when set, invokes a Python
script/C++ plugin which updates the PCB footprint of the component
depending on its SCH parameters (e.g. produces a microstrip footprint
based on Width/Length parameters defined on SCH).
- write some microwave component generator plugins (or port the existing
tools). Perhaps a good job for Python.

Changes to PCB:
1) Add two flags to each graphical primitive within a footprint:
- net_tie: DRC treats the primitive as non-conducting and doesn't throw
a short circuit error (see drawing A)
- net_inherit = pad_number: the primitive will take the net of the pad
with given pad_number (see drawing B)
2) Add new 'anchor' virtual pad type.
- indicates the point to attach a trace/via when routing the component.
- exists on a single copper layer.
- has no physical copper.
- has an optional direction vector which denotes how it can be connected
with a trace/other anchor pad (see drawing C)
- has a circular perimeter (maybe other shapes in the future if needed).
Objects intersecting the graphical primitive outside the anchor
perimeter are considered colliding by the DRC (see drawing D) even if
they have the same net.
3) modify .kicad_pcb/footprint formats to support the above:
- extend fp_* entities: net_tie & net_inherit flags
- extend pad entity: add anchor pad type, perimeter radius and direction
vector.
4) modify DRC to support the above (we can benefit from the work already
done by JP)


Advantages:
- microwave footprints generated straight from the schematics.
- net ties for free (since based on the same idea as microwave components)
- custom footprint copper shapes almost for free (costs one extra flag &
some changes in netlist importer)
- minimum changes to file formats & data structures.

The attached drawing shows use cases for all of the above and explains
the concept of anchors.

Looking forward to your feedback,
Tom


___
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] Preferences rework - pcbnew

[José Ignacio]

What about simply removing the legacy canvas preemptively from the
development branch? gal-only is pretty usable by now and it might
reduce development workload for new features.

On Tue, May 3, 2016 at 7:52 AM, Wayne Stambaugh  wrote:
> On 5/2/2016 4:54 PM, Chris Pavlina wrote:
>> I'd like to start having a look at how I can organize the preferences for
>> pcbnew, having mostly finished in eeschema. (A few things remain to be 
>> tweaked
>> and will probably be done at the same time as pcbnew, to keep things in 
>> sync).
>>
>> The problem of legacy preferences vs GAL preferences needs to be addressed. 
>> How
>> do we want to handle that? At this point, I'm not sure what the timeline is 
>> for
>> actual removal of legacy - should I wait until we do that?
>
> This is most likely going to be a while so you wont be able to remove
> the legacy canvas settings until we completely remove the legacy canvas
> from the source.
>
>>
>> If not, I want to try to merge options as much as possible. There are some
>> things that are duplicated between the two, which I'd like to fix. But the
>> bigger question is: how should we present to the user things that are only
>> available in one or the other?
>>
>> I could simply make sections on the preferences pages: "Legacy canvas only",
>> "OpenGL or Cairo canvas only". That's ugly and makes me cringe, but I can't
>> think of anything better. Two separate, parallel preferences systems like we
>> have right now just won't do. Thoughts?
>
> Even though separating the settings is probably going to be ugly, it's
> the most prudent way to go in terms of effort.  If they are organized
> this way, it should be fairly easy to remove them when we finally get
> around to dumping the legacy canvas.
>
>>
>> ___
>> 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] Bitmap fonts (+ dotted grid)

[Chris Pavlina]

I like that the distinction between bright and dark lines was kept into the
dots. The extra coarser grid on top of the fine grid is very useful :)

On Tue, May 03, 2016 at 11:01:35PM +0200, Nick Østergaard wrote:
> 2016-05-03 21:10 GMT+02:00 Bernhard Stegmaier :
> > You are right.
> > I didn’t expect the dots to be different, but every 10th dot is the bigger 
> > one.
> 
> Exactly as is the case with the lines...
> 
> >
> > BTW:
> > I do seem to get a popup “OpenGL 2.1 supported” on every start recently.
> > Is that on intention and what should it tell me (apart from the fact that 
> > OpenGL 2.1 is supported… :) )?
> > It is quite annoying… could this information maybe be moved to the About 
> > dialog?
> >
> >
> > Regards,
> > Bernhard
> >
> >> On 03 May 2016, at 19:14, Simon Wells  wrote:
> >>
> >> bernhard, are the ones that are the easily visible ones the darker
> >> grid lines (ever 5 or so) that are more intense in the line mode
> >>
> >> On Wed, May 4, 2016 at 4:27 AM, Bernhard Stegmaier
> >>  wrote:
> >>> Maybe some anti-aliasing issue?
> >>> For me, dots are also quite small and some of them are barely visible, 
> >>> while
> >>> others look quite normal.
> >>>
> >>> When I played around with the grid dots on OS X in legacy canvas I also 
> >>> had
> >>> a hard time to find a configuration where dots are visible both on (HiDPI)
> >>> retina and normal displays (on OS X also legacy canvas is anti-aliased).
> >>>
> >>> On 03 May 2016, at 18:20, jp charras  wrote:
> >>>
> >>> Le 03/05/2016 à 18:06, Bernhard Stegmaier a écrit :
> >>>
> >>> In the Dimensions => Grid menu you can switch between dots/lines (also 
> >>> took
> >>> me some while, I would have expected it in some preferences dialog).
> >>> I don’t think that it is a (common) wxWidgets 3.1 issue.
> >>> My OS X build uses a wxWidgets master maybe two weeks old and grid is fine
> >>> both with dots and lines.
> >>>
> >>>
> >>> Thanks, Bernhard.
> >>>
> >>> @Orson,
> >>> On wxWidgets 3.1, the dotted grid is not visible on Opengl. The line grid 
> >>> is
> >>> visible.
> >>> On Cairo, both are displayed.
> >>>
> >>>
> >>>
> >>> Regards,
> >>> Bernhard
> >>>
> >>> On 03 May 2016, at 17:46, jp charras  wrote:
> >>>
> >>> Le 03/05/2016 à 15:56, Maciej Sumiński a écrit :
> >>>
> >>> On 05/02/2016 06:33 PM, jp charras wrote:
> >>>
> >>> Le 02/05/2016 à 17:16, Maciej Sumiński a écrit :
> >>>
> >>> As noone had opposed the changes, I have just merged the bitmap fonts
> >>> branch.
> >>>
> >>> As a small bonus, we have also added an option to switch to dotted grid
> >>> in GAL (thanks to Tom for refactoring the grid drawing routine).
> >>>
> >>> Regards,
> >>> Orson
> >>>
> >>>
> >>> A lot of work! Thanks to Tomasz and you.
> >>>
> >>> After a fast and short test, the change looks good.
> >>>
> >>> However, I noticed 2 issues (W7 32 bits on msys2):
> >>> - The grid is not visible on OpenGL, but is visible on Cairo.
> >>> - I can switch between legacy and Cairo, as long I not switched to OpenGL,
> >>> but if I switch to Cairo
> >>> from OpenGL, or from legacy after having previously switched to Opengl,
> >>> Pcbnew crashes.
> >>>
> >>>
> >>> Hi Jean-Pierre,
> >>>
> >>> Is grid invisible in both modes (lines & dots)?
> >>>
> >>>
> >>> How to change the mode ?
> >>>
> >>> Nevertheless, the dot grid is not displayed when using wxWidgets 3.1, and 
> >>> it
> >>> is displayed when using
> >>> wxWidgets 3.0.2.
> >>> I never see issues previously with lines.
> >>>
> >>>
> >>> Would you send me a backtrace? I cannot make it crash on W7_64/msys2.
> >>>
> >>>
> >>> Unfortunately, the bt is small:
> >>> When switching from OpenGL to cairo:
> >>> #0  0x77293c4d in ntdll!DbgBreakPoint () from 
> >>> C:\Windows\SYSTEM32\ntdll.dll
> >>> #1  0x772febef in ntdll!DbgUiRemoteBreakin ()
> >>> from C:\Windows\SYSTEM32\ntdll.dll
> >>> #2  0x29813028 in ?? ()
> >>> #3  0x75b0ef1c in KERNEL32!BaseThreadInitThunk ()
> >>> from C:\Windows\system32\kernel32.dll
> >>> #4  0x772c3648 in ntdll!RtlInitializeExceptionChain ()
> >>> from C:\Windows\SYSTEM32\ntdll.dll
> >>> #5  0x772c361b in ntdll!RtlInitializeExceptionChain ()
> >>> from C:\Windows\SYSTEM32\ntdll.dll
> >>> #6  0x in ?? ()
> >>>
> >>> And when existing in legacy mode (after using Opengl mode):
> >>> #0  0x5628ae51 in ?? () from C:\Windows\system32\ig4icd32.dll
> >>> Backtrace stopped: Cannot access memory at address 0x3
> >>>
> >>>
> >>> More strange, when starting pcbnew (Debug build) in legacy mode and
> >>> switching to Cairo more:
> >>> - crash if running under gdb (giving the same backtrace as when switching
> >>> from OpenGL to cairo,
> >>> therefore this bt is perhaps due only to switching to cairo on gdb).
> >>> - does no crash when running without gdb.
> >>>
> >>>
> >>> Regards,
> >>> Orson
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Jean-Pierre CHARRAS
> >>>
> >>> ___
> >>> Mailing list: https://launchpad.net/~kicad-developers
> >>> 

Re: [Kicad-developers] Preferences rework - pcbnew

[Nick Østergaard]

I can imagine it, but I thought it was necessary to mention the idea.
This task would be easier if we could just get rid of the legacy
canvas. But that probably can't happen immediately, as we all know.

2016-05-03 17:13 GMT+02:00 Chris Pavlina :
> Oh god no. Can you imagine the bug reports from people who can't find 
> settings?
>
> http://i3.kym-cdn.com/photos/images/newsfeed/000/727/910/577.gif
>
> On Tue, May 03, 2016 at 04:41:20PM +0200, Nick Østergaard wrote:
>> Maybe just show or enable the settings if the appropriate canvas is active?
>>
>> 2016-05-03 14:52 GMT+02:00 Wayne Stambaugh :
>> > On 5/2/2016 4:54 PM, Chris Pavlina wrote:
>> >> I'd like to start having a look at how I can organize the preferences for
>> >> pcbnew, having mostly finished in eeschema. (A few things remain to be 
>> >> tweaked
>> >> and will probably be done at the same time as pcbnew, to keep things in 
>> >> sync).
>> >>
>> >> The problem of legacy preferences vs GAL preferences needs to be 
>> >> addressed. How
>> >> do we want to handle that? At this point, I'm not sure what the timeline 
>> >> is for
>> >> actual removal of legacy - should I wait until we do that?
>> >
>> > This is most likely going to be a while so you wont be able to remove
>> > the legacy canvas settings until we completely remove the legacy canvas
>> > from the source.
>> >
>> >>
>> >> If not, I want to try to merge options as much as possible. There are some
>> >> things that are duplicated between the two, which I'd like to fix. But the
>> >> bigger question is: how should we present to the user things that are only
>> >> available in one or the other?
>> >>
>> >> I could simply make sections on the preferences pages: "Legacy canvas 
>> >> only",
>> >> "OpenGL or Cairo canvas only". That's ugly and makes me cringe, but I 
>> >> can't
>> >> think of anything better. Two separate, parallel preferences systems like 
>> >> we
>> >> have right now just won't do. Thoughts?
>> >
>> > Even though separating the settings is probably going to be ugly, it's
>> > the most prudent way to go in terms of effort.  If they are organized
>> > this way, it should be fairly easy to remove them when we finally get
>> > around to dumping the legacy canvas.
>> >
>> >>
>> >> ___
>> >> 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] Bitmap fonts (+ dotted grid)

[Nick Østergaard]

2016-05-03 21:10 GMT+02:00 Bernhard Stegmaier :
> You are right.
> I didn’t expect the dots to be different, but every 10th dot is the bigger 
> one.

Exactly as is the case with the lines...

>
> BTW:
> I do seem to get a popup “OpenGL 2.1 supported” on every start recently.
> Is that on intention and what should it tell me (apart from the fact that 
> OpenGL 2.1 is supported… :) )?
> It is quite annoying… could this information maybe be moved to the About 
> dialog?
>
>
> Regards,
> Bernhard
>
>> On 03 May 2016, at 19:14, Simon Wells  wrote:
>>
>> bernhard, are the ones that are the easily visible ones the darker
>> grid lines (ever 5 or so) that are more intense in the line mode
>>
>> On Wed, May 4, 2016 at 4:27 AM, Bernhard Stegmaier
>>  wrote:
>>> Maybe some anti-aliasing issue?
>>> For me, dots are also quite small and some of them are barely visible, while
>>> others look quite normal.
>>>
>>> When I played around with the grid dots on OS X in legacy canvas I also had
>>> a hard time to find a configuration where dots are visible both on (HiDPI)
>>> retina and normal displays (on OS X also legacy canvas is anti-aliased).
>>>
>>> On 03 May 2016, at 18:20, jp charras  wrote:
>>>
>>> Le 03/05/2016 à 18:06, Bernhard Stegmaier a écrit :
>>>
>>> In the Dimensions => Grid menu you can switch between dots/lines (also took
>>> me some while, I would have expected it in some preferences dialog).
>>> I don’t think that it is a (common) wxWidgets 3.1 issue.
>>> My OS X build uses a wxWidgets master maybe two weeks old and grid is fine
>>> both with dots and lines.
>>>
>>>
>>> Thanks, Bernhard.
>>>
>>> @Orson,
>>> On wxWidgets 3.1, the dotted grid is not visible on Opengl. The line grid is
>>> visible.
>>> On Cairo, both are displayed.
>>>
>>>
>>>
>>> Regards,
>>> Bernhard
>>>
>>> On 03 May 2016, at 17:46, jp charras  wrote:
>>>
>>> Le 03/05/2016 à 15:56, Maciej Sumiński a écrit :
>>>
>>> On 05/02/2016 06:33 PM, jp charras wrote:
>>>
>>> Le 02/05/2016 à 17:16, Maciej Sumiński a écrit :
>>>
>>> As noone had opposed the changes, I have just merged the bitmap fonts
>>> branch.
>>>
>>> As a small bonus, we have also added an option to switch to dotted grid
>>> in GAL (thanks to Tom for refactoring the grid drawing routine).
>>>
>>> Regards,
>>> Orson
>>>
>>>
>>> A lot of work! Thanks to Tomasz and you.
>>>
>>> After a fast and short test, the change looks good.
>>>
>>> However, I noticed 2 issues (W7 32 bits on msys2):
>>> - The grid is not visible on OpenGL, but is visible on Cairo.
>>> - I can switch between legacy and Cairo, as long I not switched to OpenGL,
>>> but if I switch to Cairo
>>> from OpenGL, or from legacy after having previously switched to Opengl,
>>> Pcbnew crashes.
>>>
>>>
>>> Hi Jean-Pierre,
>>>
>>> Is grid invisible in both modes (lines & dots)?
>>>
>>>
>>> How to change the mode ?
>>>
>>> Nevertheless, the dot grid is not displayed when using wxWidgets 3.1, and it
>>> is displayed when using
>>> wxWidgets 3.0.2.
>>> I never see issues previously with lines.
>>>
>>>
>>> Would you send me a backtrace? I cannot make it crash on W7_64/msys2.
>>>
>>>
>>> Unfortunately, the bt is small:
>>> When switching from OpenGL to cairo:
>>> #0  0x77293c4d in ntdll!DbgBreakPoint () from C:\Windows\SYSTEM32\ntdll.dll
>>> #1  0x772febef in ntdll!DbgUiRemoteBreakin ()
>>> from C:\Windows\SYSTEM32\ntdll.dll
>>> #2  0x29813028 in ?? ()
>>> #3  0x75b0ef1c in KERNEL32!BaseThreadInitThunk ()
>>> from C:\Windows\system32\kernel32.dll
>>> #4  0x772c3648 in ntdll!RtlInitializeExceptionChain ()
>>> from C:\Windows\SYSTEM32\ntdll.dll
>>> #5  0x772c361b in ntdll!RtlInitializeExceptionChain ()
>>> from C:\Windows\SYSTEM32\ntdll.dll
>>> #6  0x in ?? ()
>>>
>>> And when existing in legacy mode (after using Opengl mode):
>>> #0  0x5628ae51 in ?? () from C:\Windows\system32\ig4icd32.dll
>>> Backtrace stopped: Cannot access memory at address 0x3
>>>
>>>
>>> More strange, when starting pcbnew (Debug build) in legacy mode and
>>> switching to Cairo more:
>>> - crash if running under gdb (giving the same backtrace as when switching
>>> from OpenGL to cairo,
>>> therefore this bt is perhaps due only to switching to cairo on gdb).
>>> - does no crash when running without gdb.
>>>
>>>
>>> Regards,
>>> Orson
>>>
>>>
>>>
>>>
>>>
>>> --
>>> 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
>>> 
>>>
>>>
>>>
>>>
>>> --
>>> Jean-Pierre CHARRAS
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>>

Re: [Kicad-developers] Bitmap fonts (+ dotted grid)

[Bernhard Stegmaier]

Yes, looks perfect now.
Thanks!

> On 03 May 2016, at 15:20, Maciej Sumiński  wrote:
> 
> Hi Bernhard,
> 
> Good catch, it should be fixed now (revision 6766).
> 
> Regards,
> Orson
> 
> On 05/02/2016 07:24 PM, Bernhard Stegmaier wrote:
>> I already wanted to try over the weekend on OS X before the merge… anyway, 
>> just 
>> tried and it looks fine for me, good work!
>> Oh yes, I love the dotted grid… :)
>> 
>> Just some small cosmetic comments/questions:
>> How is the font size and position of the net name determined?
>> 
>> If you look at the below screenshot:
>> * RTC_INT/RTC_1W is not (vertically) centered on the track as e.g., RXD/TXD, 
>> GND, or Net-(C14-Pad1)
>> * Font of RTC_INT is pretty small in comparison to GND or RXD/TXD… track 
>> width 
>> of RXD/TXD is the same as RTC_*. Similar for GND/+3.3V.
>> 
>> 
>> Regards,
>> Bernhard
>> 
>> 
>> 
>> 
>> 
>>> On 02.05.2016, at 18:33, jp charras >> >> wrote:
>>> 
>>> Le 02/05/2016 à 17:16, Maciej Sumiński a écrit :
 As noone had opposed the changes, I have just merged the bitmap fonts
 branch.
 
 As a small bonus, we have also added an option to switch to dotted grid
 in GAL (thanks to Tom for refactoring the grid drawing routine).
 
 Regards,
 Orson
>>> 
>>> A lot of work! Thanks to Tomasz and you.
>>> 
>>> After a fast and short test, the change looks good.
>>> 
>>> However, I noticed 2 issues (W7 32 bits on msys2):
>>> - The grid is not visible on OpenGL, but is visible on Cairo.
>>> - I can switch between legacy and Cairo, as long I not switched to OpenGL, 
>>> but 
>>> if I switch to Cairo
>>> from OpenGL, or from legacy after having previously switched to Opengl, 
>>> Pcbnew 
>>> crashes.
>>> 
>>> 
>>> -- 
>>> 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 
>>> 
___
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] Bitmap fonts (+ dotted grid)

[Bernhard Stegmaier]

You are right. 
I didn’t expect the dots to be different, but every 10th dot is the bigger one.

BTW:
I do seem to get a popup “OpenGL 2.1 supported” on every start recently.
Is that on intention and what should it tell me (apart from the fact that 
OpenGL 2.1 is supported… :) )?
It is quite annoying… could this information maybe be moved to the About dialog?


Regards,
Bernhard

> On 03 May 2016, at 19:14, Simon Wells  wrote:
> 
> bernhard, are the ones that are the easily visible ones the darker
> grid lines (ever 5 or so) that are more intense in the line mode
> 
> On Wed, May 4, 2016 at 4:27 AM, Bernhard Stegmaier
>  wrote:
>> Maybe some anti-aliasing issue?
>> For me, dots are also quite small and some of them are barely visible, while
>> others look quite normal.
>> 
>> When I played around with the grid dots on OS X in legacy canvas I also had
>> a hard time to find a configuration where dots are visible both on (HiDPI)
>> retina and normal displays (on OS X also legacy canvas is anti-aliased).
>> 
>> On 03 May 2016, at 18:20, jp charras  wrote:
>> 
>> Le 03/05/2016 à 18:06, Bernhard Stegmaier a écrit :
>> 
>> In the Dimensions => Grid menu you can switch between dots/lines (also took
>> me some while, I would have expected it in some preferences dialog).
>> I don’t think that it is a (common) wxWidgets 3.1 issue.
>> My OS X build uses a wxWidgets master maybe two weeks old and grid is fine
>> both with dots and lines.
>> 
>> 
>> Thanks, Bernhard.
>> 
>> @Orson,
>> On wxWidgets 3.1, the dotted grid is not visible on Opengl. The line grid is
>> visible.
>> On Cairo, both are displayed.
>> 
>> 
>> 
>> Regards,
>> Bernhard
>> 
>> On 03 May 2016, at 17:46, jp charras  wrote:
>> 
>> Le 03/05/2016 à 15:56, Maciej Sumiński a écrit :
>> 
>> On 05/02/2016 06:33 PM, jp charras wrote:
>> 
>> Le 02/05/2016 à 17:16, Maciej Sumiński a écrit :
>> 
>> As noone had opposed the changes, I have just merged the bitmap fonts
>> branch.
>> 
>> As a small bonus, we have also added an option to switch to dotted grid
>> in GAL (thanks to Tom for refactoring the grid drawing routine).
>> 
>> Regards,
>> Orson
>> 
>> 
>> A lot of work! Thanks to Tomasz and you.
>> 
>> After a fast and short test, the change looks good.
>> 
>> However, I noticed 2 issues (W7 32 bits on msys2):
>> - The grid is not visible on OpenGL, but is visible on Cairo.
>> - I can switch between legacy and Cairo, as long I not switched to OpenGL,
>> but if I switch to Cairo
>> from OpenGL, or from legacy after having previously switched to Opengl,
>> Pcbnew crashes.
>> 
>> 
>> Hi Jean-Pierre,
>> 
>> Is grid invisible in both modes (lines & dots)?
>> 
>> 
>> How to change the mode ?
>> 
>> Nevertheless, the dot grid is not displayed when using wxWidgets 3.1, and it
>> is displayed when using
>> wxWidgets 3.0.2.
>> I never see issues previously with lines.
>> 
>> 
>> Would you send me a backtrace? I cannot make it crash on W7_64/msys2.
>> 
>> 
>> Unfortunately, the bt is small:
>> When switching from OpenGL to cairo:
>> #0  0x77293c4d in ntdll!DbgBreakPoint () from C:\Windows\SYSTEM32\ntdll.dll
>> #1  0x772febef in ntdll!DbgUiRemoteBreakin ()
>> from C:\Windows\SYSTEM32\ntdll.dll
>> #2  0x29813028 in ?? ()
>> #3  0x75b0ef1c in KERNEL32!BaseThreadInitThunk ()
>> from C:\Windows\system32\kernel32.dll
>> #4  0x772c3648 in ntdll!RtlInitializeExceptionChain ()
>> from C:\Windows\SYSTEM32\ntdll.dll
>> #5  0x772c361b in ntdll!RtlInitializeExceptionChain ()
>> from C:\Windows\SYSTEM32\ntdll.dll
>> #6  0x in ?? ()
>> 
>> And when existing in legacy mode (after using Opengl mode):
>> #0  0x5628ae51 in ?? () from C:\Windows\system32\ig4icd32.dll
>> Backtrace stopped: Cannot access memory at address 0x3
>> 
>> 
>> More strange, when starting pcbnew (Debug build) in legacy mode and
>> switching to Cairo more:
>> - crash if running under gdb (giving the same backtrace as when switching
>> from OpenGL to cairo,
>> therefore this bt is perhaps due only to switching to cairo on gdb).
>> - does no crash when running without gdb.
>> 
>> 
>> Regards,
>> Orson
>> 
>> 
>> 
>> 
>> 
>> --
>> 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
>> 
>> 
>> 
>> 
>> 
>> --
>> 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
>> 
>> 
>> 
>> ___
>> Mailing list: https://launchpad.net/

Re: [Kicad-developers] Bitmap fonts (+ dotted grid)

[Simon Wells]

bernhard, are the ones that are the easily visible ones the darker
grid lines (ever 5 or so) that are more intense in the line mode

On Wed, May 4, 2016 at 4:27 AM, Bernhard Stegmaier
 wrote:
> Maybe some anti-aliasing issue?
> For me, dots are also quite small and some of them are barely visible, while
> others look quite normal.
>
> When I played around with the grid dots on OS X in legacy canvas I also had
> a hard time to find a configuration where dots are visible both on (HiDPI)
> retina and normal displays (on OS X also legacy canvas is anti-aliased).
>
> On 03 May 2016, at 18:20, jp charras  wrote:
>
> Le 03/05/2016 à 18:06, Bernhard Stegmaier a écrit :
>
> In the Dimensions => Grid menu you can switch between dots/lines (also took
> me some while, I would have expected it in some preferences dialog).
> I don’t think that it is a (common) wxWidgets 3.1 issue.
> My OS X build uses a wxWidgets master maybe two weeks old and grid is fine
> both with dots and lines.
>
>
> Thanks, Bernhard.
>
> @Orson,
> On wxWidgets 3.1, the dotted grid is not visible on Opengl. The line grid is
> visible.
> On Cairo, both are displayed.
>
>
>
> Regards,
> Bernhard
>
> On 03 May 2016, at 17:46, jp charras  wrote:
>
> Le 03/05/2016 à 15:56, Maciej Sumiński a écrit :
>
> On 05/02/2016 06:33 PM, jp charras wrote:
>
> Le 02/05/2016 à 17:16, Maciej Sumiński a écrit :
>
> As noone had opposed the changes, I have just merged the bitmap fonts
> branch.
>
> As a small bonus, we have also added an option to switch to dotted grid
> in GAL (thanks to Tom for refactoring the grid drawing routine).
>
> Regards,
> Orson
>
>
> A lot of work! Thanks to Tomasz and you.
>
> After a fast and short test, the change looks good.
>
> However, I noticed 2 issues (W7 32 bits on msys2):
> - The grid is not visible on OpenGL, but is visible on Cairo.
> - I can switch between legacy and Cairo, as long I not switched to OpenGL,
> but if I switch to Cairo
> from OpenGL, or from legacy after having previously switched to Opengl,
> Pcbnew crashes.
>
>
> Hi Jean-Pierre,
>
> Is grid invisible in both modes (lines & dots)?
>
>
> How to change the mode ?
>
> Nevertheless, the dot grid is not displayed when using wxWidgets 3.1, and it
> is displayed when using
> wxWidgets 3.0.2.
> I never see issues previously with lines.
>
>
> Would you send me a backtrace? I cannot make it crash on W7_64/msys2.
>
>
> Unfortunately, the bt is small:
> When switching from OpenGL to cairo:
> #0  0x77293c4d in ntdll!DbgBreakPoint () from C:\Windows\SYSTEM32\ntdll.dll
> #1  0x772febef in ntdll!DbgUiRemoteBreakin ()
>  from C:\Windows\SYSTEM32\ntdll.dll
> #2  0x29813028 in ?? ()
> #3  0x75b0ef1c in KERNEL32!BaseThreadInitThunk ()
>  from C:\Windows\system32\kernel32.dll
> #4  0x772c3648 in ntdll!RtlInitializeExceptionChain ()
>  from C:\Windows\SYSTEM32\ntdll.dll
> #5  0x772c361b in ntdll!RtlInitializeExceptionChain ()
>  from C:\Windows\SYSTEM32\ntdll.dll
> #6  0x in ?? ()
>
> And when existing in legacy mode (after using Opengl mode):
> #0  0x5628ae51 in ?? () from C:\Windows\system32\ig4icd32.dll
> Backtrace stopped: Cannot access memory at address 0x3
>
>
> More strange, when starting pcbnew (Debug build) in legacy mode and
> switching to Cairo more:
> - crash if running under gdb (giving the same backtrace as when switching
> from OpenGL to cairo,
> therefore this bt is perhaps due only to switching to cairo on gdb).
> - does no crash when running without gdb.
>
>
> Regards,
> Orson
>
>
>
>
>
> --
> 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
> 
>
>
>
>
> --
> 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
>
>
>
> ___
> 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] Bitmap fonts (+ dotted grid)

[Bernhard Stegmaier]

Maybe some anti-aliasing issue?
For me, dots are also quite small and some of them are barely visible, while 
others look quite normal.

When I played around with the grid dots on OS X in legacy canvas I also had a 
hard time to find a configuration where dots are visible both on (HiDPI) retina 
and normal displays (on OS X also legacy canvas is anti-aliased).

> On 03 May 2016, at 18:20, jp charras  wrote:
> 
> Le 03/05/2016 à 18:06, Bernhard Stegmaier a écrit :
>> In the Dimensions => Grid menu you can switch between dots/lines (also took 
>> me some while, I would have expected it in some preferences dialog).
>> I don’t think that it is a (common) wxWidgets 3.1 issue.
>> My OS X build uses a wxWidgets master maybe two weeks old and grid is fine 
>> both with dots and lines.
> 
> Thanks, Bernhard.
> 
> @Orson,
> On wxWidgets 3.1, the dotted grid is not visible on Opengl. The line grid is 
> visible.
> On Cairo, both are displayed.
> 
>> 
>> 
>> Regards,
>> Bernhard
>> 
>>> On 03 May 2016, at 17:46, jp charras  wrote:
>>> 
>>> Le 03/05/2016 à 15:56, Maciej Sumiński a écrit :
 On 05/02/2016 06:33 PM, jp charras wrote:
> Le 02/05/2016 à 17:16, Maciej Sumiński a écrit :
>> As noone had opposed the changes, I have just merged the bitmap fonts
>> branch.
>> 
>> As a small bonus, we have also added an option to switch to dotted grid
>> in GAL (thanks to Tom for refactoring the grid drawing routine).
>> 
>> Regards,
>> Orson
> 
> A lot of work! Thanks to Tomasz and you.
> 
> After a fast and short test, the change looks good.
> 
> However, I noticed 2 issues (W7 32 bits on msys2):
> - The grid is not visible on OpenGL, but is visible on Cairo.
> - I can switch between legacy and Cairo, as long I not switched to 
> OpenGL, but if I switch to Cairo
> from OpenGL, or from legacy after having previously switched to Opengl, 
> Pcbnew crashes.
 
 Hi Jean-Pierre,
 
 Is grid invisible in both modes (lines & dots)?
>>> 
>>> How to change the mode ?
>>> 
>>> Nevertheless, the dot grid is not displayed when using wxWidgets 3.1, and 
>>> it is displayed when using
>>> wxWidgets 3.0.2.
>>> I never see issues previously with lines.
>>> 
>>> 
 Would you send me a backtrace? I cannot make it crash on W7_64/msys2.
>>> 
>>> Unfortunately, the bt is small:
>>> When switching from OpenGL to cairo:
>>> #0  0x77293c4d in ntdll!DbgBreakPoint () from C:\Windows\SYSTEM32\ntdll.dll
>>> #1  0x772febef in ntdll!DbgUiRemoteBreakin ()
>>>  from C:\Windows\SYSTEM32\ntdll.dll
>>> #2  0x29813028 in ?? ()
>>> #3  0x75b0ef1c in KERNEL32!BaseThreadInitThunk ()
>>>  from C:\Windows\system32\kernel32.dll
>>> #4  0x772c3648 in ntdll!RtlInitializeExceptionChain ()
>>>  from C:\Windows\SYSTEM32\ntdll.dll
>>> #5  0x772c361b in ntdll!RtlInitializeExceptionChain ()
>>>  from C:\Windows\SYSTEM32\ntdll.dll
>>> #6  0x in ?? ()
>>> 
>>> And when existing in legacy mode (after using Opengl mode):
>>> #0  0x5628ae51 in ?? () from C:\Windows\system32\ig4icd32.dll
>>> Backtrace stopped: Cannot access memory at address 0x3
>>> 
>>> 
>>> More strange, when starting pcbnew (Debug build) in legacy mode and 
>>> switching to Cairo more:
>>> - crash if running under gdb (giving the same backtrace as when switching 
>>> from OpenGL to cairo,
>>> therefore this bt is perhaps due only to switching to cairo on gdb).
>>> - does no crash when running without gdb.
>>> 
 
 Regards,
 Orson
 
 
 
>>> 
>>> 
>>> -- 
>>> 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 
>>>  >> >
>> 
> 
> 
> -- 
> 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 
> 
___
Mailing list: https://launchpad.net/~kicad-developers
Post

Re: [Kicad-developers] Bitmap fonts (+ dotted grid)

[jp charras]

Le 03/05/2016 à 18:06, Bernhard Stegmaier a écrit :
> In the Dimensions => Grid menu you can switch between dots/lines (also took 
> me some while, I would have expected it in some preferences dialog).
> I don’t think that it is a (common) wxWidgets 3.1 issue.
> My OS X build uses a wxWidgets master maybe two weeks old and grid is fine 
> both with dots and lines.

Thanks, Bernhard.

@Orson,
On wxWidgets 3.1, the dotted grid is not visible on Opengl. The line grid is 
visible.
On Cairo, both are displayed.

> 
> 
> Regards,
> Bernhard
> 
>> On 03 May 2016, at 17:46, jp charras  wrote:
>>
>> Le 03/05/2016 à 15:56, Maciej Sumiński a écrit :
>>> On 05/02/2016 06:33 PM, jp charras wrote:
 Le 02/05/2016 à 17:16, Maciej Sumiński a écrit :
> As noone had opposed the changes, I have just merged the bitmap fonts
> branch.
>
> As a small bonus, we have also added an option to switch to dotted grid
> in GAL (thanks to Tom for refactoring the grid drawing routine).
>
> Regards,
> Orson

 A lot of work! Thanks to Tomasz and you.

 After a fast and short test, the change looks good.

 However, I noticed 2 issues (W7 32 bits on msys2):
 - The grid is not visible on OpenGL, but is visible on Cairo.
 - I can switch between legacy and Cairo, as long I not switched to OpenGL, 
 but if I switch to Cairo
 from OpenGL, or from legacy after having previously switched to Opengl, 
 Pcbnew crashes.
>>>
>>> Hi Jean-Pierre,
>>>
>>> Is grid invisible in both modes (lines & dots)?
>>
>> How to change the mode ?
>>
>> Nevertheless, the dot grid is not displayed when using wxWidgets 3.1, and it 
>> is displayed when using
>> wxWidgets 3.0.2.
>> I never see issues previously with lines.
>>
>>
>>> Would you send me a backtrace? I cannot make it crash on W7_64/msys2.
>>
>> Unfortunately, the bt is small:
>> When switching from OpenGL to cairo:
>> #0  0x77293c4d in ntdll!DbgBreakPoint () from C:\Windows\SYSTEM32\ntdll.dll
>> #1  0x772febef in ntdll!DbgUiRemoteBreakin ()
>>   from C:\Windows\SYSTEM32\ntdll.dll
>> #2  0x29813028 in ?? ()
>> #3  0x75b0ef1c in KERNEL32!BaseThreadInitThunk ()
>>   from C:\Windows\system32\kernel32.dll
>> #4  0x772c3648 in ntdll!RtlInitializeExceptionChain ()
>>   from C:\Windows\SYSTEM32\ntdll.dll
>> #5  0x772c361b in ntdll!RtlInitializeExceptionChain ()
>>   from C:\Windows\SYSTEM32\ntdll.dll
>> #6  0x in ?? ()
>>
>> And when existing in legacy mode (after using Opengl mode):
>> #0  0x5628ae51 in ?? () from C:\Windows\system32\ig4icd32.dll
>> Backtrace stopped: Cannot access memory at address 0x3
>>
>>
>> More strange, when starting pcbnew (Debug build) in legacy mode and 
>> switching to Cairo more:
>> - crash if running under gdb (giving the same backtrace as when switching 
>> from OpenGL to cairo,
>> therefore this bt is perhaps due only to switching to cairo on gdb).
>> - does no crash when running without gdb.
>>
>>>
>>> Regards,
>>> Orson
>>>
>>>
>>>
>>
>>
>> -- 
>> 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 
>> 
> 


-- 
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] Bitmap fonts (+ dotted grid)

[Bernhard Stegmaier]

In the Dimensions => Grid menu you can switch between dots/lines (also took me 
some while, I would have expected it in some preferences dialog).
I don’t think that it is a (common) wxWidgets 3.1 issue.
My OS X build uses a wxWidgets master maybe two weeks old and grid is fine both 
with dots and lines.


Regards,
Bernhard

> On 03 May 2016, at 17:46, jp charras  wrote:
> 
> Le 03/05/2016 à 15:56, Maciej Sumiński a écrit :
>> On 05/02/2016 06:33 PM, jp charras wrote:
>>> Le 02/05/2016 à 17:16, Maciej Sumiński a écrit :
 As noone had opposed the changes, I have just merged the bitmap fonts
 branch.
 
 As a small bonus, we have also added an option to switch to dotted grid
 in GAL (thanks to Tom for refactoring the grid drawing routine).
 
 Regards,
 Orson
>>> 
>>> A lot of work! Thanks to Tomasz and you.
>>> 
>>> After a fast and short test, the change looks good.
>>> 
>>> However, I noticed 2 issues (W7 32 bits on msys2):
>>> - The grid is not visible on OpenGL, but is visible on Cairo.
>>> - I can switch between legacy and Cairo, as long I not switched to OpenGL, 
>>> but if I switch to Cairo
>>> from OpenGL, or from legacy after having previously switched to Opengl, 
>>> Pcbnew crashes.
>> 
>> Hi Jean-Pierre,
>> 
>> Is grid invisible in both modes (lines & dots)?
> 
> How to change the mode ?
> 
> Nevertheless, the dot grid is not displayed when using wxWidgets 3.1, and it 
> is displayed when using
> wxWidgets 3.0.2.
> I never see issues previously with lines.
> 
> 
>> Would you send me a backtrace? I cannot make it crash on W7_64/msys2.
> 
> Unfortunately, the bt is small:
> When switching from OpenGL to cairo:
> #0  0x77293c4d in ntdll!DbgBreakPoint () from C:\Windows\SYSTEM32\ntdll.dll
> #1  0x772febef in ntdll!DbgUiRemoteBreakin ()
>   from C:\Windows\SYSTEM32\ntdll.dll
> #2  0x29813028 in ?? ()
> #3  0x75b0ef1c in KERNEL32!BaseThreadInitThunk ()
>   from C:\Windows\system32\kernel32.dll
> #4  0x772c3648 in ntdll!RtlInitializeExceptionChain ()
>   from C:\Windows\SYSTEM32\ntdll.dll
> #5  0x772c361b in ntdll!RtlInitializeExceptionChain ()
>   from C:\Windows\SYSTEM32\ntdll.dll
> #6  0x in ?? ()
> 
> And when existing in legacy mode (after using Opengl mode):
> #0  0x5628ae51 in ?? () from C:\Windows\system32\ig4icd32.dll
> Backtrace stopped: Cannot access memory at address 0x3
> 
> 
> More strange, when starting pcbnew (Debug build) in legacy mode and switching 
> to Cairo more:
> - crash if running under gdb (giving the same backtrace as when switching 
> from OpenGL to cairo,
> therefore this bt is perhaps due only to switching to cairo on gdb).
> - does no crash when running without gdb.
> 
>> 
>> Regards,
>> Orson
>> 
>> 
>> 
> 
> 
> -- 
> 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 
> 
___
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] mode openGL issues after latest updates

[Mário Luzeiro]

Hi Orson,

I tested your new change, still working but I was wondering:

void OPENGL_GAL::BeginUpdate()
{
if( IsShownOnScreen() )
SetCurrent( *OPENGL_GAL::glContext );

On this case shouldn't you not allow the begin of the update at all? (As you 
will not be able to render it)... but I dont know exactly how it is supposed to 
work.

Regards,
Mario


From: Kicad-developers 
[kicad-developers-bounces+mrluzeiro=ua...@lists.launchpad.net] on behalf of 
Mário Luzeiro [mrluze...@ua.pt]
Sent: 03 May 2016 15:27
To: Maciej Sumiński; kicad-developers@lists.launchpad.net
Subject: Re: [Kicad-developers] mode openGL issues after latest updates

I tested (on Windows) and it works!
I didn't feel any issues.
Thanks,
Mario

From: Maciej Sumiński [maciej.sumin...@cern.ch]
Sent: 03 May 2016 15:20
To: Mário Luzeiro; kicad-developers@lists.launchpad.net
Subject: Re: mode openGL issues after latest updates

On 05/03/2016 12:06 PM, Mário Luzeiro wrote:
> Hi Orson,
> I tested the new updates on my branch code, and now on Windows I got this 
> issues after I close the 3d-viewer windows:
>
> Error: mapping vertices buffer: invalid operation
> Error: unmapping vertices buffer: invalid operation
> Error: unbinding vertices buffer:  invalid operation
>
> My guess is that it may be related with oGL context? :S
>
> https://code.launchpad.net/~mrluzeiro/kicad/kicad_new3d-viewer
>
> On Linux it works fine.
>
> Any ideas?
> Regards,
> Mario Luzeiro

Hi Mario,

Thank you for the report. You are right, it was due to invalid OpenGL
context. I was able to recreate the problem on Linux and it should be
fixed now (revision 6769).

Regards,
Orson

___
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] Bitmap fonts (+ dotted grid)

[jp charras]

Le 03/05/2016 à 15:56, Maciej Sumiński a écrit :
> On 05/02/2016 06:33 PM, jp charras wrote:
>> Le 02/05/2016 à 17:16, Maciej Sumiński a écrit :
>>> As noone had opposed the changes, I have just merged the bitmap fonts
>>> branch.
>>>
>>> As a small bonus, we have also added an option to switch to dotted grid
>>> in GAL (thanks to Tom for refactoring the grid drawing routine).
>>>
>>> Regards,
>>> Orson
>>
>> A lot of work! Thanks to Tomasz and you.
>>
>> After a fast and short test, the change looks good.
>>
>> However, I noticed 2 issues (W7 32 bits on msys2):
>> - The grid is not visible on OpenGL, but is visible on Cairo.
>> - I can switch between legacy and Cairo, as long I not switched to OpenGL, 
>> but if I switch to Cairo
>> from OpenGL, or from legacy after having previously switched to Opengl, 
>> Pcbnew crashes.
> 
> Hi Jean-Pierre,
> 
> Is grid invisible in both modes (lines & dots)?

How to change the mode ?

Nevertheless, the dot grid is not displayed when using wxWidgets 3.1, and it is 
displayed when using
wxWidgets 3.0.2.
I never see issues previously with lines.


> Would you send me a backtrace? I cannot make it crash on W7_64/msys2.

Unfortunately, the bt is small:
When switching from OpenGL to cairo:
#0  0x77293c4d in ntdll!DbgBreakPoint () from C:\Windows\SYSTEM32\ntdll.dll
#1  0x772febef in ntdll!DbgUiRemoteBreakin ()
   from C:\Windows\SYSTEM32\ntdll.dll
#2  0x29813028 in ?? ()
#3  0x75b0ef1c in KERNEL32!BaseThreadInitThunk ()
   from C:\Windows\system32\kernel32.dll
#4  0x772c3648 in ntdll!RtlInitializeExceptionChain ()
   from C:\Windows\SYSTEM32\ntdll.dll
#5  0x772c361b in ntdll!RtlInitializeExceptionChain ()
   from C:\Windows\SYSTEM32\ntdll.dll
#6  0x in ?? ()

And when existing in legacy mode (after using Opengl mode):
#0  0x5628ae51 in ?? () from C:\Windows\system32\ig4icd32.dll
Backtrace stopped: Cannot access memory at address 0x3


More strange, when starting pcbnew (Debug build) in legacy mode and switching 
to Cairo more:
- crash if running under gdb (giving the same backtrace as when switching from 
OpenGL to cairo,
therefore this bt is perhaps due only to switching to cairo on gdb).
- does no crash when running without gdb.

> 
> Regards,
> Orson
> 
> 
> 


-- 
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] Preferences rework - pcbnew

[Chris Pavlina]

Oh god no. Can you imagine the bug reports from people who can't find settings?

http://i3.kym-cdn.com/photos/images/newsfeed/000/727/910/577.gif

On Tue, May 03, 2016 at 04:41:20PM +0200, Nick Østergaard wrote:
> Maybe just show or enable the settings if the appropriate canvas is active?
> 
> 2016-05-03 14:52 GMT+02:00 Wayne Stambaugh :
> > On 5/2/2016 4:54 PM, Chris Pavlina wrote:
> >> I'd like to start having a look at how I can organize the preferences for
> >> pcbnew, having mostly finished in eeschema. (A few things remain to be 
> >> tweaked
> >> and will probably be done at the same time as pcbnew, to keep things in 
> >> sync).
> >>
> >> The problem of legacy preferences vs GAL preferences needs to be 
> >> addressed. How
> >> do we want to handle that? At this point, I'm not sure what the timeline 
> >> is for
> >> actual removal of legacy - should I wait until we do that?
> >
> > This is most likely going to be a while so you wont be able to remove
> > the legacy canvas settings until we completely remove the legacy canvas
> > from the source.
> >
> >>
> >> If not, I want to try to merge options as much as possible. There are some
> >> things that are duplicated between the two, which I'd like to fix. But the
> >> bigger question is: how should we present to the user things that are only
> >> available in one or the other?
> >>
> >> I could simply make sections on the preferences pages: "Legacy canvas 
> >> only",
> >> "OpenGL or Cairo canvas only". That's ugly and makes me cringe, but I can't
> >> think of anything better. Two separate, parallel preferences systems like 
> >> we
> >> have right now just won't do. Thoughts?
> >
> > Even though separating the settings is probably going to be ugly, it's
> > the most prudent way to go in terms of effort.  If they are organized
> > this way, it should be fairly easy to remove them when we finally get
> > around to dumping the legacy canvas.
> >
> >>
> >> ___
> >> 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] Preferences rework - pcbnew

[Nick Østergaard]

Maybe just show or enable the settings if the appropriate canvas is active?

2016-05-03 14:52 GMT+02:00 Wayne Stambaugh :
> On 5/2/2016 4:54 PM, Chris Pavlina wrote:
>> I'd like to start having a look at how I can organize the preferences for
>> pcbnew, having mostly finished in eeschema. (A few things remain to be 
>> tweaked
>> and will probably be done at the same time as pcbnew, to keep things in 
>> sync).
>>
>> The problem of legacy preferences vs GAL preferences needs to be addressed. 
>> How
>> do we want to handle that? At this point, I'm not sure what the timeline is 
>> for
>> actual removal of legacy - should I wait until we do that?
>
> This is most likely going to be a while so you wont be able to remove
> the legacy canvas settings until we completely remove the legacy canvas
> from the source.
>
>>
>> If not, I want to try to merge options as much as possible. There are some
>> things that are duplicated between the two, which I'd like to fix. But the
>> bigger question is: how should we present to the user things that are only
>> available in one or the other?
>>
>> I could simply make sections on the preferences pages: "Legacy canvas only",
>> "OpenGL or Cairo canvas only". That's ugly and makes me cringe, but I can't
>> think of anything better. Two separate, parallel preferences systems like we
>> have right now just won't do. Thoughts?
>
> Even though separating the settings is probably going to be ugly, it's
> the most prudent way to go in terms of effort.  If they are organized
> this way, it should be fairly easy to remove them when we finally get
> around to dumping the legacy canvas.
>
>>
>> ___
>> 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] mode openGL issues after latest updates

[Mário Luzeiro]

I tested (on Windows) and it works!
I didn't feel any issues.
Thanks,
Mario

From: Maciej Sumiński [maciej.sumin...@cern.ch]
Sent: 03 May 2016 15:20
To: Mário Luzeiro; kicad-developers@lists.launchpad.net
Subject: Re: mode openGL issues after latest updates

On 05/03/2016 12:06 PM, Mário Luzeiro wrote:
> Hi Orson,
> I tested the new updates on my branch code, and now on Windows I got this 
> issues after I close the 3d-viewer windows:
>
> Error: mapping vertices buffer: invalid operation
> Error: unmapping vertices buffer: invalid operation
> Error: unbinding vertices buffer:  invalid operation
>
> My guess is that it may be related with oGL context? :S
>
> https://code.launchpad.net/~mrluzeiro/kicad/kicad_new3d-viewer
>
> On Linux it works fine.
>
> Any ideas?
> Regards,
> Mario Luzeiro

Hi Mario,

Thank you for the report. You are right, it was due to invalid OpenGL
context. I was able to recreate the problem on Linux and it should be
fixed now (revision 6769).

Regards,
Orson



___
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] mode openGL issues after latest updates

[Maciej Sumiński]

On 05/03/2016 12:06 PM, Mário Luzeiro wrote:
> Hi Orson,
> I tested the new updates on my branch code, and now on Windows I got this 
> issues after I close the 3d-viewer windows:
> 
> Error: mapping vertices buffer: invalid operation
> Error: unmapping vertices buffer: invalid operation
> Error: unbinding vertices buffer:  invalid operation
> 
> My guess is that it may be related with oGL context? :S
> 
> https://code.launchpad.net/~mrluzeiro/kicad/kicad_new3d-viewer
> 
> On Linux it works fine.
> 
> Any ideas?
> Regards,
> Mario Luzeiro

Hi Mario,

Thank you for the report. You are right, it was due to invalid OpenGL
context. I was able to recreate the problem on Linux and it should be
fixed now (revision 6769).

Regards,
Orson




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] PATCH: 3D resolver

[Wayne Stambaugh]

Most of the time! :)

On 5/3/2016 10:15 AM, Chris Pavlina wrote:
> ...but getting to tell people to pound sand is the best part of leading a
> project! ;D
> 
> On Tue, May 03, 2016 at 10:08:03AM -0400, Wayne Stambaugh wrote:
>> I knew you were kidding.  If I didn't have to be concerned with anything
>> else, I would have committed the patch already and told everyone who
>> complained to pound sand.  Unfortunately my role as product leader makes
>> things a bit more complicated.  I'm with you on the c++11 side of
>> things.  We'll get there eventually just not as quickly as I would like.
>>
>> On 5/3/2016 10:05 AM, Chris Pavlina wrote:
>>> FWIW, I meant that to come across like I was kidding, and I'm not entirely 
>>> sure
>>> I managed the right tone to get that across. I understand why you're 
>>> cautious,
>>> though indeed I'm solidly on the pro-C++11 side of things ;)
>>>
>>> On Tue, May 03, 2016 at 09:49:14AM -0400, Wayne Stambaugh wrote:
 On 5/2/2016 8:23 PM, Chris Pavlina wrote:
> On Mon, May 02, 2016 at 11:40:25AM -0400, Wayne Stambaugh wrote:
>> I'm not 100% sure we should pull the plug on mingw32/msys1 just yet.
>> There will most likely be a bunch ubuntu and fedora users who are using
>> older stable versions that this will effect as well.  Personally I'm
>> fine with dumping these older platforms but our users may not feel the
>> same way.  Anyone else have any thoughts about this?
>
> Y'all know *my* thoughts on the matter. >:) Which systems still require a
> non-C++11 compiler anyway? We don't even have to support Geriatric Giraffe
> anymore, there's a new LTS out... Debian supports C++11, Fedora supports 
> C++11,
> we've got no problem building with it on Windows, OS X... So which elderly
> platforms could we possibly still be propping up at this point?
>
> Of course a few users won't like it, you can never make any change without
> ticking off a user or two. https://xkcd.com/1172/ comes to mind. But is
> supporting them worth the trouble?
>
> Seriously, come on - we *already* decided it wasn't, you already said we 
> can
> switch to C++11. Then a bit over a month ago, we asked and you said we 
> should
> be able to start making use of C++11 features in about a month or so. Is 
> the
> C++11 cake a lie? ;)

 I just want to make sure everyone is one board with the potential shit
 storm this could create.  I know how most of the main devs feel about
 c++11.  I want to give everyone a heads up before I commit a change that
 I know will break builds.  I also am probably one of the few (possibly
 only) devs that people outside the project will email directly when they
 are pissed off.  I've come to accept this since I am the project leader
 and my email address is in the public domain but that doesn't mean I
 have to like it so you can understand why I am cautious when committing
 changes like this.

>
>>
>> On 4/24/2016 2:06 AM, Cirilo Bernardo wrote:
>>> The attached patch fixes a cut/paste syntactic error present
>>> in all previous patches. A do{} block was changed to if{} but
>>> the while() expression at the end was not removed.
>>>
>>> - Cirilo
>>>
>>>
>>> On Sun, Apr 24, 2016 at 9:06 AM, Cirilo Bernardo
>>> mailto:cirilo.berna...@gmail.com>> wrote:
>>>
>>> The attached revised patch (against r6710) adds support for 
>>> $(ENV_VAR)
>>> and fixes the bug reported by easyw: "invalid filename" on MSWin 
>>> when
>>> manually editing a file name containing ${ENV_VAR}.
>>>
>>> - Cirilo
>>>
>>>
>>> On Sat, Apr 23, 2016 at 5:29 PM, jp charras >> > wrote:
>>>
>>> Le 23/04/2016 09:16, Cirilo Bernardo a écrit :
>>> > Thanks Jean-Pierre,  I'll go through the 3D model code and 
>>> make sure it can
>>> > use "${" and "$(".  I'm not sure about "%{", "%(" though 
>>> since that wouldn't
>>> > be portable.  In principle there can also be multiple 
>>> substitutions and a
>>> > substitution in the middle of a string such as
>>> > "/path/${VAR1}/${VAR2}/model.wrl"
>>> > but I think the current system should work fine; if people do 
>>> something else
>>> > they can be responsible for the resulting behavior.
>>> >
>>> > - Cirilo
>>>
>>> Supporting both "${" and "$(" is enough for me.
>>> If "${" is the starting point, "}" is the end of var name, and
>>> for "$(" the end of var name is ")"
>>>
>>>
>>> >
>>> > On Sat, Apr 23, 2016 at 4:28 PM, jp charras
>>> mailto:jp.char...@wanadoo.fr>> wrote:
>>> >
>>> >> Le 23/04/2016 01:29, Cirilo Bernardo a écrit :
>>> >>>

Re: [Kicad-developers] PATCH: 3D resolver

[Chris Pavlina]

...but getting to tell people to pound sand is the best part of leading a
project! ;D

On Tue, May 03, 2016 at 10:08:03AM -0400, Wayne Stambaugh wrote:
> I knew you were kidding.  If I didn't have to be concerned with anything
> else, I would have committed the patch already and told everyone who
> complained to pound sand.  Unfortunately my role as product leader makes
> things a bit more complicated.  I'm with you on the c++11 side of
> things.  We'll get there eventually just not as quickly as I would like.
> 
> On 5/3/2016 10:05 AM, Chris Pavlina wrote:
> > FWIW, I meant that to come across like I was kidding, and I'm not entirely 
> > sure
> > I managed the right tone to get that across. I understand why you're 
> > cautious,
> > though indeed I'm solidly on the pro-C++11 side of things ;)
> > 
> > On Tue, May 03, 2016 at 09:49:14AM -0400, Wayne Stambaugh wrote:
> >> On 5/2/2016 8:23 PM, Chris Pavlina wrote:
> >>> On Mon, May 02, 2016 at 11:40:25AM -0400, Wayne Stambaugh wrote:
>  I'm not 100% sure we should pull the plug on mingw32/msys1 just yet.
>  There will most likely be a bunch ubuntu and fedora users who are using
>  older stable versions that this will effect as well.  Personally I'm
>  fine with dumping these older platforms but our users may not feel the
>  same way.  Anyone else have any thoughts about this?
> >>>
> >>> Y'all know *my* thoughts on the matter. >:) Which systems still require a
> >>> non-C++11 compiler anyway? We don't even have to support Geriatric Giraffe
> >>> anymore, there's a new LTS out... Debian supports C++11, Fedora supports 
> >>> C++11,
> >>> we've got no problem building with it on Windows, OS X... So which elderly
> >>> platforms could we possibly still be propping up at this point?
> >>>
> >>> Of course a few users won't like it, you can never make any change without
> >>> ticking off a user or two. https://xkcd.com/1172/ comes to mind. But is
> >>> supporting them worth the trouble?
> >>>
> >>> Seriously, come on - we *already* decided it wasn't, you already said we 
> >>> can
> >>> switch to C++11. Then a bit over a month ago, we asked and you said we 
> >>> should
> >>> be able to start making use of C++11 features in about a month or so. Is 
> >>> the
> >>> C++11 cake a lie? ;)
> >>
> >> I just want to make sure everyone is one board with the potential shit
> >> storm this could create.  I know how most of the main devs feel about
> >> c++11.  I want to give everyone a heads up before I commit a change that
> >> I know will break builds.  I also am probably one of the few (possibly
> >> only) devs that people outside the project will email directly when they
> >> are pissed off.  I've come to accept this since I am the project leader
> >> and my email address is in the public domain but that doesn't mean I
> >> have to like it so you can understand why I am cautious when committing
> >> changes like this.
> >>
> >>>
> 
>  On 4/24/2016 2:06 AM, Cirilo Bernardo wrote:
> > The attached patch fixes a cut/paste syntactic error present
> > in all previous patches. A do{} block was changed to if{} but
> > the while() expression at the end was not removed.
> >
> > - Cirilo
> >
> >
> > On Sun, Apr 24, 2016 at 9:06 AM, Cirilo Bernardo
> > mailto:cirilo.berna...@gmail.com>> wrote:
> >
> > The attached revised patch (against r6710) adds support for 
> > $(ENV_VAR)
> > and fixes the bug reported by easyw: "invalid filename" on MSWin 
> > when
> > manually editing a file name containing ${ENV_VAR}.
> >
> > - Cirilo
> >
> >
> > On Sat, Apr 23, 2016 at 5:29 PM, jp charras  > > wrote:
> >
> > Le 23/04/2016 09:16, Cirilo Bernardo a écrit :
> > > Thanks Jean-Pierre,  I'll go through the 3D model code and 
> > make sure it can
> > > use "${" and "$(".  I'm not sure about "%{", "%(" though 
> > since that wouldn't
> > > be portable.  In principle there can also be multiple 
> > substitutions and a
> > > substitution in the middle of a string such as
> > > "/path/${VAR1}/${VAR2}/model.wrl"
> > > but I think the current system should work fine; if people do 
> > something else
> > > they can be responsible for the resulting behavior.
> > >
> > > - Cirilo
> >
> > Supporting both "${" and "$(" is enough for me.
> > If "${" is the starting point, "}" is the end of var name, and
> > for "$(" the end of var name is ")"
> >
> >
> > >
> > > On Sat, Apr 23, 2016 at 4:28 PM, jp charras
> > mailto:jp.char...@wanadoo.fr>> wrote:
> > >
> > >> Le 23/04/2016 01:29, Cirilo Bernardo a écrit :
> > >>> Hi Wayne,
> > >>>
> > >>>  The attached patch was mad

Re: [Kicad-developers] Bitmap fonts (+ dotted grid)

[Chris Pavlina]

Remember, I'm about to rearrange all the options anyway, so it's probably not
much of a concern where it goes for now. Feel free to begin the preferences
organization bikeshedding on the thread I already started for that, though :D

On Tue, May 03, 2016 at 03:58:21PM +0200, Maciej Sumiński wrote:
> Hi Simon,
> 
> On 05/02/2016 07:08 PM, Simon Wells wrote:
> > just fyi for anyone as dumb/blind as me the option for switching
> > between dots and lines for the grid is in Dimensions->Grid in pcbnew.
> 
> Purposedly I have not left any clues to see if I had picked the right
> place for the setting. Apparently it is not as intuitive as I initially
> thought, so do you know another place that fits beter?
> 
> > Orson, in regards to this as the button on the left with the dotted
> > grid thingy jsut does the damn as the render checkbox for grid might
> > it not be an idea to change the button on the left to switch between
> > dots/lines or dots/lines/none?
> 
> I am not sure if it is a good idea. I believe there are two camps:
> dot-gridders and line-gridders and they never switch sides, so everyone
> would have to go through an unnecessary clicks to skip an unwanted grid
> mode while toggling grid display.
> 
> It would also introduce another inconsistency with the legacy canvas,
> and I would rather avoid it at the moment.
> 
> Regards,
> Orson
> 
> > Simon
> > 
> > On Tue, May 3, 2016 at 3:16 AM, Maciej Sumiński  
> > wrote:
> >> As noone had opposed the changes, I have just merged the bitmap fonts
> >> branch.
> >>
> >> As a small bonus, we have also added an option to switch to dotted grid
> >> in GAL (thanks to Tom for refactoring the grid drawing routine).
> >>
> >> Regards,
> >> Orson
> >>
> >>
> >> ___
> >> 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: 3D resolver

[Wayne Stambaugh]

I knew you were kidding.  If I didn't have to be concerned with anything
else, I would have committed the patch already and told everyone who
complained to pound sand.  Unfortunately my role as product leader makes
things a bit more complicated.  I'm with you on the c++11 side of
things.  We'll get there eventually just not as quickly as I would like.

On 5/3/2016 10:05 AM, Chris Pavlina wrote:
> FWIW, I meant that to come across like I was kidding, and I'm not entirely 
> sure
> I managed the right tone to get that across. I understand why you're cautious,
> though indeed I'm solidly on the pro-C++11 side of things ;)
> 
> On Tue, May 03, 2016 at 09:49:14AM -0400, Wayne Stambaugh wrote:
>> On 5/2/2016 8:23 PM, Chris Pavlina wrote:
>>> On Mon, May 02, 2016 at 11:40:25AM -0400, Wayne Stambaugh wrote:
 I'm not 100% sure we should pull the plug on mingw32/msys1 just yet.
 There will most likely be a bunch ubuntu and fedora users who are using
 older stable versions that this will effect as well.  Personally I'm
 fine with dumping these older platforms but our users may not feel the
 same way.  Anyone else have any thoughts about this?
>>>
>>> Y'all know *my* thoughts on the matter. >:) Which systems still require a
>>> non-C++11 compiler anyway? We don't even have to support Geriatric Giraffe
>>> anymore, there's a new LTS out... Debian supports C++11, Fedora supports 
>>> C++11,
>>> we've got no problem building with it on Windows, OS X... So which elderly
>>> platforms could we possibly still be propping up at this point?
>>>
>>> Of course a few users won't like it, you can never make any change without
>>> ticking off a user or two. https://xkcd.com/1172/ comes to mind. But is
>>> supporting them worth the trouble?
>>>
>>> Seriously, come on - we *already* decided it wasn't, you already said we can
>>> switch to C++11. Then a bit over a month ago, we asked and you said we 
>>> should
>>> be able to start making use of C++11 features in about a month or so. Is the
>>> C++11 cake a lie? ;)
>>
>> I just want to make sure everyone is one board with the potential shit
>> storm this could create.  I know how most of the main devs feel about
>> c++11.  I want to give everyone a heads up before I commit a change that
>> I know will break builds.  I also am probably one of the few (possibly
>> only) devs that people outside the project will email directly when they
>> are pissed off.  I've come to accept this since I am the project leader
>> and my email address is in the public domain but that doesn't mean I
>> have to like it so you can understand why I am cautious when committing
>> changes like this.
>>
>>>

 On 4/24/2016 2:06 AM, Cirilo Bernardo wrote:
> The attached patch fixes a cut/paste syntactic error present
> in all previous patches. A do{} block was changed to if{} but
> the while() expression at the end was not removed.
>
> - Cirilo
>
>
> On Sun, Apr 24, 2016 at 9:06 AM, Cirilo Bernardo
> mailto:cirilo.berna...@gmail.com>> wrote:
>
> The attached revised patch (against r6710) adds support for $(ENV_VAR)
> and fixes the bug reported by easyw: "invalid filename" on MSWin when
> manually editing a file name containing ${ENV_VAR}.
>
> - Cirilo
>
>
> On Sat, Apr 23, 2016 at 5:29 PM, jp charras  > wrote:
>
> Le 23/04/2016 09:16, Cirilo Bernardo a écrit :
> > Thanks Jean-Pierre,  I'll go through the 3D model code and make 
> sure it can
> > use "${" and "$(".  I'm not sure about "%{", "%(" though since 
> that wouldn't
> > be portable.  In principle there can also be multiple 
> substitutions and a
> > substitution in the middle of a string such as
> > "/path/${VAR1}/${VAR2}/model.wrl"
> > but I think the current system should work fine; if people do 
> something else
> > they can be responsible for the resulting behavior.
> >
> > - Cirilo
>
> Supporting both "${" and "$(" is enough for me.
> If "${" is the starting point, "}" is the end of var name, and
> for "$(" the end of var name is ")"
>
>
> >
> > On Sat, Apr 23, 2016 at 4:28 PM, jp charras
> mailto:jp.char...@wanadoo.fr>> wrote:
> >
> >> Le 23/04/2016 01:29, Cirilo Bernardo a écrit :
> >>> Hi Wayne,
> >>>
> >>>  The attached patch was made against r6709.
> >>>
> >>> - Cirilo
> >>
> >> Cirilo, I just had a look at the patch, and noticed a (minor)
> issue:
> >> you are searching an ENV VAR by searching "${"
> >>
> >> This is perfectly true, but incomplete.
> >> wxWidgets accepts both "${" and "$(". (and on windows

Re: [Kicad-developers] PATCH: 3D resolver

[Chris Pavlina]

FWIW, I meant that to come across like I was kidding, and I'm not entirely sure
I managed the right tone to get that across. I understand why you're cautious,
though indeed I'm solidly on the pro-C++11 side of things ;)

On Tue, May 03, 2016 at 09:49:14AM -0400, Wayne Stambaugh wrote:
> On 5/2/2016 8:23 PM, Chris Pavlina wrote:
> > On Mon, May 02, 2016 at 11:40:25AM -0400, Wayne Stambaugh wrote:
> >> I'm not 100% sure we should pull the plug on mingw32/msys1 just yet.
> >> There will most likely be a bunch ubuntu and fedora users who are using
> >> older stable versions that this will effect as well.  Personally I'm
> >> fine with dumping these older platforms but our users may not feel the
> >> same way.  Anyone else have any thoughts about this?
> > 
> > Y'all know *my* thoughts on the matter. >:) Which systems still require a
> > non-C++11 compiler anyway? We don't even have to support Geriatric Giraffe
> > anymore, there's a new LTS out... Debian supports C++11, Fedora supports 
> > C++11,
> > we've got no problem building with it on Windows, OS X... So which elderly
> > platforms could we possibly still be propping up at this point?
> > 
> > Of course a few users won't like it, you can never make any change without
> > ticking off a user or two. https://xkcd.com/1172/ comes to mind. But is
> > supporting them worth the trouble?
> > 
> > Seriously, come on - we *already* decided it wasn't, you already said we can
> > switch to C++11. Then a bit over a month ago, we asked and you said we 
> > should
> > be able to start making use of C++11 features in about a month or so. Is the
> > C++11 cake a lie? ;)
> 
> I just want to make sure everyone is one board with the potential shit
> storm this could create.  I know how most of the main devs feel about
> c++11.  I want to give everyone a heads up before I commit a change that
> I know will break builds.  I also am probably one of the few (possibly
> only) devs that people outside the project will email directly when they
> are pissed off.  I've come to accept this since I am the project leader
> and my email address is in the public domain but that doesn't mean I
> have to like it so you can understand why I am cautious when committing
> changes like this.
> 
> > 
> >>
> >> On 4/24/2016 2:06 AM, Cirilo Bernardo wrote:
> >>> The attached patch fixes a cut/paste syntactic error present
> >>> in all previous patches. A do{} block was changed to if{} but
> >>> the while() expression at the end was not removed.
> >>>
> >>> - Cirilo
> >>>
> >>>
> >>> On Sun, Apr 24, 2016 at 9:06 AM, Cirilo Bernardo
> >>> mailto:cirilo.berna...@gmail.com>> wrote:
> >>>
> >>> The attached revised patch (against r6710) adds support for $(ENV_VAR)
> >>> and fixes the bug reported by easyw: "invalid filename" on MSWin when
> >>> manually editing a file name containing ${ENV_VAR}.
> >>>
> >>> - Cirilo
> >>>
> >>>
> >>> On Sat, Apr 23, 2016 at 5:29 PM, jp charras  >>> > wrote:
> >>>
> >>> Le 23/04/2016 09:16, Cirilo Bernardo a écrit :
> >>> > Thanks Jean-Pierre,  I'll go through the 3D model code and make 
> >>> sure it can
> >>> > use "${" and "$(".  I'm not sure about "%{", "%(" though since 
> >>> that wouldn't
> >>> > be portable.  In principle there can also be multiple 
> >>> substitutions and a
> >>> > substitution in the middle of a string such as
> >>> > "/path/${VAR1}/${VAR2}/model.wrl"
> >>> > but I think the current system should work fine; if people do 
> >>> something else
> >>> > they can be responsible for the resulting behavior.
> >>> >
> >>> > - Cirilo
> >>>
> >>> Supporting both "${" and "$(" is enough for me.
> >>> If "${" is the starting point, "}" is the end of var name, and
> >>> for "$(" the end of var name is ")"
> >>>
> >>>
> >>> >
> >>> > On Sat, Apr 23, 2016 at 4:28 PM, jp charras
> >>> mailto:jp.char...@wanadoo.fr>> wrote:
> >>> >
> >>> >> Le 23/04/2016 01:29, Cirilo Bernardo a écrit :
> >>> >>> Hi Wayne,
> >>> >>>
> >>> >>>  The attached patch was made against r6709.
> >>> >>>
> >>> >>> - Cirilo
> >>> >>
> >>> >> Cirilo, I just had a look at the patch, and noticed a (minor)
> >>> issue:
> >>> >> you are searching an ENV VAR by searching "${"
> >>> >>
> >>> >> This is perfectly true, but incomplete.
> >>> >> wxWidgets accepts both "${" and "$(". (and on windows accept
> >>> also "%{" and
> >>> >> "%(" and more)
> >>> >> The delimiters can be { and } or ( and )
> >>> >> They are equivalent in wxWidgets, and allows using ) or } in
> >>> paths
> >>> >>
> >>> >> (have a look at wxString wxExpandEnvVars(const wxString& str) 
> >>> in
> >>> >> src/common/config.cpp, perhaps it
> >>> >> could be used )
> >

Re: [Kicad-developers] Bitmap fonts (+ dotted grid)

[Maciej Sumiński]

On 05/02/2016 06:33 PM, jp charras wrote:
> Le 02/05/2016 à 17:16, Maciej Sumiński a écrit :
>> As noone had opposed the changes, I have just merged the bitmap fonts
>> branch.
>>
>> As a small bonus, we have also added an option to switch to dotted grid
>> in GAL (thanks to Tom for refactoring the grid drawing routine).
>>
>> Regards,
>> Orson
> 
> A lot of work! Thanks to Tomasz and you.
> 
> After a fast and short test, the change looks good.
> 
> However, I noticed 2 issues (W7 32 bits on msys2):
> - The grid is not visible on OpenGL, but is visible on Cairo.
> - I can switch between legacy and Cairo, as long I not switched to OpenGL, 
> but if I switch to Cairo
> from OpenGL, or from legacy after having previously switched to Opengl, 
> Pcbnew crashes.

Hi Jean-Pierre,

Is grid invisible in both modes (lines & dots)?
Would you send me a backtrace? I cannot make it crash on W7_64/msys2.

Regards,
Orson





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] Bitmap fonts (+ dotted grid)

[Maciej Sumiński]

Hi Simon,

On 05/02/2016 07:08 PM, Simon Wells wrote:
> just fyi for anyone as dumb/blind as me the option for switching
> between dots and lines for the grid is in Dimensions->Grid in pcbnew.

Purposedly I have not left any clues to see if I had picked the right
place for the setting. Apparently it is not as intuitive as I initially
thought, so do you know another place that fits beter?

> Orson, in regards to this as the button on the left with the dotted
> grid thingy jsut does the damn as the render checkbox for grid might
> it not be an idea to change the button on the left to switch between
> dots/lines or dots/lines/none?

I am not sure if it is a good idea. I believe there are two camps:
dot-gridders and line-gridders and they never switch sides, so everyone
would have to go through an unnecessary clicks to skip an unwanted grid
mode while toggling grid display.

It would also introduce another inconsistency with the legacy canvas,
and I would rather avoid it at the moment.

Regards,
Orson

> Simon
> 
> On Tue, May 3, 2016 at 3:16 AM, Maciej Sumiński  
> wrote:
>> As noone had opposed the changes, I have just merged the bitmap fonts
>> branch.
>>
>> As a small bonus, we have also added an option to switch to dotted grid
>> in GAL (thanks to Tom for refactoring the grid drawing routine).
>>
>> Regards,
>> Orson
>>
>>
>> ___
>> 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] PATCH: 3D resolver

[Wayne Stambaugh]

On 5/2/2016 8:23 PM, Chris Pavlina wrote:
> On Mon, May 02, 2016 at 11:40:25AM -0400, Wayne Stambaugh wrote:
>> I'm not 100% sure we should pull the plug on mingw32/msys1 just yet.
>> There will most likely be a bunch ubuntu and fedora users who are using
>> older stable versions that this will effect as well.  Personally I'm
>> fine with dumping these older platforms but our users may not feel the
>> same way.  Anyone else have any thoughts about this?
> 
> Y'all know *my* thoughts on the matter. >:) Which systems still require a
> non-C++11 compiler anyway? We don't even have to support Geriatric Giraffe
> anymore, there's a new LTS out... Debian supports C++11, Fedora supports 
> C++11,
> we've got no problem building with it on Windows, OS X... So which elderly
> platforms could we possibly still be propping up at this point?
> 
> Of course a few users won't like it, you can never make any change without
> ticking off a user or two. https://xkcd.com/1172/ comes to mind. But is
> supporting them worth the trouble?
> 
> Seriously, come on - we *already* decided it wasn't, you already said we can
> switch to C++11. Then a bit over a month ago, we asked and you said we should
> be able to start making use of C++11 features in about a month or so. Is the
> C++11 cake a lie? ;)

I just want to make sure everyone is one board with the potential shit
storm this could create.  I know how most of the main devs feel about
c++11.  I want to give everyone a heads up before I commit a change that
I know will break builds.  I also am probably one of the few (possibly
only) devs that people outside the project will email directly when they
are pissed off.  I've come to accept this since I am the project leader
and my email address is in the public domain but that doesn't mean I
have to like it so you can understand why I am cautious when committing
changes like this.

> 
>>
>> On 4/24/2016 2:06 AM, Cirilo Bernardo wrote:
>>> The attached patch fixes a cut/paste syntactic error present
>>> in all previous patches. A do{} block was changed to if{} but
>>> the while() expression at the end was not removed.
>>>
>>> - Cirilo
>>>
>>>
>>> On Sun, Apr 24, 2016 at 9:06 AM, Cirilo Bernardo
>>> mailto:cirilo.berna...@gmail.com>> wrote:
>>>
>>> The attached revised patch (against r6710) adds support for $(ENV_VAR)
>>> and fixes the bug reported by easyw: "invalid filename" on MSWin when
>>> manually editing a file name containing ${ENV_VAR}.
>>>
>>> - Cirilo
>>>
>>>
>>> On Sat, Apr 23, 2016 at 5:29 PM, jp charras >> > wrote:
>>>
>>> Le 23/04/2016 09:16, Cirilo Bernardo a écrit :
>>> > Thanks Jean-Pierre,  I'll go through the 3D model code and make 
>>> sure it can
>>> > use "${" and "$(".  I'm not sure about "%{", "%(" though since 
>>> that wouldn't
>>> > be portable.  In principle there can also be multiple 
>>> substitutions and a
>>> > substitution in the middle of a string such as
>>> > "/path/${VAR1}/${VAR2}/model.wrl"
>>> > but I think the current system should work fine; if people do 
>>> something else
>>> > they can be responsible for the resulting behavior.
>>> >
>>> > - Cirilo
>>>
>>> Supporting both "${" and "$(" is enough for me.
>>> If "${" is the starting point, "}" is the end of var name, and
>>> for "$(" the end of var name is ")"
>>>
>>>
>>> >
>>> > On Sat, Apr 23, 2016 at 4:28 PM, jp charras
>>> mailto:jp.char...@wanadoo.fr>> wrote:
>>> >
>>> >> Le 23/04/2016 01:29, Cirilo Bernardo a écrit :
>>> >>> Hi Wayne,
>>> >>>
>>> >>>  The attached patch was made against r6709.
>>> >>>
>>> >>> - Cirilo
>>> >>
>>> >> Cirilo, I just had a look at the patch, and noticed a (minor)
>>> issue:
>>> >> you are searching an ENV VAR by searching "${"
>>> >>
>>> >> This is perfectly true, but incomplete.
>>> >> wxWidgets accepts both "${" and "$(". (and on windows accept
>>> also "%{" and
>>> >> "%(" and more)
>>> >> The delimiters can be { and } or ( and )
>>> >> They are equivalent in wxWidgets, and allows using ) or } in
>>> paths
>>> >>
>>> >> (have a look at wxString wxExpandEnvVars(const wxString& str) in
>>> >> src/common/config.cpp, perhaps it
>>> >> could be used )
>>> >>
>>> >>
>>> >> This in important because we are using both in Kicad.
>>> >> for instance the fp lib wizard uses $(xxx) and in docs we use
>>> ${xxx}
>>> >> notation
>>> >>
>>> >> Thanks.
>>> >>
>>> >>>
>>> >>>
>>> >>> On Sat, Apr 23, 2016 at 12:52 AM, Wayne Stambaugh
>>> mailto:stambau...@gmail.com>>
>>> >>> wrote:
>>> >>>
>>>  Cirilo,
>>> 
>>> >>

Re: [Kicad-developers] mode openGL issues after latest updates

[Maciej Sumiński]

On 05/03/2016 03:23 PM, Wayne Stambaugh wrote:
> On 5/3/2016 6:58 AM, jp charras wrote:
>> Le 03/05/2016 à 12:06, Mário Luzeiro a écrit :
>>> Hi Orson,
>>> I tested the new updates on my branch code, and now on Windows I got this 
>>> issues after I close the 3d-viewer windows:
>>>
>>> Error: mapping vertices buffer: invalid operation
>>> Error: unmapping vertices buffer: invalid operation
>>> Error: unbinding vertices buffer:  invalid operation
>>>
>>> My guess is that it may be related with oGL context? :S
>>>
>>> https://code.launchpad.net/~mrluzeiro/kicad/kicad_new3d-viewer
>>>
>>> On Linux it works fine.
>>>
>>
>> On Windows (W7, 32 bits) I have found an other issue:
>> When closing Pcbnew, it crashes, if the opengl mode was used, and if the 
>> legacy mode is activated
>> when closing pcbnew.
>> When closing Pcbnew on legacy mode, it does not crash if the opengl mode is 
>> never activated.
>> When closing Pcbnew on opengl mode, it does not crash.
>>
>>
> 
> The Cairo text rendering on my win 7 pro computer is broken with the
> changes.  Attached are the before and after screen shoots.  The text
> rendering looks fine on the OpenGL canvas.

Hi Wayne,

It has just been fixed (revision 6767).

Regards,
Orson




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] Bitmap fonts (+ dotted grid)

[Maciej Sumiński]

Hi Bernhard,

Good catch, it should be fixed now (revision 6766).

Regards,
Orson

On 05/02/2016 07:24 PM, Bernhard Stegmaier wrote:
> I already wanted to try over the weekend on OS X before the merge… anyway, 
> just 
> tried and it looks fine for me, good work!
> Oh yes, I love the dotted grid… :)
> 
> Just some small cosmetic comments/questions:
> How is the font size and position of the net name determined?
> 
> If you look at the below screenshot:
> * RTC_INT/RTC_1W is not (vertically) centered on the track as e.g., RXD/TXD, 
> GND, or Net-(C14-Pad1)
> * Font of RTC_INT is pretty small in comparison to GND or RXD/TXD… track 
> width 
> of RXD/TXD is the same as RTC_*. Similar for GND/+3.3V.
> 
> 
> Regards,
> Bernhard
> 
> 
> 
> 
> 
>> On 02.05.2016, at 18:33, jp charras > > wrote:
>>
>> Le 02/05/2016 à 17:16, Maciej Sumiński a écrit :
>>> As noone had opposed the changes, I have just merged the bitmap fonts
>>> branch.
>>>
>>> As a small bonus, we have also added an option to switch to dotted grid
>>> in GAL (thanks to Tom for refactoring the grid drawing routine).
>>>
>>> Regards,
>>> Orson
>>
>> A lot of work! Thanks to Tomasz and you.
>>
>> After a fast and short test, the change looks good.
>>
>> However, I noticed 2 issues (W7 32 bits on msys2):
>> - The grid is not visible on OpenGL, but is visible on Cairo.
>> - I can switch between legacy and Cairo, as long I not switched to OpenGL, 
>> but 
>> if I switch to Cairo
>> from OpenGL, or from legacy after having previously switched to Opengl, 
>> Pcbnew 
>> crashes.
>>
>>
>> -- 
>> 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
> 




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] Preferences rework - pcbnew

[Wayne Stambaugh]

On 5/2/2016 4:54 PM, Chris Pavlina wrote:
> I'd like to start having a look at how I can organize the preferences for
> pcbnew, having mostly finished in eeschema. (A few things remain to be tweaked
> and will probably be done at the same time as pcbnew, to keep things in sync).
> 
> The problem of legacy preferences vs GAL preferences needs to be addressed. 
> How
> do we want to handle that? At this point, I'm not sure what the timeline is 
> for
> actual removal of legacy - should I wait until we do that?

This is most likely going to be a while so you wont be able to remove
the legacy canvas settings until we completely remove the legacy canvas
from the source.

> 
> If not, I want to try to merge options as much as possible. There are some
> things that are duplicated between the two, which I'd like to fix. But the
> bigger question is: how should we present to the user things that are only
> available in one or the other?
> 
> I could simply make sections on the preferences pages: "Legacy canvas only",
> "OpenGL or Cairo canvas only". That's ugly and makes me cringe, but I can't
> think of anything better. Two separate, parallel preferences systems like we
> have right now just won't do. Thoughts?

Even though separating the settings is probably going to be ugly, it's
the most prudent way to go in terms of effort.  If they are organized
this way, it should be fairly easy to remove them when we finally get
around to dumping the legacy canvas.

> 
> ___
> 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] On net ties, microwave tools & custom pad shapes, altogether.

[Tomasz Wlostowski]

Hi all,

Recently there has been a lot of discussion on these features. Here's a
short proposal how we could hit all three birds with one stone:

Changes to SCH:
- none

Changes to netlist import:
- auto_generate flag for SCH components - when set, invokes a Python
script/C++ plugin which updates the PCB footprint of the component
depending on its SCH parameters (e.g. produces a microstrip footprint
based on Width/Length parameters defined on SCH).
- write some microwave component generator plugins (or port the existing
tools). Perhaps a good job for Python.

Changes to PCB:
1) Add two flags to each graphical primitive within a footprint:
- net_tie: DRC treats the primitive as non-conducting and doesn't throw
a short circuit error (see drawing A)
- net_inherit = pad_number: the primitive will take the net of the pad
with given pad_number (see drawing B)
2) Add new 'anchor' virtual pad type.
- indicates the point to attach a trace/via when routing the component.
- exists on a single copper layer.
- has no physical copper.
- has an optional direction vector which denotes how it can be connected
with a trace/other anchor pad (see drawing C)
- has a circular perimeter (maybe other shapes in the future if needed).
Objects intersecting the graphical primitive outside the anchor
perimeter are considered colliding by the DRC (see drawing D) even if
they have the same net.
3) modify .kicad_pcb/footprint formats to support the above:
- extend fp_* entities: net_tie & net_inherit flags
- extend pad entity: add anchor pad type, perimeter radius and direction
vector.
4) modify DRC to support the above (we can benefit from the work already
done by JP)


Advantages:
- microwave footprints generated straight from the schematics.
- net ties for free (since based on the same idea as microwave components)
- custom footprint copper shapes almost for free (costs one extra flag &
some changes in netlist importer)
- minimum changes to file formats & data structures.

The attached drawing shows use cases for all of the above and explains
the concept of anchors.

Looking forward to your feedback,
Tom


shapes.pdf
Description: video/flv
___
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] PCBNEW B.SilkS text rotation problems, is any one working on this or have see this bugs, on (bzr 6765)

[Nick Østergaard]

I am sure this is related to pcbnew refusing to put text upside down.
Den 03/05/2016 14.36 skrev "jp charras" :

> Le 03/05/2016 à 14:18, Lachlan Audas a écrit :
> > Hi  JP,
> >
> > Try Vertical  alignment,   ie +90 and -90 .. when you on the B.SilkS
> > also so note it come's back with  -0.0   IE it prefix's the deg's with  a
> > minus sing.. in some cases.
> > try 0.0 and 0.1 deg's,  and also jumps the text to new X,Y position,  in
> > some case's   try importing   from Eagle pcb file..  and see how it gets
> it
> > wrong...
> > works fine on the top layer  IE   F.SilkS
> > if  you like I can make a screen cast all all the bugs.
> >
> > Lachlan
> >
>
> No, I do not see any issue.
> Are you using the legacy canvas or the opengl canvas ?
>
> Send us a screen copy.
>
>
> --
> 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
>
___
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] PCBNEW B.SilkS text rotation problems, is any one working on this or have see this bugs, on (bzr 6765)

[jp charras]

Le 03/05/2016 à 14:18, Lachlan Audas a écrit :
> Hi  JP,
> 
> Try Vertical  alignment,   ie +90 and -90 .. when you on the B.SilkS
> also so note it come's back with  -0.0   IE it prefix's the deg's with  a
> minus sing.. in some cases.
> try 0.0 and 0.1 deg's,  and also jumps the text to new X,Y position,  in
> some case's   try importing   from Eagle pcb file..  and see how it gets it
> wrong...
> works fine on the top layer  IE   F.SilkS
> if  you like I can make a screen cast all all the bugs.
> 
> Lachlan
> 

No, I do not see any issue.
Are you using the legacy canvas or the opengl canvas ?

Send us a screen copy.


-- 
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] PCBNEW B.SilkS text rotation problems, is any one working on this or have see this bugs, on (bzr 6765)

[jp charras]

Le 03/05/2016 à 11:02, Lachlan Audas a écrit :
> Hi,   the text rotation has many problem,  for the B.SilkS  layer
> has any one else seen this ?  or working on the bugs ?
> 

What bug? I do not have any issue. I do not see what you mean.


-- 
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] mode openGL issues after latest updates

[jp charras]

Le 03/05/2016 à 12:06, Mário Luzeiro a écrit :
> Hi Orson,
> I tested the new updates on my branch code, and now on Windows I got this 
> issues after I close the 3d-viewer windows:
> 
> Error: mapping vertices buffer: invalid operation
> Error: unmapping vertices buffer: invalid operation
> Error: unbinding vertices buffer:  invalid operation
> 
> My guess is that it may be related with oGL context? :S
> 
> https://code.launchpad.net/~mrluzeiro/kicad/kicad_new3d-viewer
> 
> On Linux it works fine.
> 

On Windows (W7, 32 bits) I have found an other issue:
When closing Pcbnew, it crashes, if the opengl mode was used, and if the legacy 
mode is activated
when closing pcbnew.
When closing Pcbnew on legacy mode, it does not crash if the opengl mode is 
never activated.
When closing Pcbnew on opengl mode, it does not crash.


-- 
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

[Kicad-developers] mode openGL issues after latest updates

[Mário Luzeiro]

Hi Orson,
I tested the new updates on my branch code, and now on Windows I got this 
issues after I close the 3d-viewer windows:

Error: mapping vertices buffer: invalid operation
Error: unmapping vertices buffer: invalid operation
Error: unbinding vertices buffer:  invalid operation

My guess is that it may be related with oGL context? :S

https://code.launchpad.net/~mrluzeiro/kicad/kicad_new3d-viewer

On Linux it works fine.

Any ideas?
Regards,
Mario Luzeiro
___
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] PCBNEW B.SilkS text rotation problems, is any one working on this or have see this bugs, on (bzr 6765)

[Lachlan Audas]

Hi,   the text rotation has many problem,  for the B.SilkS  layer
has any one else seen this ?  or working on the bugs ?

This also shows up on Eagle PCB import.

As a side note,  the rotation dialog is overly complex.
IE there is no need to have a button for other  to access the deg rotation.
You should be just able to just type the new angle,  without the need hit
the "other" button.
Better still,  any change to the any of the field's  should immediately
update.
Save the endless change vale click OK.. Change vale click OK..  loop to see
the results.

Lachlan.

PS version info followers.



Application: pcbnew
Version: (2016-05-02 BZR 6765)-product, release build
Libraries: wxWidgets 3.0.2
   libcurl/7.38.0 OpenSSL/1.0.1k zlib/1.2.8 libidn/1.29
libssh2/1.4.3 librtmp/2.3
Platform: Linux 4.3.0 x86_64, 64 bit, Little endian, wxGTK
- Build Info -
wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8)
Boost: 1.55.0
Curl: 7.38.0
KiCad - Compiler: GCC 4.9.2 with C++ ABI 1002
Settings: USE_WX_GRAPHICS_CONTEXT=OFF
  USE_WX_OVERLAY=OFF
  KICAD_SCRIPTING=OFF
  KICAD_SCRIPTING_MODULES=OFF
  KICAD_SCRIPTING_WXPYTHON=OFF
  USE_FP_LIB_TABLE=HARD_CODED_ON
  BUILD_GITHUB_PLUGIN=ON
___
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] Debian and Ubuntu packaging.

[Эльдар Хайруллин]

 Hello.
You need should to look to Ubuntu Snappy packaging  
https://developer.ubuntu.com/en/snappy/   .
Solve problems with versions of 3-party dependency libraries (provide only 
properly tested versions).
Support of Snappy building  in  https://launchpad.net  .
Simple add to the Ubuntu Store without delays.
Several versions of Kicad together on PC.

>Вторник,  3 мая 2016, 1:59 +03:00 от Adam Wolf :
>
>I think this is definitely doable.  Can we do this on Miguel's machine?  Let 
>me know if we can't.
>
>Adam Wolf
>
>On Mon, May 2, 2016 at 3:07 PM, Wayne Stambaugh  < stambau...@gmail.com > 
>wrote:
>>On 5/2/2016 3:44 PM, Chris Pavlina wrote:
>>> To be entirely honest and somewhat opinionated, I have no problem telling
>>> Debian users that they chose a distribution that tampers with packages and 
>>> so
>>> they get to live with it. KiCad's easy to build anyway, should they decide 
>>> they
>>> don't like that choice.
>>
>>I'm fine with that as well.  I would rather avoid have users build kicad
>>from source though.
>>
>>>
>>> Perhaps we could provide our own Debian and Ubuntu packages, like the Ubuntu
>>> nightly PPA.
>>
>>This is a better alternative than building from source.
>>
>>>
>>> On Mon, May 02, 2016 at 03:35:48PM -0400, Wayne Stambaugh wrote:
 On 5/2/2016 3:25 PM, Nick Østergaard wrote:
> 2016-05-02 21:09 GMT+02:00 Wayne Stambaugh < stambau...@gmail.com >:
>> Do we have any Debian developers on our mailing list?  I though I saw a
>> Simon Richter on Planet Debian.  Is that you Simon?  Can someone tell me
>> why the Debian package devs decided to build KiCad with the GitHub
>> plugin disabled?  Is it a build issue or a licensing issue?
>
> Because of OpenSSL licensing stuff...
>
> Citing the debian packager:
>
> "I had to remove the Github plugin from the build process, because this
> plugins needed to compile a binary which is linked to GPLed libraries
> and to OpenSSL at the same time, which triggers a fata Lintian error
> about license incompatibility. However as the package kicad-common
> provides all the know pretty libraies, and as the default template
> declares those libraries, there is no immediate drawback.
>
> Best regards, Georges."
>
> --  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794311

 No immediate drawback for Debian when the bug reports come to us.  I
 guess we tell users no github plugin for you.  They will have to update
 their fp-lib-table accordingly.

>
>> Avhttp is
>> licensed under the boost license so it shouldn't be due to licensing
>> issues.  A warning would have been nice before we were blind sided by a
>> bunch of bug reports.  I don't have time to look it up right now so if
>> someone has time to do some digging I would appreciate it.
>
> I think this has been mentioned on the list before. Part of the goal
> with the curl instead of avhttp was to remove the dependency on
> openssl, which debian rejects... Because libcurl can use gnutls in
> debian.
>
> I know it is hard to remeber everything, but people tried to warn us
> in  https://lists.launchpad.net/kicad-developers/msg22543.html
>
> I got so confused with all the agressive reverts of the curl stuff
> that I don't even know if we use that now.

 We now use libcurl so if Debain's libcurl is compliant than there should
 be no issues packaging with the github plugin enabled for the
 development branch.

>
>>
>> Thanks,
>>
>> 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
>>
>>___
>>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


С уважением,
Эльдар Хайруллин
eldar.khayrul...@mail.ru
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-dev