Re: [Gimp-developer] GAP

2007-08-05 Thread Joao S. O. Bueno Calligaris
On Sunday 05 August 2007 06:45, 
[EMAIL PROTECTED] wrote:
  Hi,
 
  On Sat, 2007-08-04 at 01:58 -0300, Joao S. O. Bueno Calligaris 
wrote:
  I am getting an error linking gimp-gap svn in a 64bit
  enviromment, in both trunk and gap-2-2 branch:
 
  That's a problem with the copy of libavcodec that is included
  with GAP. You better disable support for libavcodec when
  configuring gap. For GAP 2.4 we should include a recent version
  of libavcodec.
 
  Sven

 To expand on Sven's answer a little, the FFMPEG project does not
 provide a stable API; therefore the GAP includes the source for a
 specific snapshot of the code and staticly links to it. The
 snapshot in the GAP's tree is from 2005 ; it needs to be updated
 and the GAP code modified to employ the new FFMPEG API (also for
 64-bit support and GCC4 compatibility as well).

 Wolgang Hofer, the main developer of the GAP, is working on that
 update but he does not have direct access to the Internet right
 now. It may be a few months before updated FFMPEG support is
 available but it is being worked on. In the interim, I would
 suggest disabling libavcodec support and using an external utility
 to convert your frames to video.



Hehh..that is a bit too much, ain't it?
It actually _did_ build when  I tweaked the Makefiles in the library 
dirs (and only there) to include the  -fPIC GCC directive.
64 bit, GCC 4.1.1

It is not like this will only work in 2010 or 2012.

js
--



___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] GAP

2007-08-04 Thread Joao S. O. Bueno Calligaris
On Friday 03 August 2007 17:18, Sven Neumann wrote:
 Hi,

 On Fri, 2007-08-03 at 23:54 +0400, Alexandre Prokoudine wrote:
   Are you absolutely sure that you removed the fuzzy marker
   after updating the translation?
 
  Yes, I am.

 OK, please try again after updating from SVN. I added some missing
 calls to gimp_plugin_domain_register(). That should fix it, but
 there might be more places affected that need a similar fix.


 Sven


I am getting an error linking gimp-gap svn in a 64bit enviromment, in 
both trunk and gap-2-2 branch:

/usr/bin/ld: bitstream.o: relocation R_X86_64_32 against `a local 
symbol' can not be used when making a shared object; recompile 
with -fPIC
bitstream.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[4]: *** [libavcodec.so] Error 1


when doing:
gcc -shared -o libavcodec.so bitstream.o utils.o mem.o allcodecs.o 
mpegvideo.o jrevdct.o jfdctfst.o jfdctint.o mpegaudio.o ac3enc.o 
mjpeg.o resample.o resample2.o dsputil.o motion_est.o imgconvert.o 
imgresample.o mpeg12.o mpegaudiodec.o pcm.o simple_idct.o 
ratecontrol.o adpcm.o eval.o dv.o error_resilience.o fft.o mdct.o 
mace.o huffyuv.o cyuv.o raw.o h264.o golomb.o vp3.o asv1.o 4xm.o 
cabac.o ffv1.o ra144.o ra288.o vcr1.o cljr.o roqvideo.o dpcm.o 
interplayvideo.o xan.o rpza.o cinepak.o msrle.o msvideo1.o vqavideo.o 
idcinvideo.o adx.o rational.o faandct.o 8bps.o smc.o parser.o 
flicvideo.o truemotion1.o vmdav.o lcl.o qtrle.o g726.o flac.o 
vp3dsp.o integer.o snow.o tscc.o sonic.o ulti.o h264idct.o qdrw.o 
xl.o rangecoder.o png.o pnm.o qpeg.o vc9.o h263.o h261.o msmpeg4.o 
h263dec.o svq1.o rv10.o wmadec.o indeo3.o shorten.o loco.o alac.o 
wnv1.o ws-snd1.o aasc.o  a52dec.o liba52/bit_allocate.o 
liba52/bitstream.o liba52/downmix.o liba52/imdct.o  liba52/parse.o 
liba52/crc.o 
liba52/resample.o  -lm -lz -ldl  -Wl,--warn-common -rdynamic

(trying the suggested fPIC makes build halt early on.)



 ___
 Gimp-developer mailing list
 Gimp-developer@lists.XCF.Berkeley.EDU
 https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] [Gegl-developer] PyGEGL instant crash

2007-07-19 Thread Joao S. O. Bueno Calligaris
On Thursday 19 July 2007 19:28, Kevin Cozens wrote:
 David Gowers wrote:
  Using Python 2.6, typing 'import gegl' at the interpreter prompt
  causes the following crash to immediately happen:

 [snip]

  I'm also pretty sure that the bug lies in the pygegl module, as
  I've compiled and used many other modules for Python 2.6, with no
  problems, and I ran the babl and gegl tests successfully (and the
  gegl editor works okay too)

 I have only tested pyGEGL with the 2.4 version of Python. It
 possible (or very likely?) that something has changed in the 2.6
 version of Python. I don't have the 2.6 version installed at the
 moment so I can't investigate this further.


Python 2.6???


The stable python is 2.5.1  - there is not even mention of a 2.6 
release on teh python.org pages.

David: do  you mean python 2.5 instead? 


regards,
js
--
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Gimp-developer] Fwd: LGM 2007 Final Report - Help needed

2007-05-10 Thread Joao S. O. Bueno Calligaris


--  Forwarded Message  --

Subject: LGM 2007 Final Report - Help needed
Date: Thursday 10 May 2007 12:10
From: Louis Desjardins [EMAIL PROTECTED]
To: Sven Neumann [EMAIL PROTECTED], Joao S. O. Bueno Calligaris 
[EMAIL PROTECTED], Plinnell [EMAIL PROTECTED], Cyrille 
Berger [EMAIL PROTECTED], Boudewijn Rempt 
[EMAIL PROTECTED], Igor Novikov 
[EMAIL PROTECTED], Alexandre Prokoudine 
[EMAIL PROTECTED], Jon Phillips 
[EMAIL PROTECTED], Andy Fitzsimon 
[EMAIL PROTECTED], Martin Poirier [EMAIL PROTECTED]

Hi guys,

(I am writing to a few of the team leaders and please feel free to
 relay this request to the person in your team you feel would do the
 best job to gather the resquested information. Also, if you think I
 have forgotten somebody or a project, please let me know. — Thanks!)

LGM 2007 has been a tremendous experience! I hope all travellers had
 a good trip back home! Thank you so much for being in Montréal with
 us! Thank you so much for all your encouragements and enthusiasm!

We now must think about the final report of this year's LGM. This is
important to keep track of what was accomplished and to prepare next
 year's edition. It is of upmost importance for our sponsors, to
 secure next year sponsorship, to let them know how and why LGM is
 important for the participating projects.

From each team I would ask a short but enough detailed summary of
 what was accomplished since last year. It can be both quantitative
 and qualitative. I doesn't need to be a long text. Since it is the
 first time we do that (I think) I leave it up to you. We will make
 it a nice layout and will include some nice pics as well. The report
 will help us draw attention on LGM and will also serve as a
 reference point for the teams.

Thank you for responding quickly. We'd like to have the report done
 within a few weeks from now.

Cheers!

Louis



--
Louis Desjardins
Organisateur / Organiser
Libre Graphics Meeting 2007 - Montréal
www.libregraphicsmeeting.org/fr
www.libregraphicsmeeting.org
+1 514 934 1353 HAE / EDT GMT -4

---
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Pixel coordinates input type for script-fu?

2007-05-01 Thread Joao S. O. Bueno Calligaris
On Tuesday 01 May 2007 00:15, Mark Lowry wrote:
 I'm working on a script in which it would be
 advantageous to use the mouse to click on an image and
 have the pixel coordinates captured as an input.
 Right now I have to manually enter the coordinates for
 four points, which is a tedious process.

 Is there a way to capture these coordinates as inputs
 to a script?  If not, where is the appropriate place
 to suggest a feature request for this?


Hi - no, there is no official way to do that.

What I do in my scripts is require the user to start a Path with the 
bezier tool before calling the script - The script then use the 
coordiantes of the first (or how many I want) points of this path as 
input coordinates. These can e read through the PDB.

js
--
 Thanks . Mark

 __
 Do You Yahoo!?
 Tired of spam?  Yahoo! Mail has the best spam protection around
 http://mail.yahoo.com
 ___
 Gimp-developer mailing list
 Gimp-developer@lists.XCF.Berkeley.EDU
 https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Pixel coordinates input type for script-fu?

2007-05-01 Thread Joao S. O. Bueno Calligaris
On Tuesday 01 May 2007 17:05, Mark Lowry wrote:
 --- Joao S. O. Bueno Calligaris [EMAIL PROTECTED]

 wrote:
  Hi - no, there is no official way to do that.
 
  What I do in my scripts is require the user to start
  a Path with the
  bezier tool before calling the script - The script
  then use the
  coordiantes of the first (or how many I want) points
  of this path as
  input coordinates. These can e read through the PDB.
 
  js
  --

 I have thought about doing that and I think that is
 the way I will have to go.  I'm confused with how to
 extract elements from the vector returned by
 gimp-path-get-points.  I thought I understood that
 (vector-ref vector k) was the way to pull the k-1
 element from the vector, but when I input (vector-ref
 '#(1 1 2 3 5 8 13 21) 5) I just get an errobj on
 vector-ref.  What do I need to do to be able to
 extract a value from the result of
 (gimp-path-get-points image path)?

oh man.,..
2 things:
1) I do python-fu, not Scheme (script-fu) - so I have erased from my 
mind the esoteric ways of getting elements out of a vector or array 
in Scheme. btw, if your plug-in is of any complexity, unless you 
think your time is being well spent as you exercise your mind around 
how to get and use data with scheme expressions as an extra exercise, 
I'd  suggest writting it in python. If you are on windows, that will 
only work witht he developemtn version of GIJMP, though. But it has 
the advantadge of letting you worry with your problem instead of the 
language _and_ your problem.


2) this very API is being obsoleted in GIMP 2.3.x - there are all new 
vector manipulation calls in place, that can finally deal correctly 
with multiple stroke vectors (not needed to fecth just one or two 
coordinates anyway)

In python, an interactiuve session exploring the return values might 
just display:
 img = gimp.image_list()[0]
 pdb.gimp_path_get_points (img, a)
(1, 0, 15, (103.03428571428572, 101.01142857142861, 1.0, 
104.74857142857149, 98.902857142857101, 2.0, 529.68571428571431, 
102.38, 2.0, 529.480002, 102.039996, 1.0, 
529.27428571428572, 101.679995, 2.0))
 v = pdb.gimp_path_get_points (img, a)
 points  = v[3]
 points
(103.03428571428572, 101.01142857142861, 1.0, 104.74857142857149, 
98.902857142857101, 2.0, 529.68571428571431, 102.38, 2.0, 
529.480002, 102.039996, 1.0, 529.27428571428572, 
101.679995, 2.0)
 points[0], points[1]
(103.03428571428572, 101.01142857142861)

(the   are the prompt, not part of the language)


--
Bill...could you see if it iyou can add a simple api for retrieving 
the sample points? I think this will bother no one at this point, it 
is starightforward as you said, and...we want to get 2.4 out, so it 
has to be done real soon.

js
--


 __
 Do You Yahoo!?
 Tired of spam?  Yahoo! Mail has the best spam protection around
 http://mail.yahoo.com
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] How to change the active current tool from a plugin?

2007-04-25 Thread Joao S. O. Bueno Calligaris
On Wednesday 25 April 2007 17:27, Laurent gauvrit wrote:
 hello everybody,

 I work on a hopefull edge detection plugin for gimp and i need to
 change the active current tool by a button in my plugin.

 Anyone know the answer???

Yes.

The answer is: it is not possible at the moment.
Sorry for that.

A plug-in can itself use the tools, , but it can't change most things 
in the UI context.

js
--



 thanks


 lolo

 _
 Windows Live Spaces : créez votre blog à votre image !
 http://www.windowslive.fr/spaces

 ___
 Gimp-developer mailing list
 Gimp-developer@lists.XCF.Berkeley.EDU
 https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] how to call gimp procedure from text terminal ?

2007-04-23 Thread Joao S. O. Bueno Calligaris
On Monday 23 April 2007 21:02, stu seven wrote:
 +I asked this on the google group, but with no answer yet...

  How can a menu item or gimp procedure be called from a
 text terminal, with a graphical gimp session already running ?

  I know that, using a function name, and parameters, this can
 be done in batch mode, for instance... however, all Im looking for
 is to remotely open the function dialog, via the text terminal.

  Is this possible... or... some other way of opening the menu
 item dialog besides clicking on it ?


Such a terminal would have to be done from within GIMP.

The easiest way I can think of doingthis is writing a python plug-in 
that will listen to a socket and execute what you type in there once 
you connect to that socket.


 thanks
 ___
 Gimp-developer mailing list
 Gimp-developer@lists.XCF.Berkeley.EDU
 https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Gimp-developer] Fwd: [CREATE] Standard RAW File Format (fwd)

2007-04-18 Thread Joao S. O. Bueno Calligaris


--  Forwarded Message  --

Subject: [CREATE] Standard RAW File Format (fwd)
Date: Tuesday 17 April 2007 05:36
From: Kai-Uwe Behrmann [EMAIL PROTECTED]
To: libtiff - Liste [EMAIL PROTECTED], Kunst Tuepfel 
[EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]

Hello, just to inform all the digital camera RAW developers out here.
Sorry for any duplication.

-- Forwarded message --
Date: Fri, 16 Mar 2007 18:18:33 +0100
From: Dietmar Wueller [EMAIL PROTECTED]
To: Dietmar Wueller [EMAIL PROTECTED]
Subject: Standard RAW File Format

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

as a member of the ISO TC42 (technical committee for photography)
working group 18 (electronic imaging) standards group I would like to
inform you that the existing Tiff/EP (ISO 12234) standard for images
captured by digital cameras is currently under revision.

The Adobe DNG format was derived from this standard and the group has
Adobe's permission to incorporate modifications and developments made
for DNG in the new standard.

In addition the standards group is asking all interested people for
comments and requirements - which are not part of the current DNG or
Tiff/EP standard - to be incorporated in the new standard.
If you have such please forward them to me by the end of April.

Hopefully we will soon be able to provide a standardized file format
which meets everybody's expectations and gets a wide support by
 camera manufacturers, software vendors, and photographers.

Please forward this message to everybody who may have contributions
 to the revision.


Best regards
Dietmar Wueller

Image Engineering
Dietmar Wueller
Augustinusstr. 9d
50226 Frechen
Germany

phone +49 2234 912141
fax +49 2234 912142
[EMAIL PROTECTED]
www.image-engineering.de


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF+tFp7Olj94xfLY4RArPaAKCtTyhP4rWNjRwfNmb5WW7B9TrtngCfYKMm
qSARyPFRA4/lBFuQE54LTm0=
=1Yi9
-END PGP SIGNATURE-
___
CREATE mailing list
[EMAIL PROTECTED]
http://lists.freedesktop.org/mailman/listinfo/create

---
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] internal representation of a selection

2007-03-30 Thread Joao S. O. Bueno Calligaris
On Friday 30 March 2007 13:10, Helmut Jarausch wrote:
 Hi,

 can somebody, please, point me to some information on how a
 selection is represented (internally) within Gimp and how one can
 access this. Is it represented by a matrix of bits?
 If the selection has many holes it's not sufficient to have a lower
 and upper bound for each pixel row. I need the selection exactly
 for my attempt at a new healing tool.

 Many thanks for a pointer,

Hi Helmut - 
the selection is a matrix of bits, yes - a drawable object, with one 
byte per pixel, meaning the strenght  of the selection at that 
point.

the call gimp_image_get_selectin available for plug-ins can return you 
the selection as a drawable object.
Through the UI you can simply enable the quickmask (click on the 
little square to the left of the hor. scroll bar on an image window), 
to transfer the selection to an editable image channel.

js
--


 Helmut Jarausch.

 ___
 Gimp-developer mailing list
 Gimp-developer@lists.XCF.Berkeley.EDU
 https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] [Gimp-Developer] One-click bi nary downloads via the gimp website

2007-03-29 Thread Joao S. O. Bueno Calligaris
On Thursday 29 March 2007 07:22, Robert L Krawitz wrote:
    We already direct users to recomendeded binaries, and as long as
 we continue to be clear that we don't build those binaries
 ourselves, why should we not make it easier to reach those?

 Because whatever disclaimers etc. you use, users will see the
 binaries as coming from the GIMP project, and will blame you if
 there are any download problems or corrupted (or trojaned!)
 binaries.


Just then - who will they blame if a binary from gimp-win crashes? 
The names and e-mails for complaint may be the ones in the gimp-win 
page, but on the users mind, the program that failed is the GIMP.

Back on the thread topic - when lecturing about the GIMP, the 
instructions I give for windows downloading are something 
like google for Gimp Windows Download. 

Having a download link straight from GIMP .or gmaybe could be a nice 
thing, but it is not the most important. There is the issue of 
needing to download the GTK+ installer as well - and the instructions 
ofr that - so it is not only linking to the GIMPwin installer from 
gimp.org/downloads.

However - (I am reviewing now), a user trying to download the GIMP for 
windows now, starting from gimp.org has to go through:
www.gimp.org
www.gimp.org/downloads
www.gimp.org/windows
gimp-win.sourceforge.net/
gimp-win.sourceforge.net/stable.html

And then grab the gtk+, and gimp win binaries. And all those pages are 
in English only - (most people in my target audiences are not 
proeficient enough in English - so, just imagine all those pages are 
in some language you don't understand, and you will see it is rather 
unprobable that one would click on the correct links at each of then)

Regardless of providing a direct link to the binaries, I think that a 
direct link from gimp.org/downloads to a page with the same 
instructions and links that live currently live in 
gimp-win.sourceforge.net/stable.html is a must. 

Discussing the i18n of some or all of these pages would be OT here, 
but that is of concern to me as well.

js
--

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Gimp-developer] Rudeness on gimp devel and bugzilla - was: Re: Tools

2007-03-19 Thread Joao S. O. Bueno Calligaris
On Monday 19 March 2007 08:11, Simon Budig wrote:
  IMHO, refraining from posts like this could greatly improve the
  atmosphere of this list.
  It is really up to you to help  somebody with answering his
  question or not to help, but this answer only hurts and helps
  nothing.

 I don't agree with you there.
... (remaining ranst tossed on bascket)


Simon, where does that forbid one to add words 
like thanks, please, would and etc... to even a short answer, 
like a FAQ URL???


You see, the GIMP is not exactly with exceeding developer resources, 
and every single person I see trying to approach the project either 
here or over bugzilla gets a rude answer that might have turned then 
away for good. Examples from the last 48 hours include a help 
yourself (bug #329020 - 2007-03-20), we don't take bug reports 
against outdated development versions anyway. (bug #420170, 
2007-03-19) 

The guys organizing LGM had called my attention to the point that GIMP 
is a project perved as hostile towards newcomers. 

I even addressed in private some hostile postings on this list over 
the last weeks to try to start changing this general behavior - but 
it looks it is just too overspread.

It is not really hard - and that is to you Mitch, you Sven, you Nomis, 
to simply rememebr the person on the other sidee is sitll a human 
being, is not it? Not less human for having less abilities to 
compile/hack complicated software projects, much less for simply not 
knowing how to do so.

You can think ut whatver you want, mutter whatver you want, write a 
scratch however you want - I ma just askign that before hitting 
the post  button you go back to thetext and add some of the magic 
words - even if in your heart you are lying.

Example:
from:
we don't take bug reports against outdated development versions 
anyway.
to:
Please, post bugs only using the latest development version. 

(that if one is really unwillingly to type a few more characters) 

sincerely,
js
--
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Brush Scaling

2007-03-15 Thread Joao S. O. Bueno Calligaris
On Thursday 15 March 2007 07:22, jbaker wrote:
 Thanks for all the work on this one, it works great...

 I was just curious if there are any plans add the ability to scale
 and rotate the standard brushes with python  ? I did a quick search
 in the procedure browser but didn't see anything except the
 functions for the generated brushes...

 thanks,


no plans made - except for generated brushes (the ones you can create 
and edit from within the brush dialog).

But this is an area I am thinking about. (actually, mostly the pdb for 
brush  stroking)

Please say a little more on what you are planning to do (the final 
effect). 

Regards,

js
--


 jerry
 ___
 Gimp-developer mailing list
 Gimp-developer@lists.XCF.Berkeley.EDU
 https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] memory manage in python-fu

2007-03-11 Thread Joao S. O. Bueno Calligaris
On Sunday 11 March 2007 20:54, D. Stimits wrote:
 I have not found any python-fu way to close a file, or to reclaim
 memory after creating an image or layer. Is there such a thing? Is
 there instead some sort of garbage collection?

 Speculating about why it claimed it was out of memory, I'm
 wondering if the hard drive simply was too slow responding. It's a
 laptop, running with core duo, entirely in ram. The drive is thus
 much slower than the ability to consume ram. How does gimp
 determine that there is no space left on the device...is it a
 timeout in addition to other means?


The normal python way would be to set the object for destruction after 
it is no longer used.

However, it may well be possible that the GIMP bindings to python are 
not deleting GIMP images creted from within python, as it should be 
done.

I had, myself,  never thought of using a script o create so many 
images. 

As you rerro r mesage is no space left on device - please try to 
cehck gimp preferences for tmp dirs, maybe it is using another 
partition that might be getting filled.

The increaseof RAM usage for itself however shows there is something 
wrong going on - could you please fill a bug report about this at
bugzilla.gnome.org ? 

If possible, please attach a minimalistic version of your script taht 
would trigger the problem.

Thank you,

js
-- 
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] SoC project ideas

2007-03-08 Thread Joao S. O. Bueno Calligaris

On Thu, 2007-03-08 at 01:43 -0500, Kevin Cozens wrote:
  It is pretty easy to crash many (most?) of the plug-ins when
  passed bad data from some script. Checks in libgimp can stop GIMP
   from crashing but will only go so far to stop the plug-in from
  crashing. I think it would be a worthwhile project to get done at
  some point. In terms of SoC, it would be a low priority project.
 
  This also raises the question as to whether the plug-in-template
  can handle being passed bad data or not. If not, it should be
  updated to show new plug-in authors how to properly write a
  plug-in to deal with the possibility of receiving bad data.


 On Thursday 08 March 2007 04:12, Sven Neumann wrote:
 The question is, is this a serious problem at all? If a script is
 broken and the result is a plug-in that crashes, is that really a
 problem? A crashing plug-in shouldn't cause further harm and
 there's a warning that informs the script author that there's a
 problem. The script can then be fixed.

I fully agree with Sven here. Besides, I can't imagine how this could 
be something cool, which, IMHO, GSoC stuff should be.

js
--
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] SoC project ideas

2007-03-08 Thread Joao S. O. Bueno Calligaris
On Tuesday 06 March 2007 05:03, Sven Neumann wrote:
 Hi,

 I have read through the list at
 http://wiki.gimp.org/gimp/SummerOfCode and I think we need to
 triage the list and try to come up with fewer but more detailed
 proposals. Here are some comments to get us started:

I added some more ideas to the list on the wiki I think could be 
feasible as GSoC projects:

 * Enhancing Painting with parameter curves 
   
   Currently there are quite a few options to use with the paint 
tools, however, mapping how these options could vary with pressure, 
tilt, speed, angle of painting is somewhat limited. A complete tabbed 
dock, where new curves could be added that would map one input 
variable to paint option could increase several fold the options 
available to artists. A request for this is drafted in 
[http://bugzilla.gnome.org/show_bug.cgi?id=119240|bug #119240].

 * Categories for brushes, fonts, gradients and palettes
  
  If one adds too many fonts or brushes to GIMP, they quickly become 
un-manageable through the existing UI. Implementing a way of 
organizing these resources in sub-categories, in a way that one 
resource could be present in more than one category (like thrugh the 
use of tags) in a nice UI could overcome these limitations;

 * Font Selector Widget
   
   We need something better. Something that is reusable.  Something to 
turn choosing fonts into a pleasure, rather than a pain. Something to 
leave the competition on the dust.


And I also came up with this idea, but did not add it to the wiki, 
because it certainl should have further consideration from the 
developers, more than the others, to get toeven a rughidea of what 
will be needed:
 
* Layer Folders UI
   
   With the upcoming integration of GEGL, there finally will be 
internal support for layer grouping, even more than one level of it.  
Aide form the work on the core, we will need a good UI to be the 
evolution of the current layers dialog. If the GIMP will only allow 
nested layers, then this should be mroe or less trivial. If GIMP will 
allow full usage of GEGL, and allow the same layer to be used as 
source for multiple operations then we will need a brilliant UI. 
   

js
--
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Gimp-developer] Libre Graphics Meeting - last call

2007-03-02 Thread Joao S. O. Bueno Calligaris
Ok, that is it.

We are closign the list of people who will need sponsorwsship to 
attend LGM 2 in Canada this year. 

Whoever wants to go an d apply for air tickect refund, please do 
contact me in the next hours.


I will also ask for people who think they are on the refunding list, 
but have had no word from me yet, to write me - ASAP.  We better have 
some few extra e-mails flaoting around than missing someone.


js
--


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Gimp-developer] gimpwin install

2007-02-27 Thread Joao S. O. Bueno Calligaris
Hi,

I, exceptionally, have a question reguarding the GIMP builds for 
windows:

How  hard would it be to create a .msi installer for gimp + gtk+, 
instead of the current zip files? 

It seems to be quite standard nowadays, and a couple high profile free 
software packages are uisng it.

I think that could be a nice surprise for win users.

regards,

js
--
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Gimp-developer] LGM - goint to, and GIMP presentation

2007-02-26 Thread Joao S. O. Bueno Calligaris
GIMP presentation at LGM -

Hi people -

LGM guys are asking for a GIMP presentation at the Libre Graphics 
Meeting. Something to show off GIMP's capabilities, new features in 
the 2.4 version, and plans for the future.

The other big projects there will feature such a presentation (more or 
less like Andyfitsz's presentation last year, sans the bugs)

christoph usage is of utmost importance; we expect many graphics 
pros who haven't even heard of FLOSS

So, if anyone wants to present such a lecture, please step ahead -

Just remembering you that Pippin will already present something about 
the achievements and other dark magic in GEGL.


---
In time: anyone who wants to get GIMP/LGM sponsorship to be there, 
should contact me ASAP, if had not done so (ok, some people did not 
write me, I picked the names inthe GIMP wiki as well - but if in 
doubt contact me).

People already confirmed should start looking after booking their 
flights. Again, if in doubt, just ask me.


http://www.libregraphicsmeeting.org

js
--
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Layer Groups

2007-02-20 Thread Joao S. O. Bueno Calligaris
On Tuesday 20 February 2007 09:54, jEsuSdA wrote:
 Hello!

 I'm not a developer, but i suscribed to the devel list because i
 work everyday with gimp and i like to know how it grow day by day.

 First at all i would to congratulate us for you efforts.
 I love Gimp and i try to install it wherever i can (friends,
 family, office, ...) and i have made some conferences to stimulate
 gimp use.

 My question is why and when Gimp will include LAYER GROUPS or
 FOLDERS (more useful)?

 I think Layer Folders were a great utility, and when i work with
 lot of layers i need them. ;)

Hi Jesusda 
(I should regard that my typing skills are bad enough already without 
me trying to copy the casing in your nick)

As soona s gimp 2.4 is out, we will start working in merging teh Gimp 
core with GEGL. GEGL provides teh equivaletn of layer folders out of 
the box - so it is almost certain that teh gimpv ersion following the 
next one, be it 2.6 or 3.0, will feature those.

However, we are at the moment with very little main force to propel 
the GIMP forward - given the natrue of your work maybe you cuod 
yurself, or incetivate some of your students, t join our efforts.

That said, I have made a hak soemwher that uses Python plug-ins and 
parasites to be able to name certain layer groups and have some 
minimal funcitonality with that. I can mail you those f you are 
interested.

Regards,

js
--

-
http://www.libregraphicsmeeting.org/


 Thanks!

 jEsuSdA 8)

 Pdta: Excuse my poor english, i'm from spain. ;)


 ___
 Gimp-developer mailing list
 Gimp-developer@lists.XCF.Berkeley.EDU
 https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Gimp-developer] LGM/2007

2007-02-05 Thread Joao S. O. Bueno Calligaris
LGM 2007 is approaching, and we have to deal which GOIMP people will 
be attending.

There will be limited funding to sponsor the air fare costs, comming 
from GIMP  donations, and possibly a little from LGM funding.  

In order to knwo which people can be sponsred, we need first to know 
who wants sponsorship (and to a certain degree, how hard one wnats to 
go/needs the sponsorship to go/is involved with the project).

People who is attending can add their names at 
http://wiki.gimp.org/gimp/TellUsYoureComing . 

Anyone who will need the sponsorship or simply wnat to query about the 
possibility, should e-mail me as soons apossible, so it can be 
deliberated among the GIMP developers.

Regards,

js
--
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] LGM brochure

2007-02-05 Thread Joao S. O. Bueno Calligaris
On Monday 05 February 2007 19:20, cedric GEMY wrote:
 To make the LGM brochure that has to be distributed in canadian
 magazins, i'm looking for the best works made with Gimp. If anyone
 have some link or files, please send. We'll choose from those one.


I will have to ask you to look at the work of some people from here.

They've been making an electronic fanzine over hte last year, and 
there is some quite astonishing stuff inside. Ms to f it 100% GIMP.

Unfortunatelly, all the articles are in Portuguese only.


http://www.ogimp.com.br/modules/tinycontent/index.php?id=1 (The 
artwork is inside the PDFs - if you need to contact the authors for 
licensing/original art, please CC me - some of then are quite bad at 
even reading English)



 cedric
 ___
 Gimp-developer mailing list
 Gimp-developer@lists.XCF.Berkeley.EDU
 https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Enabling plugins to get the user to click a point on the image.

2007-01-18 Thread Joao S. O. Bueno Calligaris
On Thursday 18 January 2007 04:58, David Gowers wrote:
 Manuel pointed out, The gimp currently lacks any way for a plugin
 to get a coordinate from the image (eg. click on the 'seed' pixel).
 I've often wanted to do this, and it is a bit awkward without it.
 Has implementing this been avoided, or is it just an oversight?

 Some example usages:
   * Color mixer: click on any number of pixels then press ENTER to
 set FGcolor to a mix of all those colors.
   * Zone selector: click on a zone to select it
   * Word balloon creation (see a recent post on gimp-user) -- click
 a series of 5 points to draw a word balloon (size, point shape and
 location)


Hi David:

If you do not need it in real time, that is, if picking a point and 
only then caling a plug-in suits your needs, one can use paths.

I have a couple of python-fu scripts myself that pick coordinates from
the first, or first two nodes on the active path, and it is quite 
usefull.


js
--
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Libre Graphics Meeting

2007-01-16 Thread Joao S. O. Bueno Calligaris
On Tuesday 16 January 2007 06:49, Sven Neumann wrote:
 Any volunteer for coordinating the GIMP participation to the
 conference?

If no one of the more active developers wants to do that, I might pick 
it.

js
--
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Gimp 2.4 workflow break

2007-01-12 Thread Joao S. O. Bueno Calligaris
On Friday 12 January 2007 14:26, Bart wrote:
 Hi,

 I often recognize a little workflow break when working with Gimp.
 This happens when you click from the image window to tool window
 (like layers) and do some thing there and then try out a specific
 shortcut that works only on the image window.
 This image window shortcut didn't work when a tool window is
 focused, so you must first click back on the image window to
 focused that and then you can use the specific short cut for the
 image window. That isn't great at all i think.

 So what about if GIMP could recognized what was the last used image
 window and if you press a specific shortcut that woks only on the
 image window GIMP will call the command on the last used image
 window?

 Thanx so far doing GIMP! 2.4 is getting great!


 Karamba!
 Bart.


Hi Bart,

I feel that too...when I am in computers other than my own. At home, I 
set up the GUI as I feel i tshould be: focus follow mouse. That means 
that I have only to hover a  window for it to get in focus - no need 
to click.

I've heard that even windows can be set up to behave like thta. Give 
it a try.

js
--
 ___
 Gimp-developer mailing list
 Gimp-developer@lists.XCF.Berkeley.EDU
 https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] The GIMP

2006-12-07 Thread Joao S. O. Bueno Calligaris
On Thursday 07 December 2006 07:54 am, Michael Natterer wrote:
 On Wed, 2006-12-06 at 22:06 +0100, Sven Neumann wrote:
  Hi,
 
  I'd like to do the following change to the comment at the top of
  all source files in the GIMP tree:
 
  -/* The GIMP -- an image manipulation program
  +/* GNU Image Manipulation Program

 I agree that old line sounds stupid (an), but why remove GIMP
 entirely?

 What about:

 /* GIMP - The GNU Image Manipulation Program */

I'd also prefer this way!


 ciao,
 --mitch

 ___
 Gimp-developer mailing list
 Gimp-developer@lists.XCF.Berkeley.EDU
 https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Gimp-developer] Rich Text editing (sort of)

2006-10-13 Thread Joao S. O. Bueno Calligaris
Hi,

The demand for a way of combining various text colors and fonts,
along with other features in gimp text is high - even I myself need 
these features a lot.

So, several months ago I started a plug-in to work around the text 
tool and provide some of these features, like the Dynamic Text did in 
the old times.

I came back to it today, poured in some hacking time, and came up
with a first usefull, if little, version.

It can: 
create a text layer with varying font-family, sizes and colors. 
All left aligned.

Edit back such a layer.


The major drawback right now is that one has to select a portion of 
the text after it was typed in, and then select the font (family and 
size) and color to apply to that text.

There are quite a few other bugs - but I find it rather usefull 
already.

People interested, please, give a try:
http://pion.sytes.net:4080/pyrichtext.py

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Gimp python

2006-08-14 Thread Joao S. O. Bueno Calligaris
On Monday 14 August 2006 04:17 pm, Sven Neumann wrote:
 Hi,

 I have opened a bug report on what I believe to be the remaining
 issues with gimp-python:

 http://bugzilla.gnome.org/show_bug.cgi?id=351287

 Even though I said earlier that's it's perhaps too late for adding
 i18n support, I feel now that we absolutely need to do this if we
 want to install any Python plug-ins by default.

 But still, if i18n support is added, the usefulness of the plug-ins
 should be reviewed and only the plug-ins that are considered useful
 should be installed and have their strings marked for translation
 (and reviewed).


 Sven



Hi Sven - 
thank you for getting to this. 

I am rather busy these days, but I will dig into it as soon as I have 
some time to the GIMP. I that is too late to 2.4 - well, thats is 
life. 

And in fact, even very simple scripts can be more usefull than the 
ones that ship by default, and at once be so simple taht could 
encourage more people to give a try at editing then. 
(center layer, apply a filter varying its parameters in a sequence o 
vertical slices of an image, and so on).

Lets see what we all can come up with.

JS
--
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] panning

2006-07-06 Thread Joao S. O. Bueno Calligaris
On Thursday 06 July 2006 04:48 pm, Sven Neumann wrote:
 Hi,

 On Thu, 2006-07-06 at 11:27 -0700, John Waugh wrote:
  I got no real response to the below question on gimp-user, so I
  guess it's time to start editing the source (:
 
  I would like to either
  1)  add a new 'pan' tool, to which I could then assign a key
  -or-
  2) somehow remap the middle mouse button to a key. Or more
  accurately, have a key perform the same function as the middle
  mouse button, but hopefully not *lose* the middle-mouse
  functionality.
 
  Any opinions on which would be harder, or pointers how to
  accomplish either ?

 I would suggest that we finally implement it the way that has been
 suggested here multiple times. Let's get rid of the Push-Move-Tool
 feature that is currently bound to the Space key and use the Space
 key for panning.


Why not create a pan tool that could be pushed with any other key?
Why not just make it configurable, instead of getting rid of the 
current functionality?

I am a heavy user of the push-move feature, and I know of other 
people who are.

There are 105 keys on the keyboard - and both features are a good 
thing to have with push functionality.  I do not care if the move 
push is changed to any other key, and space be left to pan. But I 
care about loosing the current feature.


 Sven

JS
--
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] menu cluttage

2006-07-05 Thread Joao S. O. Bueno Calligaris
On Wednesday 05 July 2006 04:47 pm, Sven Neumann wrote:
 Hi,

 On Tue, 2006-07-04 at 01:11 -0400, Kevin Cozens wrote:
  Now that GIMP handles registration of the same menu item from
  different plug-ins, I am just waiting for the time a user reports
  a bug in Whirl and Pinch (for example) and doesn't realize which
  version they were using (as in the Python version or the C
  version).

 The Python version will of course not be in any stable release.

 And so far I don't see anyone complaining about my proposal to not
 install any Python scripts at all with GIMP 2.4.
Hey.
It is allright for me if you do not install then- but I had 
complained. - At least count that.

Actually we could think of then case by case. Almost all of then are 
just clones of other plugin/scripts, buyt, py-slice, for example, has 
only an equivalent in gimp-perl, and currently py-slice is far more 
capable.

Also, IRCC, some scripts dealing with palettes where implemented in 
python, using some I had done as basis. These also provide unique 
features.


JS
--


 Sven


 ___
 Gimp-developer mailing list
 Gimp-developer@lists.XCF.Berkeley.EDU
 https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] menu cluttage

2006-07-05 Thread Joao S. O. Bueno Calligaris
On Wednesday 05 July 2006 09:36 pm, Joao S. O. Bueno Calligaris wrote:
 On Wednesday 05 July 2006 04:47 pm, Sven Neumann wrote:
  Hi,
 
  On Tue, 2006-07-04 at 01:11 -0400, Kevin Cozens wrote:
   Now that GIMP handles registration of the same menu item from
   different plug-ins, I am just waiting for the time a user
   reports a bug in Whirl and Pinch (for example) and doesn't
   realize which version they were using (as in the Python version
   or the C version).
 
  The Python version will of course not be in any stable release.
 
  And so far I don't see anyone complaining about my proposal to
  not install any Python scripts at all with GIMP 2.4.

 Hey.
 It is allright for me if you do not install then- but I had
 complained. - At least count that.

Forgot to say this: not only had I complained, but I also offered to 
fix the issues with the python scripts  right away, and you just said 
it was too late. 


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Mask to selection

2006-06-27 Thread Joao S. O. Bueno Calligaris
On Tuesday 27 June 2006 10:41 pm, sampin wrote:
 Hallo,

 does there exist a mask to selection function that can be called
 from within a plug-in?
 Have I missed it in gimp api?


Hi sampin,

Use gimp-selection-load.
'masks' count as 'channels' for gimp-internals purposes.


 Thank you
 Ollie
 ___
 Gimp-developer mailing list
 Gimp-developer@lists.XCF.Berkeley.EDU
 https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Gimp-developer] Gimp python

2006-06-27 Thread Joao S. O. Bueno Calligaris

In bug #346001, Sven wrote:

Comment #3 from [EMAIL PROTECTED]   (GIMP developer, points: 23) 
 2006-06-27 13:47 UTC [reply]  
 If you ask me, Python-Fu must not install any plug-ins at all 
 as long as the user interface doesn't hold up to our standards. This 
 includes complete internationalization and localization.  I suggest
 that we disable installation of Python plug-ins for the 2.4
 release. 

(http://bugzilla.gnome.org/show_bug.cgi?id=346001)

I consider this both sad and grave. IMHO, the build of python-fu by 
default, and support for it under Redmond OS is one of the greatest 
things in this development cycle.

I will undertake i18n of the python-fu then, with no delays. What else 
do you consider important for the UI to have for it to keep up with 
gimp standards? 

Regards,

JS
--
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Gimp-developer] menu cluttage

2006-06-26 Thread Joao S. O. Bueno Calligaris
Hi,

I e mentioned once or two that when the script-fu and python-fu 
scripts where brought togetehr to teh same menu space as the C 
filters there would be confusion about which menu entry is associated 
with a script in which language.

I have been normally replied that it does not matter for the end 
user in which language the script is in.

Well...it _does_ matter.
The specif\c language matters little, but there are some side-effects. 
Knowing which package brought which filter is more still important 
(and also impossible in the current everything mixed system)

Now I just stumbled into an 'interesting' bug arising from this 
confusion:
Python-fu Whirl and Pinch had overwritten the menu entry for C Whirl 
and Pinch (moreover Python whirl and pinch is currently crashing)

Please notice there is no way a normal user can be aware of situations 
like this. Actually, it is almost as annoying (to say the least) as 
win95 and beyond feature of not showing the image file extensions 
in the file browsers.

But even win95 has different icons for different kinds of images. The 
GIMP currently has just no clue.

SO, I am bringing this subject to discussion once more, and asking 
about adding a small icon to menu entries, or some other indicator to 
tell users which entry came from where.

Regards,

JS
--
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Getting the GIMP to work well on a OLPC laptop

2006-06-06 Thread Joao S. O. Bueno Calligaris
On Tuesday 06 June 2006 12:25 pm, Dave Neary wrote:
 Hi,

 As the SoC administrators probably know, the OLPC project is
 entering a phase soon, where they will be making a very limited
 amount of laptops (no more than 1 per project requesting) to free
 software application developers.

 I thought maybe someone here might be interested in getting one,
 and would have the time to do profiling and memory work with a
 small screen laptop to reduce the footprint and increase the speed
 of the GIMP in that kind of environment. One other constraint, you
 don't have any (or much) hard disk - swapping times out is an
 expensive operation.

 Is anyone interested? If you don't have time to spend on this, the
 greater good is probably best served by letting another project
 have one, but it would be great to have a faster smaller GIMP.

 Cheers,
 Dave.
Let's put it in these terms: 
Pippin? 

can that stuff run a washed out GIMP or Horizon? What do you think 
about matching it against the 770? 

JS
--
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Gimp-python: Artefacts when creating layer

2006-06-04 Thread Joao S. O. Bueno Calligaris
On Sunday 04 June 2006 02:45 pm, Sven Neumann wrote:
 Hi,

 On Sat, 2006-06-03 at 11:58 -0300, Joao S. O. Bueno Calligaris 
wrote:
  For C plug-ins  that might be true. However, python plug-ins are
  not good in dealing directly with pixels - that is, for rendering
  things.

 There is no need to access pixels directly. We are not asking the C
 programmer to iterate over the pixels and clear them directly.
 Calling gimp-drawable-fill is sufficient, no matter what language
 binding is being used.

That was not what I meant anyway. The matter is: the only advantadge 
of not having a layer automatically cleared when it is created, is 
sparing somw cycles if you are generating the layers content. 

Generate the layers content from within thew python code is something 
that, although can be done, is so slow, that the time spent 
auto-clearing the table becomes negligible.

It may look as a single extra line of code for us.  For one trying 
with the scripts, it is one more secret to be found or overcame, 
that might not take negligible time. That is the motive for my 
suggestion.

JS
--



 Sven


 ___
 Gimp-developer mailing list
 Gimp-developer@lists.XCF.Berkeley.EDU
 https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Gimp-python: Artefacts when creating layer

2006-06-03 Thread Joao S. O. Bueno Calligaris
On Saturday 03 June 2006 09:53 am, Simon Budig wrote:
 Alan Horkan ([EMAIL PROTECTED]) wrote:
  On Sat, 3 Jun 2006, Simon Budig wrote:
   That sounds as if you don't clear the layer before you use it
   for the first time. Layers created from a Plugin are not
   initialized from the very beginning. They need to be cleared
   using e.g. gimp_drawable_fill.
 
  I remember getting caught out by this too.  Why is necessary to
  manually clear a new layer rather than have it done
  automatically?

 I have no strong opinions on that. I guess the reasoning behind
 this behaviour was a speed optimization: If a plugin later renders
 stuff to a new layer anyway it would be a waste of time to clear it
 automatically. If it doesn't it would just invoke
 gimp_drawable_fill. No harm done, except that you have to know
 about it.

 It might even matter for big images...



For C plug-ins  that might be true. However, python plug-ins are not 
good in dealing directly with pixels - that is, for rendering things.

I guess the python api for creating a layer could create an empty one 
with no problems.

Regards,
JS
--

 Bye,
  Simon
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Re: New microsoft image format

2006-06-03 Thread Joao S. O. Bueno Calligaris
On Saturday 03 June 2006 05:49 am, Juhana Sadeharju wrote:
 Now to the quoted text.
 In my software, I have already thought of using a license
 which forbids their use in Windows. I don't know the license
 details yet; perhaps GPL + restriction.

 The major point is that domestic computers are sold with Windows
 preinstalled. I have not seen a domestic computer sold both with
 Windows and Linux, or with Linux only. This is not entirely about
 what people want: the Windows typically is ripped-down version
 which comes with ripped-down, bannered versions of software. The
 system is barely usable as standalone (not usable if you ask my
 opinion).

Just to stand the point: here they are starting to sell computers with 
linux only on the low end market. It is a step forward, but smaller 
than it looks like. Salesperson thenselves offer to install pirated 
windows versions on these computers for a small fee, for example. 

On the other hand some of the vendors thenselves make such a crappy 
install of Linux that no one can handle using it.  Linux Magazine  
Brasil tested a low end machine by HP that came with 128MB RAM and 
1GB Swap space. The result: OpenOffice would take full 3 min. to 
start!

And now, leaving this subject and back on what the main thread become: 
I am just finishing a 4 month course on the GIMP for people wiht 
little knowledge on computers and little wealth. All of then run 
Windows , if they have PC's - and if the GIMP did not run on windows, 
they'd have to be using some other software athome instead of the 
gimp.

But, step by step we are getting there.

Regards,

JS
--
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Gimp-developer] New microsoft image format

2006-05-25 Thread Joao S. O. Bueno Calligaris
Just missing the deadline for a SoC sponsored plugin for it, 
microsoft released the specs for their new image file format here:


http://www.microsoft.com/whdc/xps/wmphoto.mspx

I di dnot download it, bu I read the agreement for ownlaoding it. One 
keep his soul and his mother in doing so. I mean- there is no nasty 
NDA, it seems possible to implement a free software  as fara s 
copyright issues stand, for reading and writing the beast - but the 
nDA says that software patents involving that owned by MS still 
apply.

They announce  a lot of miracles for this format, and it would be nice 
to be able to read and write to it if half of then hold true.

JS
--

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Suggestion: Make the 'New layer' command default to 'New layer with last values'

2006-05-17 Thread Joao S. O. Bueno Calligaris
inestead of that
hold shift
!
it has been dthe default through the 2.0 series, and it was not 
firendly to novies.
You just hold shift whenpressing the new layer button.

thank you for your interest, an dyou are welcome to more suggestions. 
But this one is not a  bug.


On Wednesday 17 May 2006 04:17 am, Martin Nordholts wrote:
 Hi Everyone!

 It's me, the Xtns - Extensions guy if you remember.

 I've been using GIMP over the last months to really get to know it,
 and I must admit that the workflow improves dramatically once you
 start to really get into the UI.

 I have however noticed one thing that I think could be improved.
 I've found myself using the 'New layer' command on the 'Layers'
 window quite often, and it is very rare that I want to change the
 properties of the layer. (The absolute most frequenty
 new-layer-command is 'create a new transparent layer the same size
 as the image').

 I propose a small change to the code. Since it is very few lines, I
 thought that creating a .diff file would be overkill, so I'll just
 write the changes here:

 In gimp-2.3.8/app/widgets/gimplayertreeview.c swap place of the new
 layer callbacks so it becomes this:

   item_view_class-new_action = layers-new-last-values;
   item_view_class-new_default_action  = layers-new;

 In gimp-2.3.8/app/actions/layers-actions.c, make
 layers_new_last_vals_cmd_callback() be invoked when
 controlshiftN is pressed (instead of
 layers_new_cmd_callback()).

 If you need this as a formal patch, let me know and I'll create
 one.

 IMO this improves the workflow futher.

 /Martin Nordholts

 _
 För dig som älskar spel http://www.msn.se/noje/spel/

 ___
 Gimp-developer mailing list
 Gimp-developer@lists.XCF.Berkeley.EDU
 https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Suggestion: Make the 'New layer' command defaultto 'New lay

2006-05-17 Thread Joao S. O. Bueno Calligaris
On Wednesday 17 May 2006 08:40 am, Martin Nordholts wrote:
 One other alternative be to provide a key-shortcut which would
 create a new layer with the previous properties,

which part of hold shift  in my e-mail was that hard to understand?
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Gimp certification

2006-05-13 Thread Joao S. O. Bueno Calligaris
On Friday 12 May 2006 02:30 pm, Olafur Arason wrote:
 I think Gimp should have something like Adobe Certified Expert.

Well... I don't.

 This would ensure that gimp trained individuals could show
 that they know Gimp like it's possible to test what you know
 about Photoshop.
 This test should be hard, but not it the memorize everything
 kind of hard, this would be to ensure that people that get
 this degree actually know something about Gimp.
 What would you think a person with this degree should
 know?
 Is anybody on this list willing to participate in this?
 Is certification such a bad idea that Gimp should
 associate it self with it?


IMHO it is.

 LPI is interested, but there is nothing definite

 Olafur Arason
 P.S Please don't say it takes to much time, making true color
 management work in Gimp also takes time but I don't see
 anybody say that we should not do it because of that.

I see it from this POV: what does the World gain with more bureaucracy 
in it?  If I need to contract someone to work on GIMP or another 
Image Manipulation program, I will sit him in front of a computer and 
watch him draw. 

Besides that, certifications are sometimes sought for those without 
the abilities or application to stand by themselves, either in their 
C.V. or personally.

I dislike the idea of a GIMP certification - and please note that I 
could make a lot of money out of it, as I certainly would be entitled 
to teach courses for, and concede such certifications in my country.


JS
--
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Time or velocity info [Re: SOC - brush system]

2006-05-09 Thread Joao S. O. Bueno Calligaris
On Monday 08 May 2006 10:51 pm, GSR - FR wrote:
 Hi,

 [EMAIL PROTECTED] (2006-05-09 at 0245.34 +0200):
  Actually the vector objects already store GimpCoords at the
  control points and hopefully the code already interpolates them
  properly. This is all totally untested though, since there is no
  real way to control the additional parameters (pressure, xtilt,
  ytilt, angle).

 That reminds me another parameter, velocity (or time delta, it is
 related) and that airbrush had issues with high speed... anybody
 knows the exact definition and use of gimp_paint_core_paint's
 guint32 time (I traced to
 http://developer.gimp.org/api/2.0/app/GimpPaintCore.html but says
 nothing)?


I tried to fiddle with it once (implementing speed as a way to select 
the frame of animated brushes), and got mostly lost myself. All I 
know is that the ink tool has a different implementation that does 
time smoothing  or something to interpolate the gtk+ event time.


 GSR

 ___
 Gimp-developer mailing list
 Gimp-developer@lists.XCF.Berkeley.EDU
 https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Re: Time or velocity info [Re: SOC - brush system]

2006-05-09 Thread Joao S. O. Bueno Calligaris
On Tuesday 09 May 2006 01:52 pm, GSR - FR wrote:
 Hi,

 [EMAIL PROTECTED] (2006-05-09 at 1654.44 +0100):
  Joao S. O. Bueno Calligaris wrote:
   On Monday 08 May 2006 10:51 pm, GSR - FR wrote:
   That reminds me another parameter, velocity (or time delta, it
   is related) and that airbrush had issues with high speed...
   anybody knows the exact definition and use of
   gimp_paint_core_paint's guint32 time (I traced to
   http://developer.gimp.org/api/2.0/app/GimpPaintCore.html but
   says nothing)?
  
   I tried to fiddle with it once (implementing speed as a way to
   select the frame of animated brushes), and got mostly lost
   myself. All I know is that the ink tool has a different
   implementation that does time smoothing  or something to
   interpolate the gtk+ event time.

 [...]

  I don't think that any other brushes at the time were velocity-
  sensitive (are they now?), hence the private implementation.

 Animated brushes can be saved with such config... but it does
 nothing as it is not implemented publicly, so I guess anybody that
 tries the setting just gives up and saves with any of the other
 options from the drop downs.


Hmm.it does now - the patcjh for it has been comited some months ago - 
but, it doe slittle- not very usefull without a callibration curve 
and a way to smooth down the time coordinates, just as the paint tool 
does.

 The other use case for using the time is the airbrush. I looked at
 it time ago and looked again due this thread, first idea was
 checking the remaining of airbrush timer, but there seems to be
 none (yet?). It is required as airbrush stamps every X time, but if
 you move faster, the effect of time is ignored, getting stronger
 stampings than what really should happen.

 So no, there is no current use of velocity, but just cos it is not
 implemented, and thus nobody thinks about possible uses. Sounds a
 bit recursive. ;]

Ok - there is a velocity setting on the animated brushes, so we broke 
the recursion...we just need a volunteer to factor out the ink tool 
use of it, and implement a velocity calibration curve for the 
strokes.
:-)


 GSR

 ___
 Gimp-developer mailing list
 Gimp-developer@lists.XCF.Berkeley.EDU
 https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] gimp with large files. test.

2006-05-01 Thread Joao S. O. Bueno Calligaris
On Monday 01 May 2006 11:37 am, Campbell Barton wrote:
 On the other hand, Photoshop may be working on a smaller copy of
 the image at 1:1,
 has this been considered by the gimp dev's?

it most certainly does, and then does the real curves work on the 
background.

Considered? Yes.
Made? No.

Nowadays it is sort of postponed until after 2.4 is released and GeGL 
starts to be integrated into the GIMP. I think one of the great 
bennefits of GeGL will be allowing doing this kind of live previews 
with transparent background processing - Although that will not come 
for free with the GeGL.

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Re: Project proposal: Resource contribution, distribution and management system

2006-04-17 Thread Joao S. O. Bueno Calligaris
On Monday 17 April 2006 04:58 pm, Michael Schumacher wrote:

 Bill Skaggs, who volunteered to be the organization administrator,
   ^^^
/me smiles evilly!

 has already written a draft of the application mail. We want Sven
 or Mitch to have a look at it before it is sent. There are also
 some other project proposals, which are supposed to be presented
 here this week.


 HTH,
 Michael
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Bring Back the Keyboard!

2006-02-15 Thread Joao S. O. Bueno Calligaris
On Wednesday 15 February 2006 10:42 am, Robert L Krawitz wrote:
From: Leon Brooks [EMAIL PROTECTED]
Date: Wed, 15 Feb 2006 18:28:22 +0800

On Wednesday 15 February 2006 16:18, Sven Neumann wrote:
 The user should never ever have to do this. We need to either
 move some of our resource files into a visible folder or we
 need to provide a user interface to manage resource files that
 doesn't involve using a file manager.

All of which sounds like _much_ more work (and many more design
decisions) than simply making the file selector work
 consistently.

 Not to mention that someone might want to edit files in a hidden
 directory for other reasons (e. g. thumbnail files stored in
 .thumbnails).

Actually, my problems begun in gedit - I was editing a python script, 
and certainly, for people on GNU/Linux for the first time, EMACS 
would not be a suitable option.

GIMPwise, Sven's suggestions are ok. I like more the idea of actually 
unhiding the gimp profile directory. Because a separate interface to 
save images that are to be saved as patterns or brushes, IMHO, would 
only break things even more. A bookmark to the gimp profile would 
also work.  Of the things accessible through other interfaces, I 
think there is little left to be done.


JS
--
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Bring Back the Keyboard!

2006-02-14 Thread Joao S. O. Bueno Calligaris
On Tuesday 14 February 2006 06:00 am, Sven Neumann wrote:
 Hi,

 Scott [EMAIL PROTECTED] writes:
  Haven't had time to extensively check out the newest version, and
  I'm sure it has a lot of nifty new features: BUT one think that
  irks me right away is not having any option to type in a filename
  on the 'open' dialogue!

 There is nothing that keeps you from typing a filename in the file
 open dialog.  Perhaps you should just give it a try one day. But,
 and I think this has already been pointed out, this is something
 that you should sort out with the GTK+ developers.


Unless, of course, the filename is in the ~/.gimp-2.x dir and you try 
to getthere by start typing .

I am serious about this: I _lost_ almost 20 minutes in a 3 hour 
workshop trying to get people to open files in ~/.gimp-2.x - and 
after that I still had to try to explain  why ctrl+l + .gimp-2.2 + 
enter  would work, and .gimp-2.2 + enter, although displaying 
something would do nothing. 
Most people windows users for the first time using a GNU/Linux 
desktop. I guess they won't come be coming back any soon now.

I think it is quite clear by now that this lack of a visible place to 
type a filename is damaging to both all of gnome, the Gimp, and in 
situations like the above, to the whole Free Software movement. The 
current transparent type hack simply does not work as it should - 
if it should at all.

Regards,
Joao


 Sven
 ___
 Gimp-developer mailing list
 Gimp-developer@lists.XCF.Berkeley.EDU
 https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Plugin brush tool

2006-01-27 Thread Joao S. O. Bueno Calligaris
On Friday 27 January 2006 04:38 am, Rob Krajcarski wrote:
 I spent most of today trying to accomplish this type of plugin
 within photoshop, only to find out that it was not possible...so,
 I'd rather not have to go through the same thing with Gimp
 tomorrow..

 In general what i'd like to accomplish is the following:

 -poll the position of the brush on the canvas, or even better would
 be to receive notifications as to the position of the brush as it
 moves -using this historical position to mathematically calculate a
 specific colour to use for the brush

 Ideally I'd like to be able to just change the foreground colour of
 the brush, but still preserve artists ability to use different
 brush heads, opacties, etc...

 So, just thought I'd be a bit more explicit in what I'm trying to
 accomplish before I jump into the code.

 Please let me know if there's reason to believe that I won't be
 able to accomplish this kind of plugin without making changes
 throughout the core codebase.

 Thanks

 Rob



Hi.
I've thoguht of similar things before, but I was turned down.
I'd still likle to have this ability, so maybe if you find no other 
way, you could came back here, and then we could try to attach 
something to the core.


The bug-report where I suggested and discussed such a feature is here:
http://bugzilla.gnome.org/show_bug.cgi?id=140165


Regards,
JS
--


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] python plugin

2006-01-16 Thread Joao S. O. Bueno Calligaris
On Monday 16 January 2006 12:10 pm, Emanuele Zattin wrote:
 Hello everybody,
 my name is Emanuele Zattin and i'm developing a plug-in
 implementing a texture synthesis algorithm described in a paper
 (Texture Synthesis by Non-parametric sampling by Efros and
 Leung).
 Here attached you can  see my actual implementation which works on
 grayscale images. It is anyway VERY slow, which was anyway
 predictable judging from the complexity of the algorithm.
 I was wondering if translating it to C would make it much faster or
 if there are some more speedup techniques i'm just missing.

 Thank you very much!!

 Emanuele Zattin

Hi Emanuele,

The default way for accessing pixels from python plug-ins is slow.
I started researching a faster way a while back, but halted. i think 
it is important.
I don't have teh time now to check if this is the problem in your 
cscrpit, but from my previous experience, it is rather likely. 

I will take a look at it later, and suggest another way to manipulate 
the pixels if possible (or if not possible, seeing what can be done 
on the gimp-python bindings themselves).

Either way, since you already use Numeric, going to C won't be 
necessary (unless I fail to do all of the above).


Regards,
JS
--
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Gimp-developer] Patterns

2005-12-28 Thread Joao S. O. Bueno Calligaris
I was looking at the patterns that come with the GIMP.

They might have been nice for  320x240 web images that everyone edited 
a few years ago.

But in a world of 7 MP cameras, all patterns that come with the GIMP 
are nearly useless.

there are a few pending features for patterns on the program itself - 
like categorization, possibly scaling, and so on.

That aside, these patterns are in urgent need for an update. Even if 
not on the patterns that come along with the GIMP itself, nice 
pattern collections would be nice - perhaps some that could be 
packaged in  a gimp-data-extras module, or something like that.

Even updates of the existing patterns so that they do no look a silly 
square repetition  when covering a surface more than 400px wide would 
be a nice thing.

So - developers, what do you think might be the best approach? To 
update the patterns that come with the program thenselves or make 
additional collections available? 

And everybody - let's start building some nice patterns - one way or 
the other we have to collect then all an make then available for all 
the GIMP users.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] P.S.

2005-12-11 Thread Joao S. O. Bueno Calligaris
On Sunday 11 December 2005 07:56 pm, Chris Share wrote:
 That would be very helpful for newbies like me.

 Cheers,

 Chris


Maybe you'd find it more easy to make the move once for all.

A GNU/Linux desktop is developer friendly, besides being user 
friendly.

There are a handfull of choices you could try not even having to 
perform a hard drive install (although you hardly could get to build 
GIMP one withtout installing things to hardware.

But it certainly will be much easier to build the GIMP and plug-ins in 
a freshly installed GNU/Linux than hunt for all dependencies and 
workarounds needed under windows.

You could try getting yourself a UBUNTU CD, for example (you can order 
then for free at shipit.ubuntu.org, but there would be faster ways 
for you to get then), or some other distribution that you could get a  
nearby friend to help you with. Most distributions are downloadable 
for free at all.

Sorry if this seems O.T. but I am really interested in heling you, and 
I do not think that holding back to windows is a good way to start.

JS
--
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Path tool and plug-ins?

2005-10-25 Thread Joao S. O. Bueno Calligaris
Indeed, the Paths itnernals and UI was completly revamped on GIMP 2.0, 
but the API never catched on.


There is no way to work properly with multple component paths with the 
current API, as you had found out.

I cannot give further advise at gthis moemnt, but to ask politely for 
you to take a look at the source. Tehre is a bug report dealing with 
this in GIMP's bugzilla, but there is nothing serious there.

Apart from that, we have to wait for Simon to step him, and give some 
hints (he redesigned the vector internals for 2.0). Either way, you 
will be better able to follow his suggestions if you had already 
taken a look at the source.

Regards!!

JS
--

On Tuesday 25 October 2005 02:32 pm, Matteo Quintiliani wrote:
 Dears all,
 I'm developing an open source plug-in capable of vectorise
 historical seismograms.
 http://registry.gimp.org/list?name=teseo
 http://sismos.ingv.it/teseo/

 Using function gimp_vectors_compat_get_points() with a path that
 have more than one component, I get the following message:
 Gimp-Vectors-WARNING **: gimp_vectors_compat_get_points(): convert
 failed

 I took a look in gimp-2.2.8/app/vectors/gimpvectors-compat.c line
 164 of 281, and I was very surprised reading:

 ===
 if (open_count = 2)
  {
g_warning (gimp_vectors_compat_get_points():
 convert failed);
*n_points = 0;
return NULL;
  }

 ===

 Has someone planned to extend this function?
 If not, could someone provide me further information to do this?
 I'll be very happy to help in gimp development.

 Sincerely,
 Matteo Quintiliani
 ___
 Gimp-developer mailing list
 Gimp-developer@lists.xcf.berkeley.edu
 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Question about the plug-in system.

2005-08-05 Thread Joao S. O. Bueno Calligaris
On a note to my previous idea of linking such a script  to Blender3D: 
If it is not possible for a script  to be both a GIMP plugina  a 
blender script, anyway, a Bldenr Python Script can comunicate with a 
GIMP plugin script via sockets or TCP with very little effort. The 
major nuisance I see in this aproach is taht AFAIK blender takes full 
screen for it, so I do not know you could keep a GIMP window open 
over Blender for painting.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Question about the plug-in system.

2005-08-04 Thread Joao S. O. Bueno Calligaris
On Thursday 04 August 2005 18:43, Axel Philipsenburg wrote:
 Hello folks!

 I've just now joined this mailing list, looking for some info from
 people who know the internals of the Gimp's plug-in system.

 The reason is, that I have a project in mind that I'd like to try
 to write as an Gimp plug-in, but I am not sure if it can be done.

 So before diving headlong into the source I though I'd rather ask
 if it's even doable. If so, then I'll start digging through docs
 and code. :)

 What I'd like to do is to write a plug-in that would make the Gimp
 a nice tool for 3D artists by showing a 3D object in a seperate
 window with the currently selected Gimp image as UV mapped texture.

 The 3D object would be loaded from a Wavefront OBJ file with all UV
 mapping coordinates and been displayed by using OpenGL.

 The only thing that gives me worries about this, is if the Gimp
 plug-in system would allow a seperate window to be constantly
 displayed and updated whenever a tool operation is finished so that
 the artist can practically see each brush stroke (or other tool
 usage) instantly on the 3D object once the tool has been used.

 If that is the case, then the only real work for the plug-in in
 would be to make a flattened copy of the currently edited image and
 send it as texture to the OpenGL part of the plug-in.

 Any comments on the idea or if this possible with using the Gimp's
 plug-in system?


Hi!

Offically it is not possible.

That is: there is no way for the GIMP to call back your plug-in 
whenever an action is performed.

However nothing but the extreme deselegance of it can stop your 
plug-in of pooling the GIMP for image data every few seconds.

So, I'd say it is feasible. It won't be perfect, but would be 
functional enough.

Are you writing the 3D part? 
Maybe it is even possible to use blender for it. I do not know exactly 
how Python works with Blender - but it may be possible to write a 
script that is _both_ a blender script and a GIMP plug-in and get 
this working with less than 200 lines of code.

JS
--
 Thanks a lot in advance.

 Bye Bye

 Axel
 ___
 Gimp-developer mailing list
 Gimp-developer@lists.xcf.berkeley.edu
 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] New Colors toplevel menu

2005-08-01 Thread Joao S. O. Bueno Calligaris
I am fine with Layers Colors and FIlters integration, if submenus are 
used in an efficeint way.

I am not so sure about Image-Modes , unless tehre is a ubmenu
Colors-Image to indicate taht thos ewill operate ont eh whole image 
instead of a drawable. But then, they could just stay were they are.

JS
--


On Monday 01 August 2005 02:20, Akkana Peck wrote:
 I've posted a patch to bug 116145 which would move all the color
 operations -- currently in Image/Mode, Layers/Colors, and
 Filters/Colors -- to a new top-level menu called Colors.
 (See the bug for the request and discussion of that.)

 If I don't hear any objections I'll commit it in a day or so.

 One issue is that it makes for an awfully long menu (see screenshot
 attached to the bug). Probably some of the items in it should be
 moved to a submenu -- e.g.  move everything that was previously in
 Filters-Colors to Colors-Filters? Please post any suggestions
 here or in the bug.

   ...Akkana
 ___
 Gimp-developer mailing list
 Gimp-developer@lists.xcf.berkeley.edu
 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] New Colors toplevel menu

2005-08-01 Thread Joao S. O. Bueno Calligaris
On Monday 01 August 2005 13:01, Akkana Peck wrote:
 Joao S. O. Bueno Calligaris writes:
  I am not so sure about Image-Modes , unless tehre is a ubmenu
  Colors-Image to indicate taht thos ewill operate ont eh whole
  image instead of a drawable. But then, they could just stay were
  they are.

 How about calling it Image Mode rather than just Mode?


That would be reasonable as far as I am concerned.


   ...Akkana
 ___
 Gimp-developer mailing list
 Gimp-developer@lists.xcf.berkeley.edu
 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Snap To Canvas

2005-07-12 Thread Joao S. O. Bueno Calligaris
On Tuesday 12 July 2005 08:16, Michael Natterer wrote:
 On Mon, 2005-07-11 at 22:59 -0500, Tim E. Jedlicka - wrk wrote:
  I'm running gimp-2.3.2. Thank you for the snap to canvas edge
  option. I would suggest that it should default to on/checked.
  Snap to Guides is defaulted to on, the canvas edge should be
  considered a default guide (in fact, that is how I would
  implement the feature, have images open with the edge being the
  default guides - but since I'm not a coder I'm just thankful for
  the feature regardless how implemented).
 
  If a user does not want the snap to's defaulted to on, they can
  change the snap pixels to 0 (or 1?) in preferences and accomplish
  the equivalent behavior.

 Hi,

 you have a point here. IMHO we should change this to snap by
 default. Would you file a bug about this so it's not forgotten?

EEEKkkk!

Beware there: 
while snapping layers to the canvas on by default would be good, the 
option also snaps paint strokes!!

That is _not_ good to be on by default - one goes carefully painting 
with the paintbrush, and suddenly it is sucked to the edge, out of 
nowhere!!




 (go to http://bugs.gimp.org/)

 thanks,
 --mitch

 ___
 Gimp-developer mailing list
 Gimp-developer@lists.xcf.berkeley.edu
 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] pygimp on windows? success!

2005-06-26 Thread Joao S. O. Bueno Calligaris
On Sunday 26 June 2005 11:19, Michael Schumacher wrote:
 lode leroy wrote:
  Ah, now it starts up, and the Python-fu is there... yippee!

 It should do so now out of the box, at least in current CVS...
 maybe except for the interp file, but we should be able to fix this
 today.


Horraayy!!!  :-)

(...)
 Thanks again for your input!

 If you want to continue to work on scripting, and get even more
 scripting languages to GIMP on the windows plattform, there is
 gimp-perl, some java classes, a ruby binding and iirc even
 something for Tcl... :)

And there was the guy asking for a Lua interpreter, and I rememeber 
someone was working on GIMP-C# 




 Michael
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Layer locking proposal

2005-06-26 Thread Joao S. O. Bueno Calligaris
On Sunday 26 June 2005 13:48, Sven Neumann wrote:
 Hi,

 Well, it is up to the user to name the layers and I don't think we
 should make it harder to use long names. In general it is better to
 allow list views to scroll horizontally instead of trying to
 shorten the content to make it fit into the dialog.

 If we want to have all the lock types that PS offers, we would have
 to add three new toggles to the layer row. Is that feasible?

kkk...
I thought of three  different  states for the lock Icon (and a nice 
tooltip, of course).

JS
--





 Sven
 ___
 Gimp-developer mailing list
 Gimp-developer@lists.xcf.berkeley.edu
 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Layer locking proposal

2005-06-26 Thread Joao S. O. Bueno Calligaris
On Sunday 26 June 2005 17:48, Sven Neumann wrote:
 Hi,

 Joao S. O. Bueno Calligaris [EMAIL PROTECTED] writes:
  If we want to have all the lock types that PS offers, we would
  have to add three new toggles to the layer row. Is that
  feasible?
 
  kkk...
  I thought of three  different  states for the lock Icon (and a
  nice tooltip, of course).

 Three lock types make up for 2^3 states. Not sure if all of them
 are useful but it could become difficult to display all useful
 states in a single icon.

Oh well, as Homer Simpson would say:
DOH!

:-)


What about a drop-down menu there?
The icon would display an open lock - or nothing at all. When clicked, 
a drop down contest menu with check itens for each locking option 
would appear. If any of the locking options would be picked, the icon 
would ebcome a locked bolt. Clicking on it, would make the drop-down 
menu to show up revealing the state of the layer.

This UI could even be used to the linked state as well, therefore 
resoving the space problem.

I do not have the time to elaborate a mock up on this, so I will 
explain the idea again, with a different wording:

On left-clicking on the layer-tree, where the current linked icon 
for each layer is placed, a drop-down menu would be displayed.
This menu would contain 4 itens which could each be checked or 
unchecked:

Transparency Lock
Color Lock
Geometry Lock
Linked  

-
If either of these get checked, an apropriate icon (which could be 
always the same) would  displayed in that place.
--
IMHO, the idea of other specific contest menus on the layers tree may 
be needed anyway when layer grouping is included - There will simply 
be more options than the current UI can deal with.





 Sven
 ___
 Gimp-developer mailing list
 Gimp-developer@lists.xcf.berkeley.edu
 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Patterns tab

2005-06-24 Thread Joao S. O. Bueno Calligaris
On Friday 24 June 2005 10:02, nuno alexandre wrote:
 Hi,
 I got a request, I hope that request are welcome in this list.
 I'd like to have the possibility to organize the patterns tab into
 classes.
 for example:
 patterns -
  clouds
  grain
  metals
  etc..etc..

 Maybe this is possible, and I'm not aware of it?


Sven sent a detailed plan to do this as soon as 2.2 was released. 
Unfortunattely, as far as I know no one is implementing that. (The 
palane including making categories for both Patterns, Palettes, 
Brushes, Gradients and Fonts).

Maybe we should at least paste that e-mail into an enhancement request 
in bugzilla so it is not lost? Does anyone have it around?

JS
--

 Thanks,

   nuno
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] About Preferences enrtry in the Edit menu

2005-06-23 Thread Joao S. O. Bueno Calligaris
It just feels great.

I t always took me sometime when pointing someone to Preferences to go 
to Toolbox-FIles-Preferences and not Image-File...

Thanx Sven!

___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] About Preferences enrtry in the Edit menu

2005-06-23 Thread Joao S. O. Bueno Calligaris
On Thursday 23 June 2005 17:22, Michael Schumacher wrote:
 Joao S. O. Bueno Calligaris wrote:
  It just feels great.
 
  I t always took me sometime when pointing someone to Preferences
  to go to Toolbox-FIles-Preferences and not
  Image-File...

 Well, unfortunately this seems to lead back to the Why the heck do
 I have to open an image to access $feature? times... and I thought
 these were finally gone.

Why so? The Preferences entry is still in the toolbox-File menu.

One other possible rearangement would be drop the dialogs and 
prefences entries into Xtns and rename that to Extras once for 
all.



 Michael
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-22 Thread Joao S. O. Bueno Calligaris
On Tuesday 21 June 2005 20:30, Sven Neumann wrote:

 If you just add an entry to the current dialog you don't get the
 current dialog with the extra benefit of an entry with Tab
 completion. Unfortunately what you get is a dialog that has two
 orthogonal ways of navigating it with the keyboard and both ways
 keep getting into the way of each other.


Ok - What about this: Hitting the easy and intuitive CTRL + L, 
instead of cluttering everything else with a pop-up, make such an 
entry field to appear, with focus in it?

Therefore, nothing else would be on the way of one who can spend about 
a minute or two navigating the file structure and clicking on a file, 
while thos eint he know cna hit ctrl+L for soemthing actually 
usefull. 

Joao
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Gimp Marbled Paper Bounty?

2005-06-15 Thread Joao S. O. Bueno Calligaris
Hi!

Please check if http://hopey.nervo.org/~gwidion/marble_1.png is close 
to what you want.

And tell me whether you have pygimp (Shows up as a Python-fu menu 
option) installed.

Regards,
JS
--

On Wednesday 15 June 2005 17:23, Giles wrote:
 Hello.

 As I alluded in a previous message, there's a reason I'm lurking
 about on the gimp-developer list and it isn't that I'm a gimp
 developer.  I've used Linux since 1994, and the GIMP for ...
 several years.  Not sure how long.

 In 2003 I went to Venice and fell in love with marbled papers.  I
 would really like to be able to recreate those papers with the
 Gimp, preferably with wrap so they would tile.  There are some
 parts of the process that you can pull off with the Gimp as it is
 now, and some you can't.

 The best book I've found on the process is this one:

   Marbling Paper and Fabric by Carol Taylor, 1990.  Sterling, New
 York.

 Unfortunately I haven't found a good photographic record of the
 process of creating marbled paper online.  There are plenty of
 other books though. You can see examples of marbled paper at
 http://www.gilesorr.com/Venice/marbled/ - these are scans of part
 of each of the papers I brought back with me.  You could also take
 a look at what I consider two of my more successful Gimp attempts:

   http://www.gilesorr.com/images/200305/VenetianMarble05.html
   http://www.gilesorr.com/images/200305/SlideUpwards02.html

 Or just look at that whole lot,
 http://www.gilesorr.com/images/200305/ to see a bunch of my Gimp
 tiles and a lot of not-so-good marbled paper attempts.

 The parts of the process that would need to be recreated in Gimp
 plugins follow:

 - adding paint - essentially localized spraying/spotting (different
 size of dots, not perfect circles, random scatter)
   - some way to vary brush size (ie amount of paint, size of dots)
   - needs wrap
   - since it's paint on size (a form of paste on top of the water),
 it needs to _push_ other dots rather than just overlaying them
 - combing (or single stylus)
   - I would like wrap, stroke path, and by hand
   - specialized combs - boquet comb in particular, two rows of
 alternating teeth
   - again, the way it pulls the paint should mimic the physical
 world - shaking the tray
 - blowing on it as with suminagashi (http://www.suminagashi.com/ -
 this process isn't a priority for me)

 I've been planning to offer a bounty for this, but my $50 is
 sounding fairly small compared to the recently posted Gnome
 bounties.  I assume the Gnome bounty code is released GPL, and
 that's what I'd expect here.

 So, questions: is anyone interested in working on this?  Should I
 separate the parts and offer bounties (they'd have to be smaller)
 on each of the individual parts?  How could all of this be handled?
  Is there somewhere else I should post a request like this?

 --
 Giles   [EMAIL PROTECTED]
 http://www.gilesorr.com/
 --

 ___
 Gimp-developer mailing list
 Gimp-developer@lists.xcf.berkeley.edu
 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] New alignment tool

2005-06-12 Thread Joao S. O. Bueno Calligaris
Hi,

I had played with the alignent toll a while, and here is my feedback:
 
- It really feels like going together with  the move tool. 
When selecting a target layer, one just  tries to drag it - no help 
doing it otherwise.


- Once a reference layer  is set, if moving the target layer is 
possible, it feels natural that it should snap to the reference layer 
- thus allowing aligning the left edge of the target layer with the 
right edge of the reference layer, and further snap so that both 
tops, or both bottons are in the same coordinates. That would feel 
great, and there is no need for further UI elements.

Regards,

JS
--
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: Akanna Menu patch [was Re: [Gimp-developer] The GUADEC meeting]

2005-06-07 Thread Joao S. O. Bueno Calligaris
On Tuesday 07 June 2005 09:53, Alan Horkan wrote:

 I was thinking fo doing something similar for the python plugins
 (and making sure to add ellipses where needed).  However some of
 the python plugins duplicate existing functionality so putting two
 Clothify plugins beside each other would only confuse users.  I see
 Akkanna tackled this by marking the Script-Fu unsharp as Unsharp
 2 but if people have idea on how to tackle this duplication of
 functionality I would be interested to hear it. (I must say when it
 comes to learning to port scripts to python I found it very helpful
 to have similar examples written in a different language) plugin
 written .  One possible way to disambiguate similar plugins might
 be to give them different menu icons but expect you can probably
 come up with something better than that.



I always saidthat tehere should be some way to identificate a menu 
entry. Not only there will be up to four (C, script-fu, Python-fu, 
tiny-fu) equivalent entries on a row, as you point out - but I think 
one has the right to know how each menu entry got there. 

Today it already happens with stuff like 'filter all layers', 
installed with Gimp-GAP - one can't know where it came from.

People suggested that an icon before menu entries would cause to much 
hassle to the UI - and I agree. I suggested them that right-clicking 
on a menu item would bring some information about it. (Like:  the 
package where it came from, what language it is written in, and maybe 
even accept a new shortcut for that item, without having to enable 
dynamic shortcuts)

Regards,

JS
--


 Sincerely

 Alan Horkan
 http://advogato.org/person/AlanHorkan/

 ___
 Gimp-developer mailing list
 Gimp-developer@lists.xcf.berkeley.edu
 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Apply palette to image colormap

2005-06-01 Thread Joao S. O. Bueno Calligaris
On Wednesday 01 June 2005 00:03, Kevin Cozens wrote:
 Joao S. O. Bueno Calligaris wrote:
 It seems this fucntionality exists in other programs but not in
  the GIMP - i.e.: the ability to apply a palette to an already
  indexed image, keeping the color numbers.
 
 This is easily doable in script, but it could also be done in the
  core

 One of the scripts in Tiny-Fu is called tiny-fu-set-cmap.sct and
 provides the functionality you are talking about. I think it is a
 feature useful enough that it should be included as part of the
 core. It would also run a lot faster than my scripted version.

Ah..thre it is. 
Anyway - the person needing this right now is on win32 -  Will this 
script work in script-fu?

And... it is buggy.  It failed me when applying 256 color palette to a 
256 colro image with the message:
---
Error while executing
(tiny-fu-set-cmap 6 12 Gold)

Error: car: argument 1 must be: pair
--
Not to mention:

WARNING: Plug-In tiny-fu
(/usr/local/lib/gimp/2.0/plug-ins/tiny-fu)
called deprecated procedure 'gimp_image_set_cmap'.
It should call 'gimp_image_set_colormap' instead!

(ooopss... I remember being the one who asked that this particular 
procedure got renamed before 2.2 )
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] 48 Bit Tiff for the Gimp

2005-05-31 Thread Joao S. O. Bueno Calligaris
On Tuesday 31 May 2005 08:00, Sven Neumann wrote:
 Hi,


 You already got in touch with the relevant party. Adding support
 for higher color depths to GIMP is on the roadmap and will be
 addressed as soon as GIMP 2.4 is done. The plan is to use GEGL
 (http://gegl.org/). Part of it has already been written but this
 work had been abandoned for a while. Incidentally we only yesterday
 decided to pick up work on this library again. Mitch, Pippin and me
 will be reviewing and cleaning up the code over the next days. If
 you want to help, we can certainly need help in this area. At the
 moment I can not really tell you exactly what needs to be done but
 I should be able to tell you in a couple of days.

HOORAAY!!!

That is __great__ news!

I f possible I ask that you three post any progresses, and most 
importantly, specific small tasks that could be done by others, on 
the GEGL-devel list.


Regards,

JS
--




 Sven
 ___
 Gimp-developer mailing list
 Gimp-developer@lists.xcf.berkeley.edu
 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] Apply palette to image colormap

2005-05-31 Thread Joao S. O. Bueno Calligaris
Hi,

It seems this fucntionality exists in other programs but not in the 
GIMP - i.e.: the ability to apply a palette to an already indexed 
image, keeping the color numbers.

This is easily doable in script, but it could also be done in the core 
(and them DND palettes from the palette to the color map dialog, or 
to the image window could be made to work).

Which solution do you think would be better?

Regards,
Joo
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] use of the Space key

2005-05-23 Thread Joao S. O. Bueno Calligaris
Hi, 
I find the current use of the space key just great.
If other image manipul;ation programs fail to do that, that is a lack 
of functionality on those programs - I see no reason to downgrade 
the GIMP just to get the look and feel of other programs. The panning 
funcionality on the botton right corner of the image windows works 
allright for me - maybe there could be a way to let that more 
visible.

OTOH, what about making it configurable? Is it feasible?

Regards,
joao
--

On Saturday 21 May 2005 12:00, Sven Neumann wrote:
 Hi,

 I consider to change what GIMP uses the Space key for and would
 like to get some user feedback on this. Currently, pressing the
 Space key temporarily switches to the move tool. This is sometimes
 convenient but I am not sure if it is all that useful.

 Another image manipulation program, which GIMP is frequently being
 compared to, uses the Space key to offer the functionality that
 GIMP has bound to the middle mouse button: panning the image
 display. Since not everyone has a middle mouse button (especially
 on tablet pens), it might be a good idea to follow that example. If
 we did that, pressing Space would keep the current tool but the
 cursor would change to a hand symbol and one could drag the image
 display (not the content!) using the mouse.

 Any opinions on that, anyone?


 Sven
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] use of the Space key

2005-05-23 Thread Joao S. O. Bueno Calligaris
On Monday 23 May 2005 20:08, Sven Neumann wrote:
 Hi,

 Laxminarayan Kamath [EMAIL PROTECTED] writes:
  An entire new idea of keystrokes : for the keyboard shortcuts: if
  you press a key the normal way ,it will select the tool
  indefinetely alright. But if the key is pressed and held, and i
  do something, and then release the key, the tool reverts back to
  the one last used.

 Sounds interesting. Probably worth trying. Anyone?

I like the idea.
I had never looked at this part of the code. I believe that with Gimp 
contexts it is possible to push any tool with the current code 
already?

JS
--



 Sven
 ___
 Gimp-developer mailing list
 Gimp-developer@lists.xcf.berkeley.edu
 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Macro recorder?

2005-05-21 Thread Joao S. O. Bueno Calligaris
On Thursday 19 May 2005 03:51, Jan Olof wrote:
 Hello! I wonder if the macro recorder will be implemented soon in
 Gimp? I guess that it would be good if it generates Scheme script
 code.

 It would be very great if there was possible to use a macro on
 every picture in the GAP image range.

 Could I contribute in some way? I'm a college educated software
 engineer.

So...

I think this subject could raise back on this list.

The last time it was discussed, we had some dependencies on the Undo 
System for this to be implemented the Right Way (tm).

How is that doing today?

JS
--
 // Best Regards Jan-Olof Jansson

 ___
 Gimp-developer mailing list
 Gimp-developer@lists.xcf.berkeley.edu
 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] help required

2005-05-02 Thread Joao S. O. Bueno Calligaris
On Monday 02 May 2005 15:07, Michael Schumacher wrote:
 Rajesh T.S wrote:
  Hi all,
   I am very newly introduced to GIMP. now i need to do 2D image
  rotation and needs to read pixel values at some specified
  coordinates. can anyone guide me in this aspect by pointing to me
  any simple example codes  written using GIMP libraries ...

 First advice:

 Configure your mailer to not send HTML and to not attach vcf files.


And after the first advice, to answer your question:


If all you need is what you describe,m you are in agood position to 
use the GIMP - Python bindings. You will be at a disvantadge if you 
are in a non-posix OS, though, as GIMP-Python bindings do not build 
on this peculiar platform.

Just install/compile gimp-python, check the example scripts 
(sphre.py). If you need to learn python, 20 or 30 minutes at 
www.gimp.org, pick the links to the tutorial, will do.

And them, just check what functions you need from the GIMP's PDB 
(XTNS-PDB browser) , like the gimp_drawable_get_pixel  function.

It is not really hard.

You can also do similar in scheme and C languages, if you prefer,or 
even perl.

Regards,

JS
--






 HTH,
 Michael
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Alpha compositing

2005-04-13 Thread Joao S. O. Bueno Calligaris
On Tuesday 12 April 2005 13:06, JS wrote:
 Hi,

 I'm trying to locate the alpha compositions code in Gimp and
 cannot find it. I've found C/MMX/Altivec versions of many
 image-image composition operations but they don't seem to use the
 alpha channel at all.

 For example, I wonder wether the overlay composition
 corresponds to the Porter-Duff over operand. I've seen that some
 of the Porter-Duff operations are now part of GGGL
 (http://pippin.gimp.org/gggl/). I'm a little lost in all this. So I
 guess my questions are:

 1) Does Gimp implement the 12 Porter-Duff operations
 (http://www.w3.org/TR/2002/WD-SVG11-20020215/masking.html)? If so,
 I guess they must have different names.
 2) Where are the specifications for the compositing functions found
 in Gimp (like blend, screen, overlay, etc)? None of these functions
 seem to make use of the alpha channel, but is there still a link I
 do not see with the Porter-Duff ops?
 3) Where is Gimp heading wrt composition ops? Is GGGL the new
 standard?

 Thanks,
Hi! The
app/paint-funcs/paint-funcs-generic.h. file Bill pointed too is not 
used anymore - it is there in case someone builds the GIMP disabling 
aceleration with an option I forgot which is.

For the composting functions, take a look in the app/composite 
directory, in the gimp-composite-generic.c file.
Some of the functions are acelerated for MMX or SSE in the 
corresponding files, others are not.

As for your question  (reading about Porter Duff) wow...
comparing 12 kindso oif operations is a lot - but AFAIK the 
compositing models on the GIMP were not created thinking on these 
specific Ops. Some may be the same, others certainly are not.
http://bugzilla.gnome.org/show

2) There is not a proper Spec. This area of the current Docuemtnation 
is finding lacking, and there is even a bug openned against the docs. 
A better description can be found on the older groking the GIMP 
book for some of the modes. Currently, teh best way to know what 
eachmode does, if the explanation in the above sources does nto 
suffice, is checking the code in the above file.

3) No. GEGL is not in use yet. As I told, the funciotns are in the 
app/composite directory.


4) Please, take a look at 
http://bugzilla.gnome.org/show_bug.cgi?id=161449
for a way  to check a cheap way of implementing these new combination 
modes in a way that would not cluter the GIMP ui. If there is people 
wanting it working (custom layer modes) , I could go backk to work on 
it, even making it available to the GIMP if GEGL use is further 
stalled.

5) Nice name this of yours!

Regards,
JS
--
João Sebastião de Oliveira Bueno Calligaris
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Alpha compositing

2005-04-13 Thread Joao S. O. Bueno Calligaris
On Wednesday 13 April 2005 21:12, Joao S. O. Bueno Calligaris wrote:
 On Tuesday 12 April 2005 13:06, JS wrote:


Let's see how far I can MAP these SVG comp. modes to GIMPs:

1) clear:  Not available as a composite mode. One might just turn the 
layers visibility off.

2) src:No mode.  Turn off the visibility of the dst layer. 
3) dst: No mode.  Turn off the visibility of the src layer. 
4) src_over: mode behind
5) dst_over: mode normal
6) src_in: no equivalent mode. There would be needed another (custom) 
mode mode that would multiply or lighten only the alpha  component, 
and ignored the dst color.
7) drc_in: no equivalent mode. There would be needed another  mode 
that would multiply or lighten only the alpha  component, and 
ignored the src color.
8) src_out: no equivalent mode. There would be needed another mode 
that would multiply or lighten only srca by the complement of dsta, 
and ignored the dst color.
9) dst_out: no equivalent mode. There would be needed another mode 
that would multiply or lighten only srca by the complement of dsta, 
and ignored the dst color.
10) src_atop: no equivalent mode. There would be needed another mode 
that would be like the current behind mode, but use dsta instead of 
srca
11) drt_atop: no equivalent mode. There would be needed another mode 
that would be like the current normal mode, but use srca to replace 
dsta. 
12) src_atop: no equivalent mode. A XOR_alpha mode would be needed to 
emulate this.


Apart of the nice code I pointed in the other e-mail, I have a current 
python script is flexible enough to easily do these compositions. As  
a plug-in, however, it doesn't operate in real time: you have to draw 
you layers, and call the plug-in to generate a resulting layer from 
the operation.

If you are interested I can have it dealing with these 12 modes in a 
little more than an hour.

JS
--
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Version 0.9.8 of Tiny-Fu is available, and feature/string freeze.

2005-03-27 Thread Joao S. O. Bueno Calligaris
It ocurred to me that most GIMP translations are done by people 
working on the Gnome translation teams.

These teams intensify their work (ok, at least pt_BR team), on the 
verge of stable gnome releases. 

Since GIMP packages are released in a different schedulle, I guess 
that this string freeze message should be forwarded to a global 
gnome-l10n mailing list, or many languages will only update tiny-fu 
when gnome 2.12 gets close.

Regards,
JS
--

On Sunday 27 March 2005 16:54, Kevin Cozens wrote:
 Greetings, all.

 A tarball of version 0.9.8 of Tiny-Fu is now available at:
 http://www.interlog.com/~kcozens/software/gimp/tiny-fu.html

 It was barely a week between the release of the 0.9.7 and 0.9.8
 versions. The main work for this new release was started before
 0.9.7 was made available. The 0.9.7 version provided a stable base
 of code from which to work prior to the big changes that were about
 to be introduced to the Scheme interpreter.

 This latest version includes one useful bug fix and one important
 new feature. The bug fix allows Tiny-Fu to be used with GIMP in
 batch mode. The important new feature is support for UTF-8 coded
 strings. This allows the creation and use of scripts which need to
 manipulate strings written in non-English languages. You can see an
 example of what is now possible on the main web site for Tiny-Fu.

 It has been almost exactly one year since Tiny-Fu successfully run
 its first script. The 0.9.8 version also marks another important
 milestone in the life of this plug-in. This version is a release
 candidate for a 1.0 version. As a result, the plug-in is now in
 feature and string freeze. No new features will be added or strings
 changed until after the release of a 1.0 version.

 The one set of changes I will accept are any updates to the
 translation files which are very out-of-date with the exception of
 en_CA, en_GB, and pt_BR.

 Prior to the release of 1.0, I will be running some additional
 tests and would appreciate any reports of problems I may have
 missed. I will also be starting to make the changes needed to allow
 Tiny-Fu to be used with the current CVS versions of GIMP. Any
 submissions related to new features will be held until after 1.0 is
 released or will be incorporated in to the version for use with CVS
 GIMP.


 Changes since the 0.9.7 release:

 - Added UTF-8 support to the TinyScheme interpreter.

 - Changes to allow use of Tiny-Fu with batch mode. Fixes bug
 #167964.

 ___
 Gimp-developer mailing list
 Gimp-developer@lists.xcf.berkeley.edu
 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Colorizing Images and Video by Scribbling

2005-03-15 Thread Joao S. O. Bueno Calligaris
On Tuesday 15 March 2005 18:03, Pepster wrote:
 Their page says
 Our method is based on a simple premise: neighboring pixels in
 space-time that have similar intensities should have similar
 colors

 I assume this to mean you need the timing information of the
 stroke, similar to data needed for recognizing handwriting.

 While I am not sure of the GTK low-level API for such a capture,
 a plugin using such low level functions would have to re-implement
 the non trivial functionality of drawing the stroke (colors, brush,
 what-have-you ...), which is pointless.


Nope.
The time part of the space time proximity applies to animations 
(and movies, of course). For stativc drawings , it is all about 
spatial proximity.


 I was asking if any of you see a better way to implement such a
 method in the gimp.

 Hope I made myself clear this time.

 -Joseph

 Sven Neumann wrote:
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] Free Guids

2005-03-06 Thread Joao S. O. Bueno Calligaris
Hi,

I was thinking...
One of the great things of drawing with rulers and squares is the 
ability of drawing paralell lines at any angles.

Currently, this cannot be easily be done with thew GIMP. Actually, 
even drawing a line at a given angle is rather difficult.

And then one see those GIMP_ORIENTATION_UNKNOWN as a possible option 
for guides. What if these were implemented? Guides that could stand 
at any given angles, instead of just horizonatal and vertical?

Please, I'd like to hear comments on the feature, not on 
implementation issues.

Regards,

JS
--
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Adaptive Contrast Enhancement

2005-03-02 Thread Joao S. O. Bueno Calligaris
On Wednesday 02 March 2005 09:30, Sven Neumann wrote:
 Hi,

 [EMAIL PROTECTED] writes:
 Shlomi Fish and I independently ported the ACE plugin to GIMP
  2.0/2.2. Now both codes are reunited again. I think it works very
  well now. Shlomi removed a lot of bugs I was not able to correct.
  It would be great if it could be added to GIMP-2.2 itself now.
  Anyone against this idea?

 No new features in a stable version, so there's no way this plug-in
 is going to be added to GIMP 2.2.


I am pretty sure he meant adding it to CVS,a nd have it in the next 
stable release.


 Sven
 ___
 Gimp-developer mailing list
 Gimp-developer@lists.xcf.berkeley.edu
 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Re: Re: optional scaling in the save dialog?

2005-02-20 Thread Joao S. O. Bueno Calligaris


That is great.

I did not know that the GIMP could reuse tiles from one image to 
another. Actually, I didi not tought this was done even from a layer 
to another - that explains why adding new layers to large images goes 
so smoothly.

I am more than happy.

How does this memory usega behave when one apply a transform (scale 
down in this case), ont he image, or on a copy of it?

Because Mateusz wrote me that the disabling undo improved the 
performance of the operation. 

Maybe it is just the beneffits f not having  X allocated anymore, 
and therefore no more swaps after the scale down.

Regards,

JS
--


On Sunday 20 February 2005 11:43, GSR - FR wrote:

 I assume there is Copy On Write, thus delaying real memory usage
 (and the bandwidth too) until the data changes. Lets see COW at
 work:
(...)
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Re: optional scaling in the save dialog?

2005-02-19 Thread Joao S. O. Bueno Calligaris
On Saturday 19 February 2005 16:06, GSR - FR wrote:
 Hi,

 [EMAIL PROTECTED] (2005-02-18 at 2053.55 -0200):
I am currently working on a poster, and it's huge (from the
point of view of the amount of memory I have ;) ). Once in a
while I have to post it to the mailing list for my people to
see if they like it and tell me what to change. Every time I
want to mail it I first have to save it (.xcf), then scale it
down, save as jpg then undo the scaling or just close and
load again. So I thought it would be great if there was an
option in the save dialog to choose the size you want to save
the image in. It could be hidden in the Advanced Options or
something so that usually it wouldn't bother you.
 
  Try disabling script-fu previously to scale,
  then save as copy, and reload your image.

 I would go with duplicate image, scale the clone, save then close.
 No undo problems that way, xcf version stays untouched, both disk
 and memory.

Let X bre a Huge Amount of Memory (tm) taken by said image, and Y be A 
Couple Kilobytes (tm) used by scaled down version
Your proccess: 
- Initially using X memory
duplicate image - now using x * 2 memory.
scale image down, with UNDO active - using x * 2 + Y memory 
discard copy- back to using X memory.

My proccess:
- Inittially using X memory
- Disable Undo for this image
- Scale down: Using Y memory.
- Save copy
- Revert: Using back X memory.

As you see, they are roughly equivalent, exepct that your method, in 
the intermediate steps, use twice as much memory.  The slowdown 
complained about is probably due to Tile swapping . 

Take your conclusions.




 GSR

 ___
 Gimp-developer mailing list
 Gimp-developer@lists.xcf.berkeley.edu
 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] optional scaling in the save dialog?

2005-02-18 Thread Joao S. O. Bueno Calligaris
On Friday 18 February 2005 19:31, Sven Neumann wrote:
 Hi,

 Mateusz Misiorny [EMAIL PROTECTED] writes:
  I am currently working on a poster, and it's huge (from the point
  of view of the amount of memory I have ;) ). Once in a while I
  have to post it to the mailing list for my people to see if they
  like it and tell me what to change. Every time I want to mail it
  I first have to save it (.xcf), then scale it down, save as jpg
  then undo the scaling or just close and load again. So I thought
  it would be great if there was an option in the save dialog to
  choose the size you want to save the image in. It could be hidden
  in the Advanced Options or something so that usually it
  wouldn't bother you.
  What do you think about this? Should I put up a reuqest on
  bugzilla for that? It shouldn't be too hard to implement, since
  it's just one more operation during saving (like flattening or
  so) and it would require copying the Scale Image dialog somewhere
  to the Save Dialog. It would save you undo memory, and time.

Mateusz,
I have two 1 liner script-fus to enable/disable undo . Maybe they can 
help you?

Try disabling script-fu previously to scale,
then save as copy, and reload your image.


 No, this would only clutter the save dialog. It is already crowded
 enough. If we'd do that, next week someone will call for
 auto-whitebalance on save, adding a border and sending mail to
 grandma. No way.


 Sven
 ___
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] floating layers

2005-02-16 Thread Joao S. O. Bueno Calligaris
On Wednesday 16 February 2005 14:05, Carol Spears wrote:
 On Wed, Feb 16, 2005 at 11:10:55AM +0100, Sven Neumann wrote:

 
  There is no such thing as a floating layer, it's called a
  floating selection.  Your argumentation is flawed. Of course if I
  paste something into a layer mask, I want to be able to position
  it. That's the whole point of a floating selection. This has,
  IMO, been discussed enough in Bugzilla. There is certainly room
  for improvement here and I am all for reducing floating
  selections as well as for making them easier to deal with. But we
  can certainly not get rid of them completely. That would be a
  major regression.

 what is the bug report.

bug 113477
 carol
 ___
 Gimp-developer mailing list
 Gimp-developer@lists.xcf.berkeley.edu
 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Feedback on new rect select tool

2005-02-13 Thread Joao S. O. Bueno Calligaris
On Sunday 13 February 2005 08:25, David Neary wrote:
 Hi,


Ok...
I say I agree fully with Dave's comments. I'd have something to add 
here: 

 One usability change which would be great, but I know that it is
 a lot trickier, is to have the selection be both a selection and
 adjustable at the same time. It would be great to be able to drag
 the corners (or even, why not, the edges) of a selection to move
 it around  resize it dynamically, but have it actually be a
 selection if I do something like apply a filter. The question is
 whether the adjustableness would only apply to the last element
 added to the selection (ellipse, rectangle, or why not,
 freehand?) or to the bounding box of the entire active selection.
 I haven't thought a whole lot about it.


Great - I think that if the selection was not replaced by the 
rectangle, the adjustment could be - for the time being - on the 
boundng box of the selection. I say for the time being - because 
the olny satisfactory UI I can perceive for this is to have each 
element on the selection adjustable - that means that sucessive 
erctangle selects, ellipse, free hands, select by colors, use of 
quickmask, etc, should be individually pickable and re-edited.

The only way this functionality might be implemented is if - or rather 
- when - Pippin's suggestions for what could be called an 'action' 
model for the drawables is implemented. That is - the GIMP would 
record not only the actuall raster data, but each action performed on 
a drawable as a data independent model. That would also allow for a 
great macro recorder,  out of order undo/redo, per drawable undo/redo 
- and this - a fully readjustable selection. Maybe we could put some 
more thinking in how this proposed model would be achievable.


 Cheers,
 Dave.


Regards,

JS
--
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Re: Some questions

2005-02-13 Thread Joao S. O. Bueno Calligaris
On Sunday 13 February 2005 08:58, Jordi Canton wrote:
 You can embed ICC profiles in JPEG files. The lcms distribution
 contains code to insert and extract profiles: check the sources
  for jpegicc and friends.

 Thank you John, I have hust checked that code and compared it to
 the actual GIMP jpeg part. As I can see, actually Gimp does not
 support the embedding of ICC profiles in JPEG files.

 Is there any official mantainer of this part?. I can try to modify 
 this part myself and submit a patch, but I don't want to interfere
 with anyone's work.

Submit a properly commented patch to bugzilla - in bugzilla.gnome.org.
That is teh way to go, and not interfering in anyone's work - 
regardless of anyone being more or less officially in charge of 
certain partts of the program.

Once filed in bugzilla, your patch will be looked upon by teh core 
developers - revisons might get asked - and if it is approved, it 
will be commited by the developers themselves, ensuring no conflicts 
happen.

And of course, you as anyone else, are mostly welcome to post usefull 
patches to bugzilla - It is not meant only for reporting problems, 
but also for feature requests and code management.


Regards,

JS
--

 Jordi


___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Jury member sought for a Paris free software competition

2005-01-31 Thread Joao S. O. Bueno Calligaris
On Monday 31 January 2005 09:03, David Neary wrote:
 Hi all,

 I was contacted over the weekend by the organiser of a Paris
 based free software contest, who wanted to know whether I knew
 anyone in the GIMP project who was prepared to be a jury member
 for the competition. 

What exactly is the contest about? Coding flor a new project? Fixing 
bugs on existing projects? Or just using some free software at all?

Regards,
JS
--
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] xtns-extras ?

2005-01-22 Thread Joao S. O. Bueno Calligaris
Hi,

a few weeks ago I wrote mentioning that it might be a good idea
to rename the Xtns menu entry to Extras.

Unless my ISP account ate selected e-mails from the list, that got no
answer.

On the optmistic side, I see that no one strongly disagrees with
 that.

Therefore, I am trying it again:
What do you say about renaming Xtns to  Extras? I think it would
be a good change to the GIMP's general look and feel.

Regards,

JS
--
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Color Curves

2005-01-09 Thread Joao S. O. Bueno Calligaris
Hi there!

Please, feel welcome! 

The said news is that GIMP's color curve code is outdated and is 
begging for being rewritten, for about an year.  :-(

The good news, is that as you dive into it, you can also help the code 
in the GIMP itself.

That said, the code is in app/base/curves.[ch], and 
tools/gimpcurvestool.[ch]  


Regards,

JS
--

On Sunday 09 January 2005 06:13, Buck Arue wrote:
 I really don't know where to begin.  I am an avid Gimp user. I am
 not a programmer or developer.  This is my first attempt at
 programming, so be gentle.

 In addition to image processing, I am also a bit of a videophile. I
 am interested in porting the Color Curve function found in The
 Gimp to Avisynth to be used for video.

 This is my first attempt at programming, so be gentle.  I would
 like to know where I might find the relevant source code for the
 Color Curve function in The Gimp?

 Maybe I am biting off more than I can chew, but I would like to
 attempt it, so any help or advice you could supply would be
 appreciated.

 Thank You,
 Buck Arue

 ___
 Gimp-developer mailing list
 Gimp-developer@lists.xcf.berkeley.edu
 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] Renaming the Xtns menu

2005-01-08 Thread Joao S. O. Bueno Calligaris
Hi everyone!

Due to a suggestion on the portuguese-br translation I had set up, 
I renamed, in GIMP 2.2 already, the Xtns menu option to Extras.

Extras is written and means the same in PT and EN, just as Xtns was 
being used as abreviation of extenses. 

I am writting this because I liked the way it feels, with a whole word 
in there, instead of some pr3-h4x0r dialect, and am suggesting that 
it gets renamed in this development cycle.

On other news, I was going to update my build today, as I've returned 
from holydays, and anoncvs seens to be down. :-( So I am with a 
pre-2.2.1 build right now.


___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] Talkings about the road ahead.

2004-12-22 Thread Joao S. O. Bueno Calligaris
Today the issue of the path to take to begin gegl- talks for the gimp 
arised again on #gimp.

As irc is so transient, I was asked to save the talk in a more 
permanent way. Given there are just QA with ideas and nothing 
concrete, the list seems me to be permanent enough for this.

Yuck - Just noted that I was without time stamps.
It took place 12/22/2004, at about 17h00 UTC
=



bolsh pippin: So - I saw your mail listing the order in which you 
thought the tools should move to gegl
bolsh pippin: Do you have any idea how that might happen (I mean, 
what gegl interfaces you use, how you make paintstrokes be ops, that 
kind of thing)
bolsh A design sketch for gegl tools, I mean...
pippin bolsh: yes, but I have not had time to hack it into 
oxide/bauxite yet,.
bolsh pippin: I'd be interested in reading your ideas, if you've 
written them down somewhere...
bolsh I'm trying to get my head around what kind of interface gegl 
needs, and how much work needs doing to provide it
pippin bolsh: I have a lot of ideas,. and as well as hunches,.
pippin bolsh: I am starting to internally conceptualise how gimp 
image model fits with gegl,. and the place with least intrusion would 
be the tools,. new gegl based tools could even coexist with the 
current ones,. thus I think it would be the ideal proving ground,. 
(granted we wouldn't get high bitdepth whilst doing it,. since we'd 
still be using gimp drawables)
-- toady has quit (Leaving)
-- toady ([EMAIL PROTECTED]) has joined #gimp
pippin bolsh: the compositing requires somewhat deeper restructuring 
to be really useful,. I think it is wise to start working to get the 
tools done,. before deciding on a design there,. the design I am 
using in oxide seems to work fairly well,. but I think it needs more 
review,. a sane form of a such review won't be possible until after 
some people have started building things with gegl
joao pippin: What would you say about moving the brush and 
paint-tools compositing to Gegl first, so that brushes can have more 
parameters?
pippin bolsh: I am also,. kind of suggesting,. to allow blessing any 
image source with the 'drawable' properties,. this would mean that 
the source op gets a hidden internal chain of operations that are to 
be executed (the associated stroke history),. caching should 
eventually happend on the GEGL level,.  but that kind of changes,. 
might have to wait until gimpdrawables are replaced by  source ops 
from gegl,.
pippin joao: I don't quite follow
dindinx pippin: how hard would it be to replace gimpdrawables by 
source ops?
dindinx pippin: would this means we'll have to rewrite all the code 
that use GimpDrawable ?
bolsh pippin: And what do you think about the plan that Daniel 
outlined some months back? It appears consistent with your idea
bolsh pippin: IIRC, he was saying that we wouldn't need to migrate 
to the compositing model before we had started using GeglImage rather 
than (or contained in) GimpDrawable
joao we were talking about this yesterday. Currently, a brush in 
gimp is a tempbuff - it can't do much by itself. We were talking 
about adding a UI for scaling, and implement rotation on the brushes. 
That could be done adding/bettering the transforms in tempbuff, or 
moving it to a gdkpixbuf, or using gegl to handle the brush.
-- toyowheelin ([EMAIL PROTECTED]) has joined 
#gimp
pippin bolsh: starting with the tools,. and keeping the exiting 
infrastructure for support,. means earlier integration into gimp,. 
and the ability to start doing integration without breaking 
everything first,.
bolsh pippin: Like I said, it sounds like your idea is consisitent 
with what Dan proposed - it's a step before everything else
bolsh And it would mean depending on gegl, which is good
dindinx pippin: the sooner we start the better.
dindinx sooner == as soon as we branch
pippin 
http://www.mail-archive.com/gimp-developer%40lists.xcf.berkeley.edu/msg06446.html
 
- dans roadmap
bolsh dindinx: It might be possible to wrap a GeglImage in a 
GimpDrawable and keep all the code there
dindinx bolsh: this would be a wonderful first step, then
bolsh But everything that uses data buffers directly (TimeManager, 
TempBuf) would need re-writing to use equivalent gegl structures
pippin bolsh: _might_
pippin bolsh: it does dictate the future capabilities possible,.
-- toyowheelin has quit (Leaving)
bolsh Which would ideally abstract away details like the tiles, and 
make the API simpler, perhaps even reducing code size
bolsh pippin: Sure
pippin bolsh: aI see it,. mapping the whole internal data structure 
ofof gimp to a tree,. similar to what I have in oxide, woudl be a 
good thing
pippin s/aI/as/
bolsh pippin: That would mean, in short, replacing GimpImage by a 
graph, plus some auxilary stuff that doesn't have to do with data 
(like guides and undo) - does that sound right?
pippin bolsh: any thing touching a pixel doesn't belong above gegl
pippin bolsh: yes,. it means extending for instance my xcf2 draft 
with guides,. 

Re: [Gimp-developer] panel and winning splash

2004-12-13 Thread Joao S. O. Bueno Calligaris
Hi Carol.
[nothing of much interest on this mail for people who are ok with the 
panel]


On Monday 13 December 2004 22:25, Carol Spears wrote:
 On Mon, Dec 13, 2004 at 11:52:03PM +0100, David Neary wrote:
  Hi Carol,
 
  Carol Spears wrote:
   make a decision.  was their any discussion here of the panel
   needing the approval of these artists?  the panel was put
   together to make a recommendation to the developers.  you need
   additional handholding?  was anyone interested in being on this
   panel who can make a decision on their own?
 

Can you please calm down?
I am in the panel. The other four people in the panel  are all part of 
the comunity formed by Gimp development in all ways it stays in touch 
- that is #gimp, bugzilla, and here at least.

There were 672 splashes from which to pick one.
You did run your script in there, and after some tens of seconds, it 
spilled out a movie, did not it?

Each of us took time to appreciate each of the splashes over the last 
week. I can't speak for the others, but I looked at each of them in 
full size, in painfull proccess of narrowing down the list of viable 
splashes..Why painfull? Because most of the entries are, in their own 
way, very nice at least. The funny ones. The scary ones. So each one 
in the panel had to create a personal set of criteria to narrow the 
list, so that the whole panel had a small list upon which to debate.

You express concern about the results of a panel. I think it is 
reasonable for you to perceive that the panel is concerned about this 
result as well. Otherwise, we'd just spill out the highest ranking 
among ourselves as the final winner. Instead, we decided that the 
choices we were left with were quite good, and that diffferent point 
of views would be apreciated.

 (...)
  If the panellists want to ask for the opinion of outside people,
  or give weight to mukund's page, so be it. When their decision is
  made, it will be final.

 a final recommendation.  just spit it out.
Carol, since it seems to be so easy, why do not yourself give the 
panel feedback. Which is your choosen one?
(NB - this is mostly retorical at this point, as we have a good winner 
candidate by now - nonetheless I'd like to know your one pick among 
those 600+ entries)


 ask adam.  adam is an artist and has been involved with gimp since
 before you, me, tigert and jimmac -- i dunno about drc.


Adam is in the panel.

 if they did not want to work as a group, for what reason was it
 formed?
We want and are working as group. A nice group of  persons from 
different countries with different entries which got a unique chance 
to learn about each other's inner feelings about art and feelings 
about The GIMP and its usages as well. I may be speaking for myself, 
but it is a lifetime experience.


 if they were afraid of peoples opinion of their opinion, why did
 they want to be on the panel.

How would us know that people would arise questioning the panel 
before? On a side note, I feel the panel had been set by the Release 
Manager, and fear no one outside. As far as I am concerned, if the 
panel would vote for the dullest splash out there, that would be the 
panel recomendation and no more questions. 

But how do you feel about questioning any judge about being afraid of 
other's opinions when you yourself are attacking the panel - and at 
least  on this list, you are the only one doing so.


 this is crap.  this is pathetic like this stupid election we just
 had here in the states.

Ok - I am writting this lenghty reply, because _this_ I found 
offensive.

I agree that a way to select a winner should have been determined 
before opening up for the contest for the entries. But it was not 
done. Since the formation of the panel itself was a sugestion on this 
list, and people got a chance to propose a better, working idea, I am 
perfectly confortable  with the panel. Just because if determined 
beforehand, it probably would have been the better idea anyway.

 is the recommendation from this panel to be have tigert i approve
 this to make it worth something?

We feel more confident now we've read Tigert's comments on some of our 
picks, if that maters.

 is there anyone on the panel whose opinion does not count?
No.
It is a five way panel, and everyone is doing their part and getting 
listened.

 carol

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


Re: [Gimp-developer] A beginning GIMP Developer?

2004-12-12 Thread Joao S. O. Bueno Calligaris
Hi and welcome!

There are people in better position to answer you on this!

But I am just quite happy to see a mail like this - I myself just go 
around proposing weird features, and eventually finding and fixing a 
minor bug. Lots of fun, either way.

So...bugzilla is the way to deliver bug corrections.
You should better be using GIMP from CVS, read the 'Hacking' file in 
there for building tips - if you aren't already. Them, just check the 
bugs in bugzilla, erradicate them, taking care to maintain the coding 
style (it is GNU style, I've read somewhere). After it works, make a 
patch by running diff with -u3 option, and attach that patch to the 
bug report.

Now, keep online to hear from Sven, Bolsh, Alan, Carol and others... 

Oh, also, underliying GTK and the GIMP object system is Glib and 
Gobject - you should learn about these. There is a small app called 
devhelp which allows for interactive browsing of the API.

Regards,
js
--

On Sunday 12 December 2004 19:52, Henry Roeland wrote:
 He all GIMP developers out there,

 I'm new to this list and therefore lets introduce myself first. As
 a Software developer I'm working for about 2 years now with
 Java/C/C++ and other languages like XML/XSLT. My expirence with
 C/C++ is about medium and I know a little about Linux/UNIX
 programming but have more expirence with Win32 platforms.My
 expirence with GTK+ and GIMP code is zero.

 At this time I'm working(Using) now about 2 weeks with The GIMP for
 graphical stuff (as a hoby) and I'm very excited about all that
 GIMP offers! Because I'm a developer I like to help fixing bugs or
 add some new features. A already debuged some of the code but
 because of my lack of expirence with GTK+ and all I like to begin
 easy :-).

 In short: Can I help with bug fixing? If so should I start with bug
 fixing (which bugs) and how and to who can I deliver the patches?

 Greetings,

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


Re: [Gimp-developer] Scissors tool

2004-12-09 Thread Joao S. O. Bueno Calligaris
On Thursday 09 December 2004 06:45, Laxminarayan Kamath wrote:

 OOps, Sorry Sven, Gmail is nice but is confusing for replies. Will
 be care full next time.
 By the way,  what i mean is, when such confusions occur, like
 whether or not to remove a tool from the toolbar, isn't it nice to
 have a poll engine and make the poll public?

You are worrying over the edge here.
There is no chance this tool will be removed - not this time, nor 
soon.

What happened is that I, having the opinion that the tool is borken, 
sent a question about it to the list - which is public, in some 
sense.  People replied that  not only it is actually usable, but they 
use it on an often basis.

Therefore, there is no sense in hiding it.
And just one more point: I never suggested the removal of the tool, 
but just hiding the tool - it would be available from dialogs-tools, 
even to be put back into the toolbox.

If  a change is made to the GIMP that you do not like - in a way it 
brakes the way you work, Bugzilla is the place to ask for the old 
behavior back. 

Recently, for example, there was a bug asking for the old behavior of 
the Move tool - that would change the selected layer. That was 
promptly implemented as an option.

Regards.

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


Re: [Gimp-developer] Scissors tool

2004-12-08 Thread Joao S. O. Bueno Calligaris
On Wednesday 08 December 2004 04:17, Austin Donnelly wrote:


 I think I was probably the last person to do any major work on the
 scissors tool, and that was in 1999 to port it to the (then new)
 tile-based world.

 The code when I took it on was a software Vietnam; a complete
 mess.  I had to read the SIGGRAPH paper it was attempting to
 implement before I could fix it, and believe me it left my hands
 much cleaner than I got it!

 There are two areas where it could do with improvement:
   - it doesn't handle tile-boundaries (it treats them as edges)

hmm..this explains the major complaint I had about it.
Sorry again to all who make use of the tool. 

   - the point editing interface sucks; I merely made the existing
 one work but it might be interesting to see if it could use the
 same code from the Path tool (that was always the plan)

It may not be fine, but it works. As stated in other e-mail, it could 
benefit from undo. The tile boundary == edge thing is not good.

 Austin


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


Re: [Gimp-developer] Scissors tool

2004-12-07 Thread Joao S. O. Bueno Calligaris
/me shame on, and goes learn how to properly use it.

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


Re: [Gimp-developer] Multiple Layers and curves?

2004-12-07 Thread Joao S. O. Bueno Calligaris
On Tuesday 07 December 2004 19:52, Joseph Heled wrote:
 When opening the curves tool, it shows the current layer.
 Then switching to another layer, the curve tool remains unchanged.
 Now opening curves for the second layer, the first tool disappears.

 So, How can I view/adjust curves for two layers simultaneously?
You cannot.
That is simply it.

If you have a good motive to need this, you better open upa  feature 
request on bugzilla.gnome.org and describe your uses.

Meanwhile, the workaround for this is running 2 simultaneous GIMPs, 
and editing one of your layers as a separate image on other instance 
of the GIMP.



 Thanks, Joseph

 ___
 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] Scissors tool

2004-12-06 Thread Joao S. O. Bueno Calligaris
Hi!

I should've done this __very__ earlier on the dev. cycle. But the fact 
is that I think developers should seriopusly consider the visibility 
of the scissors tool on the tool box.

I mean - it is a good hack, it is there for historical reasons, and 
the graphic algorithyms behind it are nice for paper presentations 
and etc...

But nowadays, who seriously uses it? 
The fact is  that it doesn't deliver the functionality it should, 
and is simply awkard. The new Vectors interface from GIMP 2.0 allows 
one to do with vectors what the Scissors tool should be doing, only 
it is easier to use, and to figure out how to use.

That said, I raise the question: Should the scissors tool be visible 
by default in the toolbox?


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


Re: [Gimp-developer] Gimp Plug-in for Retrieving Text Layers

2004-12-05 Thread Joao S. O. Bueno Calligaris
On Sunday 05 December 2004 01:00, Sven Neumann wrote:
 Hi,

 Joao S. O. Bueno Calligaris [EMAIL PROTECTED] writes:
.

  There is one thing to do - The plug-in have to manage text layers
  on it's side, creating itsef the parasites it need to store the
  information. - Just like the old Dyn text. Then, the standard
  text-tool api can be used. The plug-in won't know about any other
  text layers but the ones it creates, thought.

 Why should a plug-in do this? Plug-ins shouldn't have to deal with
 the hacks that GIMP uses to extend the XCF file format. These hacks
 might change at anytime and should become part of the API.



Sorry Sven, I am afraid I was broadly misunderstood here.
When I speak of parasites above, I am talking of parasites as they 
intend to be used: extra data that can be used by the plug-in. My 
idea above is that the plug-in stores the information it needs about 
which text layers exist on the image, and their content, on it's onw 
- on a parasite it creates for its own use. 
When a text changes - on the plug-in interface, it just deletes the 
text layer and create a new one.

I cannot figure out any other way of a plug-in managing text layers 
right now.


 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


  1   2   >