Re: [Kicad-developers] Mac HighDPI performance

Wayne, According to our plan, eeschema GALification is one of the major points of v6 roadmap. We plan to start it early, but I think it is better to begin with the schematic model refactor, as GAL and Tool Framework heavily rely on that. Doing things in reverse order means we will have more code

Re: [Kicad-developers] Mac HighDPI performance

Of course Wayne, that was my way of expressing concern for delaying a performance issue and trying to sauce out your feeling of the possible duration of v6 development. Do you think there is currently manpower and list of features that requires 1 year plus 6 months delay, or do you think it's more

Re: [Kicad-developers] [PATCH] macOS CFBundleName

OK, I’ll merge Michael’s patch as it is (only fixing the mac package strings to match the window titles). @Michael, I merged your patch. Thanks for your contribution. Cheers, Jeff. > On 5 Mar 2018, at 01:06, Wayne Stambaugh wrote: > > The capitalization which has

Re: [Kicad-developers] [PATCH] macOS CFBundleName

The capitalization which has always been part of the original naming scheme, although there have been bugs in the strings from time to time. On 03/04/2018 08:01 PM, Jeff Young wrote: The names or the capitalisation? We’re only suggesting changing the capitalisation, which varies from place

Re: [Kicad-developers] Mac HighDPI performance

When you become the project leader of KiCad, then you can make these decisions and live with the consequences of them. In the mean time, that responsibility falls on my shoulders. We are in a feature freeze for v5 stable so I'm going to err on the side of caution here. If we can pick up

Re: [Kicad-developers] [PATCH] macOS CFBundleName

The names or the capitalisation? We’re only suggesting changing the capitalisation, which varies from place to place anyway. Cheers, Jeff > On 5 Mar 2018, at 00:57, Wayne Stambaugh wrote: > > These are the names assigned by the founder of the project (JP). They are >

Re: [Kicad-developers] [PATCH] macOS CFBundleName

These are the names assigned by the founder of the project (JP). They are not open for debate. On 03/04/2018 07:32 PM, Jeff Young wrote: Anyone care if we go the other way with some of these (ie: rename Eeschema window to EESchema, CvPcb to CvPCB, and Pcbnew to PCBNew)? On 4 Mar 2018, at

Re: [Kicad-developers] [PATCH] macOS CFBundleName

I'd prefer it actually, since it uses proper capitalization of abbreviations. But that's just me and aesthetics. On Sun, Mar 4, 2018 at 4:32 PM, Jeff Young wrote: > Anyone care if we go the other way with some of these (ie: rename Eeschema > window to EESchema, CvPcb to CvPCB,

Re: [Kicad-developers] [PATCH] macOS CFBundleName

Anyone care if we go the other way with some of these (ie: rename Eeschema window to EESchema, CvPcb to CvPCB, and Pcbnew to PCBNew)? > On 4 Mar 2018, at 22:43, Bernhard Stegmaier wrote: > > I guess it just is like that because the Linux binaries are also written like

Re: [Kicad-developers] Mac HighDPI performance

If 6.0 is coming in 1 year, OK, but if it's 2-3 years away then I'd say v5.0 should be stable and not have performance issues, in my mind better to delay v5 up to 1 month at most to fix it rather than let it sit like that for 2-3 years. On Sun, Mar 4, 2018 at 3:39 PM, Jeff Young

Re: [Kicad-developers] Mac HighDPI performance

As for road-map, I’d suggest that EeschemaGAL + newSymbolFileFormat == 6.0. Anything else that can ride along is fine, but not definitive. The legacy stuff represents a tax on all development we do. Cheers, Jeff. > On 4 Mar 2018, at 23:31, Jeff Young wrote: > > Well, I

Re: [Kicad-developers] Mac HighDPI performance

Well, I pounded on it a bit more, and it wasn’t really fitting into “easy” or “straight forward”. It’ll have to wait. Cheers, Jeff. > On 4 Mar 2018, at 20:07, Jon Evans wrote: > > We should probably make some kind of road map if it doesn't exist already, > concerning the

Re: [Kicad-developers] [PATCH] macOS CFBundleName

I guess it just is like that because the Linux binaries are also written like that and it has always been like that… :) Regards, Bernhard > On 4. Mar 2018, at 23:37, Michael Kavanagh wrote: > > The attached trivial patch fixes the app menubar items to match the >

Re: [Kicad-developers] Jumpy canvas on other platforms?

There is actually code in there to make them always on, but there seems to be something defeating it. I’ll poke around some more. > On 4 Mar 2018, at 21:57, Jon Evans wrote: > > Ah yes, I can reproduce that on Windows too. I guess I didn't notice before > because

Re: [Kicad-developers] Jumpy canvas on other platforms?

Ah yes, I can reproduce that on Windows too. I guess I didn't notice before because generally the scrollbars are visible (I noticed that "zoom extents" doesnt *always* result in the scrollbars being hidden, for whatever reason) Any reason why we hide the scrollbars? Seems like it might be

Re: [Kicad-developers] Jumpy canvas on other platforms?

Do a “fit to window” and then pan left/right… I use the touchpad. After “fit to window” there is no scrollbar. When the scrollbar comes back due to panning, I see almost always a small shift of the whole view down and then up again. Sometimes, but not always if you just pan left/right it will

Re: [Kicad-developers] Jumpy canvas on other platforms?

Hi Jon, Yes, I meant the zoom extents. When you open the file it auto-zooms to fit. Therefore you have no scrollbars. But panning with the trackpad (or I imagine middle mouse button) causes it to show the scroll bar which “jumps” the schematic by the width and height of the scrollbars.

Re: [Kicad-developers] MacOS Packaging Question

Yes, it probably still uses the old libs. It is ready when it is ready or someone else submits a patch. 2018-03-04 21:38 GMT+01:00 Andy Peters : > The macOS nightlies still use “old” libraries. By that I mean, for > example, Housings_SOIC instead of Packages_SOIC and the like. >

Re: [Kicad-developers] MacOS Packaging Question

The macOS nightlies still use “old” libraries. By that I mean, for example, Housings_SOIC instead of Packages_SOIC and the like. -a > On Mar 3, 2018, at 7:53 PM, Nick Østergaard wrote: > > This is the current scripts used for the current nightlies for macos >

Re: [Kicad-developers] Jumpy canvas on other platforms?

Maybe I don't really understand what you mean, but I can't see any jumpiness on Linux when panning around (with middle-mouse drag). What do you mean by "it automatically fits to window, so there's not really any place to go"? It does not do any kind of auto-fitting except for the zoom-extents on

[Kicad-developers] Jumpy canvas on other platforms?

If I open an eeschema file on OSX and pan around (it automatically fits to window, so there’s not really any place to go), the screen jumps around a bit. True also on other platforms, or Mac-specific? Thanks, Jeff. ___ Mailing list:

Re: [Kicad-developers] Mac HighDPI performance

We should probably make some kind of road map if it doesn't exist already, concerning the path to GAL for eeschema and who will be doing what. For example, it might make sense to do the SCHEMATIC class refactoring you were talking about before or in parallel with parts of the porting effort. I'm

Re: [Kicad-developers] [PATCH] Fix building on macOS with non-Xcode clang

Bernhard, I merged your patch. Thanks. Wayne On 03/04/2018 07:26 AM, Bernhard Stegmaier wrote: > Hi, > > Attached patch fixes building on macOS with non-Xcode clang: > * To avoid problems make documentation suggest that > cmake_minimum_required(...) has to be the very first statement

Re: [Kicad-developers] Mac HighDPI performance

I agree. If it's not an easy straight forward fix, I would prefer to spend our precious manpower resources on the GAL port as well. I don't know when in the v6 cycle any of this will happen but I'm guessing it will happen fairly early. Tom or Orson, do either of you have any idea when this will

Re: [Kicad-developers] MacOS + OpenMP

Bernhard, On 03/04/2018 02:32 PM, Bernhard Stegmaier wrote: > Wayne, I am seeing the same funny stuff on my old Debian box. > I didn’t follow up, because I thought it might have to do something with my > OpenGL setup… it’s an old Core2Duo which I usually don’t use, so it is not > that good

Re: [Kicad-developers] Mac HighDPI performance

FWIW, I don't find the existing performance to be unusable, it's just not up to the standards of PcbNew/GAL. I don't think it's worth any effort beyond easy fixes, we should put that energy into the GAL port. -Jon On Sun, Mar 4, 2018, 14:34 Bernhard Stegmaier wrote: >

Re: [Kicad-developers] Mac HighDPI performance

I would judge it wrt eeschema GAL conversion. If that starts with v6, I don’t know if it is worth the effort. If it is unsure when this will happen, it might be worth it. > On 4. Mar 2018, at 20:30, Wayne Stambaugh wrote: > > Ughh! I don't have a good answer for this

Re: [Kicad-developers] MacOS + OpenMP

Wayne, I am seeing the same funny stuff on my old Debian box. I didn’t follow up, because I thought it might have to do something with my OpenGL setup… it’s an old Core2Duo which I usually don’t use, so it is not that good maintained. But, the first picture is the OpenGL renderer, so this one

Re: [Kicad-developers] Mac HighDPI performance

Ughh! I don't have a good answer for this one. My best guess is to fix the wx macos code first and see what performance issues are left. The problem with messing with any of this is that if you break something it will break all of the legacy canvas rendering not just the schematic editor. I

Re: [Kicad-developers] MacOS + OpenMP

Orson, no, the raytracing renderer is completely fine in that use-cases. It is only the OpenGL renderer. I first noticed the hang when I switched back from Raytracing to OpenGL (obviously after I did one of the 2 use-cases). If it crashes, I get a backtrace of the crashing thread as follows

Re: [Kicad-developers] Mac HighDPI performance

It turns out the fonts aren’t really the problem. It starts with this gem in wxWidgets: void wxWidgetCocoaImpl::ScrollRect( const wxRect *rect, int dx, int dy ) { #if 1 SetNeedsDisplay() ; #else // We should do something like this, but it wasn't working in 10.4. if (GetNeedsDisplay()

Re: [Kicad-developers] MacOS + OpenMP

Bernhard, I suppose this is about raytrace rendering? Anyway, I see it crashing even without any design loaded. 3D viewer passes the first phase so I see the design rendered, but during 'Post processing shader' stage it crashes. Cheers, Orson On 03/04/2018 07:36 PM, Bernhard Stegmaier wrote: >

Re: [Kicad-developers] MacOS + OpenMP

Debian testing package reports libgomp1 version 8-20180218-1 and CMake finds it as version 4.5. I'm not sure why the disconnect. I'm using gcc 7.3.0. I'll check windows when I get a chance. On 03/04/2018 01:36 PM, Bernhard Stegmaier wrote: > Hi all, > > could please anybody test the

Re: [Kicad-developers] [PATCH] Fix building on macOS with non-Xcode clang

Please note that the fix is only needed with a non-Xcode clang. My cmake is 3.10.x, I had the problem both with clang-5.0.1 and clang-6.0 from MacPorts. clang-6.0 only did work because it defaults to C++-14. Xcode clang is fine without the change. Bernhard > On 4. Mar 2018, at 19:15, Seth

Re: [Kicad-developers] MacOS + OpenMP

Hi all, could please anybody test the following on a Windows/Linux OpenMP version? I have a PCB with only components placed (via “Update from Schematic”), no routing done yet. Make sure 3d-viewer OpenGL rendering is OK, close 3d-viewer. Now, edit a footprint (“e”) and do a “Update Footprint

Re: [Kicad-developers] [PATCH] Fix building on macOS with non-Xcode clang

I see no issues on Mac OS. -S On Mar 4, 2018 10:00 AM, "Wayne Stambaugh" wrote: > I didn't notice any issues on linux builds. Has anyone else confirmed > this doesn't break anything on macos builds? > > On 03/04/2018 07:26 AM, Bernhard Stegmaier wrote: > > Hi, > > > >

Re: [Kicad-developers] [PATCH] Fix building on macOS with non-Xcode clang

I works for me (although I’m using more-or-less the same dev env as Bernhard so it’s not much of a second datapoint). Cheers, Jeff. > On 4 Mar 2018, at 18:00, Wayne Stambaugh wrote: > > I didn't notice any issues on linux builds. Has anyone else confirmed > this

Re: [Kicad-developers] Improving Eagle Import netlist matching

I have just merged the patches. On 02/28/2018 12:38 PM, Russell Oliver wrote: > Hi Orson, > > All I can say is thanks for taking the time to polish this further. > > Just went through the matching code and am now kicking myself that i didn't > think of that approach before. No worries, it was

Re: [Kicad-developers] [PATCH] Fix building on macOS with non-Xcode clang

I didn't notice any issues on linux builds. Has anyone else confirmed this doesn't break anything on macos builds? On 03/04/2018 07:26 AM, Bernhard Stegmaier wrote: > Hi, > > Attached patch fixes building on macOS with non-Xcode clang: > * To avoid problems make documentation suggest that >

Re: [Kicad-developers] [PATCH] Fix clang-mp-6.0 compile error

Bernhard, I merged your patch. Thanks! Wayne On 03/03/2018 02:02 PM, Bernhard Stegmaier wrote: > Hi, > > Small patch to fix a compile error with (MacPorts) clang-6.0-mp. > See >   https://www.mail-archive.com/llvm-bugs@lists.llvm.org/msg20164.html > > > Regards, > Bernhard > > > > > >

Re: [Kicad-developers] Git noob question

With the shorter notation with -r for --rebase 2018-03-03 21:50 GMT+01:00 Maciej Suminski : > [...] git pull would do a fetch and merge together, but you want to fetch >> and rebase -- you can set your .gitconfig to do the fetch and rebase, but I >> think it's easier to

[Kicad-developers] [PATCH] Fix building on macOS with non-Xcode clang

Hi, Attached patch fixes building on macOS with non-Xcode clang: * To avoid problems make documentation suggest that cmake_minimum_required(...) has to be the very first statement directly followed by project(...) * Policy CMP0025 must be set with min version <3.1 to NEW otherwise cmake will