kexi project
Rapid Database Application Development
"Microsoft Access for Linux"

Home Download FAQ Support Features Handbook Screenshots Screencasts Compile Kexi Development Authors Contact License Sponsorship Translate This Site

wiki navigation:

Front Page
[info] [diff] [login]
[recent changes]
[most popular]
You can donate
to Kexi Project:
Via PayPal

Spread the word about Kexi!
Get Kexi Now!

Built on the KDE technology

Member of the Calligra Suite

No Software Patents!

Kexi Core Design:

Image Handling

Table of Contents
   1. Image Handling Within Forms
   2. Storage
     2.1. Database backend specifics
   3. Image Handling Within Reports

 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.
  • MySQL
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.

Kexi - "MS Access for Linux" ... and Windows
© Kexi Team
This content is available under GFDL
Last edited: October 5, 2005 by js, visited 0 times.