Skip site navigation (1) Skip section navigation (2)

s/xpm/png/g

From: Dave Page <dpage(at)pgadmin(dot)org>
To: pgadmin-hackers <pgadmin-hackers(at)postgresql(dot)org>
Subject: s/xpm/png/g
Date: 2011-03-07 13:55:46
Message-ID: AANLkTi=LdY_PATqDuNpstVgTZHdvCXisfW16CNSPv9=9@mail.gmail.com (view raw or flat)
Thread:
Lists: pgadmin-hackers
Hi,

The (large) patch at
http://developer.pgadmin.org/~dpage/embedded_images_infra-v8.diff
replaces all the XPM images in pgAdmin with PNG ones. This offers us
two major advantages:

1) XPM images aren't supported by many graphics tools, and almost
always require manual editing to fix the internal naming anyway.

2) XPM images don't support alpha transparency.

The patch is a little complex, as it's not straightforward to embed
PNG images at build time. Here's what it does:

- Adds a new project, png2c, on which the pgAdmin project is dependent.
- Adds a new build rule for .png files, which will cause them to be
pre-processed with png2c, to create .pngc files which are C source
code, containing the PNG data and some accessor functions and macros.
- #include's the .pngc files in place of the XPMs.
- Updates the rest of the code to use the new accessor macros created
in the .pngc files:

    filename_png_img - represents a wxImage*
    filename_png_bmp - represents a wxBitmap*
    filename_png_ico - represents a wxIcon*

Each of the accessors uses static data, so in theory, this also gives
us a performance optimisation as any given image only need be
converted to a different format (by using the appropriate accessor)
once, upon first access.

I've tested on Linux, Mac and Windows, and everything looks good.
Comments/objections before I commit?

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Responses

pgadmin-hackers by date

Next:From: Thom BrownDate: 2011-03-07 13:57:09
Subject: Remove name as valid parameter for catalog functions
Previous:From: Dave PageDate: 2011-03-07 06:49:02
Subject: Re: Support for invalid foreign keys

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group