kicad-developers team mailing list archive

[Jon Evans <jon@xxxxxxxxxxxxx>]

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 <
kristofferodmark90@xxxxxxxxx> 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 <pavlina.chris@xxxxxxxxx> 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     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>