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 option from both of these 3) Port eeschema to GAL and remove legacy canvas 4) Rewrite all "internal" code that makes use of wxWidgets classes to use something else (STL, custom data types, etc) 5) Rewrite the GUI using the new toolkit of choice (maybe starting with GerbView as a proof of concept since it is mostly stand-alone and much simpler than the rest) wx not only provides the GUI code, but also event handling, OS interaction, etc which all would have to be ported to something else. 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. For example, instead of calling a toolkit function to open a file, call some kicad ReadFile() command that wraps the Qt / whatever implementation. The above represents many, many person-months of work :-) -Jon On Mon, Dec 4, 2017 at 1:17 PM, kristoffer Ödmark < [email protected]> wrote: > 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 <[email protected]> wrote: >>> >>> On Mon, Dec 04, 2017 at 05:53:12PM +0000, 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 different profile from on >>>>> other systems. I had to do things in really unobvious ways to make it >>>>> perform reasonably there. >>>>> >>>>> I've noticed spending more and more time fixing wxWidgets bugs instead >>>> of Kicad bugs. Maybe we should have a serious look at Qt or Electron >>>> (Webkit/JS-based UI) as a possible future alternative for wx... >>>> >>> YES. I try not to bring it up too much because I know the lead devs >>> aren't fond of the idea of changing the GUI toolkit, but I strongly >>> believe we could benefit from that. Obviously it can't really happen >>> until we ditch wxDC. >>> >> From a macOS perspective I’d really love to see this. >> There are many small/big usability/GUI problems that just don’t work on >> macOS. >> The ones I tried to fix always ended up being some wx problem… and I gave >> up hope that they will get fixed any time soon or late (I am watching/using >> wx master for that reason, but didn’t see any improvements). >> >> >> Regards, >> Bernhard >> _______________________________________________ >> 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
