GNOME Bugzilla – Bug 153346
flame plugin should be updated
Last modified: 2018-06-17 18:07:24 UTC
the flame plugin in the gimp is based on code that is years out of date. the current flame renderer has a nice xml file format, much greater variety of shapes and colors, a higher quality, symmetries, etc etc. see http://flam3.com
i filed this against 2.0.1 because that is what i have on this fedora box, but i believe the cvs head has the same issue.
Given that the flame code seems to be very well maintained out there, shouldn't the GIMP plug-in perhaps better become part of the flame package? Or could the flame functionality be exported as a library so that the gimp plug-in could link it? We would have to maintain the GIMP specific code only then. Alternatively you can of course choose to maintain the plug-in code in the GIMP source tree. That would mean some code duplication though which would make maintainance more difficult.
when you say a library approach you mean to take the flame sources out of the gimp tree and have the flame plugin link with libflame? that sounds like the right thing. on my end that just means adding makefile targets that install flame.h and libflame.a files in standard locations, right? i will take this opportunity to cleanup the namespace. anything else?
Perhaps you want to add a pkg-config file (flame.pc?) for libflame. That would make it easier for GIMP and other apps to check for it.
btw., I just fell in love with electricsheep. What a wonderful project.
the flame code now has its own library with a clean namespace etc. the module name is "flam3" and it's hosted on sourceforge: http://sourceforge.net/projects/flam3/ this will be released as version 2.0 soon. still putting some finishing touches on. can you point me at an example of how to be compatible with pkg-config? ie how to tell autoconf to make & install a .pc file?
You could for example have a look at gimp. Or at glib if you are looking for a smaller package. Or look at this code for a smaller library that is using automake/autoconf and pkg-config: http://blinkenlights.de/dist/blib-1.1.7.tar.gz
thanks. i followed the example of blib & checked it in to flam3.
I did merge the new variations from flam3 into the plug-in for my own use... this is just a temporary solution, but for now It's ok, until something like libflame will be used in future gimp versions. Thanks Scott, for this great piece of code ! File saving and loading still works, also the old files can be load. The randomization also seems to be ok but may act strange sometimes. I attached the patch here, and I also posted it to the mailing list.
Created attachment 35203 [details] [review] gimp flame plug-in patch I'm very sorry ... here's the patch... Apply it to the plug-ins/flame directory in the gimp source tree
I don't think we should apply this patch. The right thing to do is to use libflame and now is the best time to do this.
Is there a Win32 binary of libflame, or would we have to create one first?
If it is just a static library, I managed to build it -
Scott, now would be a good time to do the changes to the Flame plug-in. Do you think we should depend on the library you wrote or would it be better to include a copy of it in the GIMP source tree and link it statically?
i think the library should be fine. can you handle updating the gimp code to call it? it would be significant work for me to compile the gimp. last time i tried i had to download a million packages and then couldn't get it to go.
Well, where's the library?
http://flam3.com/index.cgi?&menu=code if you have any trouble or find anything stupid, rather than work around it let me know and i'll change/fix the interface.
Perhaps I am just too stupid but I fail to see something like libflame at this page. I am also unable to find such a library in the debian repositories. If we let the flame plug-in depend on a library that isn't installed anywhere, we are effectively removing the plug-in. Perhaps the best thing would be if you shipped the GIMP plug-in with your source code. I guess it is more likely that people have the GIMP libraries and headers installed than the other way around.
there's a source code tarball there. if you make and install it, you get libflam3.a in addition to the executables.
So, it's a static library then which is probably not installed. And even if it is installed, it will not be commonly available.
no i wouldn't expect gimp users to have it installed. but i would expect gimp developers to install it. i don't understand the problem.
We don't do binaries, that's the problem.
Comment on attachment 35203 [details] [review] gimp flame plug-in patch It appears we would need a way to either 1 - include the sources to libflam3 in the GIMP (not a good option) 2 - Have libflam3 install a .so and headers, so that we can do a compile time check for its presence.
As Sven suggested above, there is also a third option: 3 - include the sources of the GIMP plug-in in the flam3 package and remove the plug-in from GIMP CVS Regarding libflam3, I don't think that the issue is to make it dynamic (*.so) instead of static (*.a). A static library is fine, especially for something as specialized as this. The main issue is that "make install" should install it and it should be included among the packages of some Linux distributions (maybe among the *-devel packages).
Optimistically setting to 2.4 milestone in the hope to catch someone's interest in doing this change.
Scott, any news on this? Is libflam3 packaged by any major distro yet?
Bumping to Future because this is not a blocker for 2.4 and it is unlikely that it will be resolved.
See also bug #389004.
can someone remind me what's wrong with the flam3 library as it stands? doesn't make any sense to me you can't use this.
As far as I can see we were waiting for your reply (see comment #24). I guess we just need someone to pick this up and do it for 2,6.
i am more than happy to include the plugin into the flam3 package as an option. please provide a patch or full tar based on head of CVS.
So just to ask, is there any process?
Dennis, if there was any progress, we would have added a comment here.
Reminder of the current status: we are waiting for one of the following things to happen: - Have libflam3 included in at least one major Linux distribution. Then we could keep the plug-in in the GIMP source tree and depend on the library that would be available from a standard package. - Get a comment from Scott telling us that he would prefer that the sources of libflam3 are maintained in the GIMP source tree together with the plug-in. I do not consider this to be a good option. - Get a comment from Scott telling us that he will take care of the plug-in. Then we can remove it from the GIMP source tree as it would be maintained and distributed together with libflam3. Until one of these things happen, there is not much that we can do about this bug report. I noticed on the flam3 web site that Erik Reckase is now responsible for the development of the library, and this matches what I see in http://flam3.cvs.sourceforge.net/flam3/src/. So we would also be glad to get comments from Erik regarding what is the best way to proceed.
IMO the only viable option we have is to include a copy of libflam3 with the GIMP source tree and update it from time to time.
who do we ask to get it into a distro? the electric sheep is in debian/ubuntu and it also includes a copy of flam3. the next version will break it out, but there's no reason to wait to include flam3 itself, i just have no idea how to pursue this. erik is doing most of the coding but i'm still in charge of the package.
Scott, the point is that we don't want to maintain a copy of the library, if possible. We also don't keep a copy of libjpeg or libpng or any other library that one of the GIMP plug-ins depend on.
i understand the point i said "who do we ask to get into a distro"?
https://bugzilla.redhat.com/show_bug.cgi?id=417711 flam3 package has been approved for fedora. i am still looking for someone to do debian.
FLAM3 package now available for fedora: http://rpmfind.net/linux/RPM/fedora/devel/i386/flam3-2.7.9-1.fc9.i386.html how can i find someone to package for debian and ubuntu? can we now move forward on updating the gimp plugin to use this library?
For Ubuntu, you can file a bug report at https://launchpad.net/ubuntu/ , using the keyword "needs-packaging". Can I ask you to clarify what you're doing here? On one hand, you could distribute the Flame stuff separately from gimp, but then you would have to distribute your own gimp plug-in along with it, and you would have to do something to keep it from conflicting with the version that is included with gimp (such as giving it a different name). On the other hand, you could ask to make libflam3 a dependency for gimp, and have the gimp package include a version of the plug-in built using it. If you want to take the second approach, the libflam3-dependent code in the plug-in should be marked "#ifdef HAVE_LIBFLAM3", so that the packagers can easily get the correct build just by building gimp in an environment that includes libflam3. Also, I just did a test-run of this -- very cool stuff -- and find that the patch in comment #10 is a bit stale. It still applies, but there are some warnings when it builds, and it generates a bunch of Gtk complaints when it runs (but no crash so far).
The whole plug-in would of course be libflam3 dependent. So there is absolutely no need to introduce #ifdefs here. We can easily handle the optional dependency in the build environment.
thanks, i filed the bug on ubuntu: https://bugs.launchpad.net/ubuntu/+bug/198136
flam3 is also available in Gentoo (with electricsheep) (http://bugs.gentoo.org/show_bug.cgi?id=237107 )
Debian: http://packages.debian.org/search?keywords=flam&searchon=names&suite=all§ion=all
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/95.
Scott, I don't know how but this came up again a few days ago :) Can you please join the discussion at https://gitlab.gnome.org/GNOME/gimp/issues/95