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.. :]
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.
That
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, although
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. Another
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.
Now
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
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 then
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 thing,
[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
--
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 afford the
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 a completely broken
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.
As long as you
[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
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 the
[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 mode
[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 contradict yourself.
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 have a
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?
The
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
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
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
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
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
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 :). Looks
+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
* 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
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
* 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
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
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
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 reading some file-formats
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 working on it.
If
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
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 :
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 like
36 matches
Mail list logo
