(oops, forgot to send this)
On Fri, 2011-01-21 at 13:32 +0100, Michael Natterer wrote:
[...]
Yes, but still even the most basic, non grouped command might still
be triggering a whole series of atomic micro undo operations that
would go into an undo group associated with the command.
I'm not
On Thu, 2011-01-20 at 23:01 -0500, Liam R E Quin wrote:
On Thu, 2011-01-20 at 15:10 +0100, Michael Natterer wrote:
I discussed this with Martin, and the outcome was to have a command
layer around the core, and not make it a 1:1 match of undo operations,
because undos are very atomic
On Tue, 2011-01-18 at 19:59 -0500, Liam R E Quin wrote:
On Fri, 2011-01-14 at 22:39 +0100, Michael Schumacher wrote:
[...]
Martin wants to change the Undo system using the Command Pattern (see
comment 43 of the above report, and
http://en.wikipedia.org/wiki/Command_Pattern for an
On Thu, 2011-01-20 at 15:10 +0100, Michael Natterer wrote:
I discussed this with Martin, and the outcome was to have a command
layer around the core, and not make it a 1:1 match of undo operations,
because undos are very atomic operation, whereas commands rather
correspond to undo groups of
On 1/14/11, Kevin Cozens wrote:
It is well known in that a lot of people know it exists. As for it being
understood, not so much.
I hate to tell you, but JS indeed is broadly known and used. At least
half of Creative Suite is scripted in JS, and there is a whole
industry around various JS
On 01/14/2011 12:29 PM, Alexandre Prokoudine wrote:
On 1/14/11, Kevin Cozens wrote:
It is well known in that a lot of people know it exists. As for it being
understood, not so much.
I hate to tell you, but JS indeed is broadly known and used. At least
half of Creative Suite is scripted in
On Thu, Apr 08, 2010 at 05:17:45PM +0200, Michael Schumacher wrote:
Von: Alexia Death alexiade...@gmail.com
2010/4/8 Aurimas Juška aurimas.ju...@gmail.com:
I believe most users write script-fu scripts to automate commonly
repeated steps. Therefore, it would be even better to complete
On Friday 14 January 2011 21:59:36 Marco Ciampa wrote:
On Thu, Apr 08, 2010 at 05:17:45PM +0200, Michael Schumacher wrote:
Writing out recorded actions in any language shouldn't be the problem...
I think that this is one of the most wanted TODO for GIMP.
If it is not a problem, why noone
On 14.01.2011 21:59, Marco Ciampa wrote:
On Thu, Apr 08, 2010 at 05:17:45PM +0200, Michael Schumacher wrote:
Von: Alexia Death alexiade...@gmail.com
I think script-fu would be ideal for such use. If you could record an
action, and then optionally convert it to a full script a lot of
Martin Nordholts wrote:
To me, there is only one sensible scripting language to consider when
talking about a major overhaul of the GIMP scripting core, and that is
JavaScript. It is a well-known and understood scripting language with a
bright future (HTML5)
It is well known in that a lot
I'd like to chime in here also supporting tiny-fu.
I agree with almost everything said by SG
While the language is less common than some languages, it provides a
very simple way to script existing pdb functions when you have no need
to access the individual image pixels.
Rather than considering
2010/4/8 Aurimas Juška aurimas.ju...@gmail.com:
I believe most users write script-fu scripts to automate commonly
repeated steps. Therefore, it would be even better to complete action
framework so that user could record commonly used action sequences and
play them from GUI.
I think script-fu
Von: Alexia Death alexiade...@gmail.com
2010/4/8 Aurimas Juška aurimas.ju...@gmail.com:
I believe most users write script-fu scripts to automate commonly
repeated steps. Therefore, it would be even better to complete action
framework so that user could record commonly used action
I thought I'd comment with some of my opinions on the proposal/project
presented by Andreas_P. I have included the original post in its
entirety at the end of this mail (as it's been a while since it was
made).
Over the years, GIMP's plug-in/extension system has remained fairly
language
The real problem with script-fu is that it is archaic. Few people in this
modern age want to deal with Lisp-derived languages, with all those
ridiculous strings of parentheses. It's like going back to the dark ages of
programming. Even a scripting language derived from BASIC would make more
On Wed, 2010-04-07 at 12:56 -0400,
saulgo...@flashingtwelve.brickfilms.com wrote:
Script-fu's main limitations are that it is restricted from
interfacing directly with libgimp -- it only has access to
functionality as provided by the Procedural DataBase (PDB)
I think I better add a
On Wed, 2010-04-07 at 10:54 -0700, Bill Skaggs wrote:
The real problem with script-fu is that it is archaic. Few people in
this modern age want to deal with Lisp-derived languages, with all
those ridiculous strings of parentheses. It's like going back to the
dark ages of programming. Even a
I hope that this email was not being posted several times here
Hey all,
I think I did loose the previously designed letter which I thought,
having sent to Kevin Cozens.
Now I have to write the whole letter again, hoping for him, that he is
on this list, from time to time.
It sounded like
On 04/04/2010 11:53 AM, Andreas_P wrote:
Now my proposal: Just look at the upcoming (brand) new version of
racket which is nothing else than the newly renamed and rebranded
PLT-Scheme. PLT is (in case you don't know) the bunch of hackers who
are refining the elements of R6RS-Scheme to a
Hi again,
Thank you for answering me. It was meant a little different: I would not
want to replace GIMP Core Scripting languages (JavaScript and those
stuff) but to extend Plug-in scripting power for languages like python,
perl etc ...
to its maximum (and yes you can set up GUI elements with
20 matches
Mail list logo
