Quote
Well, there are currently no useful Imaging visual/display functions to speak of.

Sorry if i was misinterpreted. I did not mean "not useful", i mean not needed by some types of projects.

QuoteDo you mean DisplayImage?

All functions in ImagingComponents. They are dependent/used by LCL/VCL, so in a fpGui project can not be compiled.

QuoteMore ifdefs could be put here so that the components unit would compile with other widgetsets too (probably without DisplayImage function).

Currently Imaging does not support Qt and Carbon. Adding such ifdefs would allow compiling with them and resolves one of the problems.

BTW: did you considered using include files instead of ifdefs? It leads to more readable code. The problem is that the Delphi ide does not support include files as well as Lazarus.

QuoteConverting images to LCL TBitmap works ok with different widgetsets?

I did not tested, but i can do it and inform you.

QuoteI could split the package but if this could be resolved just by conditional compilation I would prefer this approach (= if other stuff in the unit work for all widgetsets remove DisplayImage only).

Feel free to do what is best to you. I already managed this problem by myself, just it would be easier to have bundled in the main Imaging distribution.

I can (try) implement the Qt widgetset code and move the code for include files (only for LCL, keep VCL code in the same unit) if you agree. I don't have a mac so no carbon, but i could add empty methods to allow compilation.

BTW: the project i'm working is LuiImage, an image display component that uses cairo to display. It features tiling mode, arbitrary scale and clips and some more. The code and demo can be found at https://svn.bountysource.com/luipack/trunk/luicairo/. The required packages can be found at https://svn.bountysource.com/luipack/trunk/cairo/. In https://svn.bountysource.com/luipack/trunk/cairo/imaging/extra/ i've put the modified Imaging packages for those that want to use LuiImage.

Is necessary the cairo dll: http://www.gtk.org/download-windows.html

Luiz

I'd like to see a Lazarus package with only the base features (loading images, manipulating image data).
The visual features/LCL integration should go in another package that depends of the base package.

What is the advantage of this schema?

- Allowing other graphical toolkits like fpgui (http://opensoft.homeip.net/fpgui/) use imaging
- Allowing LCL components that uses only image loading features to be used in currently unsupported widgetsets like Qt and Carbon

I developed an LCL component that uses Imaging to load the images but don't use Imaging functions for the display. Since visual functions of Imaging does not compiles with Qt i created such "base" package and already uses it, but i'd like to see in the Imaging distribution.

Attached is the base and the visual packages. The only difference to users is that is needed to load the vampyreimaging_base package before installing vampyreimagingpackage.

When i have imaging 0.24.2 installed with Lazarus from svn under gtk the display of png files is wrong (As example the images in component palete of the ide are messed).

If i comment the RegisterTypes call in ImagingComponents unit the problem is gone.

Trying to compile imaging from svn with Lazarus from svn (rev 14368) under gtk gives an error due to internal changes in gtk widgetset.

Attached patch fixes it.

I have installed Imaging 0.24.2 in a recent Lazarus from svn (rev 14810) under Windows.

When i load a bitmap file into a image list using the image list editor the transparency does not work even if i load the project in a machine where vampyre is not installed.

If i comment RegisterTypes in ImagingComponents unit and rebuild Lazarus the transparency works again.

To a test application and more info see the bug report at http://bugs.freepascal.org/view.php?id=11150