Just remembered this thread. This doesn't really apply to file-target
really but it'd be good to remember for anyone reading/writing image libs.
Of course a good solution for image libs is to support reading from stdin
and writing to stdout :)
[the calling proggy can deal with the probs.. :]
On
> > char *ext;
> > int (*load)(void **data, char *filename);
> > int (*save)(void **data, char *filename);
>
> This is a bit simplistic. While the extension is a good hint usually, I'd as
> well include more sophisticated detection techniques.
>
> I as well do not like teh void **dat
> char *ext;
> int (*load)(void **data, char *filename);
> int (*save)(void **data, char *filename);
This is a bit simplistic. While the extension is a good hint usually, I'd as
well include more sophisticated detection techniques.
I as well do not like teh void **data prototyp
> > I have for now only argued with respect to bloating the file target.
> > While IMHO a p?m loader wouldn't add much bloat, Marcus is right with the
> > "we need a good image loading library anyway" argument.
> Not a only loading library. He said:
>> Image loading should ideally be written as
[EMAIL PROTECTED] (Christoph Egger) writes:
> So when we write two libraries, to load and save images - Should the
> file-target then be removed?
No, because as I said:
The purpose of the file-target is to transparently render a LibGGI
application's output to a file.
//Marcus
--
Andrew Apted <[EMAIL PROTECTED]> writes:
> Imagine this: one process using display-file to output (via mmap) a
> constantly changing image to a file. Another process using
> display-file to read that image (again via mmap) and displaying it.
>
> There are no-doubt other ways of achieve the same
On Sun, 6 Feb 2000, Andreas Beck wrote:
> Let's get something done (you all know that I hate the "no action talk only"
> syndrome):
>
> 1. Someone please propose an external API for an image loader/writer. At
> best one that already exists with working code attached to it.
>
> 2. We will the
O.K. folks ...
I think we heard enough opinions about the pros and cons of implementing
image loading in the file target.
Let's summarize:
Pro:
- It is simple to use for LibGGI-aware applications.
Con:
- It doesn't help non-LibGGI-aware applications while a separate lib would.
- If it implem
> > Yes, I keep redesigning it, although this time I promise Ill release both
> > libggiImg and libggittf regardless of there design, I am sure others will be
> > able to polish them off from there.
>
> Oh please please. But DO include a wishlist - it'll help others in
> redesigning same too.
>
On Sat, 5 Feb 2000, Andreas Beck wrote:
> > > The purpose of the file-target is to transparently render a LibGGI
> > > application's output to a file.
>
> > And the application's output can be _anything_. And "anything" means, that
> > this could be also a screenshot for example, which is usua
On Sun, 6 Feb 2000, Andrew Apted wrote:
> Marcus Sundberg writes:
>
> > Well, Andrew is wrong. The functionality does not belong there, and
> > you gain nothing by putting it there.
>
> Imagine this: one process using display-file to output (via mmap) a
> constantly changing image to a file.
On Sat, 5 Feb 2000 [EMAIL PROTECTED] wrote:
> > on libggiImg: Release it please :)
> > I suspect SOMEONE will help ya finish it. Unless you're having problems
> > with design
>
> [clip libggittf]
> > ooohhh... toy! *cool*. I -could- use that right now :)
> Yes, I keep redesigning it, al
> > The purpose of the file-target is to transparently render a LibGGI
> > application's output to a file.
> And the application's output can be _anything_. And "anything" means, that
> this could be also a screenshot for example, which is usually saved as
> *.pcx, *.ppm or something like that.
On 5 Feb 2000, Marcus Sundberg wrote:
> > So, you have contradict yourself. :)
>
> Huh? If you find two contradictory statements of mine in this thread
> you are welcome to show them to me.
No problem:
-
Christoph Egger:
W
Marcus Sundberg writes:
> Well, Andrew is wrong. The functionality does not belong there, and
> you gain nothing by putting it there.
Imagine this: one process using display-file to output (via mmap) a
constantly changing image to a file. Another process using
display-file to read that image
Marcus Sundberg writes:
> The ggiCheckMode() and ggiCrossBlit() in your program invokes
> undefined behaviour, because you have not set a mode on file_vis.
> If you did set a mode on file_vis it would be all black.
It's a read-only visual, so the ggiFillScreen() within ggiSetMode()
fails. Th
Christoph Egger writes:
> Uhm, and what sense does the fbdev-target make? Or perhaps the question
> should be: What sense does the RAW format, because of the existing
> fbdev-target?
> Or perhaps the question should be: What is the difference between the
> RAW format and the fbdev-target?
T
> on libggiImg: Release it please :)
> I suspect SOMEONE will help ya finish it. Unless you're having problems
> with design
[clip libggittf]
> ooohhh... toy! *cool*. I -could- use that right now :)
Yes, I keep redesigning it, although this time I promise Ill release both
libggiImg and l
On Sat, 5 Feb 2000 [EMAIL PROTECTED] wrote:
[clip]
on libggiImg: Release it please :)
I suspect SOMEONE will help ya finish it. Unless you're having problems
with design
>
> I am sorry to have not yet made libggiImg available, I have been too busy with
> work, and research :(
> I also hav
[EMAIL PROTECTED] (Christoph Egger) writes:
> Well, I asked you:
>
> > > What do _you_ think what is the idea behind of the file-target?
>
> And you answered:
>
> > The purpose of the file-target is to transparently render a LibGGI
> > application's output to a file.
>
> So, you have contradi
On 5 Feb 2000, Marcus Sundberg wrote:
> [EMAIL PROTECTED] (Christoph Egger) writes:
>
> > And what is the sense? (see below too!)
>
> What I have already said several times - to do something sane instead
> of an ugly kludge.
>
> > > The ggiCheckMode() and ggiCrossBlit() in your program invok
[EMAIL PROTECTED] (Christoph Egger) writes:
> And what is the sense? (see below too!)
What I have already said several times - to do something sane instead
of an ugly kludge.
> > The ggiCheckMode() and ggiCrossBlit() in your program invokes
> > undefined behaviour, because you have not set a mo
On 5 Feb 2000, Marcus Sundberg wrote:
> [EMAIL PROTECTED] (Christoph Egger) writes:
>
> > > Making it _read_ files does not gain you anything over any other
> > > approach, and is plain wrong.
> >
> > No. You can easily write a ggiviewer for example (have a look at the
> > attachment).
>
> I
[EMAIL PROTECTED] (Christoph Egger) writes:
> > Making it _read_ files does not gain you anything over any other
> > approach, and is plain wrong.
>
> No. You can easily write a ggiviewer for example (have a look at the
> attachment).
If you do what I suggest you can replace the code:
>
> [EMAIL PROTECTED] (Christoph Egger) writes:
>
> > > If you want to load images into a LibGGI visual, write a library
> > > that loads them into a memory visual.
> >
> > What do _you_ think what is the idea behind of the file-target?
>
> The purpose of the file-target is to transparently rende
On 5 Feb 2000, Marcus Sundberg wrote:
> [EMAIL PROTECTED] (Christoph Egger) writes:
>
> > > If you want to load images into a LibGGI visual, write a library
> > > that loads them into a memory visual.
> >
> > What do _you_ think what is the idea behind of the file-target?
>
> The purpose of
[EMAIL PROTECTED] (Christoph Egger) writes:
> > If you want to load images into a LibGGI visual, write a library
> > that loads them into a memory visual.
>
> What do _you_ think what is the idea behind of the file-target?
The purpose of the file-target is to transparently render a LibGGI
appli
On Sun, 6 Feb 2000, Andrew Apted wrote:
> Christoph Egger writes:
>
> > Andreas Beck ([EMAIL PROTECTED]) [000203 13:09] wrote:
> >
> > > The idea of the ppmtools is to finally put an end to reinventing the
> > > picture loading and saving wheel for every program/lib/whatever.
> > >
> >
On Sat, 5 Feb 2000, Christoph Egger wrote:
>
>
> On 5 Feb 2000, Marcus Sundberg wrote:
>
> > [EMAIL PROTECTED] (Christoph Egger) writes:
> >
> > > Is anyone here already hacking the file-target?
> > >
> > > If not, I want to hack it to add support reading some file-formats
> >
> > This is
On 5 Feb 2000, Marcus Sundberg wrote:
> [EMAIL PROTECTED] (Christoph Egger) writes:
>
> > Is anyone here already hacking the file-target?
> >
> > If not, I want to hack it to add support reading some file-formats
>
> This is a completely broken idea. Having a target reading images
> like thi
[EMAIL PROTECTED] (Christoph Egger) writes:
> Is anyone here already hacking the file-target?
>
> If not, I want to hack it to add support reading some file-formats
This is a completely broken idea. Having a target reading images
like this makes about as much sense as having LibGII inputlibs
re
Christoph Egger writes:
> Andreas Beck ([EMAIL PROTECTED]) [000203 13:09] wrote:
>
> > The idea of the ppmtools is to finally put an end to reinventing the
> > picture loading and saving wheel for every program/lib/whatever.
> >
> > As long as you can load/save ppms (which is trivial) you
On Fri, 4 Feb 2000, Andreas Beck wrote:
> > > Hmm - I'd like it better, if it would read only P?M and use ppmtools to
> > > convert any other format as required.
>
> > I'd prefer PNG myself.
>
[clip]
> -rwxr-xr-x 1 root root19408 Mar 21 1999 /usr/bin/djpeg
>
> > And I can't aff
Hi all!
Here is the 2nd patch (is attached) I produced.
Changes:
* use the file-stream from libc now
* some more cleanups
* added ppm read support
* added bmp (both OS/2 and Windows-format) read and write support
The patch compiles for me, but be beware:
I have nothing tested yet, so there
> > Hmm - I'd like it better, if it would read only P?M and use ppmtools to
> > convert any other format as required.
> I'd prefer PNG myself.
But PNG is complicated (compared to PPM which is really as trivial as any
picture format could be, i.e. PNG would require using libpng to avoid
lengthy
Hi!
In the early afternoon MET I sent a new patch (has a size about 45KB,
text only, uncompressed) to this ML, but it seems to me, that the
ML-Server has either refused it, or it hasn't delivered yet. :-(
Normal mails with no attachments are devilered immediatly, but why makes
the ML-server the
teunis wrote:
>> Why don't you just use a file-stream and leave buffering to the libc ?
>
>It's handy for overriding to read from sources -other- than files? :)
>(ie: network connections [okay poor example], messaging systems *giggle*,
>WWW connections preformatted files ie embedded WWW or g
On Thu, Feb 03, 2000 at 08:54:03AM -0800, Cesar Crusius wrote:
> Well, now it displays image, but not correctly. If the image is small a
> partial copy of it appears on the right side of the screen. My screen is
> 800x600 if someone wants to help. I can't set it to 640x480 because I'm
> using a la
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 l
> > 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 t
> * 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
* 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
> > 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
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
* 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 08
> +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
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 :
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...
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 :
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 libgii
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
Good that someone talked about it. It never worked in my machine. Segfaults
immediately... I tried to email the author to no avail.
* Andrew Apted ([EMAIL PROTECTED]) [000202 15:56]:
> Christoph Egger writes:
>
> > One further question:
> >
> > I need an viewer using the file-target, to tes
Christoph Egger writes:
> One further question:
>
> I need an viewer using the file-target, to test it.
>
> Has anyone already one written?
There's GGV, which should be on the GGI FTP site. It would prolly be
easier though to just take one of the demos (e.g. pageflip), and put
something
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 libgii/include/ggi/system.h
and libgii/configure :
GGI_LITTLE
Hi!
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.
Then I will hack on.
Christoph Egger
E-Mail: [EMAIL PROTECTED]
Binary files 2130/degas/lib/libggi/di
Hi!
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.
Then I will hack on.
Christoph Egger
E-Mail: [EMAIL PROTECTED]
Binary files 2130/degas/lib/libggi/di
Hi!
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.
Then I will hack on.
Christoph Egger
E-Mail: [EMAIL PROTECTED]
P.S.: I have already tried twice times to s
On Wed, 2 Feb 2000, Christoph Egger wrote:
>
>
> On Wed, 2 Feb 2000, Christoph Egger wrote:
>
> >
> >
> > On Wed, 2 Feb 2000, Andrew Apted wrote:
> >
> > > Christoph Egger writes:
> > >
> > > > Is anyone here already hacking the file-target?
> > >
> > > No, I'm pretty sure no one is wor
On Wed, 2 Feb 2000, Christoph Egger wrote:
>
>
> On Wed, 2 Feb 2000, Andrew Apted wrote:
>
> > Christoph Egger writes:
> >
> > > Is anyone here already hacking the file-target?
> >
> > No, I'm pretty sure no one is working on it.
> >
> > > If not, I want to hack it to add support readin
On Wed, 2 Feb 2000, Andrew Apted wrote:
> Christoph Egger writes:
>
> > Is anyone here already hacking the file-target?
>
> No, I'm pretty sure no one is working on it.
>
> > If not, I want to hack it to add support reading some file-formats
> > (i.e. bmp, tga, pcx).
>
> Go ahead, it wou
Christoph Egger writes:
> Is anyone here already hacking the file-target?
No, I'm pretty sure no one is working on it.
> If not, I want to hack it to add support reading some file-formats
> (i.e. bmp, tga, pcx).
Go ahead, it would be good.
Semantics wise, you should load the file at init t
Justin Cormack <[EMAIL PROTECTED]> writes:
> The file target in ggi-devel-000103 invariably segfaults
> if you ask the file target to write a ppm file rather
> than a raw file (can send more debugging info if you need
> it). Works fine in 2.0b2.1. The file target code is the
> same, so must be so
62 matches
Mail list logo
