> Guillermo, I would encourage you towards formalizing this application -
> try to summarize objectively what exists today and what do you plan to
> implement. Also, try some "guestimates" on a time frame for completing
> each task.
Joao: Unfortunately I'm not a coder. I'm not even a student :)
Hi,
On Tue, 2008-03-25 at 10:06 -0700, Bill Skaggs wrote:
> If you can build the svn-trunk version of gimp (which by the way
> is a very useful thing to do if you are interested in soc), you
> can find there a new "gegl tool" that allows a long list
> of operations to be performed, but has a pret
Hi,
On Tue, 2008-03-25 at 20:20 -0400, Robert Krawitz wrote:
> A lot of what was described about separate+ is already present in the
> Gutenprint plugin for GIMP (and I think also in Cinepaint), and also
> in PhotoPrint, which is a standalone application layered on the
> Gutenprint core. I'd rat
Hi,
On Wed, 2008-03-26 at 04:07 -0300, Guillermo Espertino wrote:
> About the plugin itself, it already provides profiles management.
Profile management should be left to the GIMP application and to widgets
provided by it. It doesn't make sense if every plug-in does its own
thing here.
> It's
Hi,
On Tue, 2008-03-25 at 07:40 -0600, Joshua Stratton wrote:
> Well, I do not know the current status of GEGL in GIMP's code,
> although I do believe it is the right way to go (from the GEGL
> presentations I have seen). I was assuming much of GEGL's
> implementation would be transparent to t
Well, I guess I'm a little confused about the actual purpose of GEGL. It
sounded like it would provide a more formal and robust interface for GIMP's
image processing. GEGL might be a good choice if the current tools are hard
to interface with, but I really wanted all filters, for example, accesib
Hi,
2008/3/26, Sven Neumann <[EMAIL PROTECTED]>:
> Whatever you do to the image is represented as a graph. If you are doing
> a series of operations on an image, then your graph boils down to a load
> operation, a chain of manipulations and a save operation.
Do you mean every stroke path like
Hi,
On Thu, 2008-03-27 at 00:55 +0900, Souichi TAKASHIGE wrote:
> Do you mean every stroke path like interactive paint tool MUST become
> an graph nodes ?
Probably not an individual graph node, but it will be kept in a paint
operation node which itself stores each stroke so that it can be edited
hey GIMPsters,
let me give you an update here.
in the last 10 days the concept and spec has matured quite a bit.
the feedback and plain old bug reports, both here and on the IRC
went into what is being built right now.
check it out when you have the chance.
thanks,
--ps
founder
Hi,
I run Gimp 2.2 on a Red Hat machine. The Perl scripts delete the images
that are created by using gimp_image_delete. Even so, the swap file is
created and it inflates significantly. For instance, after creating 250
images its size is of 2.7 MB. If the image is not deleted in the script,
th
Andrei Simion <[EMAIL PROTECTED]> wrote:
>
> I run Gimp 2.2 on a Red Hat machine. The Perl scripts delete the images
> that are created by using gimp_image_delete. Even so, the swap file is
> created and it inflates significantly. For instance, after creating 250
> images its size is of 2.7 MB
Andrei Simion wrote:
> I run Gimp 2.2 on a Red Hat machine. The Perl scripts delete the images
> that are created by using gimp_image_delete. Even so, the swap file is
> created and it inflates significantly. For instance, after creating 250
> images its size is of 2.7 MB.
I have done some work
12 matches
Mail list logo
