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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Thom Brown | 2011-03-07 13:57:09 | Remove name as valid parameter for catalog functions |
Previous Message | Dave Page | 2011-03-07 06:49:02 | Re: Support for invalid foreign keys |