Quote from: blikblum

QuoteConverting images to LCL TBitmap works ok with different widgetsets?

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

That would be great, I'm finishing 0.26 release so I don't have much time for experiments.

Quote
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.

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.

Ok, I'll add your Qt or other code to Imaging.
I know many/nested ifdefs are messy but I just don't like to have too many source files.
How many inc files are we talking about? I guess Qt code would be just for DisplayImage (Imaging<>TBitmap conversions use just widgetset independent LCL code)?

Quote
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.

Nice work with the component.

Every contribution is welcomed.
I'm just leaving and won't be online till Monday/Tuesday so I'll take a longer look at your post then.

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

Well, there are currently no useful Imaging visual/display functions to speak of.
Do you mean DisplayImage?
More ifdefs could be put here so that the components unit would compile with other widgetsets too (probably without DisplayImage function).

Converting images to LCL TBitmap works ok with different widgetsets?
I don't use Lazarus much so I'm not sure.

I 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).

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.