Re: [Kicad-developers] COMPONENT_TREE performance

2018-01-11 Thread Jörg Hermann
Gaurav asked for examples using Qt: Eagle. As they implemented their awkward UI across all OS, I see no problems whatsoever for Kicad. Having done multiplatform / multiarchitecture releases with Qt, I can confirm it was totally stable and automatized. Wayne is correct, a huge amount of effort

Re: [Kicad-developers] COMPONENT_TREE performance

2017-12-04 Thread Wayne Stambaugh
Bernhard, Please file a bug report(s) so we know about the issue(s) and fix them. They tend to get lost in the dev mailing list noise. I haven't used the new symbol table view at all other than so initial testing so I suspect there are some bugs in there. Hopefully the developer who did the

Re: [Kicad-developers] COMPONENT_TREE performance

2017-12-04 Thread Bernhard Stegmaier
Hi, a bit of topic, but just out of curiosity… I tried to use “Component Table View” of eeschema recently in one of my projects - on macOS of course. Nice to have a look at the parts, but apart from that not usable at all. Most of the time I cannot enter something into the grid cells, I have to

Re: [Kicad-developers] COMPONENT_TREE performance

2017-12-04 Thread Oliver Walters
Perhaps to help prevent the discussion bubbling up unbidden every few months, we should create a document which formalises: 1. Gripes or difficulties with wx 2. Features we would require in some hypothetical GUI toolkit 3. Pros/cons of each toolkit This document could be updated as we discover

Re: [Kicad-developers] COMPONENT_TREE performance

2017-12-04 Thread Gaurav Juvekar
Hi all, > > I wondered when this subject would rear it's ugly head again. Every > couple of years we dig this horse up and beat it to death again. It's > getting rather comical. Like JP, I would like to see some proof of all > the wonderful things QT can do for us that wx cannot. It has been

Re: [Kicad-developers] COMPONENT_TREE performance

2017-12-04 Thread Chris Pavlina
I haven't had any complaints yet, just want to make sure everyone knows there is basically only one way you can do it that works well. On Dec 4, 2017 13:21, "Maciej Suminski" wrote: > Hi Chris, > > I suppose I am the main wrestler and as far as I can tell, >

Re: [Kicad-developers] COMPONENT_TREE performance

2017-12-04 Thread Maciej Suminski
Hi Chris, I suppose I am the main wrestler and as far as I can tell, wxDataViewCtrl tree works very differently on each platform. I tried to implement dynamic updates, then have jumped through numerous wxRingsOfFire and in the end I have returned to your approach. It should works as fast as in

Re: [Kicad-developers] COMPONENT_TREE performance

2017-12-04 Thread Chris Pavlina
I really hope the original point of the thread is not lost in the 53rd boring repeat of this argument. PLEASE test COMPONENT_TREE on macOS, I don't want to have to fix it myself if it's slow again. On Mon, Dec 04, 2017 at 07:44:19PM +, Wayne Stambaugh wrote: > On 12/4/2017 1:47 PM, jp charras

Re: [Kicad-developers] COMPONENT_TREE performance

2017-12-04 Thread Wayne Stambaugh
On 12/4/2017 1:47 PM, jp charras wrote: > Le 04/12/2017 à 18:53, Tomasz Wlostowski a écrit : >> On 04/12/17 18:48, Chris Pavlina wrote: >>> Hey, just a comment because I see people are wrestling with >>> COMPONENT_TREE performance as I did when writing it. TEST ON MACOS. The >>> performance of the

Re: [Kicad-developers] COMPONENT_TREE performance

2017-12-04 Thread jp charras
Le 04/12/2017 à 18:53, Tomasz Wlostowski a écrit : > On 04/12/17 18:48, Chris Pavlina wrote: >> Hey, just a comment because I see people are wrestling with >> COMPONENT_TREE performance as I did when writing it. TEST ON MACOS. The >> performance of the widget there has a really different profile

Re: [Kicad-developers] COMPONENT_TREE performance

2017-12-04 Thread Jon Evans
Yes, so we could perhaps extend this to cover the other common areas where we use the UI toolkit for non-UI things (mostly OS interaction, I guess), although at some point it becomes about more than just tools, so the name might be confusing. On Mon, Dec 4, 2017 at 1:28 PM, Tomasz Wlostowski

Re: [Kicad-developers] COMPONENT_TREE performance

2017-12-04 Thread Tomasz Wlostowski
On 04/12/17 19:23, Jon Evans wrote: > It's probably a good idea to implement a "toolkit abstraction layer" if > we ever go down this road, so that we wouldn't have to do it *again* if > we ever switch again. This is the very purpose of the internal event system (TOOL_EVENT, TOOL_ACTION,

Re: [Kicad-developers] COMPONENT_TREE performance

2017-12-04 Thread Jon Evans
I think the huge amount of programming effort is the main roadblock, but maybe Wayne et. al. have other thoughts. The roadmap might look something like this: 1) Enable printing without wx (using cairo) 2) Finish porting any remaining features to GAL for PcbNew and GerbView -> Remove legacy canvas

Re: [Kicad-developers] COMPONENT_TREE performance

2017-12-04 Thread kristoffer Ödmark
What are the roadblocks besides the huge amount of programming effort required for this? Im on linux and I would like this as well. - Kristoffer On 2017-12-04 19:09, Bernhard Stegmaier wrote: On 4. Dec 2017, at 18:55, Chris Pavlina wrote: On Mon, Dec 04, 2017 at

Re: [Kicad-developers] COMPONENT_TREE performance

2017-12-04 Thread Bernhard Stegmaier
> On 4. Dec 2017, at 18:55, Chris Pavlina wrote: > > On Mon, Dec 04, 2017 at 05:53:12PM +, Tomasz Wlostowski wrote: >> On 04/12/17 18:48, Chris Pavlina wrote: >>> Hey, just a comment because I see people are wrestling with >>> COMPONENT_TREE performance as I did

Re: [Kicad-developers] COMPONENT_TREE performance

2017-12-04 Thread Tomasz Wlostowski
On 04/12/17 18:59, Jon Evans wrote: > I've got some experience with Qt and would be willing to help out with > investigating this at some point.   My only experience with wx is with > kicad, and it seems to have many more problems than Qt... > On the other hand, I disagree with the suggestion that

Re: [Kicad-developers] COMPONENT_TREE performance

2017-12-04 Thread Jon Evans
I've got some experience with Qt and would be willing to help out with investigating this at some point. My only experience with wx is with kicad, and it seems to have many more problems than Qt... On the other hand, I disagree with the suggestion that Electron would be a good path for KiCad,

Re: [Kicad-developers] COMPONENT_TREE performance

2017-12-04 Thread Chris Pavlina
On Mon, Dec 04, 2017 at 05:53:12PM +, Tomasz Wlostowski wrote: > On 04/12/17 18:48, Chris Pavlina wrote: > > Hey, just a comment because I see people are wrestling with > > COMPONENT_TREE performance as I did when writing it. TEST ON MACOS. The > > performance of the widget there has a really

Re: [Kicad-developers] COMPONENT_TREE performance

2017-12-04 Thread Tomasz Wlostowski
On 04/12/17 18:48, Chris Pavlina wrote: > Hey, just a comment because I see people are wrestling with > COMPONENT_TREE performance as I did when writing it. TEST ON MACOS. The > performance of the widget there has a really different profile from on > other systems. I had to do things in really

[Kicad-developers] COMPONENT_TREE performance

2017-12-04 Thread Chris Pavlina
Hey, just a comment because I see people are wrestling with COMPONENT_TREE performance as I did when writing it. TEST ON MACOS. The performance of the widget there has a really different profile from on other systems. I had to do things in really unobvious ways to make it perform reasonably there.