other stuff on sf

[Juha Helminen]

Kai-Uwe Behrmann wrote:

>Had a small view on the sources. I saw many dependencies wich are not
>documented for me (*.hpp, windows-dependencies and *.dfm -files). It seems
>You are using standard windows- or borland-libraries for doing the
>graficconversions. Where is the point for giving the read-in datas to the
>memory? In wich way they these functions ( read-file?() ...? ) are called
>(filename, size, bitdepth...) .
>  
>
dfm-files are those files that define layout of visual components -- IDE 
handles them. Most of components are from borland libraries. Portability 
from this enviroment to generally unix is not so good or depends on style.

>Is as in
> --  void __fastcall TFormMain::TimerPreviewTimer(TObject *Sender) { } --
>all Your reading stuff merged with the Gui at the moment?
>  
>
As an example this function reads jpeg image and reading is implemented 
in VCL-library. I suppose that this kind of functions are not a problem 
when program is ported for Kylix.
I moved "normal" image reading functions to UnitProgressBar.cpp 
(initially progressBar). TiffBmb.pas is not standard components and must 
be changed if it is used in Linux (can be changed but there are 
betters). This could make conversion between general image reading 
functions and memory bitmaps.

>We can do it so only while putting the related code in an
>"Unit###.c"-file ;-). Using libgimp could help us doing this, while we
>would need more dependencies, wich is not good for portability of the
>code.
>  
>
Unit###.cpp -files are easiest to edit with IDE. It makes function 
prototypes and connects them to events (if they are added with IDE). All 
portable methods should be outside of Unit.c files. This might not be 
problem when there is no functions that are strictly related to GUI.

Juha