Re: file-target

2000-02-03 Thread Andrew Apted
Christoph Egger writes: I have now produced a patch of my currently done work. The patch compiles for me, but I've nothing tested yet, so be beware. I post it, because I want have some comments about it. OK, some comments :). Looks pretty good so far. Except for the FILE_PPM and

Re: file-target

2000-02-03 Thread Christoph Egger
On Thu, 3 Feb 2000, Andrew Apted wrote: Christoph Egger writes: I've some question: Is there any macro or any #define, that say at compile time, if libggi is compiled on a bigendian or on a littleendian architecture? There used to be... looking... It is in

Re: file-target

2000-02-03 Thread Christoph Egger
On Thu, 3 Feb 2000, Andrew Apted wrote: Christoph Egger writes: I have now produced a patch of my currently done work. The patch compiles for me, but I've nothing tested yet, so be beware. I post it, because I want have some comments about it. OK, some comments :). Looks

Re: ggv (Re: file-target)

2000-02-03 Thread Christoph Egger
On Wed, 2 Feb 2000, Cesar Crusius wrote: Good that someone talked about it. It never worked in my machine. Segfaults immediately... I tried to email the author to no avail. That's bad. Run it with GGI_DEBUG=255 ggv and send the output to the list. Maybe that someone could help you...

Re: file-target

2000-02-03 Thread Christoph Egger
On Thu, 3 Feb 2000, Andrew Apted wrote: Christoph Egger writes: I have now produced a patch of my currently done work. The patch compiles for me, but I've nothing tested yet, so be beware. I post it, because I want have some comments about it. OK, some comments :). Looks

Re: data type sizes

2000-02-03 Thread Andreas Beck
i found int ggiCrossBlit(ggi_visual *src, int sx, int sy, int sw, int sh, ggi_visual *dst, int dx, int dy); which has compiler dependend sizes. is this intended ? Yes. Compilers set int size to be the data size that is most efficient to handle. ggi won't work on a 8 bit computer

Re: file-target

2000-02-03 Thread Andreas Beck
+struct file_type_op_t file_type[] = +{ +{ "ppm", _ggi_file_detect_ppm, NULL, _ggi_file_ppm_write }, +{ "bmp", _ggi_file_detect_bmp, _ggi_file_bmp_read, NULL }, +{ NULL, NULL, NULL, NULL } +}; Hmm - I'd like it better, if it would read only P?M and use ppmtools to

Re: ggv (Re: file-target)

2000-02-03 Thread Cesar Crusius
* Christoph Egger ([EMAIL PROTECTED]) [000203 07:38]: That's bad. Run it with GGI_DEBUG=255 ggv and send the output to the list. Maybe that someone could help you... It was not a GGI problem. Here's the culprit: *** config.c.orig Thu Feb 3 08:38:42 2000 --- config.cThu Feb 3

Re: file-target

2000-02-03 Thread Andreas Beck
Hmm - I'd like it better, if it would read only P?M and use ppmtools to convert any other format as required. I want to have reading some different file-formats and not only one. That's why I hack the file-target. This is a misconception IMHO. The idea of the ppmtools is to finally put

Re: file-target

2000-02-03 Thread core
* Andreas Beck ([EMAIL PROTECTED]) [000203 13:09]: Hmm - I'd like it better, if it would read only P?M and use ppmtools to convert any other format as required. I want to have reading some different file-formats and not only one. That's why I hack the file-target. This is a

Re: file-target

2000-02-03 Thread Andreas Beck
So what you should do is to use ppmtools to convert other filetypes to/from ppm on the fly. I almost agree, let me just clarify some points. I think it should be completely transparent. What I think you're suggesting, and what I would suggest, is to have this conversion built in the file

Re: file-target

2000-02-03 Thread teunis
On Thu, 3 Feb 2000, Andreas Beck wrote: +struct file_type_op_t file_type[] = +{ +{ "ppm", _ggi_file_detect_ppm, NULL, _ggi_file_ppm_write }, +{ "bmp", _ggi_file_detect_bmp, _ggi_file_bmp_read, NULL }, +{ NULL, NULL, NULL, NULL } +}; Hmm - I'd like it