Re: Layers, dialogs and other bits of love on Valentines Day

[Sven Neumann]

Hi,

"gimptek DESIGNS" <[EMAIL PROTECTED]> writes:

> Maybe I wasn't clear.  I didn't mean layering should change in any way than
> it does now (except maybe adding Photoshop style color dodge ;) but, just
> the representation of it should.  The way the layers stack isn't the change
> that I was thinking about but rather, the way they are represented in the
> dialog.

Your ideas are worth considering after the preview stuff has been 
generalized and we start to rewrite the layers dialog (which is 
something we definitely want to do for gimp-1.4).

> For Gimp 2.0, how much of it will be Bonoboized?

We have not yet decided if we want to bonoboize something at all, but 
mostly due to the fact that noone I talked to so far could explain what 
this would mean in particular.


Salut, Sven

Re: Layers, dialogs and other bits of love on Valentines Day

[Sven Neumann]

Hi,

Emmanuel Mwangi <[EMAIL PROTECTED]> writes:

> Anyways, all that is far off.  I was wondering you could just have nested
> layers in this next version of Gimp.  It doesn't even have to have all the
> strange but, cool stuff that tigert was talking about but, even just being
> able to organize your layers and having the ability to group them
> hierachially and turn a group's visiblity on and off, and being able to
> move a layer from one group to the next, etc.

I have very strong doubts that allowing layer trees in Gimp-1.4 would 
mean you'd get layer trees earlier than if you'd wait for Gimp-2.0. In
fact I believe it would only mean that you wouldn't see a stable Gimp-1.4
before 2003.

The problem implementing all this in the current code tree is that the 
current code is a mess. The layers dialog is especially messy. So what
we will do is clean up that mess first, then port to GTK+-2.0, then 
release 1.4, then take all the nice new code, add GEGL and PUPUS and 
release Gimp-2.0 shortly after.

> On a side note, is there any work being done on the layers dialog?

Yes, all dialogs and everything else is under heavy development. 


Salut, Sven

Re: CVS HEAD channel previews?

[Sven Neumann]

Hi,

Nick Lamb <[EMAIL PROTECTED]> writes:

> Maybe it's just me, but it seems that channel previews have been broken
> in CVS HEAD for some time. I'm not complaining, it just seems possible
> that no-one has bothered looking at that entire tab for say, two weeks
> and didn't realise that they'd broken it.

IIRC, Mitch changed some of the code that used to emit the signals that
causes the previews to update. Once the preview code is generalized and
the new widgets are in place, everything should work again, only better.


Salut, Sven

Re: Error messages from a plug-in

[Sven Neumann]

Hi,

Ernst Lippe <[EMAIL PROTECTED]> writes:

> What is the "official way" to display error messages from a plug-in to
> the user?
> Basically what I looked for was a simple window (perhaps even with some
> threatening icon) that I could invoke with a single function call
> (I guess that I have been spoilt by too much Delphi programming).
> I could find no such thing in the standard Gtk/Gimp libraries.

Use g_message (), which is a standard glib logging mechanism that is 
configured to do the right thing from gimp plug-ins. The right thing is 
to use the console if the user specified the --console-messages option 
or if gimp is running in batch mode. If running interactively it will 
display a dialog window or use the error console.


Salut, Sven

Re: NLS-Problems passing GIMP_PDB_FLOAT PDB parameters

[Sven Neumann]

Hi,

"wolfgang hofer" <[EMAIL PROTECTED]> writes:

> - The Problem is related to NLS (the LANG Environment Variable)  
>   (when I do unset LANG, everything is OK)

If you had used the macros gimp provides for initializing I18N, you 
wouldn't have had this problem. Your code should look like this:

  gtk_set_locale(); 
  setlocale (LC_NUMERIC, "C");

Actually I would suggest you copy code from libgimp/gimpintl.h and
adapt it your needs.

> Should I report this as Bug of the GIMP PDB-Interface ?

No, it's a bug in your code.


Salut, Sven

Re: [Fwd: Gimp/fourier]

[Sven Neumann]

Hi,

[EMAIL PROTECTED] (Carsten Hammer) writes:

> > gcc -g `gtk-config --cflags` -O2 -Wall -c fourier.c
> 
> Anybody here who can help Frank? I dont know whats going on there..

what about using gimptool to get the compiler and linker flags right?

Try:
gimptool --build fourier.c

or if the relevant plug-in has more than one C-file, use 
gimptool --cflags / --libs in the Makefile instead of gtk-config.


Salut, Sven

Re: Value in histogram

[Sven Neumann]

Hi,

Nick Lamb <[EMAIL PROTECTED]> writes:

> On Thu, Feb 08, 2001 at 01:36:10PM +0100, Roel Schroeven wrote:
> > The value in the gimp histogram is calculated as the maximum of the red,
> > green and blue channels now. Wouldn't it be better to use the average of the
> > three color channels?
> 
> We discussed this when I was fixing the histogram for 1.2.x BRANCH (btw,
> did that fix go into 1.2.1, or did it just rot? Maybe I should look for
> myself) and I can't remember what the arguments were for leaving it as
> it is, but that's what we decided to do in 1.2 at least.

Well, max (r,g,b) is the correct formula for calculating the value of a 
color (assuming that value corresponds to the V in HSV). The average of the 
three channels is a somewhat useless number, but it might make sense to add 
intensity (mostly defined as 0.3 r + 0.59 g + 0.11 b) as an option.


Salut, Sven

Re: ANNOUNCE: GDynText 1.5.4

[Sven Neumann]

Hi,

Marco Lamberto <[EMAIL PROTECTED]> writes:

> Now really compiles with GTK_DISABLE_COMPAT_H defined.
> 
> I can download it at:
>  
> or:
>  

If you think this release containes some important bugfixes with
respect to the version we ship with gimp-1.2, please send us a
patch, so we can integrate your changes into the 1-2 branch.


Salut, Sven

Re: Proposed Paint Core changes to support textures

[Sven Neumann]

Hi,

[EMAIL PROTECTED] writes:

> > I think a better solution would be a definable pressure curve, much
> > like Wacom's Windows driver has.  That'd probably be a feature of the 
> > general mechanism you described and perhaps what you have in mind.
> 
>  Hm, generating a lookup table and getting the pressure from there
>  instead directly from the driver would be trivial to implement and
>  seems like a worthy feature to me.

What driver are you speaking about? 

The code to use a LUT to map brush pressure to a more sophisticated curve
is already in the paint_core (only #ifdef out). Look for the FANCY_PRESSURE
define. Actually this is not what we want...

>  I made an entry into bugzilla so we don't forget that. I'd like to wait
>  for Sven and Mitch to complete the changes so we don't have to implement
>  this in several places hopefully.

Currently Mitch is working on the previews and selection dialogs for data 
objects. IMHO there is a need for at least two more things to think about:

- A cache mechanism to avoid holding all the data objects in memory.

- A mechanism to select different data from the same object depending
  on paint_core parameters (like the brush-pipe we have now, only more
  general). This does not imply that all data has to be stored on disk
  as pixmaps, it could also be the result of applying a transformation 
  on pixmap data or could even be completely calculated (think generated
  brushes).

The paint_core should be changed to work with abstract data objects 
instead of distinguishing between brushes, patterns, textures and 
images. While this might be a good way of sorting things for the user,
there is no reason why I shouldn't be able to paint with an image, using
a pattern as texture. The paint_core doesn't really need to know the
difference.


Salut, Sven

Re: Proposed Paint Core changes to support textures

[Sven Neumann]

Hi,

"David A. Bartold" <[EMAIL PROTECTED]> writes:

> I think a better solution would be a definable pressure curve, much like
> Wacom's Windows driver has.  That'd probably be a feature of the
> general mechanism you described and perhaps what you have in mind.  A
> user (or a brush designer) can define their own function and the mechanism
> would be usable for all tools, not just ones that draw by copying from
> bitmaps.

Pressure curves are indeed a good idea and should be implemented generally.

> The major problem with having different texture maps for each pressure is
> the amount of memory necessary to store them.  Texture tiles generally are
> much bigger than brushes to reduce visible repetition.  A texture of size
> 256x256 is not uncommon, and if there were 8 copies of that texture stored
> in a brush pipe file, each bitmap corresponding to a different pressure,
> then the file will be ~500k.  That's a big download (and a lot of cache
> misses) just for one texture.  Since many people download their copies of
> GIMP, that's a lot of bandwidth, too.

And do not forget that Gimp holds all patterns and brushes in memory 
regardless if they are ever used. This is one of the main points why
I'm asking for spending some thoughts about a better data system for
The GIMP before adding just another data type like textures.


Salut, Sven

Re: Proposed Paint Core changes to support textures

[Sven Neumann]

Hi,

"David A. Bartold" <[EMAIL PROTECTED]> writes:

>   * new function gimp_context_get_texture:
> Returns a GPattern * from the specified context.  Heeding Seth's
> advice not to create a new file format without good reason, I've
> determined the .PAT format to be suitable for this purpose: it
> supports grayscale data and description text.  Also, it provides
> an already existing API framework, GPattern.

which has just disappeared from CVS. We are in the middle of migrating
all data types. The brush code will change a lot too. It might be better 
to wait until this is finished... Once we have cleaned up the object
hierarchy it should be easy to reuse the code from the brushpipe that 
changes the brush to make it change texture patterns in a similar way.

Overall I'm very positive that your texture additions will make it into
The Gimp very soon.


Salut, Sven

Re: porting a plug-in from 1.18 to 1.20

[Sven Neumann]

Hi,

david rohde <[EMAIL PROTECTED]> writes:

> I have been trying to port a plug-in that I have been writing to the latest
> gimp, but I have been having troubles.
> 
> Firstly a lot of the constants that were defined in 1.18 are no longer defined
> in 1.20 for example RGB.  Is this a deliberate change, I find it a strange
> thing to remove from the header.  What approach should I be using to deal with
> this?

Assuming you are porting to 1.2.x, running the following script does most of 
the work for you:

http://sven.gimp.org/files/remove_cruft

Make sure to do a backup before you run it and check the diff. You need to 
fix the RGB -> GIMP_RGB issue yourselves since the script is not intelligent
enough for this (it's a quick hack).

Together with the libgimp API reference, it shouldn't be too hard to port
to 1.2.x. Perhaps you could write down what you had to do, so we can point
other people to this document later?!


Salut, Sven

Re: gimp.themes.org ideas

[Sven Neumann]

Hi,

Jordan Evatt <[EMAIL PROTECTED]> writes:

> hey guys. we at themes.org are creating gimp.themes.org (you knew it was coming). i 
>was wondering if anyone had any suggestions or ideas for what should go on it. i just 
>got through talking to #gimp, and here's what i have so far:
> 
> a) don't create a separate repository for plugins and scripts
> b) things like patterns / gradients / brushes are good
> c) tutorial section probable, but some want that to stay at tutorials.gimp.org
> 
> i guess i emailed because of the plugin issue. would you mind if we did create a new 
>repository? it seems to me that people would be more willing to visit gimp.themes.org 
>and click "plugins" and go to the big repository (i could upload all of the existing 
>ones), then having to wade through gimp.org's repository. i'm not trying to make a 
>"we get more hits than you so lets move the repository to our site" flame war, i just 
>want some suggestions (in the nice way).

First of all, I would be more happy if finally someone (or better, a group 
of people) would show up who want to redo gimp.org. The web-site needs an
overhaul urgently and I don't think creating new gimp sites will help us
with this task.

The plug-in issue is special since we want to rethink the way plug-ins are
developed, maintained and distributed. The key for a new better plug-in
system is a description format for plug-ins that fulfills the needs of 
developers, webmasters and users. This issue should be discussed here on 
this list. I talked to Ingo, the creator and maintainer of the infamous 
plug-in registry, recently and he is willing to revamp the registry once 
we have settled on such a description format.

I heard several people have already made plans for a better plug-in system
but I'm still waiting for this ideas to show up here.

> also the tutorials. included in the tutorials would be everything we have standard 
>on all the other sites, like the documentation for installation and 
>configuration/setup. it wouldn't be that bad of an idea to me to put some of tigert's 
>tutorials (with due credit) on there as well for quick access.
> 
> i'm pretty sure i'm gonna be the project manager of gimp.t.o whenever we get it 
>drawn up. so this is why i want suggestions... SUGGESTIONS AND IDEAS!! NOW!! GIVE 
>ME!! :P
> 

Noone can stop you from doing gimp.t.o, but in a perfect world, you'd 
better put that energy into gimp.org. Just my 2 cents.


Salut, Sven

Re: Gimp 1.3 compile and link dependencies

[Sven Neumann]

Hi,

Hans Breuer <[EMAIL PROTECTED]> writes:

> while adapting make and export definition files for the
> win32 build of Gimp 1.3, there where some questions ariseing :
> 
> - what are the supposed dependency between all the libgimp* 
>   libraries ?

you got it right in your graphics below.

> what I have at the moment is (gimp.exe works, but most
> plug-ins do not yet) :
> 
> gimp.exe  plug-ins
>   + gimpcolor.dll+ gimp.dll
>   + gimpwidgets.dll  + gimpui.dll
>  + gimpcolor.dll |  + gimpwidgets
>  + gimpmath.dll  |+ gimpcolor.dll
>  |+ gimpmath.dll
>  + gimpcolor.dll
>  + gimpmath.dll
>  + gimpwidgets.dll
> 
> all the above resolves fine except libgimwidgets dependcies,
> because there are the functions listed below, which need
> (and have) different implementations in Gimps and Plug-Ins
> context. Currently I'm linking gimpwidgets.dll against
> the functions exported by Gimp, but this probably is the
> reason why most plug-ins aren't running ...
>
> I could hack up a windoze specific version for those functions, 
> to dynamically detect, if they are running in Gimp's or Plug-In's 
> context, but does anyone now of a proper cross platform sollution ?
> 
> critical functions:
>  gimp_palette_get_background
>  gimp_palette_get_foreground
>  gimp_standard_help_func
>  gimp_unit_get_abbreviation
>  gimp_unit_get_digits
>  gimp_unit_get_factor
>  gimp_unit_get_number_of_built_in_units
>  gimp_unit_get_number_of_units
>  gimp_unit_get_plural
>  gimp_unit_get_singular
>  gimp_unit_get_symbol

We probably need to export the symbols you listed so you can link
gimp against libgimpwidgets. libgimp exports the same symbols but
has an implementation that works through the PDB.

> Second question:
> - to make Gimp compile again I needed to include some headers 
> in other headers again (see attached patch). Yes, I've read the 
> docs, which say not to do so, but is it really wanted to get 
> a header order dependency ?

Please send the patch included in your email, not as zip archive.
Makes it easier to read and allows me to comment on the diff in
a reply. I have looked into it and parts of it look good, others
need a different solution imho.


Salut, Sven

Re: Proposal for a texture selector

[Sven Neumann]

Hi,

"David A. Bartold" <[EMAIL PROTECTED]> writes:

> Very cool, that should simplify the process of creating a texture selector
> greatly.  In addition to providing UI elements for the user, there also
> needs to be an API for scripts and the plug-ins to change the texture.

Thanks to Mitch the first implementations of the new object hierarchy are
already in CVS. When this is finished, the code for a texture selector should
be a few lines only. We are planning to generalize the plug-in interface as
well, so that you get libgimp functions quasi automatically. This object 
system should be reusable for gimp-2.0 too.


Salut, Sven

Re: Proposal for a texture selector

[Sven Neumann]

Hi,

"David A. Bartold" <[EMAIL PROTECTED]> writes:

> There needs to be a way to select a texture before advanced tools can
> be added to The GIMP.  I propose to create a new dialog box similar
> to the pattern selector.  Instead of containing tilable RGB pixmaps, it
> will contain tileable greyscale heightfield pixmaps.  These textures will
> be used by some tools to simulate, for example, paper grain.
> 
> The user can see the current texture in the main window and in the
> Device status window.  It will be near the current brush selection,
> pattern, and gradient.
> 
> A mock-up "screenshot" is available here:
> http://uts.cc.utexas.edu/~foxx/texture_sel.png
> 
> I'm not too happy about making the gradient a square rather than a
> rectangle.  The brush, pattern, and texture could be horizontally
> adjacent and the gradient placed underneath all three.  I.e.:
>  ___   ___   ___
> |   | |   | |   |
> |___| |___| |___|
>  ___
> |   |
> |___|
> 
> Anybody else have a suggestion?
> 
> There will need to be a new file format for the textures, however
> the code can easily be borrowed from the .pat or .gbr plug-ins.  The
> extension could be .gtx for GIMP Texture (assuming that extention isn't
> used). 

Sounds like a reasonable idea if and only if we make almost all paint tools
use this texture. Are there any algorithms which have proven to fit into
the Gimp paint_core?

Before you think about writing code, we are are designing an abstract 
GimpData object at the moment which will be the parent of all those brush,
pattern, gradient, ... stuff. Those data objects will go into a GimpContainer
(which has just appeared in CVS) which will handle the problems of keeping
names unique, etc. We will also provide views on these objects so all data
previews and all sort of brush, pattern, gradient, ... -dialogs can reuse
the same code. 

This is work in progress, but I'd suggest you don't just copy a lot of 
code around and create a new data type. This is the way it has been done 
several times before and it has led to the awful mess they call gimp-1.2.
In a few weeks, when the basic object infrastructure is in place, it will
be very easy to introduce a new data type.


Salut, Sven

Re: problem with gtk+ colorselector

[Sven Neumann]

Hi,

Nick Lamb <[EMAIL PROTECTED]> writes:

> On Sun, Feb 04, 2001 at 04:45:58AM +0100, Sven Neumann wrote:
> > The colorselector has already undergone a major overhaul in the HEAD tree.
> > The color previews as well as all sliders are now global to all color
> > selector notebooks so all selectors should behave identically. Have a look
> > at http://sven.gimp.org/files/color_selector_1_3.png for a screenshot.
> 
> Yeah, but there's some odd bugs or features with it. Firstly when you're
> not using the "Gimp" selector (we should find better names) you can still
> see the radio-buttons which control it - they just don't react. Odd.

They are set insensitive which should IMHO be feedback enough. If you can
think of a better place for the toggle buttons, let us know.

> Secondly the "GTK+" tab resizes oddly the first time you look at it, then
> it's fine, but too small the next time. If we can't get it working right
> we should write our own circle+bar selector instead of fudging it.

Yes, indeed. We have hidden almost every widget in the GTK+ colorselector
and we had to do it from an idle callback. This broke size allocation. We
should kick the GTK+ color selector and write a simple circle+bar as you
suggested.

> What does the GTK+ selector bring to the party anyway?

The reason was that many other places (plug-ins, gradient editor) in The
GIMP used to use the plain GTK+ colorselector, so it should also be 
available in the main color selector. Since we plan to use the new 
combined selector everywhere, the circle-shaped GTK+ selector is not really
necessary anymore. GTK+-2.0 replaces it with a triangle colorselector 
anyway, so if we want to keep that circle thing, we have to put the code
into Gimp.


Salut, Sven

Re: problem with gtk+ colorselector

[Sven Neumann]

Hi,

"Uwe Koloska" <[EMAIL PROTECTED]> writes:

> This isn't in sync with the behaviour of the other selectors.  There you 
> always have the comparison with the color you want to change!  If you click 
> on the fg-color you can watch your changes in contrast to the old color.  
> It's of very limited use, to see the changes in contrast to a color you 
> have chosen before.

OK, I think I see your point now.

> Therefore the gimp colorselectors behaviour has to be changed or that of 
> gtk+.

The colorselector has already undergone a major overhaul in the HEAD tree.
The color previews as well as all sliders are now global to all color
selector notebooks so all selectors should behave identically. Have a look
at http://sven.gimp.org/files/color_selector_1_3.png for a screenshot.

If someone finds a simple fix for this (minor) problem in gimp-1.2 we
should consider applying it to the stable version.


Salut, Sven

Re: New wishlist for next GIMP available??

[Sven Neumann]

Hi,

Avi Bercovich <[EMAIL PROTECTED]> writes:

> has the wishlist for features for gimp 1.4/2.0 been started?? If so where
> can I find it/add to it?

The source tree contains a file TODO which is a collection of ideas
that have come up over the years. Actually the file should not be
called TODO, but probably IDEAS or something similar.

The HEAD branch in CVS has a new file called TODO.xml which is the 
real TODO. We create a html version from it which can be found at
http://developer.gimp.org/. This site is supposed to become a place 
for documents regarding gimp development. We plan to add the API 
references and other documentation here and I talked with Xach 
about adding a forum where people can exchange ideas and discuss
feature requests.

Only very few new features will be allowed for Gimp-1.4. The goal
of the current development cycle is to clean up the source in order
to make it possible to reuse at least parts of it for Gimp-2.0.


Salut, Sven

Re: problem with gtk+ colorselector

[Sven Neumann]

Hi,

"Uwe Koloska" <[EMAIL PROTECTED]> writes:

> I have found a very annoying problem with gimps gtk+ colorselector.  Since 
> I don't use it normally, it came into my eye after installing digipencil. 
> 
> Because the testprogramm that come with gtk+ shows the right behaviour, it 
> maybe there is a problem with the gimp inheritance of this widget.
> 
> The problem:
> I click on the foreground color (black) and choose the gtk+ selector. Close 
> the color selector.
> Then click on the background (white) and the two labels under the 
> colorcircle are filled with black and white (from the left)

Very well noticed.
 
> My first problem was that I was unable to change the foreground color.  But 
> this was a problem with the value.  The circle shows a color but this color 
> has no value, so it was always black ...

The circle alone is not sufficient to choose a color. There has to be a 
way to change the colors value. But I guess you found that out pretty soon.

> And the behaviour I described above seems to be related to this.  The gtk+ 
> colorselector seems to display the color that was chosen the last time. 
> This is probably due to the fact, that the color selector isn't destroyed 
> after choosing a color.  If you leave the selector open and doubleclick on 
> the other color (back- or foreground) you can see this clearly.

The GTK+ colorselector does indeed remember the color last choosen so you
are able to see the contrast between the new color and the one you started 
with.

Now to the point: Where's the problem??


Salut, Sven

Re: problems with windows gimp

[Sven Neumann]

Hi,

Nick Lamb <[EMAIL PROTECTED]> writes:

> On Thu, Jan 18, 2001 at 12:42:23AM +0200, Tor Lillqvist wrote:
> > (No, I don't know why duplicate PDB procedures cause strange errors
> > and not just warnings. Anyway, GIMP seems to handle this situation
> > better in the current gimp-1-2.)
> 
> It's a long standing bug in Gimp. I would really like to change the name
> of one of my plug-ins, but this bug prevents that (it would crash Gimp)
> It's possible, but unlikely that it's actually fixed in 1.2.0, but
> generally people poke inside the PDB, throw up, tweak something until
> the crash that annoyed them stops and go home.
> I don't blame them, and I wouldn't volunteer to re-write its hairy
> logic, so I've stopped whining about it. (unless this counts :) )

Oh, you better would have whined louder and submitted a bug-report. 
I just stumpled across this issue by accident and added a few checks
for NULL pointers after 1.2.0 was out. 1.2.1 should behave better 
because of this, but I'm sure the problem wouldn't have existed in
1.2.0 if there would have been a proper bug-report earlier.

A quick test (creating a copy of one plug-in in the plug-in path) makes
me think that the problem is fixed in the current gimp-1-2 branch in 
CVS, but it would be nice if people could test it a little more. 


Salut, Sven

Re: configure

[Sven Neumann]

Martin Weber <[EMAIL PROTECTED]> writes:

> There seems to be a problem in configure. If I use a freshly installed
> Linux without the headers of the kernel sources installed, configure runs
> without any error, but doesn't define certain variables. So the whole couldn't
> compile. The thing is that configure should check for the headers of the kernel
> sources.

A linux installation without kernel headers can not be called "a freshly 
installed Linux". In fact it's an "incompletely installed Linux" at least
if you intend to compile stuff on this box. The distribution (or the user
himself) should take care of installing appropriate header files when 
installing the compiler. It's not Gimp's job to take care of each and every 
thing a dumb user could do wrong.


Salut, Sven

Re: Bug in configure

[Sven Neumann]

"Uwe Koloska" <[EMAIL PROTECTED]> writes:

> "./configure --help" gives a wrong default for "--enable-gimpdir":
>   --enable-gimpdir=DIRchange default gimpdir from .gimp to DIR
> must be
>   .gimp-1.2
> 
> Same change in INSTALL.  (I don't know wether I can use variables, so I 
> can't make a patch)

you can't use variables in INSTALL (but we could make an INSTALL.in to
generate INSTALL from), so I changed it by hand there. Using variables
should work in configure.in, but obviously not in the output of 
AC_ARG_ENABLE, so my quick fix was to hardcode the value as well. 
Thanks for the report.


Salut, Sven

Re: GIMP 1.3x - gradients

[Sven Neumann]

Hi,

Martin Weber <[EMAIL PROTECTED]> writes:

> We should change the behavior of the selection of gradients in gflare and
> we should allow functions to be used as gradients in GIMP like random in
> gflare.

We accept patches (or properly outlined proposals).


Salut, Sven

Re: plugins

[Sven Neumann]

Hi,

Martin Weber <[EMAIL PROTECTED]> writes:

> Could we now start and add new plugins to GIMP cvs?

No, but we should settle on a system for plug-in development, 
maintainance and distribution and start to move plug-ins out
of gimp CVS soon. Some ideas have come up, but the discussion
calmed down a little. Does this mean that you people are working
on this ??


Salut, Sven

Re: Plugin patches

[Sven Neumann]

Jens Christian Restemeier <[EMAIL PROTECTED]> writes:

> I recently got a bug report for QBist, and in turn made a new version.
> What is the easiest way to get it into CVS-Gimp ? I made a patch, but
> the patches directory on ftp.gimp.org doesn's seem to be cleaned for 2
> years,

The patches directory may look a bit untidy, but it's not as worth as 
you mention. If you upload a patch and this patch applies clean, you 
can expect your patch to be applied to CVS within a few days.

You can also ask someone who has CVS access to apply the patch for you.

You can also ask for CVS write access and apply the patch yourself. 

> and the latest CVS version doesn't have the changes from the
> newest version on the plugin repository.

This is very bad! How could this have happened?


Salut, Sven

Re: gauss_rle bad error (indexed image)

[Sven Neumann]

Rick Bradley <[EMAIL PROTECTED]> writes:

> I've run into a problem with gauss_rle and perl-called script-fu's in
> Gimp 1.1.29.
> 
> Basically:
> 
>  - I'm calling some of the various logo script-fu's using the perl
> Gimp interface
> 
>  - On those script-fu's which internally use gauss_rle I get the
> following error in the server output log:
> 
> 979272234: server version 1.201 started, authorization required
> 979272234: accepting connections on port 10009
> 979272240: accepted tcp connection from 127.0.0.1:2683
> gimp: gauss_rle: cannot operate on indexed color images
> 
> ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ 

[snip]

> It seems like gauss_rle is either mistaken about the type of image it
> receives, the perl interface is not creating images of the proper
> type, or there's some hoodoo/voodoo loose under the hood.

>From a quick glimpse at the code in gauss_rle it seems to do the right 
thing, which is basically:

if (gimp_drawable_is_rgb (drawable->id) ||
gimp_drawable_is_gray (drawable->id))
  { 
 /*  blur  */
  }
else
  {
gimp_message ( "gauss_rle: cannot operate on indexed color images"); 
/*  exit wit error  */
  }


The problem seems to be elsewhere.


Salut, Sven

Re: Histogram patch

[Sven Neumann]

Nick Lamb <[EMAIL PROTECTED]> writes:

> A potential patch for the histogram tool in 1.2.x (assuming we do plan
> to release e.g. file handle leak fix as a 1.2.1) has been uploaded
> as gimp-ruth-010109-0.patch.gz

The patch is available on ftp://ftp.gimp.org/pub/gimp/patches. Please
give it a try. I'll look into it myself tonight.


Salut, Sven

Re: Submitting Patches

[Sven Neumann]

Hi,

"oliver" <[EMAIL PROTECTED]> writes:

>   An updated version of the patch is attached. Let me know if all is well
> this time.

I have applied the patch to CVS. If you would have given us your full name,
I would also have been able to it to the ChangeLog...


Salut, Sven

Re: Submitting Patches

[Sven Neumann]

Hi,

"oliver" <[EMAIL PROTECTED]> writes:

>   I've hacked a few of photoshop's blending modes (dodge and burn -- which
> are different in photoshop than multiply and divide -- and hardlight) into
> the gimp 1.3 sources. I was wondering if this would make an interesting
> patch, and if so how do you guys prefer recieving them?
> 
>   In any event a unified diff against current CVS is attached.

A short patch like this one can always be sent through this list.
But I'd prefer if you could redo the patch, because of the following
reasons:

- it reverts a change in the preferences dialog. You obviously 
  didn't cvs update before creating the diff. 
- it changes some autogenerated code (the files ending in _cmds.c).
  The changes have to performed in the directory tools/pdbgen/pdb
  on the .pdb files.

You could help us by providing a new patch. Sent it to the list again
or upload it to ftp.gimp.org.


Salut, Sven

Re: Suggestions for gimp

[Sven Neumann]

Hi,

"Orson Jones" <[EMAIL PROTECTED]> writes:

>   Background Remover
> Used for defringing.  Makes an edge partialy transparent and 
> removes the background color from the semi-transparent area.
> (Imagine a black area bluring onto a white background)
> In this example the gray area would be made black, and the 
> transparancy would be adjusted to give the same appearance of 
> gray

This is exactly what the "Color To Alpha" plug-in shipped with
Gimp-1.2 does.

The other ideas seem to be good suggestions. I think we should
set up a web-forum where we collect ideas and suggestions like
this.


Salut, Sven

Re: GIMP 1.2.0 and Solaris 7/SPARC

[Sven Neumann]

Hi,

Tino Schwarze <[EMAIL PROTECTED]> writes:

> Without having looked at the code - what do we need that many FDs for?!
> We don't need to open all palettes at once, do we?

Gimp-1.2.0 leaks a filedescriptor when loading palettes. This has been fixed
in the meantime. 


Salut, Sven

gimp translations, CVS branches

[Sven Neumann]

Hi Rodrigo,

I noticed that you checked updates for the spanish translation of
gimp into CVS. Please note that we branched gimp CVS after the 
1.2.0 release. Since I assume you want the updates to go into the
stable branch (so they are available with the upcoming 1.2.1 
release), you should have checked into the gimp-1-2 branch. 

Please backup your versions of the es.po files and update your local
gimp repository using 'cvs update -r gimp-1-2'. Your CVS version will
then be tagged and subsequent updates and commits apply to the stable
branch. You should then apply your changes to this source tree and 
commit them. 

I wouldn't suggest you try to keep the translations uptodate in the
development branch. Translators should not yet have to worry about
gimp-1.3. I have forwarded this mail to the gimp-developers list so 
I don't have to explain this too often...


Salut, Sven

Re: GIMP 1.2.0 and IRIX

[Sven Neumann]

Hi,

"Garry R. Osgood" <[EMAIL PROTECTED]> writes:

> > I can successfully use pepper.gbr. File->Open loads it in just fine
> > and I can select the brush in File->Dialogs->Brushes.
> >
> > FYI, I have no problems with Solaris 8/SPARC nor Tru64 UNIX 4.0D/5.0.
> 



> Just this evening (GMT -5.00) I've observed this phenomenon, on the
> same brushes that gave Al problems. Not on the Linux laptop, but on
> the SGI O2 and Indigo (Irix 6.5.8 and 6.5.4 respectively).
> 
> I can spend some time isolating it, but not until this weekend. If I don't
> obtain resolution, I'll make summary comments in a bug report.

I think the problem is that we seek backwards in the file since we try
to read in a pattern header after we have read a grayscale brush. This 
is to remain backward compatibility (something we should probably not
have done). If no pattern can be found, we seek back to read the data
again as the next brush. Obviously something goes wrong here on some
platforms.

The best way to solve this problem is most probably to drop backward
compatibility in the core. For the plug-in, I can think of a way to
avoid the seek, but retain the possibility to read old brushes: Parse 
the data in the pattern header struct to recreate the brush header 
from it and continue reading the next brush. I wouldn't want this hack 
in the core however. The question is: can we afford to drop the 
backwards compatibility of the core when it comes to read old .gpb and 
.gih files? And can we do this in the 1.2 branch? Remember: Users can
always use the gbr and gih plug-ins to convert old brushes into the new
format.


Salut, Sven

Re: GIMP 1.2.0 and IRIX

[Sven Neumann]

Hi,

Albert Chin-A-Young <[EMAIL PROTECTED]> writes:

> On IRIX 6.2 and 6.5 with GIMP 1.2.0:
> 
>   $ gimp
>   /opt/TWWfsw/gimp12/bin/gimp: Failed to load one of the brushes in the
>   brush pipe
>   "/opt/TWWfsw/gimp12/share/gimp/1.2/brushes/SketchBrush-64.gih"
>   /opt/TWWfsw/gimp12/bin/gimp: Warning: Failed to load brush pipe
>   "/opt/TWWfsw/gimp12/share/gimp/1.2/brushes/SketchBrush-64.gih"
>   /opt/TWWfsw/gimp12/bin/gimp: Failed to load one of the brushes in the
>   brush pipe
>   "/opt/TWWfsw/gimp12/share/gimp/1.2/brushes/SketchBrush-16.gih"
>   /opt/TWWfsw/gimp12/bin/gimp: Warning: Failed to load brush pipe
>   "/opt/TWWfsw/gimp12/share/gimp/1.2/brushes/SketchBrush-16.gih"
>   /opt/TWWfsw/gimp12/bin/gimp: Failed to load one of the brushes in the
>   brush pipe
>   "/opt/TWWfsw/gimp12/share/gimp/1.2/brushes/SketchBrush-32.gih"
>   /opt/TWWfsw/gimp12/bin/gimp: Warning: Failed to load brush pipe
>   "/opt/TWWfsw/gimp12/share/gimp/1.2/brushes/SketchBrush-32.gih"
> 
>   $ ls -ld /opt/TWWfsw/gimp12/share/gimp/1.2/brushes/SketchBrush-64.gih
>   -rw-r--r--1 root sys20818 Dec 26 22:32
>   /opt/TWWfsw/gimp12/share/gimp/1.2/brushes/SketchBrush-64.gih
> 
> The fix is to revert to data/brushes/SketchBrush* from 1.1.32. Any
> reason the version of these three files in 1.2.0 is different than
> from 1.1.32?

Yes, the old format was braindead and while the new is still bad,
it does not suck that much. We tried to keep backward-compatibility
with the old format and this piece of code might bite you here. 
I can not reproduce the problem here, but you could help me to locate
it by explicetely checking if you can load and use the pepper.gbr
file (which provides the "Pepper" pixmap brush).


Salut, Sven

Re: Problem building an gimp-1.1.32 RPM

[Sven Neumann]

Henning Sauer <[EMAIL PROTECTED]> writes:

> today I tried to build a an rpm of gimp-1.1.32 from the source via
> "rpm -ta gimp-1.1.32.tar.bz2", but it didn't work because in the
> installation phase it couldn't find the gimp executable in the
> /usr/bin directory under BuildRoot. Instead the gimp exectuable as
> well as the plug-ins, modules and libraries where directly installed
> to /usr.
> Is their a way to correct this behaviour and build an RPM ?

Yes, there is indeed. Someone needs to correct the spec file that
is distributed with The GIMP. This file is unmaintained at the 
moment and I wonder if we should probably remove it from 1.2 if
noone takes care of fixing it.


Salut, Sven

Re: gimp 1.1.31-32 BUG

[Sven Neumann]

[EMAIL PROTECTED] writes:

> I have just downloaded 1.1.31 and 1.1.32 patches from ftp.gimp.org
> 
> I notice that 'TODO' file has been updated to show some things that will
> happen with Gimp.
> 
> However, I don't see any mention of "improved keyboard operation",
> i.e. the stuff that generated quite a bit of hate mail on this exact list
> a few weeks ago.  I have to admit though, as soon as the discussion
> shifted into intelligent suggestions, everyone dropped out real quick.
> 
> Still, I think being able to operate a program from keyboard is very
> important even if this program is a mouse-oriented graphics tool.
> 
> Especially since it has been mentioned in the last few posts on this
> subject that this would affect things like shortcuts, and cause them to be
> reassigned using common sense, and not first-come-first-serve method that
> has been used up until now.
> 
> I hope this bug gets fixed as soon as possible! :>

first of all we need some changed in GTK+. So you would probably do better
by sending a mail to gtk-developer mailing-list. Of course you are right and 
the keyboard stuff should go into the TODO. I'll try to remember adding this
the next time we touch the TODO.


Salut, Sven

Re: Request To Revert Curve Tool

[Sven Neumann]

Hi,

David Hodson <[EMAIL PROTECTED]> writes:

> After some offline discussion with Garry, we have jointly agreed
> to propose the following (my wording, don't blame him):
> 
> The curves and levels tools should reset when called, and this
> behaviour should be reinstated before 1.2.
>
> Comments?

Agreed. I have tonight added the necessary change to make the
curves tool display the initial state when the dialog pops up. 
I have only done this change since I thought the new behaviour
would stay. But please do as you suggested and reinstate the old
behaviour. And please ... do it very soon! 


Salut, Sven

Re: RFC: The future of The GIMP

[Sven Neumann]

Hi,

Lourens Veen <[EMAIL PROTECTED]> writes:

> All true, but then the problem is that non-technical users have to wait
> for someone (or their favourite distribution) to package new plugins.
> IE, let's say I write a new plugin, put it on plugins.gimp.org in source
> form. Then Joe User can't use it until Red Hat releases an updated rpm,
> which may take a while. With the automatic building the plugin is
> instantly available.
> 
> For distributing, this makes sense, but what about updates? I don't
> think anyone would want to download a whole new tarball just to get one
> new plugin. And if you're going to do separate tarballs, then what's
> wrong with also creating a standard automated way to build and install
> them?

What's wrong with letting the distributors do their job and let them 
take care of creating binary packages? I doubt we have the possibilities
to support all the various platforms out there. By releasing seperate 
tarballs we'd make it very esay for distributors to package plug-ins. 

If plug-in authors want their plug-in to be binary distributed, they should
have the possibility to put up binary packages to the new registry as well. 
I do not think we should try to create a new binary package format however. 
Let's see what the future brings. Eventually distros will converge to one 
format anyway.


Salut, Sven

Re: RFC: The future of The GIMP

[Sven Neumann]

Hi,

Jon Winters <[EMAIL PROTECTED]> writes:

> We should keep in mind that the vast majority of Gimp users are not
> compiling from source.  A shell script is not something those folks
> understand.  Their reaction will be... Heh.. Where are all the plugins,
> this sucks!

Please keep in mind that the main intention of our proposal has been to 
better distribute work between core and plug-in developers by seperating 
the source trees during development. Perhaps this scheme could be translated
to distribution too, but it does not have to. If we decide to continue to 
distribute an awful lot of plug-ins with The GIMP as we do know, we can 
always put them all into one tarball at release time. Or several smaller
tarballs, or a single for each plug-in ... 



Salut, Sven

Re: RFC: The future of The GIMP

[Sven Neumann]

Hi,

Tino Schwarze <[EMAIL PROTECTED]> writes:

> Why would you want to reinvent the wheel? Follow Unix philosophy: Use
> tools which are already there.
> 
> I propose:
> 1. let the user use the package tool she wants
> 2. make plugins relocateable (I guess, not only RPM can do that)
> 3. provide easy integration of any additional files (help, data etc.) by
> means of directory structure etc.
> 
> We do not need to care how one gets those Plugin packages. We do not
> need to care for depencies (we should however propose a standard way to
> name depencies). 

I aggree. It shouldn't be our task to think about binary distributions.
We brought up the issue because we think that having all plug-ins in the
main tree does not make sense in the long run for the following reasons:

- The core maintainers shouldn't have to care about maintaining plug-ins.
- The plug-in authors shouldn't have to worry about the gimp core. 
- Bug reports, patches, etc. should go to the plug-in maintainers directly
  instead of being handled by the core developers.
- Gimp gets too large with all the plug-ins included (think of package 
  size and overlhy crowded menus).

I do not think that the current approach of using a sourceforge 
gimp-plugins module is a good idea. The core and the plug-ins should be
on the same CVS server. This would allow us to include core plug-ins 
virtually into the main gimp CVS tree and it will make it easier for 
core developers to apply changes to a whole bunch of plug-ins that 
become necessary after an API change in libgimp. If gnome-cvs can not
do this for us (because it only has all-or-nothing permissions), we
need to look for another CVS server. Eventually our employer 
convergence could help, I'll ask.

> We just need to care for a place to install the plugins
> in so that Joe User is able to install a binary plugin without root
> access.

We already have that: ./gimp-1.2/plug-ins 
and we have a tool that helps with from-source installation of simple
plug-ins: gimptool. What we should think about are some rules all
plug-in packages have to follow to make it easy to compile, install
and package them. A description file should be part of these rules.
Another thing that should be mandatory is that each plug-in needs to 
have a maintainer.


Salut, Sven

Re: [nick lamb] UI again

[Sven Neumann]

[EMAIL PROTECTED] writes:

> Hey, that's -YOUR- window key.  Throughout this thread I felt like I was
> always being talked down because these are -MY- ideas.  Nobody wants to
> hear them because they are -PERSONAL- and -YOU- don't -LIKE-
> them.  Instead, why not make things like that configurable?  That
> preferences dialog needs to be unkludged, and how about seeing an option
> like:
> 
> "[x] Grab Win95 keys for Gimp"
> "Use [ Windows ] key to invoke the root menu"
>  [ Menu]
> 
> Naturally, clearning the "Grab" checkbox would disable the selection
> below, so those of you who assign the "Menu" key to your window manager,
> are still happy.
> 
> What do you think?

I think it will not work. Your ideas are not actually new and we have
discussed this stuff a lot coming to the conclusion that it's not that 
easy. 

> The whole preferences thing could have a new subtree entitled "Keyboard
> control" where one would choose things like the above Win95 key
> assignment, enabling/disabling of underline accelerators, etc.  Then
> instead of complaining about -MY- bad preferences, you just disable them,
> and use your mouse.

It could have, but only if someone would write the code. Complaining
about missing features is not the way Free Software works. I do not
have a windows key on my (pretty new) keyboard and I'm very happy that
this is the case. I will certainly not add support for that key. If 
someone else does and manages to keep Gimp useable for people that do
not have that key, that's fine with me. 

Now shut up, start coding and submit your patches to ftp.gimp.org.


Salut, Sven

Re: [Sven Neumann] Assistance with GUI design

[Sven Neumann]

[EMAIL PROTECTED] writes:

> I am rather shocked.  For someone who doesn't really know me, that's some
> pretty bold statements.  But then again, I've come to expect that from
> you, dear Sven, so I don't really take it too seriously.  You are still
> upset from when I called you an asshole about a year ago. :)

I think I know you good enough from the various provocative statements
you made in various places on the web insulting the members of the Free 
Software community. I must admit that I always had a good laugh at your 
statements and I'm not taking you really serious. You can continue to 
call me an asshole without any problem at my part. I just refuse to work 
with you since I do not like the style you use to propose your ideas 
even though you made some good points.

> On the side note, one thing that could use serious serious improvement is
> the preferences dialog.  I think, the "Tree" structure of organizing
> preferences is truly confusing.  Reserve tree structures for directory
> lists and things like that.  Someone using the Gimp for the first time
> would expect preferences dialog to look something similar to a tabbed
> notebook where each setting is grouped by section, which occupies one tab
> of the notebook, etc.

We had this design before and switched to the tree structure since the
notebook interface simply didn't work. A lot of other programs (not only 
GNOME) are using the same interface (Netscape, Mozilla for example) and
IMHO it's a good way to present the user with a large amount of 
configuration options.


Salut, Sven

Re: Some Compile Error 1.1.30

[Sven Neumann]

Hi,

Frank Werner <[EMAIL PROTECTED]> writes:

> i have problems to compile gimp-1.1.30.
> I have installed glib-1.3.2 and gtk+-1.3.2.
> 
> Can someone tell me, how can I solve this problem?

The INSTALL file clearly states that gimp-1.1.x will not compile with
the developers versions of glib and gtk+. Use version 1.2.8 instead.


Salut, Sven

Re: new plugin

[Sven Neumann]

Hi,

david rohde <[EMAIL PROTECTED]> writes:

> I am currently writing a new plugin, which I hope if there is intrest in it
> could be included in to standard gimp distributions.  I understand that the
> gimp is frozen at the moment, but if anyone could tell me the process
> required for a new plugin to be considered for the gimp.  Should I have
> users before I ask you guys to look at it.

It's definitely too late to get it included into gimp-1.2. We can consider 
it for the 1.3.x development series, but I think we should think about a 
new system to distribute plug-ins anyway. Including more and more plug-ins 
with the standard gimp distribution does not make much sense and slows down 
development considerably. I'll come back to this issue in the "Future of 
The GIMP" document I'm preparing with Mitch right now.


Salut, Sven

Re: How much longer do I have to put up with this shit? (This is NOT a troll)

[Sven Neumann]

Hi, 

Zachary Beane <[EMAIL PROTECTED]> writes:
> On Mon, Dec 11, 2000 at 02:31:13AM +0900, [EMAIL PROTECTED] wrote:
> 
> > * Contents of about half of the dialog boxes seems to be entries in a
> >   contest for the next century's ugliest user inteface.  What ever
> >   happened to uniform interface?
> 
> I'm sure assistance in redesign would be greatly appreciated. Mocking
> up sane designs would be extremely helpful.

I'm pretty sure that we can live better without timecops assistance. A lot
of people that work a lot with The GIMP have contributed their ideas of a
nice and usable GUI and should continue to do so. We all know that we can 
still improve a lot, but we can certainly do better without people like 
him.


Salut, Sven

Re: 1.2 and beyond

[Sven Neumann]

Hi,

Robert L Krawitz <[EMAIL PROTECTED]> writes:

> What are the plans for maintenance of 1.2?  At some point (long before
> 1.4), we're going to do a gimp-print 4.2; it may even happen in 3
> months or so if the quality (particularly color) improvements outrun
> the rest of the development projects.  Will there be any kind of
> release train such that there will be a convenient way of getting
> something into later versions of 1.2, or will everything be happening
> in 1.3?

As Mitch already pointed out, bug fixes will go into the 1.2.x branch.

We think about having a 1.3 branch which should lead into a stable 1.4
release. The goal of this branch will be to cleanup a lot of the gimp's
internal structures to make it easier to port that stuff to gimp-2.0.

The gimp-2.0 development should begin at the same time but it might take
some time before a useable application with comparable features evolves
from this effort. As we do not intend to keep the plug-in API backwards
compatible in 2.0, some parts of gimp-print will have to be rewritten
at some point.

I'm actually preparing sort of a RFC for "The future of GIMP" which I
want to present to this list pretty soon.


Salut, Sven

Re: [PATCH] improving on i18n

[Sven Neumann]

  Zbigniew Chyla <[EMAIL PROTECTED]> writes:

> This patch _fixes_ GIMP translations. Currently it's _impossible_ to
> correctly translate GIMP to any slavic language (and probably many others).
> Polish GIMP users keep saying "Can you speak Polish? Translation is broken!"
> and the only thing we can say is "Sorry, it's developers' fault, but please
> wait another 1-2 years for GIMP 1.4/2.0 release and hopefully it will be
> useable".
> Patch is extremely simple, it doesn't touch existing code at all. Why don't
> you like it?

I have discussed your patch with Mitch and it really looks safe. The 
problem we see is that most likely translators will find a lot of 
collisions and each string marked with your Q_ macro will end up being
untranslated in all languages until translators change the po-files
again. Since we want to release 1.2.0 real soon now this change would
significantly degrade the status of i18n we have reached so far. I suggest
we reconsider applying your patch after 1.2.0 so it could become part of
the 1.2.x series but early enough before a release to give translators a 
chance to update translations. To do so we'd need a list of colliding 
strings from all translators as soon as possible.

I'd still prefer a clean solution that would give every translator the
chance to apply different translations for every string without the need
to change the original string. This would make it possible to work around
collisions without breaking the translation for all other supported
languages.


Salut, Sven

Re: [PATCH] improving on i18n

[Sven Neumann]

Hi,

  Zbigniew Chyla <[EMAIL PROTECTED]> writes:

> On Tue, 2000-12-05 at 16:01:17, Sven Neumann wrote:
> 
> > Probably a good idea, but I doubt we can count this as a bugfix. We 
> > should consider integrating a fix like this after the 1.2 release.
> 
> This patch _fixes_ GIMP translations. Currently it's _impossible_ to
> correctly translate GIMP to any slavic language (and probably many others).
> Polish GIMP users keep saying "Can you speak Polish? Translation is broken!"
> and the only thing we can say is "Sorry, it's developers' fault, but please
> wait another 1-2 years for GIMP 1.4/2.0 release and hopefully it will be
> useable".
> Patch is extremely simple, it doesn't touch existing code at all. Why don't
> you like it?

Because we are very close to the stable release we are working towards for
over a year now. I18n is its final state for months and noone complained 
about it recently. Every time we changed stuff with respect to i18n, it 
produced lots of problems and I'm very happy that it seems to be working 
for most people now. We are not going to change anything here before 1.2.

> > But actually I would prefer a real solution instead of something hacked
> > around gettext. 
> 
> What do you expect me to do? Create replacement for gettext? 

Actually yes. I hope that a better system than gettext evolves so we can
use it for the 1.3.x series.

> I want GIMP _1.2_ to be correctly translated and I don't see any other 
> proposals besides my patch.

Sorry, I don't see any solution either. It's simply too late to fix this
know.


Salut, Sven

Re: [PATCH] improving on i18n

[Sven Neumann]

Zbigniew Chyla <[EMAIL PROTECTED]> writes:

> As you probably already know there are lots of problems with current i18n
> tools. Every genuine inscription can have only one equivalent in particular
> language when using gettext. In the case of GIMP this is really serious
> problem because of huge .po files (and thus many collisions).
> The authors of Freeciv worked out an easy method of the partial solving this
> problem. My patch is based on code from Freeciv.
> Every string marked for translation can be preceded with a prefix in the
> form "!prefix!". Thanks to this prefix, two appearances of the same
> string can have different meanings. The prefix can be omited in
> translated string, but leaving it will not influence displayed text because
> it will be always stripped (it is helpful for translators who don't know
> this solution). You should just use Q_() macro instead of _() in your code
> to use this feature.

Probably a good idea, but I doubt we can count this as a bugfix. We 
should consider integrating a fix like this after the 1.2 release.
But actually I would prefer a real solution instead of something hacked
around gettext. 


Salut, Sven

Re: use of the Delete key on Dec keyboard or similar

[Sven Neumann]

Olivier Lecarme <[EMAIL PROTECTED]> writes:

> Now you only need to get them Gimp developers to make it so :). (I'm not
> a real full-time developer, I'm just on the list because I fixed a bug
> not so long ago)

GIMP does not do anything about key mappings and it will never do. 
Configure your X-Server correctly and you're done.


Salut, Sven

Re: layer_get_offests(layerId, &x, &y);

[Sven Neumann]

Maneesh Yadav <[EMAIL PROTECTED]> writes:

> No one knows how to get the offsets for a layer from libgimp do they?

Yes, we know. Since a layer is only a special kind of drawable, the
following call will perfectly do:

gboolean gimp_drawable_offsets (gint32  drawable_ID,
gint   *offset_x,
gint   *offset_y);


Salut, Sven

Re: [newbie] 1.1.29 build problem

[Sven Neumann]

Mats Nygren <[EMAIL PROTECTED]> writes:

> Probably this is the wrong place but I know no other.
> 
> Having downloaded the gimp and built it the following message
> is written several times at startup:
> 
> Gtk-WARNING **: Unable to locate loadable module in module_path:
> "libpixmap.so", 

This is a problem with your gtk+ themes settings, not a gimp problem.
Either stop using themes based on the pixmap-engine or include the
proper path to libpixmap.so as module_path in your gtkrc.

> I also failed getting Python in it but that's not immediately
> important.

Python support is not build by default and IIRC it's not a trivial task 
to get it to compile.


Salut, Sven

Re: [PATCH] Gimp-Print locale

[Sven Neumann]

Zbigniew Chyla <[EMAIL PROTECTED]> writes:

> Gimp-Print uses non-existant textdomain. Attached patch fixes this. Is it OK
> to commit?
> 
> 
> Zbigniew
> --- gimp/plug-ins/print/print.c.cyba  Tue Nov 14 19:29:01 2000
> +++ gimp/plug-ins/print/print.c   Tue Nov 14 19:25:06 2000
> @@ -327,7 +327,7 @@
>  ;
>  #endif
>  
> -  INIT_LOCALE ("gimp-print");
> +  INIT_LOCALE ("gimp-std-plugins");
>  
>/*
> * Initialize parameter data...

Nope. Please do not commit this. You are correct that the code is wrong
and your fix is fine, but we want to be able to use the same files as
the gimp-print package ships with. I will hack a better solution using
compiler defines in the Makefile to achieve this goal. Thanks for reporting
the problem.


Salut, Sven
 

Re: blury picture

[Sven Neumann]

robert lund <[EMAIL PROTECTED]> writes:

> I AM NEW TO THIS KINDA. I AM MAKING A SHIP FOR A GAME CALLED XSHIPWARS WHICH 
> REQUIRES A ROTATION OF THE PIC 22.5 DEGREES UNTILL IT GOES ALL THE WAY 
> AROUND TO 360 SO YOU END UP WITH 16 PICS OF THE SAME SHIP BUT JUST IN A 
> DIFFERENT POSITION. MY PROBLEM HOWEVER IS WHENEVER I TRY TO ROTATE IT THE 
> PICTURE BECOMES BLURY EVER SO SLIGHTLY. WHAT AM I TO DO?

This effect is unavoidable. You can disable Smoothing for the rotation
but I guess you will not be happy with the result. If you want perfectly
rotated objects, you'll have to use a vector-based application like
Sketch or Sodipodi and export the results into a pixel-based image format.

Oh, and you should turn off Caps-Lock ...


Salut, Sven

Re: signal handler problems in screenshot plug-in

[Sven Neumann]

Hi,

[EMAIL PROTECTED] (Raphael Quinet) writes:

> I took a look at bug #27786 "screenshot plugin on Solaris takes bus
> error on exit" because I wanted to see if I could reproduce it.  Well,
> I got another problem: the screenshot plug-in exits with "xwd didn't
> work" before giving any results.  If my followup message makes it to
> #27786 (http://bugs.gnome.org/db/27/27786.html), you will read that
> xwd does work but the plug-in thinks that it doesn't.  As a result, it
> exits prematurely and leaves the temporary files in the user's dir.
> 
> I tried to debug this and I finally came to the conclusion that
> waitpid() fails because the SIGCHLD signal handler installed by
> libgimp steals the return status of the xwd child before waitpid() in
> screenshot.c has a chance to get it.  In libgimp/gimp.c, the signal
> handler gimp_plugin_sigchld_handler() calls waitpid() in a loop and
> throws away the child status before returning.

> I think that the best way to fix the screenshot plug-in is to add this
> before the call to fork():
>   gimp_signal_private (SIGCHLD, SIG_DFL, SA_RESTART);
> (don't forget to #include )

This seems to work fine (at least under Linux). I'm only wondering why
the gz, bzip2 and mail plugins do work under Solaris then. Or is this
not the case ?


Salut, Sven

Re: GIMP help docs

[Sven Neumann]

Hi,

[EMAIL PROTECTED] (Raphael Quinet) writes:

> Hmmm...  Looks like we need a couple more beta releases before 1.2. ;-)

Nope, the new help system will most probably be integrated after 
1.2.0 was released. There's no point in waiting any longer.

> But I am wondering...  What's the point in maintaining a Gimp-specific
> help browser? 

Since we think it's nice to have a fast and small (screen estate) 
browser for the gimp help files. The help files will however stay
usable from any HTML-browser out there.


Salut, Sven

Re: GIMP help docs

[Sven Neumann]

[EMAIL PROTECTED] writes:

>  This is now the case: The help is completely converted now and we found
>  a way to compile it very nicely. We just need to integrate it now and get
>  Sven to add some of the promised new and necessary features to the helpbrowser.

If you want me to change the helpbrowser, I need a detailed list of the
changes that are necessary.


Salut, Sven

Re: Gimp tool icons

[Sven Neumann]

Zolan Davis <[EMAIL PROTECTED]> writes:

> It isn't urgent but this seemed the best place to ask. If not, please provide 
>alternative.
> 
> Please tell me the rationale behind having the drawing icons point downwards.
> 
> On my desk, the monitor is above the mouse, and my other applications reflect this.
> Far from becoming one with the brush, the Gimp arrangement seems to exaggerate 
>indirectness;
> We have to work out where the hot spot is going to be from operation to operation.
> 

Try to use the new Crosshair cursors which can be enabled in the Preferences
dialog. IMHO they are much nicer to work with and should eventually become
the default.

> But just in case, let me know how I can change the icons. I'm using v 1.1.19 on W'98 
>(yes, a bit dodgy, but I'm getting there).

If you want to change the cursors, the files are in the cursors directory in
the gimp source tree. You will find an .xcf file there that contains all 
cursors. The GIMP xbm plug-in allows you to set the hotspot when saving.


Salut, Sven

Re: build problems from cvs

[Sven Neumann]

Marc Lehmann <[EMAIL PROTECTED]> writes:

> On Fri, Nov 03, 2000 at 08:12:07AM +0100, Marc Lehmann <[EMAIL PROTECTED]> wrote:
> > Since quite some time I get spurious errors while building gimp:
> 
> sorry, found it (I am not sure that is, I just checked out the build module
> in gnome and moved it into the gimp tree. Is that correct??)

Yup. If you do a fresh checkout of gimp, you get the build directory too.
It's a virtual module included in gimp.


Salut, Sven

Re: [gimpwin-users] gtkrc

[Sven Neumann]

Hi,

Tor Lillqvist <[EMAIL PROTECTED]> writes:

> It used to be posssible to have a user-specific gtkrc file for GIMP,
> in the user's .gimp1.1 directory (_gimp1.1 on Windows), but apparently
> this has changed at some time. (I had not noticed.) The user-specific
> gtkrc file that user_install (.bat) copies from the gtkrc (_user) file
> is not used at all. The GIMP's gtkrc file is now supposed to be a
> common one for all users of a GIMP installation.

This is a bug and I have just added the missing lines to parse the
users gtkrc (as found in ~/.gimp-1.1) after the systemwide gtkrc is
parsed. Tor, please check out gimp from CVS and check if it works for
the windows version too.


Salut, Sven

Re: exec-prefic in systemwide gimprc

[Sven Neumann]

Hi,

Sascha Luedecke <[EMAIL PROTECTED]> writes:

> I have a multiplatform installation of gimp.  Though one can specify
> --prefix and --exec-prefix to configure the sources and thus the
> installation, the separation is not 100% clean.
> 
> The file 
> 
> /etc/gimp/1.1/gimprc
> 
> contains the hardcoded exec-prefix which IMHO is a bad thing, since it
> will be set to the last platform one installed GIMP for.  GIMP then
> cannot load plugins when started on a different platform.
> 
> My workaround is to define system specific aliasesÖ
> 
> gimp --system-gimprc 
> 
> and maintain two gimprcs.
> 
> I think this should be changed.  What is your opinion?

Could you please explain how this should be changed in your 
opinion. 

IMO we do The Right Thing (TM): system-dependent configuration
files are stored in ${sysconfdir}/etc. Your workaround looks
like a very clean way of handling multiple installations and
I do not see what gimp could do to make it more convenient.


Salut, Sven

Re: Pb with the display of the Gimp Toolbox (1.1.28)

[Sven Neumann]

Ludovic Poitou <[EMAIL PROTECTED]> writes:

> I'm facing a pb with the way the toolbox is displayed. I've had this pb
> with the 1.1 versions, and it's still there (1.1.28).

Just to make sure: Have you tried to remove the file 
~/.gimp-1.1/sessionrc? Please report back if this helps or if
the problem continues to exist.


Salut, Sven

Re: [patch] Wishlist #7100 (create layer mask with layer as content)

[Sven Neumann]

Hi,

Andreas Jaekel <[EMAIL PROTECTED]> writes:

> I have just patched gimp-1.1.28 so that it now can do
> what is registered as wish list item #7100
>   #7100: [Wishlist] layer mask initialization
> in the bug database. (meaning, you can create a new
> layer mask and initialize it with a (desaturated) copy
> of the layer's content)
> 
> Whom do I send this patch to, and did I use the prefered
> patch format?

It's perfectly OK to send small patches like this one to this
list. Another possibility is to upload it to ftp.gimp.org as
described in the README that you'll find in the incoming 
directory. The patch format is fine.


> What happens now?  ;)

Well, as my patch-criticm below explains I see only a few 
minor problems with your patch (from a first glimpse), but
we are very close to a 1.2 release and I'm undecided if I 
your change can be considered as a bug-fix... 


> diff -r -u gimp-1.1.28/app/layer_cmds.c gimp-1.1.28-a/app/layer_cmds.c
> --- gimp-1.1.28/app/layer_cmds.c  Thu Jun 22 05:23:18 2000
> +++ gimp-1.1.28-a/app/layer_cmds.cThu Oct 26 13:37:19 2000

don't edit files in the app directory ending on _cmds.c. They're
autogenerated from their counterparts in tools/pdbgen/pdb. Edit
the pdb file and run make in the toplevel directory.

> +   if(has_alpha)
> + { // apply layer alpha to mask
  ^^
No C++ comments allowed in our code!!

> +   gray = (rgb[0] + rgb[1] + rgb[2]) / 3;

This is plain wrong. Use INTENSITY (rgb[0], rgb[1], rgb[2]) instead.

I'll have to look through the rest more carefully...


Salut, Sven

Re: Gimp gimp-1.1.28 (script-fu problem)

[Sven Neumann]

Hi,

Jeff Sheffield <[EMAIL PROTECTED]> writes:

> [jsheffie@kelly bin]$ ./gimp
> ^[[A./gimp terminated: Interrupt
> /opt/gimp/gimp-1.1.28/lib/gimp/1.1/plug-ins/animate_cells terminated:
> Interrupt
> ---
> animate_cells...??

animate_cells is a gimp-perl script, which makes me think that this
thread should be titled "perl-fu problem". The fact that the splash
says script-fu when gimp hangs most probably means nothing but the 
fact that the script-fu extension has been properly started, but
gimp hangs during initialization of the first plug-in, which seems
to be a gimp-perl plug-in in your case.

I suggest you make sure that there are only recent plug-ins in your
plug-in dir (probably the gimp-perl scripts are from an earlier
installation?). Then check that you run a compatible verion of perl
(ask Marc what that means and please ask him to put that information
into the README). If everything else fails, compile gimp with
--disable-perl. 


Salut, Sven

Re: Icon of color picker

[Sven Neumann]

Hi,

COUTIER Eric <[EMAIL PROTECTED]> writes:

> After Tobias Gärder message, i've tried to use color picker on the image and
> i've seen a little "bug" (it isn't really in fact) with the mouse cursor:
> when the mouse fly over transparent zone, the cursor become "pipette with
> forbidden panel". The problem is that in this configuration, the tip of the
> pipette is no more on the pixel.
> 
> A simple suggestion.

A not so simple suggestion since solving this problem involves a major
reorganization of the cursor code. A suggestion for a workaround is to
enable the "Tool Icon with Crosshair" cursor mode in the Preferences.
IMO this mode is much more useful than the default mode anyway.


Salut, Sven

Re: api break before release

[Sven Neumann]

Hi,

> Maybe it's just gimp-perl then. Maybe it's the fact that gimp-perl simply
> relies on all symbols, while gimp-print probably only relies on the most
> common (&small) subset. In that case, most probably only gimp-perl is hurt...
> Which might also be the only plug-in where the community has considerable
> need to be convinced that a new version of some tool is as stable as the old
> one (because people's income depends on working servers) before they switch.
> 
> Anyway, I *did* switch to the new API before writing my lament. I wrote
> that mail because I *do* think such an under-the-hood-change deep *within*
> the feature freeze is highly unconventional.

Marc, believe me or not, but there was no great API change. The symbols 
gimp-perl used to use have been mapped to the new API until recently by 
defines and typedefs in gimpcompat.h and gimpenums.h. Now these defines
are disabled by default and you can turn them back on with a small change
to your Makefile. The number of symbols you use from that set should be
totally irrelevant.

Maybe your problems to get gimp-perl going with GIMP_ENABLE_COMPAT_CRUFT 
defined were related to the fact that gimp-perl seems to prefer to use 
installed libgimp header files over the current ones in the source tree.


Salut, Sven

Re: api break before release

[Sven Neumann]

Hi,

>Are you sure? Why does it work for the gimp-print plug-in then?
> 
> We've been using the old names.  I ran Sven's conversion script to
> generate the new names, and put a whole stack of #define's in the one
> UI-related file that's shared between the 1.0 code and the 1.2 code.
> 
> It does make it harder to maintain the plugin for both releases,
> although not all that much so.

I was referring to the version of gimp-print that is included in gimp 
CVS. It was left unchanged by me despite the inclusion of the line 
#define GIMP_ENABLE_COMPAT_CRUFT in print_gimp.h. This seemed to work
very well. I'm happy however that you've decided to switch to the new
API. 


Salut, Sven

Re: resource management...

[Sven Neumann]

Hi,

> Secondly, I'm confused by the function gimp-file-save.  Specifically why do 
> I need to pass an image and a drawable?  If I load an image, do some image 
> level manipulations on it, and then want to save it with gimp-image-save, 
> do I need to create a layer?

most save plug-ins can not handle multiple layers and will therefore only
save the drawable you pass them and silently ignore the rest of the image 
(and the image_ID). Other plug-ins (gif for example) do something useful
with all layers (creating an animation in this example) and ignore the
drawable_ID.


Salut, Sven

Re: api break before release

[Sven Neumann]

Hi,

> While, in theory, I agree that having compatibility cruft inside a
> software package is bad, I think breaking compatibility deep within a
> feature freeze was a very bad idea.
> 
> I thought different this afternoon when I could just enable
> GIMP_COMPAT_CRUFT_STH, but it just turned out that this define only
> catches very few of the API changes.

There were no API changes at all. All of the names that are standard 
now have been around for a long time and the only thing we did was to 
reverse the logic of the COMPAT_CRUFT defines. What was 

#ifndef GIMP_DISABLE_COMPAT_CRUFT

before, has become

#ifdef GIMP_ENABLE_COMPAT_CRUFT

now. That's it! Nothing else changed!!

> So, in effect, the recent undiscussed changes completely break the API and
> make it impossible to maintain a plug-in for both 1.0 and 1.2 versions.

Are you sure? Why does it work for the gimp-print plug-in then?


Salut, Sven

Re: [Gimp-print-devel] libgimp COMPAT_CRUFT now disabled by default

[Sven Neumann]

Hi,

> Are you not cleaning up CAN_HANDLE_INDEXED and friends?

you are right, we should have done this earlier. I've done it now.


Salut, Sven

libgimp COMPAT_CRUFT now disabled by default

[Sven Neumann]

Hi,

in a final move to finish the 1.2 libgimp API we have changed the
logic of the COMPAT_CRUFT definitions in libgimp. The compatibility 
definitions from gimpcompat.h and gimpenums.h are no longer included
by default. Old plug-ins that use the 1.0 API will therefore not
compile against the 1.2 API. Those who are too lazy to perform
the trivial steps to port to the 1.2 API or who wish to keep backward
compatibility, can define GIMP_ENABLE_COMPAT_CRUFT before including
gimp.h and everything will be as before. Remember however that the
compatibility definitions will go away as soon as the 1.3 development
cycle starts.


Salut, Sven


PS: You can download a trivial sed script from 
http://sven.gimp.org/files/remove_cruft that might come in handy when
converting plug-ins to the new API.

Re: Help files

[Sven Neumann]

Hi,

> > Format issue 1: DocBook or HTML?
> > 
>  
> > Points in favour of DocBook:
> >  * Can be pushed to a variety of output formats with existing tools.
> >  * Is more searchable and indexable and whatnot, using hypothetcial
> > tools.  (If you can point to stable packages that index and
> > intelligently search docbook, I'll take that "hypothetical" back.)
> 
>  That's not the point, but you can also automatically create
>  crossreferences and also something like:
> 
>  Sorry, this page hasn't been written in  yet. Would you
>  like to read this help in  instead?

As you might have noticed the creators of the help system have already
thought about that. The current help-system does not yet support 
multi-language
help files, but the current directory structure and the code should allow to 
add this feature anytime with little effort. Our plan so far was to use a 
simple
shell-script to create links to english pages where other translations are
not yet done.

AFAIK there is no DocBook browser and we certainly don't want to write one.
The format is not even intended to be browsed directly. Creating HTML from
it will (at least in the short term) be the right thing to do.

I'm all for using DocBook to create the help files if and only if the help
authors feel comfortable with it, someone who knows DocBook and all that 
stylesheet stuff volunteers to help and Yosh as the gimp maintainer gives 
his OK, since he will have to build the releases. I'll help as much as I
can to create the necessary framework. As you might have noticed we already
use DocBook-SGML to create the libgimp API reference.

> >1) This adds significantly to the time and tools the maintainer
> > requires to make a release. 
> 
>  Tools: yes, Time: I doubt that. Automatically processing text makes
>  things faster not lenghtier...

If you would have ever used Jade, you'd know that it adds a significant 
amount of time. Processing SGML is a very CPU-intensive and time-consuming
task (at least with the available tools).

> >  2)
> >  Making the output look good will require a non-trivial amount of 
> >   work on the transformation stylesheets.  That's a relatively rare   
> > skill, so finding someone to do that might be difficult.
> 
>  It's not that hard. I could do that...

Do I read, you could do that, or you will do that??

> > Everyone probably agrees that we shouldn't have a different background
> > colour for every help page.  It might also be nice if there was some 
> > organizational consistancy from page to page.  Also, is there anything 
> > that shouldn't be in the help file, or should always be in seperate 
> > files?  For instance, should information about using the plug-in 
> > non-interactively not be displayed in the same file as the rest, to 
> > avoid exposing the user to "scary pdb stuff"?

I'd vote for a plug-in API reference separated from the normal users help.
This API reference could be automatically created from the plug-in sources.
But please let us concentrate on finishing the libgimp API reference before
we start another project.

> > "GIMP doesn't *need* help files to run, so they can be
> > distributed seperately."
> 
>  That's just a fraction of my argument. I've no problem with
>  shipping GIMP with online help. I just think it's better
>  to keep the source archive smaller since the onlinehelp shouldn't
>  depend on the source and thus can without any problem reside outside
>  of our maintree which would make maintainance easier IMHO...

What advantage would we have if the help files are stored separately if
the release is going to include it anyway? Anyway, the one who creates
the releases should decide that.

Now to a few things Kevin pointed out in his first mail that I haven't 
dealed with so far:

> ** Speaking of the help browser:

> I don't really know what the qualities and status of gimp's help
> browser are, or why we have our own instead of passing the job to the
> user's favourite browser.  I vaugely remember some noise about "Oh, we
> need our own help browser because it is going to have special
> navigational things for our help architecture," so I let that issue
> slide, but since those people have largely signed off the project, do we
> need to re-think these questions?

The advantage of the helpbrowser plug-in is it's speed, small screen estate 
and small memory footprint. I guess a lot of people are very happy that they
do not have to use their "favorite" browser since it's a huge memory-eating
monster that takes ages to start if GIMP is already running. For those of
us that are happy with their browser, they can continue to use it. At some 
point we might consider adding another option, namely a gtkhtml-based
helpbrowser or interfaces to the GNOME and KDE help-systems. As all this
is implemented as a plug-in it should be trivial to do so.

> Egger argues, "GIMP doesn't *need* help files to run, so they can be
> distributed seperately." 

Re: GIMP Table Magic

[Sven Neumann]

Hi,

first of all: please stop posting HTML mail to this list.

> I was looking in the DB Browser, and noticed a function called =
> file-GTM-save. In the blurb, it says that it is called "GIMP Table =
> Magic", and it creates an HTML table from an image by slicing it up. =
> This is not unlike what Macromedia Fireworks does (in Fireworks, you can =
> slice up an image and create javascript rollovers from certain slices).

GTM is definitely not what you are looking for. It creates a HTML table
with uniformly colored table cells representing your image. You don't 
want to try that on a 800x600 image.

Try using guillotine or perl-o-tine. Both plug-ins slice the image along
guides and perl-o-tine even creates the HTML for you.


Salut, Sven

Re: Perl Scripting

[Sven Neumann]

Hi,

>  Perl normally should be there. But since the Perl plugin has never
>  really worked (greetings Marc! :) it's not a big phenomenon that 
>  it doesn't work for you... 

Sorry Daniel, but don't we don't need that kind of FUD here. If gimp-perl
is still not working for you, please let us know exactly what kind of 
problems you experience with it. I have the expression that gimp-perl works 
quite good on most installations.


Salut, Sven

Re: How many layers are supported?

[Sven Neumann]

> >I need this information to beat a Photoshop-user.
> 
> That would probably depend on the layer size, how much memory you've got, and a
> gazillion of factors. If you mean the theoretical max, I'd guess that's as many
> as your int size supports (ie. about 2 billion for a 32-bit machine), without
> ever having looked at the code itself.

IIRC, GTK+ limits us to 32768 layers. At least that's the maximum number of
layers the L&C-dialog can handle. This will change with GTK+-1.4 which moves
this barrier up to somewhere around 2^31.


Salut, Sven

Re: Bug reports

[Sven Neumann]

Hi,

> Can someone close the following bugs? I have reported this twice to
> [EMAIL PROTECTED], but no one closed them.
> #12303, #12302, #12298

Wouldn't it be easier to close them yourself instead of asking other 
people? Especially since closing them is simpler and less work.
You should read http://bugs.gnome.org/server-control.html.


Salut, Sven

Re: Hi, I'm here to scratch a scripting itch.

[Sven Neumann]

> you may want to invlove yourself in development of gimp 1.4 or 2.0 if you
> really want to make really big changes.

That's right. We won't accept any changes for Gimp-1.2 unless its an 
obvious bugfix and I'd even agree to declare the batchmode officially
broken and release 1.2 before we do major changes to the core. 
Noone can stop you from releasing patches (or a patched gimp) however.
 
Don't get me wrong: Any help is greatly appreciated and we will be very
happy to incorparate your changes into the 1.3 development branch once
we start it. 


Salut, Sven

Re: XCF code in Imlib2

[Sven Neumann]

Hi,

> I talked to Raster right after the first email arrived and he said he
> would take care of it. I was hoping to give him a running start before
> the ugly free software posse jumped him. I must say that this mailing list
> has degenerated into something akin to a Microsoft legal newsgroup. Shoot
> first, let god sort'em out.

hmm, did it really felt that way?? I must admit that a few people 
probably overestimated the problem and asked for immidiate actions 
when it was not yet time for it, but I believe that most of us stayed 
as calm as possible. I could have handled this differently in the first 
place by sending a private email to Raster, but since I haven't really 
contributed that much to this special piece of code, I thought it would 
be fair to announce the situation on gimp-devel and ask for advice.  

What exactly annoyed you that much about our response? As I've stated
in my first mail, it's not our intention to prevent anyone from doing 
an XCF loader. We have even aggreed to change the license of the 
relevant code when the gdk-pixbuf people asked us. But asking us before
you take the code and use it under another license is the absolute 
minimum. You shouldn't wonder that people get a little bit upset if
you don't follow those simple rules.


Salut, Sven

Re: Getting mouse coordinates from inside a gimp plug-in?

[Sven Neumann]

Hi,

> I think my question is:
> 
>   If I have an image loaded into gimp, and displayed in a window, and my
>   plug-in fired up, how do I get the coordinates of the mouse when one of
>   the buttons is clicked into the plug-in?
> 
> Here's what I want to do:
>   
>   I'm trying to write an "unplot" plugin.  The idea is to load a graph
>   image into the gimp (probably using a scanner), and then, using the mouse
>   to click on points on the graph, write the x and y values of
>   mouse-selected points to a file.  Thus, if I had a graph of, say,
>   voltage vs. current, I could digitize it manually using the plug-in,
>   obtaining a file with voltages and currents.
> 
> In order to do this, the plug-in has to be able to get the mouse
> coordinates when a button is clicked.  I think I know how to do that in
> a stand-alone gtk-based program, but I can't figure out how to do it
> from a gimp plug-in.  I guess the optimum coordinate system would be the
> local coordinates within the image window, but global coordinates of the
> underlying root window would probably be OK too.
> 
> Advice would be much appreciated.  I've looked in Kevin Turner's "Writing
> a GIMP Plug-in" tutorial, and in all the FAQ's I can find.  I've also
> looked in the plug-in registry for an existing plug-in I could snarf.  If
> the solution was in any of these places, I was too dense to realize it.

Well, the answer is that you can't! There is no way for a plug-in to 
notice what a user is doing in the image window. 

The only possibility you have is to ask gimp for a preview of the image
using gimp_image_get_thumbnail() or the complete image data using 
gimp_pixel_rgn_init() and friends, then render that image into your own 
GtkDrawingArea or GtkPreview and connect to the events they emit. 



Salut, Sven
   

Re: gDynText 1.5.0 is out!

[Sven Neumann]

Hi,

> I've finally released a new version.
> A lot of stuff was updated, I've tried to keep all the
> patches made to the
> gDynText 1.4.3 shipped with gimp 1.1.x.

Shall we update the version in gimp CVS or is this code considered
to be unstable compared to the version we ship with gimp now ?
There are a few bugs regarding the GDynText plug-in listed at the
gimp bugtracker. Does this version fix those problems?


Salut, Sven 

Re: License of the XCF loader in Imlib2

[Sven Neumann]

Hi,

> I would at first try to be a bit more friendly. I think, it is
> sufficient if one of the original authors writes an E-mail mentioning
> that Carsten forgot something and explaining what.
> 
> What he did was definitely wrong but he should be given a chance to get
> out of the issue without losing his face. I guess it was a mistake
> (though a nasty one).

I agree with this opinion and would be happy if we could set up a short 
email that we send to the Imlib2 people signed by some of the people
owning the copyright of the affected code. Since it seems not necessary 
to involve Peter and Spencer at this point, some of the people who have 
made changes to the code should be ok as senders. I'm short in time right 
now. Who wants to set up an apropriate email ??


Salut, Sven

License of the XCF loader in Imlib2

[Sven Neumann]

Hi,

yesterday night on #gimp someone pointed out that an XCF 
loader appeared in the Imlib2 CVS tree. I was curious,
checked out the source and had a closer look. 

There are two files, namely loader_xcf.c and 
loader_xcf_pixelfuncs.c, and as expected they contain 
code from the gimp tree, more exactly, from app/xcf.c 
and app/paint_funcs.c. The copyright header is however
missing from both files and only loader_xcf_pixelfuncs.c
has a small hint somewhere at the top that code was 
taken from the gimp source.

Imlib2 seems to be distributed under the X11 license. 
Since it is quite short, I have attached the text of 
the file COPYING as found in the Imlib2 source tree
so you can have a closer look yourself.

It's definitely not our intention to make life too 
hard for someone who wants to hack an XCF loader. This
has been clearly stated lately when the gdk-pixbuf
people asked us to allow to include the relevant code
under the LGPL license.

Simply using the code, removing the copyright notices
and putting it under a non-compatible license is however
too much if you ask me and we shouldn't let Carsten get
away with this. 
  
I'm not too deep into licenses and I hate to deal with 
legal questions. Could someone please step forward and
take care of asking Carsten to change the files and 
take legal actions if it becomes necessary ?!



Salut, Sven




Copyright (C) 1999 Carsten Haitzler and various contributors 

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to
deal in the Software without restriction, including without limitation the
rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
sell copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
  
The above copyright notice and this permission notice shall be included in
all copies of the Software, its documentation and marketing & publicity 
materials, and acknowledgment shall be given in the documentation, materials
and software packages that this Software was used.
   
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER 
IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Re: fyi: segv during rotate

[Sven Neumann]

> My gimp has crashed twice today, both times rotating a selection.  I'm
> using GIMP version 1.1.22 -- with a big mushroom-cloud "PRERELEASE" on the
> splash screen.
> 
> I suppose I'll change versions.
> 

Yeah, you better update to 1.1.23 since that bug has been fixed there.


Salut, Sven

Re: Greyscale crash

[Sven Neumann]

Hi,

> Does anyone recognise this? I'm fairly sure it's a brand new "feature"
> perhaps from recent patches to app/ ? If no-one recognises this I will
> file it through the normal channels, but since it looks like a fresh
> regression it seemed easiest to ask first.
> 
> 1. Create new _greyscale_ image
> 
> 2. Use a nice colorful pepper brush (you know, the demo color brush)
> 
> 3. Scribble all over the image, off the edges...
>[This being a memory scribble bug it might not work first time]
> 
> 4. Bang.

I can reproduce this. Multiple stacktraces show that the error
does not always occur at the same place but is always related to
tile memory. I have carefully checked the latest changes to app
that might cause the problem:

app/pixel_region.c 1.20
app/paint_core.c 1.90  app/paint_core.h 1.30
app/undo.c 1.60

and couldn't see any problems. I could reproduce the crash after 
reverting all those changes, so it seems the problem is elsewhere.


Salut, Sven

Re: compression parameters on re-save jpeg

[Sven Neumann]

> When I load a jpeg image (e.g. to turn it 90drg) which compression parameters
> got 
> it saved with using save (Ctrl-S). I assume the original once are not recorded
> in the image,
> so how could I be shure that the quality is perserved.

The quality can not be preserved since JPEG is a lossy format and will
always degenerate the image on each subsequent save. If I remember 
correctly, GIMP does indeed store the compression parameters with your 
image. If you use the "Save As" function you have the possibility to 
check and change the parameters. 


Salut, Sven

Re: The undo stack does not record some changes in layer attributes

[Sven Neumann]

Hi,

> Here is my proposal: save and restore all layer attributes (opacity,
> mode, keep trans, visibility) together with any operation that is
> currently put on the undo stack.
> 
> This means that if you do anything that starts an undo step
> (e.g. painting in the image), the current attributes of all layers are
> saved on the undo stack.  After finishing your painting operation, you
> can modify the visibility or mode of any layer and nothing will be
> saved on the undo stack... until you start another undoable operation
> and then the current layer attributes are saved again at the same time
> as the new undo step is created.  Later, if you undo the last
> operation, then the image is restored and simultaneously all layer
> attributes are reset to the values that they had before.

This sounds extremely similar to our proposal for the Undo system
of Gimp-2.0, where we will record changes to the context together
with the Undo information. 

The question is: do we really want to make this change now? This
won't be trivial and is likely to introduce new bugs. We could 
have a 1.2 release this month, or we start to hack the undo system
now and end up doing similar changes until the end of the year.
Is this change worth that effort? 



Salut, Sven

Re: The undo stack does not record some changes in layer attributes

[Sven Neumann]

Hi,

> > I would be very unhappy if changing the layer opacity from 100% to 50%
> > would eat up a dozen or more undo-steps since each value_changed signal
> > from the slider triggers an undo which causes another undo-step fall 
> > off the end of the undo queue. 
> 
> Oh, sure - that's clearly a bad idea.
> 
> I was thinking of only pushing the undo when you release the slider.
> That doesn't help those using the keyboard to nudge the slider though.
> 
> This could be done by pushing a group start on mouse down, and closing
> it on mouse up, for example.

Gtk+ is already prepared for that. Changing line 420 in 
app/layers_dialog.c to

  gtk_range_set_update_policy (GTK_RANGE (slider), GTK_UPDATE_DELAYED);

should do the trick without any fiddling with events. 

I still believe that it is a bad idea to waste undo steps for operations 
that don't save any shadow tiles. How hard would it be to change the 
undo system so that the number of undo steps is calculated only from
"real" undos? What about the idea of merging consecutive changes to the
layer attributes into one?


Salut, Sven

Re: The undo stack does not record some changes in layer attributes

[Sven Neumann]

Hi,

> Anyone else want to comment at this stage?  As a user, would _you_ get
> confused when you hit undo and all that changes is (eg) the layer
> opacity?

I would be very unhappy if changing the layer opacity from 100% to 50%
would eat up a dozen or more undo-steps since each value_changed signal
from the slider triggers an undo which causes another undo-step fall 
off the end of the undo queue. 

We could think about merging consecutive undo steps into one, but this
wouldn't work well for paintstrokes for example. Another possibility
would be to take only those undo-steps into account that save tiles. 
All other undo operations should consume so little memory that they
can be safely ignored.


Salut, Sven

Re: Performance of Gimp vs. photoshop for large images

[Sven Neumann]

Hi,

> at 4k x 3k for most things you do see the line comming
> down. its slow for hue/sat/lightness adjustments, and
> fastest for curves. i may try this on windows, but i
> think some of the others on this list have already
> beaten that horse enough.

Someone already mentioned it, but I want to repeat it again 
for clarification: Gimp-1.1.23 has a bug in the preview code.
The function that updates the thumbnails shown in the 
L&C-dialog is called for every pixel that is changed. Of 
course this slows down things considerably. This has been 
fixed in CVS.

As profiling the Gimp shows, there's the need and room for
optimization. Marc and Daniel did work on this last weekend
and hopefully we will soon see those changes in CVS.


Salut, Sven

Re: XCF loader for gdk-pixbuf

[Sven Neumann]

Hi,

Since I've touched app/xcf.[ch] too:

I hereby give my permission for anyone to use the portions of xcf.c
that I have written under the terms of the LGPL.

Please note that we consider to add a thumbnail of the image
composition to the XCF file format. This might even happen before 
1.2...


Salut, Sven

Re: [gimptool] Missing config.h/stdplug-ins.h

[Sven Neumann]

Hi,

> if I want to build a plug-in with gimptool from 1.1.23, I get for
> example
> 
> ps.c:62: config.h: No such file or directory
> ps.c:74: libgimp/stdplugins-intl.h: No such file or directory
> 
> gimptool --cflags
> 
> gives me
> 
>  -I/usr/local/lib/glib/include -I/usr/local/include -I/usr/X11R6/include
> 
> 
> stdplugins-intl.h has not been installed at /usr/local/include/libgimp.
> config.h not installed at /usr/local/include (would not be a good place
> although).

The behaviour is correct! gimp-tools is spupposed to be a tool to compile 
plug-ins outside the gimp source tree. Plug-ins that are not part of 
the standard distribution should never include stdplugins-intl.h, but
implement similar macros by themselves. Have a look at gimp-freetype
or gimp-plugin-template in CVS. 

config.h should of course not be installed since it is created by 
configure.



Salut, Sven

Re: gimp-plugin-template questions

[Sven Neumann]

Hi,

> What is the purpose of including src/plugin-intl.h in the template?
> Does #include "plugin-intl.h" do something 
> that #include  does not?

Yes, a lot! 

Actually plugin-intl.h as shipped with gimp-plugin-template is the 
equivalent to libgimp/std-plugins-intl.h which is included from all
plug-ins in the standard distribution.

plugin-intl.h includes  and builds a wrapper 
around the basic internationalisation macros defined their. 
By including it you get two macros:

INIT_I18N() and INIT_I18N_UI()

that do the dirty work of binding your application to the libgimp's
and its own textdomain. I'd suggest you take a short look into
plugin-intl.h, it should be self-explanatory.

> How are individual user installations supposed to work?  (is there a
> target that installs to ~/.gimp?)

I don't think so. Do we need to add that?

> are config.sub and guess necessary for most plug-ins?

AFAIK they are necessary if you want to use configure.


Salut, Sven

Re: Bugs?? on IRIX...

[Sven Neumann]

Hi,

> Do I post bugs here, or on some wunnerfull automated bug-tracking system??
> Am running 1.1.22 on SGI IRIX 6.5.8m with gtk 1.2.7.

Please check on http://bugs.gnome.org/db/pa/lgimp.html if your has already 
has been reported. You might also consider looking into the ChangeLog if
someone has fixed it in between (if you don't have CVS, you may for example 
use http://sven.gimp.org/1.1/gimp-ChangeLog.txt).

If your bug is unique, please report it using the bugtracker at 
http://bugs.gnome.org/ or use Xach's bugreport form:
http://www.xach.com/gimp/news/bugreport.html

Please do not report any bugs triggered by the invalidate_preview handler
(check the stack trace). I'm getting tired of closing those reports...


Salut, Sven
  

Re: BUG in color chooser

[Sven Neumann]

Hi,

> if you type in the hex value of a color the display will not be updated
> after pressing return.  Only by changing the color chooser, the hex/web
> color will be used.

Unfocusing the hex entry does the trick too (for example by pressing Tab).
I have nevertheless changed the code in CVS so that pressing Return 
updates the color too.


Salut, Sven

Re: SWF format...

[Sven Neumann]

> I've also seen some news that Corel Draw can export SWF files.  I'm not a
> big fan of Corel at all and I the Gimp is how I like to do things.

Flash is a vector format while GIMP is pixel manipulation program and 
most probably not the right app to author flash contents.


Salut, Sven

Re: Layer Dialog - Tree Structure??

[Sven Neumann]

>   Has anybody thought about implementing a hierarchy or tree structure for
> the layer dialog box? 

Yes, this is considered for gimp-2.0.


Salut, Sven

Re: Request for new, high-quality, brushes (and maybe patterns too)

[Sven Neumann]

Kevin wrote:

> As long as things remain well-linked both from and to gimp.org,

which implies that someone is actively maintaining the gimp.org site. If 
the few people interested and willing to do website design and website 
maintainance decide to perform their skills outside the gimp.org domain, 
noone is left to do the (sometimes boring) job of maintaining, updating 
and redoing the main site. That's the only problem I have with 
outsourcing gimp.org.


Salut, Sven
 

Re: Request for new, high-quality, brushes (and maybe patterns too)

[Sven Neumann]

> 
> He asked this very mailing list. [See attached] For just 
> one link. And while only Dr. Bunks can authoritatively 
> state the response he received, apparently it was zip.

It was never my point to say that the situation is perfect as is.
The only reason why I spoke up was that I wanted to speak for 
gimp.org. If there's a chance to get new people, new ideas, new 
spirit into gimp.org then the time is now.

> Perhaps only the IRC is the proper forum for gimp administrivia...

Sometimes it is, perhaps it shouldn't be. Everything can be 
changed...

> On the other hand, perhaps this is why we really, truly need 
> a gimp.org  webmistress/master - or a group that can make the role
> function - so as to realize requests such as this. That is the 
> true issue. As any number of posters have observed, bits can 
> live anywhere - who cares where they live. Sourceforge. gimp.org.
> Anyplace is fine by me. 

I do not at all insist on staying with the gimp.org server, but
I'd really like to see a more uniform namespace. And I do agree
wholeheartly with you that we need a group of people feeling 
responsible for gimp.org. 

> 
>  Original Message 
> Received: by u2.farm.idt.net for gosgood(with pop daemon (v1.21 1997/08/10) Thu Apr 
>13 20:35:10 2000)
> 
> 
> 
> What do folks think of adding either of these two resources to the Gimp?
> 
>   /Xtns/Web Browser/Gimp-Savvy.com --> http://gimp-savvy.com/
>   /Xtns/Web Browser/Grokking the GIMP  --> http://gimp-savvy.com/BOOK/
> 

I think it's a very good idea and as soon as those routers decide 
that I may reach cvs.gnome.org, I will commit this change. Sorry, 
that the mail was silently ignored in the first place. Sometimes 
it's hard to follow each and every mail on the list...


Salut, Sven

Re: Request for new, high-quality, brushes (and maybe patterns too)

[Sven Neumann]

Hi,

> Alternatively, why not put all of the Gimp on Sourceforge rather than
> trying to duplicate their effort?  

OK, probably I haven't enough experience with sourceforge. But could 
someone please explain me what effort you are talking about that would 
make it worse to use their service? Of course, provided the fact that 
you have a running web-service and DNS. 


Sourceforge is surely a great thing if you have a project and need a 
place on the web. But in our case we have a project and we have a 
place on the web. All we have to do is to find skilled volunteers, 
settle on a direction and do it.

> That doesn't prevent www.gimp.org
> from existing; you may even be able to DNS alias the appropriate
> *.gimp.org site to Sourceforge, although I'm not positive about that.

I'm sure that could be done. 


Salut, Sven