The problem with this branching method is that virtually no one else but
the developer who is working in a feature branch actually tests the code
in the feature branch. If you are lucky, one other person developer
will test it. That is why I don't really like this model. Our
development branch
There is no formal process. It's primarily based on discussion on the
mailing list and me making the final decisions. The road maps live in
the kicad source repo in the /Documentation/development/ folder. They
definitely need updated. I just haven't gotten around to updating them.
I was going
Do we have a process or workflow for proposing changes to the roadmap? A
number of the things from the V5 roadmap didn't happen, so it might make
sense to move some things around to V6 (and possibly a V5.1) roadmaps
-Jon
On Mon, Mar 5, 2018 at 9:12 AM, Wayne Stambaugh
Jon,
The v6 road map is here:
http://docs.kicad-pcb.org/doxygen/v6_road_map.html
I was planning on working on the schematic object but I wouldn't be
offended if you want to implement it. If you do decide to work on this,
please keep me in the loop. I have some things that I definitely want
It is not possible for me to make any kind of accurate time predictions
about when v6 might be released. KiCad development does not move at a
constant pace. Right now, we are at an all time high with developer
involvement but that may not last. We have had a number of developers
come and go
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
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
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
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
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
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
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
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
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:
>
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
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
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()
No.
> On 4. Mar 2018, at 01:51, Andrey Kuznetsov wrote:
>
> Would it be an easy fix to change the text/font such that it does not affect
> performance so significantly on MacOS?
>
> On Sat, Mar 3, 2018 at 5:20 AM, Wayne Stambaugh
On 03/03/2018 07:33 AM, Jeff Young wrote:
Hi Andrey,
I did some profiling and I’d guess that the difference in eeschema and
pcbnew-legacy performance is down to there being more text in the
schema. Since we use a stroke font, there’s a lot of stroke segments in
each letter.
@Devs,
I
Hi,
to be honest, I don’t really know what this is about.
@Andrey:
You looked for a very complex (foreign) project (Chris mainboard?) to prove
that eeschema is slow on Mac?
Well, we know that and we told you already some weeks/months ago why it is like
it is (if memory serves me right).
Or,
> On Mar 1, 2018, at 8:53 PM, Seth Hillbrand wrote:
>
> Andrey-
>
> I'm moving this to a new thread so that we don't conflate the OpenMP
> discussion with this.
>
> Can you test running Kicad with the "Open in Low Resolution" mode enabled?
> You can activate this
Hi Andrey,
I just tried some and I didn't see a large difference in zoom behavior
between eeschema and pcbnew. They do use different zoom mechanisms when
you use Modern toolset in PcbNew, but the difference is minor.
Eeschema is not hardware-accelerated so I would expect that running it in
low
On 02.03.2018 06:52, Andrey Kuznetsov wrote:
> Thank you to someone on the dev team I guess for getting rid of the mouse
> warp events from right click, however the zoom mouse warp to the center of
> the screen is still a major WTF.
That is an option in preferences -> general -> pan and zoom
Thanks, I didn't know that, Open in Low Resolution definitely speeds up
eeschema, I know kicad has this info on the website, however that fact that
you have to go inside the package and set that to low res mode as far as I
remember was not stated!
The docs should be updated to properly show how
Usually, Eeschema, Pcbnew, etc are links into the KiCad package. If you
right-click and go to "Show Original", you will get the actual
application. Get Info there will allow you to select "Open in Low
Resolution" for that application.
-S
2018-03-02 4:00 GMT+00:00 Andrey Kuznetsov
Only KiCad app has Open in Low Resolution Mode, and I already had it
enabled!
On Thu, Mar 1, 2018 at 7:53 PM, Seth Hillbrand
wrote:
> Andrey-
>
> I'm moving this to a new thread so that we don't conflate the OpenMP
> discussion with this.
>
> Can you test running Kicad
26 matches
Mail list logo