hello, i'm the gimp maintainer in mandrake linux distribution.

here're the patches i currently apply on gimp-1.2.3:

explaination note for a default that make perl programmers behave strangely with gimp. by default, gimp perl modules doesn't export functions, which makes perl programmers became fool ...

this one is needed so that perl plugins're able to be compiled :

this one forces the font selection dialog to only accept scalable fonts (which isneeded since gimp forces the dpi of the font to dpi of the image, and so fails on non-scalable fonts) :

latest releases of wget print "Resolving hostname... done" which broke some gimp assumptions (this patch also enforce old wget progress report):

i've also another patch that changes the dependancy on libmpeg to libbmpeg but i won't submit it to you since not all distributions've renamed mpeg_lib's libmpeg to libbmpeg (we did this in order to prevent a clash with kdemutlimedia)

see you

Sven Neumann writes:

explaination note for a default that make perl programmers behave strangely with gimp. by default, gimp perl modules doesn't export functions, which makes perl programmers became fool ...

I don't understand this patch nor the explanation you give. But then I don't know much about Perl.

one of my coworker tried one day to write perl stuff for gimp but got mad since he wasted two hours before understanding the doc was wrong since some stuff didn't got imported into namespace, which is what use is intended to do.

this one is needed so that perl plugins're able to be compiled :

what is it you want us to say here? Perl plug-ins don't compile for you?

yes. gimp-1.1.23 didn't fully compiles without this one, and since that day, we've always applied this patch.

this one forces the font selection dialog to only accept scalable fonts (which isneeded since gimp forces the dpi of the font to dpi of the image, and so fails on non-scalable fonts) :

this is only true if the user chooses to enter the size in Points.

you see, distro maintainer job is to make programs that works for everybody :-)

The gimp-1-2 CVS tree already has some changes that addresses this problem. See http://bugzilla.gnome.org/show_bug.cgi?id=58848

the bug really is that gimp try to apply image dpi to the font setting, and fonts don't provides/support all dpi settings. it'll work with "classic" dpi setting ... but not for everybody. if you create an image with a strange resolution *then* you'll enter the devil lands :-(

as far as i can see, this has nothing to do with anti-aliasing but the fact that gimp blindy try to force font to enforce the image resolution even for non scalable fonts which cannot do this by definition.
hence the patch.

well, that's your problem. Shouldn't KDE use another name since libmpeg has been around for longer? Or am I wrong here?

you're right: this is why i will never submit it to you as i said :-)

Could you please check Bugzilla for existing bug-reports regarding your problems and attach your patches to these reports or open new bug-reports. Thanks a lot.

humm. once the bug is spotten and a fix is availlable, i see no point to use such db but it's just my 2 cents.

Sven Neumann writes:

hi

demad dit!

one of my coworker tried one day to write perl stuff for gimp but got mad since he wasted two hours before understanding the doc was wrong since some stuff didn't got imported into namespace, which is what use is intended to do.

please file a bug-report then so I can ask the Perl gurus to have a look at it and to make sure we don't forget about it.

done

as far as i can see, this has nothing to do with anti-aliasing but the fact that gimp blindy try to force font to enforce the image resolution even for non scalable fonts which cannot do this by definition.
hence the patch.

your patch doesn't fix the problem since unconditionally disabling non-scalable fonts is not an option.

i won't claim the reverse: the real fix won't be as easy. but this prevents users to get tons of error messages when XFree86 detect the screen resolution instead of using default 72x72, or when the user set the X11 resolition or the gimp image resolution...

Could you please check Bugzilla for existing bug-reports regarding your problems and attach your patches to these reports or open new bug-reports. Thanks a lot.

humm. once the bug is spotten and a fix is availlable, i see no point to use such db but it's just my 2 cents.

well, you won't get anything changed in The GIMP if you refuse to use Bugzilla.

ok, ok, done even if i dislike web like interfaces.

It helps us a lot and we won't be able to handle the amount of bug-reports we receive without a bug-tracking system.

i can buy that even if my experience is that 90% of bugs tracked by such system belong to:
- non bugs
- help request
- assigned to random modules
- doesn't provides any useful information beside "XYZ sucks", sometimes with the useful reply-adress

You seem to forget that you ask for changes in the stable GIMP tree.

i can wait for a better fix in gimp-1.3.x. i would prefer gimp-1.2.x being fixed if feasable.

We can't do such changes without reviewing them extensively.

that's understandable.

Fixes tend to break stuff that used to work. It already happended often enough.

especially on critical packages such as kernel and the like :-(

We will certainly not accept any patches for 1.2 without them being submitted to Bugzilla.

ok, i followed your will.

Salut, Sven

kenavo :-)

Sven Neumann writes:

Of course well-done bug-reports make our life easier and the ones you've submitted don't fall into this category.

i love you too :-)

i'm open to enhancements ... i must admit i send bug reports very seldom but gots several ones on each day the Big Root offers us :-)

as for now, i didn't receive any info request :-)

But then Bugzilla isn't that easy to handle and you said already that you don't like web interfaces...

well, bugzilla.gnome.org has dead links and lacks a patch upload tool (unless i miss it but i don't see this possibility in submission form).

at least, it works with links :-)

and also, i've a strong mood against web interfaces, feeling faster to deal with mail/irc...
for all bug reports i got, mail reported ones were always faster to get good information/tests/... from.

anyway, my position is biaised since:

- as lots of the 200+ packages i maintain're (relatively) small/simple, they've few authors and it's easy and fast to works with them by mail.

- i deal with the communauty that exists around our permanent / perpetual / developement distro (cooker) through mail

in both case, we ended in relations with (well-)known people we can trust for ideas, enhancements, bug reports, ... (in both directions)

gimp doesn't exactely belong to such situation. but i can learn to deal better with the way the gimp devel team works :-)

Thierry Vignaud writes:

i'm open to enhancements ...

i've received some now, and i have to admit that coming back to the previous bug report in links is the best way to forget to change the title of the second one :-(

Sven Neumann writes:

well, my position in this thread is a bit biased since me and other GIMP developers have spent lots of their free time hunting down bugs that turned out to be caused by buggy GTK+ themes Mandrake used to ship.

which ones ? i've only got bug reports about crash caused by eazel gtk engine. if you want me to fix something, mail me :-)

Please excuse if I've sounded harsh, but you can upset most core gimp developers just by silently mumbling the word "Mandrake" when they're around.

i don't understant "mubling"

This is no personal offense and I promise I'll try hard to restore a neutral position regarding Mandrake.

well, our goal is the same: making the world better through free softwares, so if i can do something so that gimp developpers get happier, just tell me.

On Thu, 13 Jun 2002 03:17:55 +0200, "Thierry Vignaud" wrote:

Sven Neumann writes:

well, my position in this thread is a bit biased since me and other GIMP developers have spent lots of their free time hunting down bugs that turned out to be caused by buggy GTK+ themes Mandrake used to ship.

which ones ? i've only got bug reports about crash caused by eazel gtk engine. if you want me to fix something, mail me :-)

The details are in http://bugzilla.gnome.org/show_bug.cgi?id=55735 This has been fixed in Mandrake 8.0 one year ago, but we still got a duplicate bug report related to it this year. And it took a while for us to figure out that these apparently unrelated bugs were all caused by the broken GTK+ theme shipped in the default Mandrake distribution. Not a big deal, but annoying anyway...

This is no personal offense and I promise I'll try hard to restore a neutral position regarding Mandrake.

well, our goal is the same: making the world better through free softwares, so if i can do something so that gimp developpers get happier, just tell me.

Well, there are lots of things that you could do so that GIMP developers get happier. For example, I need a new PC. ;-)

On a more serious side, you could try to convince the KDE developers to avoid using the name "libmpeg" that conflicts with the original libmpeg that has been around for quite a while. This would avoid some compilation problems on Mandrake systems.

Raphaël Quinet writes:

The details are in http://bugzilla.gnome.org/show_bug.cgi?id=55735 This has been fixed in Mandrake 8.0 one year ago, but we still got a duplicate bug report related to it this year. And it took a while for us to figure out that these apparently unrelated bugs were all caused by the broken GTK+ theme shipped in the default Mandrake distribution. Not a big deal, but annoying anyway...

ok, i just looked at mandrake_desk changelog, we speak about the same bug, ie the eazel themes bugs...
you then know who dit it ... :-)

i didn't understant at first since you speak about "default mdk theme" whereas :
- the only bug of this specie i known whas eazel one - the installation just install some packages in each packages sections selected by the user in newbie installation. but this term was used by mdk updates team

well, our goal is the same: making the world better through free softwares, so if i can do something so that gimp developpers get happier, just tell me.

On a more serious side, you could try to convince the KDE developers to avoid using the name "libmpeg" that conflicts with the original libmpeg that has been around for quite a while. This would avoid some compilation problems on Mandrake systems.

[tv@ke rpm]$ urpmf libmpeg
kdemultimedia:/usr/lib/libmpeg-0.3.0.so kdemultimedia:/usr/lib/libmpeg.la
kdemultimedia:/usr/lib/libmpeg.so

the problem is that now they'll probably claim it'll break source compatibility... :-(
and worse, one of the kde project goal is to remains binary compatible in Y branch.
the question is: is kde's libmpeg only used in kdemultimedia ? if yes, this may be fixed in a simple manner.

i've already made them changed their mind when i was ImageMagick maintainer: mosfet just put ImageMagick in kde because he wanted to use an altered version of it ...
i noticed it immediatly whan it conflicted with libMagick5-devel :-(

hopefully they've stopped to do this. but others projects (eg mplayer) continue to "cvs_steal" other projects (but at least mplayer doesn't comew with shared libs that would conflicts)

Ça dépend du type d'opérations pratiquées par le médecin...

i won't translate for those who don't undertand french :-)