|
Kexi Core Design:
Image Handling
started: 2005-09-26, jstaniek
1. Image Handling Within Forms
KexiImageBox is a widget displaying images. It can work in two modes:
- data-aware widget, when it's dataSource and dataSourceMimeType properties are properly set. Then, image's data can be retrieved from a field of type BLOB, on demand.
- static (non-data-aware) widget. Image's data is assigned once on form's design time by user, and then displayed as static grapahics.
KexiImageBox widget's features:
- scalable both in design and data modes, using free-scale or with keeping image's aspect ratio
- supports all types of vertical and horizontal alignment, which works also when image is cropped
- does not loose original image's quality, e.g. when rescaled
- supports "insert from file", "save to file", "clear" and all clipboard-related actions
- stores original image's file name (without a path) in "originalFilename" property, so it can be used for "save to file" action. Pasted images have this property cleared.
- read-only mode works as expected, inheriting data model's settings
- in data mode, user-friendly drop-down button is displayed for context menu with related actions (right-click context menu is also available)
^ toc
2. Storage
kexi__blobs "system" table contains static image's binary data.
More about the table schema: doc/dev/kexidb_issues.txt file.
Original file's contents are stored when dealing with static image's.
This ensure original images are not altered by conversion between different color depths, palettes or rescaling.
^ toc
2.1. Database backend specifics
Most important issues when dealing with BLOBs using statement strings:
- PROBLEM 1: Character escaping is required. This is costly for large data blocks.
- PROBLEM 2: Entire SQL statement string needs to be created and then it should be sent in one go (is this true?). This not only costs more of memory and time but also complicates multithread access and makes user-visible feedback (e.g. using progress bar widget) for large data blocks hard to implement.
Alternative could be to use specific functions for given backends, where data is not copied but is transfered using IO streams. See below.
- PostgreSQL
- Docs: Large Objects
- PostgreSQL has special functions for effective creating/accessing BLOBs on libpq level, what solves the PROBLEM 1. Moreover, using lo_write() and lo_read() can solve PROBLEM 2. However it's custom solution :(
- This looks ok: PQexecParams.
- Docs: The BLOB and TEXT Types
^ toc
3. Image Handling Within Reports
It's planned to reuse KexiImageBox widget and static image's storage for Kexi Reporting.
|
