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
On Sat, Feb 05, 2000 at 04:46:58PM -0500, teunis wrote:
On 5 Feb 2000, Marcus Sundberg wrote:
[EMAIL PROTECTED] writes:
The second library should be a simple glue-layer between the first
library an LibGGI. The reason to make two libraries that a generic
image loader/writer that is
DOHT! I didnt write that, that was, I think ?Marcuses? response...
[EMAIL PROTECTED] writes:
The second library should be a simple glue-layer between the first
library an LibGGI. The reason to make two libraries that a generic
image loader/writer that is _not_ tied to any
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
--
10 matches
Mail list logo
