SVN:(CHB)[73709] fixed the new Zoom code -- thanks to Ralf Werner

noreply@wxsite.net wrote:

Revision
    73709 <wxTrac has been migrated to GitHub Issues - wxWidgets;
Author
    CHB
Date
    2013-03-22 18:12:12 -0700 (Fri, 22 Mar 2013)

      Log Message

fixed the new Zoom code -- thanks to Ralf Werner

      Modified Paths

  * wxPython/3rdParty/FloatCanvas/floatcanvas/FloatCanvas.py
    <#wxPython3rdPartyFloatCanvasfloatcanvasFloatCanvaspy>

      Diff

        Modified:
        wxPython/3rdParty/FloatCanvas/floatcanvas/FloatCanvas.py (73708
        => 73709)

Hi Chris,

Don't forget about keeping Phoenix/trunk/wx/lib/floatcanvas up to date too.

···

--
Robin Dunn
Software Craftsman

Well, I haven't forgotten, but neither have I found the time to even
give Phoenix a try.....but I've got a couple active users lately, so
spending a bit more time on it -- we'll see!

Werner -- have you tried FloatCanvas with Phoenix?

Also, IIUC, you pull wx.lib.floatcanvas from the ThirdPart branch --
are you doing that for Phoenix too?

-Chris

···

On Mon, Mar 25, 2013 at 9:22 AM, Robin Dunn <robin@alldunn.com> wrote:

Hi Chris,

Don't forget about keeping Phoenix/trunk/wx/lib/floatcanvas up to date too.

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

Chris Barker - NOAA Federal wrote:

Hi Chris,

Don't forget about keeping Phoenix/trunk/wx/lib/floatcanvas up to date too.

Well, I haven't forgotten, but neither have I found the time to even
give Phoenix a try.....but I've got a couple active users lately, so
spending a bit more time on it -- we'll see!

Thanks.

Werner -- have you tried FloatCanvas with Phoenix?

Also, IIUC, you pull wx.lib.floatcanvas from the ThirdPart branch --
are you doing that for Phoenix too?

No. Using svn:externals worked well for including other repo trees at specific locations in another tree, but only for just svn. Trying to use git or mercurial as a front-end for the svn repository broke that scheme as neither has good support for following svn:eternal directives, and trying to set it up as additional git submodules or similar was more hassle than it was worth IMO. So, to follow the KISS principle I felt it was better to just have the single source tree in Phoenix instead of trying to blend multiple ones together.

···

On Mon, Mar 25, 2013 at 9:22 AM, Robin Dunn<robin@alldunn.com> wrote:

--
Robin Dunn
Software Craftsman

got it -- svn:externals is a pretty cool feature, but I've ended up
dropping it for various reasons in all my other stuff, too.

-Chris

···

On Mon, Mar 25, 2013 at 12:59 PM, Robin Dunn <robin@alldunn.com> wrote:

No. Using svn:externals worked well for including other repo trees at
specific locations in another tree, but only for just svn. Trying to use
git or mercurial as a front-end for the svn repository broke that scheme as
neither has good support for following svn:eternal directives, and trying to
set it up as additional git submodules or similar was more hassle than it
was worth IMO. So, to follow the KISS principle I felt it was better to
just have the single source tree in Phoenix instead of trying to blend
multiple ones together.

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov