Re: [Gimp-developer] easy questions

2004-07-07 Thread Dave Neary

Hi Zack,

Quoting Zack [EMAIL PROTECTED]:
 The first is, how intimately is the GIMP tied to GTK+?

Very. Although the GUI code has been separated out from the internals, the GIMP
depends on GTK+ to a huge extent. It is inextricably linked to glib and gobject too.

 The second is, I haven't looked at the code at all, but is the GIMP
 multithreaded and/or does it absolutely require a multitasking OS?

I wouldn't say so. I don't believe there is threading code in the GIMP, but I am
not sure.

Cheers,
Dave.

-- 
Dave Neary
Lyon, France
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Lists, Arrays and Vectors [was Re: [Gimp-developer] Re: Tiny-Fu: A new plug-in for GIMP]

2004-07-07 Thread Shlomi Fish
On Wednesday 07 July 2004 05:05, Kevin Cozens wrote:
 On Tue, 2004-07-06 at 19:45, Sven Neumann wrote:
  The fact that the PDB uses arrays doesn't necessarily mean that a
  language binding such as Tiny-Fu needs to represent them as arrays.
  One of the most annoying bits of Script-Fu is that it forces you to
  work with arrays even though the natural choice for a scheme dialekt
  would be lists. If Tiny-Fu cannot provide backward-compatibility, then
  it should overcome this mistake and map the PDB API to lists.

 Tiny-Fu makes no attempt to provide backwards compatability with the
 SIOD Scheme interpreter way of doing things. It expects scripts to
 follow the current Scheme standard as defined in the R5RS document.

 Since the R5RS does not define an array type, any script which uses
 arrays either internally or when dealing with PDB calls needs to be
 modified to use a list. The marshalling code of Tiny-Fu converts between
 PDB *ARRAY and Scheme lists as needed. The alternative would be to use a
 Scheme vector but instead of a list. Using a list seemed like the
 simplest approach.

Are you sure using lists instead of vectors is the right thing to do? Lists 
are linked lists and as such accessing the i'th element is O(i). In vectors 
it is O(1). This can cause an order of complexity increase in handling them.

Are you certain that all the scripts initialize the arrays, one element after 
another in sequential order? Or are there scripts with random access?

In any case, this may not be an issue, because a programmer can temporarily 
use a vector, and convert it to a list before calling the PDB entries.

(It reminds me that in Visual Basic the built-in array is implemented as a 
linked list, and so random access to it is slow as hell. What serious 
programmers do is implement the array logic in C and bind it to their VB 
programs)

Regards,

Shlomi Fish
-- 

-
Shlomi Fish  [EMAIL PROTECTED]
Homepage:http://shlomif.il.eu.org/

Knuth is not God! It took him two days to build the Roman Empire.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] color management

2004-07-07 Thread Alastair M. Robinson
Hi,
(Second try, this time sent to the list at large.  Brains where art thou!)
Sven Neumann wrote:
Well, we have only one internal color space. We just need to agree on
what we want to call it...
My two-penneth (as author of the separate plugin, and a day-to-day user
of the GIMP in a pre-press environment):
There are as I understand it, two possible ways of dealing with colour
profiles.
In the first method, is what I believe is what PhotoShop uses (and what
I think Sven proposed):  When an image is loaded, scanned or whatever,
it is converted from its source colour space into a working colour
space (sRGB, AdobeRGB, etc.).  Of course, the source colour-space and
working colour-space can be the same.  The advantage of this method is
that the working data is always normalised, so plugins and the like
have perceptually identical results, whatever the image's native
colour space.
The workflow for an sRGB Image might be:
Image (AdobeRGB) - Working data (convert to sRGB) - Editing - Save
(convert back to AdobeRGB)
Personally, I don't think this method is appropriate for the GIMP until
such time as we  have support for 16-bit or float pixels, because if we
convert from the source space to a working space with only 8 bits per
sample we're going to lose some information through quantization errors.
The second method, which I think we should use for the time being, is
just to keep track of the source profile for each image (and have a
user-selectable default profile - sRGB, AdobeRGB or whatever).  This
source profile should be user-changable (so the user can tag a scanned
image with the scanner's profile, for example), and just needs to be
accessible to the proof and image-saving code.
The equivalent workflow would be:
Image (tagged with AdobeRGB) - Working data (8-bit RGB, unmodified) -
Editing - Save (AdobeRGB)
The advantage is that the image data doesn't have to be transformed
between profiles (so we need the facility to do this manually, should
the user need it), but there are some disadvantages:
The effects of some plugins will look different depending on the image's
colour space.  (GFlare's flares, for example, will look slightly
different applied to an sRGB image compared with an AdobeRGB image...).
Colour-choosing is less-predictable (though no less than at present),
since the RGB values selected are in a variable colour space.  Since
we're unlikely to get a PanTone colour-selector any time soon, this
shouldn't be an issue.  The ultimate solution here is to have a
colour-profile attached to the colour-selector, and simply transform the
selected colour to the current image's profile.  The colour-selector's
profile is probably as close as we need to get at the moment to a
working profile.
You would have to convert between colour spaces when copying and pasting
between images with different profiles.  (Ideally a warning with yes/no
buttons.  I personally wouldn't want this done silently, because again
it would introduce quantization errors with 8-bit data).
In short, though, if we use this method, we don't need to agree on what
to call our working space, because it will simply be whatever is
appropriate for the image being edited!
Hope this little essay is some help!
All the best,
--
Alastair M. Robinson
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: Re: [Gimp-developer] start perl server

2004-07-07 Thread kovzol
On Thu, 17 Jun 2004, Seth Burgess wrote:

 I'd recommend putting the call inside an 'eval' block, so that it
 failing doesn't stop the execution of the script.

Sorry, I'm here again... ;-)

If I run the attached script without parameters, then I can see that gimp
appears and I can generate my needed image. But with parameters (without
the appearing gimp window), I get the following:

[EMAIL PROTECTED]:/home/wmi/cvs/wmi/ui ./oval-0707.pl -output_file FILENAME \
-font_size_pixels 11 -text_string TEXT
oval-buttons.pl: gimp_text_get_extents_fontname: procedural database
execution failed at ./oval-buttons.pl line 64 (DIE)

I cannot 'eval' it out, because I need the data captured in line 64.

Could you please help?

TIA, Zoltan


oval-0707.pl
Description: Perl program
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] OSCon attendance

2004-07-07 Thread Dave Neary

Hi all,

As everyone knows (hopefully), the GIMP won an OSI award 
recently. Part of the results of that is that the GIMP is
one of the candidates for the annual golden award (with a 
large cash prize) which will be presented to the winning 
project in Portland at the O'Reilly Open Source Conference 
in a couple of weeks. 

Is anyone here planning to go to OSCon already? And to 
answer the question before it's asked, there will be no 
cash to pay for travel or accommodation expenses. But if 
someone were already going they could be our official 
representative at the awards dinner.

Alternatively, there are several GNOME developers going 
and presenting papers that I noticed - if no-one here 
wants to go, I suggest that we ask one of them to represent 
us and pick up the prize (if we get one).

What do people think?

Cheers,
Dave.

-- 
Dave Neary
Lyon, France
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] easy questions

2004-07-07 Thread David Odin
On Wed, Jul 07, 2004 at 10:06:58AM +0200, David Neary wrote:
 
 Hi Zack,
 
 Quoting Zack [EMAIL PROTECTED]:
  The first is, how intimately is the GIMP tied to GTK+?
 
 Very. Although the GUI code has been separated out from the internals, the GIMP
 depends on GTK+ to a huge extent. It is inextricably linked to glib and gobject too.
 
  The second is, I haven't looked at the code at all, but is the GIMP
  multithreaded and/or does it absolutely require a multitasking OS?
 
 I wouldn't say so. I don't believe there is threading code in the GIMP, but I am
 not sure.
 
  You won't be able to use any plugin without a multitasking OS...

Regards,


  DindinX

-- 
[EMAIL PROTECTED]
Celibacy is not hereditary
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: Lists, Arrays and Vectors [was Re: [Gimp-developer] Re: Tiny-Fu: A new plug-in for GIMP]

2004-07-07 Thread Kevin Cozens
At 05:17 AM 07/07/2004, Shlomi Fish wrote:
Are you sure using lists instead of vectors is the right thing to do? Lists
are linked lists and as such accessing the i'th element is O(i). In vectors
it is O(1). This can cause an order of complexity increase in handling them.
No, I'm not sure. For the few scripts I looked at (and for ease of 
implementation), using a list was the easier route to have something 
functional during the early development stages. Using vectors instead of a 
simple list would mean the ability to use functions which would provide 
rough equivalents to the SIOD interpreters array manipulation functions.

In any case, this may not be an issue, because a programmer can temporarily
use a vector, and convert it to a list before calling the PDB entries.
Conversion is simple through the use of vector-list and list-vector.
I will take a closer look at using vectors. It will simplify the work 
needed to update old Script-Fu scripts for use with Tiny-Fu. I will start 
by converting between list and vector. If the approach works well, I will 
bit the bullet and update the marshalling code to use vectors for the 
*ARRAY types.

Cheers!
Kevin.  (http://www.interlog.com/~kcozens/)
Owner of Elecraft K2 #2172|What are we going to do today, Borg?
E-mail:kcozens at interlog dot com|Same thing we always do, Pinkutus:
Packet:[EMAIL PROTECTED]|  Try to assimilate the world!
#include disclaimer/favourite   |  -Pinkutus  the Borg
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] plugin to put points on top of each other

2004-07-07 Thread Christoph Lutz
Hi,
I think, a very common problem is to put particular points of two (or 
more) different pictures/drawables on top of each other. This could be 
done by a perspective transformation and is useful, if you for example 
want to create an animated gif out of many slightly different pictures 
(consider unwanted waggling of the camera) you took with your digicam. 
If you use the raw source pictures, there might be small jumps in the 
flow, but if you use a transformation to put particular points on top of 
each other, there is a smooth effect of motion.

I need this feature to create stereooscopic-images, using the 
stereoscopic-plugin. The output-image could be viewed using red/green 
glasses. With stereoscopic-images it is very important to adjust the two 
images (right, left) so that at least the points of the focused object 
are exact on top of each other.

Is there already a plugin which provides the needed feature? My 
recherche in the registry was negative, but may be I overlooked something.

Despite of the fact there might be a already existing plugin, I wrote a 
plugin which implements the following algorithm:
- You provide three source points in the left-eye-image/drawable which 
should be exact on top of the corresponding three points in the 
right-eye-destination-image/drawable.
- The plugin calculates a matrix for a affine transformation out of this 
data and performs the transformation.

Unfortunately, for the moment, the plugin  is not very comfortable to 
use: you have to provide 6 points (x and y-value) in 12 spin-buttons and 
you have to enter all values by hand. Since I am not very firm with gtk 
and the gimp-tools, there is no way to enter these values just by 
clicking on the points in the displayed images. Could your help me in 
that point? I just need to know how to grab the point-coordinates of a 
click to an image! I want to take these coordinates and fill the 
spin-buttons with these data to provide more comfort. From the context 
of my plugin (the run-function), I don't know anything of the diplayed 
image (and the events that are activated in it), isn't it? All I know is 
the image_id and the drawable_id. Any hints are very welcome!!

My algorithm works very similar to the perspective-transformation in 
the toolbox. The main difference is that with perspective-transformation 
it is not possible to provide the source-points which are fixed to the 
corner points. You may only change the 4 destination points. Regardless, 
the user-interface of perspective-transform is very comfortable 
(grid-preview, move points in the picture) and I would be happy if my 
plugin could provide the same comfort.

thanks,
Christoph
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Script-fu-server and queuing

2004-07-07 Thread pcg
  Because the Gimp was not originally designed as a server, it does
  not follow some conventions that are necessary for such a mode. This
  includes the issue of managing shared resources among different
  threads of execution. A few of the resources that are not
  'thread-safe' include the current foreground/background color and
  brush shape.

Your can work around this problem by using Gimp::lock until it is
solved.

-- 
The choice of a  |
  -==- _GNU_ |
  ==-- _   generation Marc Lehmann +--
  ---==---(_)__  __   __  [EMAIL PROTECTED] |e|
  --==---/ / _ \/ // /\ \/ /  http://schmorp.de/   --+
  -=/_/_//_/\_,_/ /_/\_\  XX11-RIPE|
   |
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] OSCon attendance

2004-07-07 Thread Carol Spears
On Wed, Jul 07, 2004 at 04:06:38PM +0200, Dave Neary wrote:
 As everyone knows (hopefully), the GIMP won an OSI award 
 recently. Part of the results of that is that the GIMP is
 one of the candidates for the annual golden award (with a 
 large cash prize) which will be presented to the winning 
 project in Portland at the O'Reilly Open Source Conference 
 in a couple of weeks. 
 
awesome.

 Is anyone here planning to go to OSCon already? And to 
 answer the question before it's asked, there will be no 
 cash to pay for travel or accommodation expenses. But if 
 someone were already going they could be our official 
 representative at the awards dinner.
 
who are the people who live in this area?

 Alternatively, there are several GNOME developers going 
 and presenting papers that I noticed - if no-one here 
 wants to go, I suggest that we ask one of them to represent 
 us and pick up the prize (if we get one).
 
lets look to find a gimp person first.

carol

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] easy questions

2004-07-07 Thread Dave Neary

Hi,

Quoting David Odin [EMAIL PROTECTED]:
   The second is, I haven't looked at the code at all, but is the GIMP
   multithreaded and/or does it absolutely require a multitasking OS?
   You won't be able to use any plugin without a multitasking OS...

Won't the plug-in just become modular over the main app? Oh, no - we 
use shared memory, so the two apps need to be running at the same time...

Dave.

-- 
Dave Neary
Lyon, France
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] OSCon attendance

2004-07-07 Thread Dave Neary

Hi,

Quoting Carol Spears [EMAIL PROTECTED]:
 On Wed, Jul 07, 2004 at 04:06:38PM +0200, Dave Neary wrote:
  Part of the results of that is that the GIMP is
  one of the candidates for the annual golden award (with a 
  large cash prize) which will be presented to the winning 
  project in Portland at the O'Reilly Open Source Conference 
  in a couple of weeks. 
 awesome.

We're a long way from winning - we're up against the Valgrind 
guy, Pango, VideoLAN, GNU arch and a couple of other really 
good projects. We have a shot, though.

 who are the people who live in this area?

Do people live near Portland? (Joke!) AFAIK, no-one is 
actually here and living in Portland. yosh is in the bay area, 
and has said he will be able to go if the conference 
registration fee is waived (which I think it should be).

So I guess our search is over :)

 lets look to find a gimp person first.

That was the point of mailing here.

Cheers,
Dave.

-- 
Dave Neary
Lyon, France
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] plugin to put points on top of each other

2004-07-07 Thread William Skaggs

Christof Lutz writes:
 Could your help me in that point? I just need to know how to grab the 
 point-coordinates of a click to an image!

If you go into the plug-ins/common directory of the source and grep
for GDK_BUTTON_PRESS, you will find plenty of examples that will
quickly show you how to do it.

There are three main steps involved:  (1) requesting to receive
button press events, (2) connecting a callback for them, and
(3) handling them in the callback.  

Best,
  -- Bill
 

 
__ __ __ __
Sent via the KillerWebMail system at primate.ucdavis.edu


 
   
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] what's required to develop GIMP

2004-07-07 Thread Chamal De Silva
Hi,

I am completly new to GIMP development. And I would like to be a gimp
developer.
Please give me information on the following quetion.

1. What is the programming language used to develop gimp.
2. What are the tools and compilers that i need to compile gimpe source code.
3. What is the latest version of GIMPs source code.

Thanks a lot,
Chamal.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] plugin to put points on top of each other

2004-07-07 Thread Sven Neumann
Hi,

William Skaggs [EMAIL PROTECTED] writes:

 Christof Lutz writes:
  Could your help me in that point? I just need to know how to grab the 
  point-coordinates of a click to an image!
 
 If you go into the plug-ins/common directory of the source and grep
 for GDK_BUTTON_PRESS, you will find plenty of examples that will
 quickly show you how to do it.

I guess that Christof is asking for a way to get the coordindates of a
click into a GIMP image window, not a click on a widget in the plug-in
dialog. If that is the case, then the answer is that plug-ins can't do
that.


Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] what's required to develop GIMP

2004-07-07 Thread Raphaël Quinet
On Wed, 7 Jul 2004 09:41:48 -0700, Chamal De Silva [EMAIL PROTECTED] wrote:
 I am completly new to GIMP development. And I would like to be a gimp
 developer.
 Please give me information on the following quetion.
 
 1. What is the programming language used to develop gimp.

Most of it is written in C, some parts of the build system use a bit of
Perl.  A quick look at the source code would have allowed you to answer
your own question easily.  In addition to the gimp core written in C,
you can also have the various scripting extensions written in Scheme
(Script-Fu or the newer Tiny-Fu), Perl and Python.

 2. What are the tools and compilers that i need to compile gimpe source code.

Please have a look at:
  http://www.gimp.org/source/  (stable version)
  http://developer.gimp.org/   (development version)
That will give you all the necessary information.  In addition, once
you have a look at the source code, please read the README and INSTALL
files.  If you get the code from CVS, you can also have a look at the
HACKING file.

 3. What is the latest version of GIMPs source code.

The latest version of the source code is in CVS.  If you want tarballs,
then the latest stable version is 2.0.2 and the latest unstable version
is 2.1.1, available from ftp.gimp.org and its mirrors.  This information
is also available from the web sites listed above.  Please have a look
at them.

-Raphaël
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] plugin to put points on top of each other

2004-07-07 Thread Christoph Lutz
Sven Neumann wrote:
Hi,
William Skaggs [EMAIL PROTECTED] writes:

Christof Lutz writes:
Could your help me in that point? I just need to know how to grab the 
point-coordinates of a click to an image!
If you go into the plug-ins/common directory of the source and grep
for GDK_BUTTON_PRESS, you will find plenty of examples that will
quickly show you how to do it.

I guess that Christof is asking for a way to get the coordindates of a
click into a GIMP image window, not a click on a widget in the plug-in
dialog. If that is the case, then the answer is that plug-ins can't do
that.
yes, that's true and it's a pity that there is no way :-) So what do you
suggest:
I want to mark particular points in one or more images and use the
marked coordinates in my plugin-dialog. Do you think it's the best to
create picture-buttons with more or less small thumbnails of the images
and read the coordinates of the corresponding GDK_BUTTON_PRESS? The
smaller the thumbnail, the more unprecise the coordinates I get. Is this
 way possible actually? How can I get reasonable results in respect to
the precision of the corrdinates? I always had in mind to do it that way
(create a picture-button), but I felt the results may be better if I
click into the GIMP-image itself which is unfortunately not possible.
Christoph

Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] the gnome foundation and board

2004-07-07 Thread Carol Spears
someone should say something nice about the gnome foundation and their
help in getting the gimp conference to eh, be.  they were also very nice
to have visit in that one meeting.

the very best thing i can say about the event and the gnome foundations
influence on it is that Tim Ney was a pleasure to communicate with.  i
remember relaxing and enjoying everything and a nifty wireless keyboard
which should have been collecting notes 

carol

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] plugin to put points on top of each other

2004-07-07 Thread William Skaggs
Christof Lutz writes:
 yes, that's true and it's a pity that there is no way :-) So what 
 do you suggest:

 I want to mark particular points in one or more images and use the
 marked coordinates in my plugin-dialog. Do you think it's the best to
 create picture-buttons with more or less small thumbnails of the images
 and read the coordinates of the corresponding GDK_BUTTON_PRESS? The
 smaller the thumbnail, the more unprecise the coordinates I get. Is this
 way possible actually? How can I get reasonable results in respect to
 the precision of the corrdinates?

My apologies for misunderstanding the question.  I am doing something
very much like this in gfig, using the following code (simplified
a little bit):

  if (! back_pixbuf)
back_pixbuf = gimp_image_get_thumbnail (image_id,
preview_width, preview_height,
GIMP_PIXBUF_LARGE_CHECKS);

  if (back_pixbuf)
gdk_draw_pixbuf (preview-window,
 preview-style-fg_gc[GTK_STATE_NORMAL],
 back_pixbuf, 0, 0,
 0, 0,
 gdk_pixbuf_get_width (back_pixbuf),
 gdk_pixbuf_get_height (back_pixbuf),
 GDK_RGB_DITHER_NONE, 0, 0);

Here preview is a GtkDrawingArea.  You can create a thumbnail up
to 512 x 512 in this way.  (Incidentally, thanks to Sven for improving
the code I originally wrote to do this.)

Best,
  -- Bill

 

 
__ __ __ __
Sent via the KillerWebMail system at primate.ucdavis.edu


 
   
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] plugin to put points on top of each other

2004-07-07 Thread Sven Neumann
Hi,

William Skaggs [EMAIL PROTECTED] writes:

   if (back_pixbuf)
 gdk_draw_pixbuf (preview-window,
  preview-style-fg_gc[GTK_STATE_NORMAL],
  back_pixbuf, 0, 0,
  0, 0,
  gdk_pixbuf_get_width (back_pixbuf),
  gdk_pixbuf_get_height (back_pixbuf),
  GDK_RGB_DITHER_NONE, 0, 0);

Any particular reason that you use GDK_RGB_DITHER_NONE here instead of
GDK_RGB_DITHER_NORMAL? GdkRGB dithering is rather fast and it yields a
much better visual appearance on 16bit displays.

Or did I write it this way?


Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: Lists, Arrays and Vectors [was Re: [Gimp-developer] Re: Tiny-Fu: A new plug-in for GIMP]

2004-07-07 Thread Markus Triska

 Are you sure using lists instead of vectors is the right thing to do?
  Lists are linked lists and as such accessing the i'th element is O(i). In
  vectors it is O(1). This can cause an order of complexity increase in
  handling them.

This is true, but not much of a problem, since most scripts only use either 
the first 1 or 2 elements of arrays or work on typically very short arrays, 
or want to pass a (short) array to PDB, where there is no difference between 
list-construction and setting every element of a vector explicitly (the 
latter possibly being even more inefficient).

 No, I'm not sure. For the few scripts I looked at (and for ease of
 implementation), using a list was the easier route to have something
 functional during the early development stages. Using vectors instead of a
 simple list would mean the ability to use functions which would provide
 rough equivalents to the SIOD interpreters array manipulation functions.

As I understand it, there are even *exact* equivalents to the current array 
type. No wonder, since a Lisp vector is a special case of an array 
(one-dimensional). In Script-Fu, arrays are indeed vectors.

 I will take a closer look at using vectors. It will simplify the work
 needed to update old Script-Fu scripts for use with Tiny-Fu. I will start
 by converting between list and vector. If the approach works well, I will
 bit the bullet and update the marshalling code to use vectors for the
 *ARRAY types.

I also opt for vector because apart from being the natural Scheme equivalent 
to PDB's one-dimensional arrays, it makes writing plug-ins easier for people 
that have no to little practice in converting common for/while loops using 
tail-recursion, and current scripts would work practically unmodified, 
without explicit conversions list-vector that would only cost time (with 
everybody ending up calling these instead of working on lists most of the 
time).

Markus.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] CVS updates?

2004-07-07 Thread Brion Vibber
Is Gimp anonymous CVS on a delayed copy? I'm assuming so based on the 
fact that I can't seem to get at the most recent commits through a cvs 
up -dP or cvs log. If there's something in the developer FAQ which is 
explicit about this, please point me to it so I can feel stupid. I did look!

Also, the RSS changelog (http://wilber.gimp.org/~rss/gimp-cvs.rdf) has 
links to the GNOME bonsai on cvs.gnome.org which are all dead links. The 
only thing running on cvs.gnome.org seems to be viewcvs, which does at 
least seem to be more up to date than anon cvs, and diffs can be dug out 
of it.

Would it be possible to fix the RSS changelog to point at viewcvs, which 
works, instead of bonsai, which doesn't?

-- brion vibber (brion @ pobox.com)


signature.asc
Description: OpenPGP digital signature