On Tue, Mar 07, 2017 at 11:58:27AM +1300, Simon Wells wrote: > I wonder whether it is worth making this a policy that no new > components can use wxTreeListCtrl as the performance on OSX is abysmal > and there are alternatives, granted they are slightly more complicated > but a much better long term solution (not only in osx performance) but > in code structure as well.
I agree. wxTreeCtrl is fine, but if you need more sophisticated data or display you should go straight to wxDataViewCtrl. I'm 100% in favor of making it policy. > > On 6 March 2017 at 17:00, Chris Pavlina <[email protected]> wrote: > > Ready for testing, I'll merge tomorrow since it mostly only touches my > > parts. This is a pretty significant improvement, and solves some > > wxTreeListCtrl quirks as well. > > > > > > On Sun, Mar 05, 2017 at 05:02:10PM +0100, Nick Østergaard wrote: > >> Please report back when it is ready for testing... > >> > >> 2017-03-05 15:04 GMT+01:00 Chris Pavlina <[email protected]>: > >> > Ongoing refactor of COMPONENT_TREE_SEARCH_CONTAINER into a > >> > model-view-adapter architecture is at [1] (componentchooser branch of my > >> > dev repo). The code is seriously cleaner now and significantly faster. > >> > Should be done later today. > >> > > >> > [1] https://github.com/cpavlina/kicad/tree/componentchooser > >> > > >> > > >> > On Sat, Mar 04, 2017 at 01:38:37PM -0500, Chris Pavlina wrote: > >> >> Hi, > >> >> > >> >> Just thought I'd provide a quick update on what's going on with the > >> >> component chooser. Things have been pretty delayed - I've had more > >> >> issues than expected, and I'm trying to work around my school schedule > >> >> too - but I'm still moving along (and I have almost a full week off now, > >> >> most of which will be spent on this). > >> >> > >> >> Currently, I'm working on resolving a macOS performance issue that > >> >> causes updates to cost about 0.5s per keystroke for large library sets. > >> >> I'm looking at two possible solutions: > >> >> > >> >> - Implement my own wxDataViewModel, reimplementing most or all of > >> >> COMPONENT_TREE_SEARCH_CONTAINER in the process and making the > >> >> component tree a model/view architecture. This is very much > >> >> preferable, but I'm not 100% sure if this will give the desired > >> >> performance boost. I'll do this first as it's a useful refactoring > >> >> anyway. > >> >> > >> >> - Implement an optimizing adapter that wraps TWO_COLUMN_TREE_LIST. This > >> >> would populate the underlying list only with visible items, > >> >> intercepting "expand" events and populating the parents with their > >> >> children on demand. This is an ugly hack and I'd like not to resort > >> >> to this. > >> >> > >> >> When I'm done with this, I want to make a couple more changes before > >> >> proceeding, based on user feedback: > >> >> > >> >> - Make the component info box collapsible. > >> >> - Also display component info in a rich tooltip > >> >> - Add a resizable splitter between footprint and symbol display > >> >> > >> >> Once all of this is done, the next steps are: > >> >> > >> >> - Add footprint filtering and selection > >> >> - Add 3D preview > >> >> > >> >> Please, feel free to file bug reports even on minor UI quirks - I don't > >> >> always notice or remember them. > >> >> > >> >> -- > >> >> Chris > >> > > >> > _______________________________________________ > >> > Mailing list: https://launchpad.net/~kicad-developers > >> > Post to : [email protected] > >> > Unsubscribe : https://launchpad.net/~kicad-developers > >> > More help : https://help.launchpad.net/ListHelp > > > > _______________________________________________ > > Mailing list: https://launchpad.net/~kicad-developers > > Post to : [email protected] > > Unsubscribe : https://launchpad.net/~kicad-developers > > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
