kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 05/18/2018 12:49 PM, Tomasz Wlostowski wrote:
> On 18/05/18 18:42, jp charras wrote:
>> Le 18/05/2018 à 17:51, Tomasz Wlostowski a écrit :
>>> On 18/05/18 17:38, Wayne Stambaugh wrote:
>>>> As we approach the v5 stable release, I want to discuss a something we
>>>> should seriously consider before we open the flood gates for new feature
>>>> merges after the v5 branch.  We are currently in an awkward position
>>>> with regards to gtk3 builds on Linux.  Given that most distros are now
>>>> building wx against gtk3, we really should work towards fixing this at
>>>> the beginning of v6 and back porting it as soon as possible so that we
>>>> can better support the current Linux distros.  Fortunately, most distros
>>>> have thankfully provided a gtk2 build version of wx in order to build
>>>> kicad.  However, they have not done the same thing for wxpython so for
>>>> most new distro releases, we have to build kicad without wxpython
>>>> support.  I propose we spend some time immediately after the v5 release
>>>> and fix the gtk3 issues before we start making major changes to the code
>>>> base so that it is not difficult to back port.  Anyone else have any
>>>> thoughts on this?
>>>>
>>>
>>> Wayne,
>>>
>>> I would put most of the effort on developing the GAL version of
>>> eeschema. It's not our fault that Linux distros change the APIs of
>>> essential system libraries every 2 years. As a short term solution, I
>>> would propose distributing a distro-agnostic binary Kicad package that
>>> includes all dependencies, including wx and gtk2 libraries. In the
>>> longer run, GALified schematic editor is IMHO the way to go.
>>
>> Hi Tom,
>>
>> When we are talking about GAL, we are actually talking about 2 different things:
>> 1 - the GAL itself, that is the graphic part of "GAL"
>> 2 - the new event management, that has nothing to do with the graphic layer itself.
>>
>> Using the new event management could be a much more amount of work than writing the  graphic layer
>> code only.
>>
>> So my question is:
>> It is possible to use the GAL itself (restricted to the graphic layer), and keep the current
>> wxWidget management events in eeschema and page layout editor (although the graphics in pl_editor
>> are so basic we can redraw the full screen without any optimization each time a object is moving).
> 
> Hi JP,
> 
> Yes, it should be possible with some modifications to the current event
> handling code (mostly removing XOR draw calls). I have partly written a
> GAL canvas renderer for eeschema some time ago, let me dig it up and
> post it on Github.
> 
> Tom

How did you did code this?  I would think that it would be possible to
use a wxBitmapDC to draw upon and then blit it to the actual hardware
device context without any changes to drawing code (any thing derived
from wxDC can be passed to the drawing code).  This certainly would be
faster than drawing directly to the hardware device context.  The tricky
part with this in the past was getting the viewable area correct.  This
is how the legacy canvas in gerbview works (or at least it used to work
that way because rendering directly to the hardware device context was
too slow).

> 
>>
>>>
>>> Best,
>>> Tom
>>>
>>>
>>>
>>>> Cheers,
>>>>
>>>> Wayne
>>
>>
> 
> 
> _______________________________________________
> 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
>