Survex 1.2.18 released

[Robert Jones]

Hi Olly,

I've built wx trunk and tried to build again with your patch applied. The
build succeeds, however an assert fails when loading bitmap images:
../src/osx/core/bitmap.cpp(1302): assert ""image.IsOk()"" failed in
wxBitmap(): invalid image

I think the problem might be in the stringification macro:
#define TOOL(x) wxBitmap(wxImage(#x "_xpm"), -1, content_scale_factor) -->
doesn't work
#define TOOL(x) wxBitmap(wxImage(x##_xpm), -1, content_scale_factor) -->
does work

If I'm reading the docs right, # doesn't concatenate the tokens.

With that change, icons are still rendered at the same resolution. Instead
the icon bitmap gets resampled by content_scale_factor prior to being
rendered. As you might expect, this makes no discernable difference (but
produces debug warnings) for values of content_scale_factor > 1, and fuzzy
down-sampled images for values <1. The rendered icon size on-screen remains
constantly large as before.

I played around with toolbar->SetToolBarBitmapSize. I can enlarge the
rendered icons further (values above 32x32) but values below this do not
reduce the image size.

I'm happy to produce some .icns images at the appropriate resolutions given
a little time. Would that be helpful?

Rob







On Thu, 4 Jun 2015 at 15:43 Olly Betts <olly at survex.com> wrote:

> On Thu, Jun 04, 2015 at 02:07:16PM +1000, Robert Jones wrote:
> > I’ve attempted to build 1.2.18 on OSX 10.10.4.
> >
> > This bails with an undefined reference to
> wxClientDC(WIN).GetClientScaleFactor() in mainfrm.cc.
> > If I remove the OSX #ifdef then the build completes successfully.
> >
> > I can’t find any references to GetClientScaleFactor or an argument for
> > scale in the wxBitmap call in WX.
>
> Thanks for spotting that - I made that change after I last had access to
> a Mac to test on.
>
> Looks like it's actually "GetContentScaleFactor", and that both that and
> the extra wxBitmap argument are only present in wx trunk.
>
> I've committed a change to only try to use them for wx >= 3.1.0, which
> they should be present in, and to fix "Client" to "Content".
>
> If anyone's trying to build for themselves, just change line 93 of
> src/mainfrm.cc to:
>
> #if 0
>
> instead of:
>
> #ifdef __WXMAC__
>
> > I did try the workaround in this post, explicitly managing a non-native
> toolbar:
> >
> https://groups.google.com/forum/#!msg/wx-commits-diffs/kkMc1qvLCQ4/b0gwJ4xbWYQJ
> >
> > This change did work, but I saw some odd corruption that you can see
> > in the screenshot attached.
>
> It looks like there's an extra small square window there for some
> reason - I've seen similar issues before, but I don't remember what
> the cause was.
>
> A more minor issue is that the 3rd and 4th icons seem to have the
> bottom row of pixels clipped off.
>
> > The suggestion seems to be to use OSX-style, larger icons in a native
> > toolbar.
>
> Problem is we don't have larger versions of those icons, and just
> scaling up the current ones is unlikely to look better than what we have
> currently (which seems to be just automatically scaled up versions).  If
> someone artistic is up for drawing a set, that'd be great (the current
> ones do the job, but they're not especially pretty).
>
> Cheers,
>     Olly
>