Re: [Gimp-developer] perl-fu : cannot save image
On Fri, Feb 28, 2003 at 08:05:04PM +0100, Raphaël Quinet <[EMAIL PROTECTED]> wrote: Please don't call this rethorics - if you do, you are measuring different things differently, which is not at all fair. > this discussion on the developers' mailing list so I would expect that > most subscribers care about the status of the current version, which > is GIMP 1.3.x (or CVS HEAD). GIMP 1.3.x will hopefully become the > next stable relase during this year, and it does not have a working > Gimp-Perl yet. Actually, we were having this discussion with somebody who uses gimp-1.2, and for whom gimp-perl _does_ work, as much as you can expect, that is. gimp-developers is IMHO well-suited for discussion about gimp-1.2, otherwise there would be no forum for bugfixes etc. with respect to gimp-1.2, and people certainly do care about fixing bugs and devloping gimp-1.2 into an even more stable form. > This issue is not as simple as you make it look like. It may be > possible (but not necessarily easy nor elegant) for the Gimp-Perl > Makefile to switch compilers and compiler flags depending on what part > of the code is being compiled. On IRIX, it isn't (compilers _are_ link-incompatible). On other platforms you will find that just switching compiler flags won't help, as perl uses different versions of it's macros depending on compiler and configuration, and will not work properly no matter what. And I don't at all think it's reasonable to get this to work anywhere, since, if NO perl module can be compiled, then the right place to fix it is not in gimp-perl, but in the general configuration (And it's easy, just supply your own version of perl that is capable of compiling and linking). I mean, I simply don't see why a perl module should be able to reconfigure an already instaleld perl on every possible configuration, when this configuration step is done by perl already - duplicating it is just a maintainance nightmare, and won't help other modules. I mean, it's way easier to just ship perl together with gimp and always use it's own version > Also, I could also argue that your definition of a "non-broken" > environment is a bit too strict. Except for Perl modules, there are no > problems in compiling and linking some software with libraries produced > by different compilers. Well, if _no_ perl module (that uses non-perl code) can be installed on that environment, I think it's "broken", in the sense that you can't build perl modules. It's still way less strict than your definition of broken, though. > It's not as if we were trying to link windows dlls and glibc together: > here we are talking about linking object files and libraries that are > designed for the same platform and use the same basic format (ELF, for > example). No, we are talking about _source_ configured for a particular compiler and things like building dynamic objects, which is not very common (it's not the same as building a shared library, for example), and certainly differes a lot between platforms. Especially when you find that some platforms have funny dependency issues regarding which shared library is linked with which dynamic object to which binary. HPUX is the prime offender, but even "sane" ELF machines like IRIX all need various compiler-specific workarounds (not to mention n32 vs. n64 vs). > So for many people (again, mostly on non-Linux platforms), Gimp-Perl > is the part in which the GIMP build process breaks. Yes, so gimp is broken (according to your definition). However, the same logic applies to a compiler that cannot compile gimp because it requires pre-iso-c89 or has bugs that keep it from working. In any case, it's not reasonable to be able to build gimp-perl with a perl that isn't able to build any modules. No matter how you argue, I fail to see why this should be different - if a user cannot supply a working perl, he should --disable-perl or ask thed evelopers to try and _detect_ this case and diable it. The expectation to make a perl module work with a broken installation of perl (which I define as: perl modules can't be build because the compiler is missing) is and will always be unreasonable. Mind you, I have IRIX and hpux machines, and gimp-perl _works_ _fine_ on them. So your claim that users can't use it on these machines is wrong. You just have to provide the build environment to build perl modules, and if you don't have the compiler, then provide gcc and a perl that works with it. Especially on irix, where the bundled perl is old and doesn't work properly with many of irix' own scripts. > plug-ins depend only on simple libraries such as the JPEG or PNG Yes, perl is not a library at all. it's rather big and rather optimised for it's build environment. For example you wouldn't expect to be able to link with a libjpeg if you used a different header file than the one supplied (it checks for structure sizes etc. at runtime, but it's no fun). > mod_perl for Apache, for example. It may be possible to imp
Re: [Gimp-developer] perl-fu : cannot save image
On Fri, 28 Feb 2003 16:11:46 +0100, <[EMAIL PROTECTED] ( Marc) (A.) (Lehmann )> wrote: > On Fri, Feb 28, 2003 at 01:53:59PM +0100, Raphaël Quinet <[EMAIL PROTECTED]> wrote: > > Even if the problems were only due to the build/install process, I > > think that it would be appropriate to say that "gimp-perl is broken". > > The result is that it is not possible for some users to use gimp-perl. > > And although gimp-perl works for most people in the 1.2.x releases, > > this is not the case for GIMP 1.3.x, in which gimp-perl is really > > "broken". I am not blaming you for that, but the current version is > > simply not working. > > Sorry, but your definition is simply useless. Gimp itself (and any > other software package) does not work for many users, and calling every > software package "broken", while, according to your definition, would be > true, is simply not useful. It really makes no sense to define "broken" > as "every software package in existence". If people would use such a > useless definition they would have no way of talking about "really" broken > software, since the word "broken" would have no information content > whatsoever. Well, OK, this is a rethoric issue. But this part of my comment started with "Even if the problems were only due to...". The other part of my comment was about GIMP 1.3.x. This is the part in which Gimp-Perl is really "broken" because nobody can use it. Although the last stable version is still GIMP 1.2.3 (soon 1.2.4), we are having this discussion on the developers' mailing list so I would expect that most subscribers care about the status of the current version, which is GIMP 1.3.x (or CVS HEAD). GIMP 1.3.x will hopefully become the next stable relase during this year, and it does not have a working Gimp-Perl yet. > > other than Linux (Solaris, IRIX, AIX, etc.) include a version of Perl > > while compiling or linking Perl modules because the compilers are > > different. > > Well, this is obviously a configuration problem on the system in > question. Nobody would assume that it should work to link windows dlls > together with glibc and get something useful out of it, or configure > gimp with compiler switches the compiler can't understand. The fix is to > fix the configuration. Nothing is broken, it all works fine if the build > environment is non-broken. This issue is not as simple as you make it look like. It may be possible (but not necessarily easy nor elegant) for the Gimp-Perl Makefile to switch compilers and compiler flags depending on what part of the code is being compiled. Using always the compiler flags provided by Perl is not necessarily a good idea, especially if the user does not have access to the compiler that was used for compiling Perl. This may require some tricks (such as extracting the right flags for -I, -L and so on) but it may solve some of the problems as long as the object files from different compilers can be linked together. Also, I could also argue that your definition of a "non-broken" environment is a bit too strict. Except for Perl modules, there are no problems in compiling and linking some software with libraries produced by different compilers. It's not as if we were trying to link windows dlls and glibc together: here we are talking about linking object files and libraries that are designed for the same platform and use the same basic format (ELF, for example). So for many people (again, mostly on non-Linux platforms), Gimp-Perl is the part in which the GIMP build process breaks. The other plug-ins depend only on simple libraries such as the JPEG or PNG libraries and there are usually less problems with that (regardless of the compiler used). As I wrote in my previous message, this problem is due to the way Perl modules are built and it is not specific to Gimp-Perl. The same problems can also occur when trying to build mod_perl for Apache, for example. It may be possible to implement some hacks in Gimp-Perl that allow it to work regardless of the compiler used, but this will not be easy. > > Another problem is for non-root users who install everything in a > > to the Perl directories. It is possible to avoid these problems by > > building and installing a second version of Perl or by installing the > > It's also possible to avoid this problems by setting the prefix, nothing > complicated like you say is neccessary. Yes, that's what I mentioned in the next line of my reply (which you unfortunately forgot to include in your quote): it is possible to install the modules in a separate directory, but then you have to make sure that it appears in @INC. So you may have to set the environment variable PERL5LIB. [...] > > > confusion and misinformation going on... > > I don't think that it is intentional. > > Well, maybe not, but I am pretty sure that your claiming that everything > is broken is not helping users. I understand your frustration about this. Anyway, I hope that you will be able to solve the problems
Re: [Gimp-developer] perl-fu : cannot save image
On Fri, Feb 28, 2003 at 01:53:59PM +0100, Raphaël Quinet <[EMAIL PROTECTED]> wrote: > Even if the problems were only due to the build/install process, I > think that it would be appropriate to say that "gimp-perl is broken". > The result is that it is not possible for some users to use gimp-perl. > And although gimp-perl works for most people in the 1.2.x releases, > this is not the case for GIMP 1.3.x, in which gimp-perl is really > "broken". I am not blaming you for that, but the current version is > simply not working. Sorry, but your definition is simply useless. Gimp itself (and any other software package) does not work for many users, and calling every software package "broken", while, according to your definition, would be true, is simply not useful. It really makes no sense to define "broken" as "every software package in existence". If people would use such a useless definition they would have no way of talking about "really" broken software, since the word "broken" would have no information content whatsoever. > other than Linux (Solaris, IRIX, AIX, etc.) include a version of Perl > while compiling or linking Perl modules because the compilers are > different. Well, this is obviously a configuration problem on the system in question. Nobody would assume that it should work to link windows dlls together with glibc and get something useful out of it, or configure gimp with compiler switches the compiler can't understand. The fix is to fix the configuration. Nothing is broken, it all works fine if the build environment is non-broken. > Another problem is for non-root users who install everything in a > to the Perl directories. It is possible to avoid these problems by > building and installing a second version of Perl or by installing the It's also possible to avoid this problems by setting the prefix, nothing complicated like you say is neccessary. > >From that point of view, it would make sense to distribute the Perl > plug-ins as a separate package. It makes sense from a social standpoint, too. It might get rid of occasions where some of the main gimp developers who obviously have a problem with the language perl can spread FUD. > Now, regarding the problems with Gtk-Perl, this is something that I > experienced: I tried to fetch it from CPAN and build it on Solaris > 2.6, using Perl 5.8.0. Well, gtk-perl, while extremely useful, is not neccessary to build gimp-perl. Many people use scripts to remotely control the gimp (and gimp-perl is about the only secure way to do that, afaics), and a gui is often not necessary for server operation. > Those affected by these bugs are probably thinking that the Perl part > is not actively maintained. Well, I can't help that. The problem is that people who DO KNOW THIS spread misinformation, which doesn't at all help these people. It's one thing when people are misinformed because they don't get information, it's a completely different thing if people get told that "gimp perl is unmaintained and broken" by people whom they assume are authorities on the subject, while the opposite is the case. > as well: there are several long-standing bugs in some plug-ins or > parts of the core. Even if they have an official maintainer, there is > not much happening in some areas. Yes, gimp is simply broken, according to your definition. This of course also included version 1.2. I don't share your definition of broken, though, and I think gimp-1.2 is not really broken. I also think your definition is not at all understood by most users, so telling them "gimp is broken" is not helping them in any way, they will just get confused. This is *backwards*. > > confusion and misinformation going on... > I don't think that it is intentional. Well, maybe not, but I am pretty sure that your claiming that everything is broken is not helping users. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] perl-fu : cannot save image
On Fri, 28 Feb 2003 01:02:48 +0100, <[EMAIL PROTECTED] ( Marc) (A.) (Lehmann )> wrote: > On Thu, Feb 27, 2003 at 02:04:51PM +0100, Raphaël Quinet <[EMAIL PROTECTED]> wrote: > > - Gimp-Perl is broken and is not maintained > > Well, I don't know of anything like "gimp-perl is broken". I think that > build problems that are due to people using the wrong compiler (like on > irix), or problems with gtk-perl (that I am still not aware of) do not > warrant such wording as "gimp-perl is broken". Even if the problems were only due to the build/install process, I think that it would be appropriate to say that "gimp-perl is broken". The result is that it is not possible for some users to use gimp-perl. And although gimp-perl works for most people in the 1.2.x releases, this is not the case for GIMP 1.3.x, in which gimp-perl is really "broken". I am not blaming you for that, but the current version is simply not working. Some of the build or installation problems are not specific to gimp-perl and are shared by all programs that have to install Perl modules. One example that comes to my mind is that most UNIX systems other than Linux (Solaris, IRIX, AIX, etc.) include a version of Perl with the OS (pre-installed or available as an optional package). This version is compiled with the vendor's compiler, which is not installed by default. Those who do not want to pay extra for the vendor's compiler install some version of gcc. But then this causes problems while compiling or linking Perl modules because the compilers are different. Another problem is for non-root users who install everything in a non-standard directory but still have problems with the Perl modules that cannot be installed because the user does not have write access to the Perl directories. It is possible to avoid these problems by building and installing a second version of Perl or by installing the Gimp-Perl files in a private directory and playing with @INC, but this is not trivial. >From that point of view, it would make sense to distribute the Perl plug-ins as a separate package. Regardless of its merits, this part of the GIMP has typically caused more installation problems than the other parts. Distributing it separately will ensure that more people can easily get a basic GIMP installation working. Now, regarding the problems with Gtk-Perl, this is something that I experienced: I tried to fetch it from CPAN and build it on Solaris 2.6, using Perl 5.8.0. I got many errors while compiling and linking. In the end, it compiled but I got random crashes in any script that was using the Gtk module. I spent a few hours trying to fix that, but in the end I gave up. Also, the current version of Gtk-Perl has lots of optional dependencies on various GNOME components, libxml and other things. It also depends on XML::Writer and XML::Parser. Since this system did not have any of these, I had to supply a nice list of options (the order of some of them is significant): o conf makepl_arg "--without-gtkhtml --without-gtkglarea --without-gdkimlib --without-gtkxmhtml --without-gnome --without-gnomeprint --without-applets" So building Gtk-Perl is not very easy. It works on Linux, though (with the old GTK+ 1.2.10). > Also, gimp-perl not being maintained is news to me. Who claims this?? I > was under the impression that I was the maintainer, and I certainly still > maintain it. Where do you have this "gimp-perl is not maintained"? Or has > the maintainer silently changed without the maintainer knowing it? Of course, you are still the maintainer. But in practice, the Perl part in GIMP 1.3 is not actively maintained. Currently, it just does not work with the current versions of libgimp, GTK+ 2.x, etc. Also, I just saw Sven's message listing some of the bugs that are still open. Those affected by these bugs are probably thinking that the Perl part is not actively maintained. This happens to other parts of the GIMP as well: there are several long-standing bugs in some plug-ins or parts of the core. Even if they have an official maintainer, there is not much happening in some areas. > I really wonder what is going on here, but there is a great deal of > confusion and misinformation going on... > I don't think that it is intentional. -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] perl-fu : cannot save image
On Thu, Feb 27, 2003 at 02:04:51PM +0100, Raphaël Quinet <[EMAIL PROTECTED]> wrote: > Note that I am not engaging in any kind of Perl-bashing here: Perl is my Indeed, you aren't. However, you get a lot of things wong: > - Gimp-Perl is broken and is not maintained Well, I don't know of anything like "gimp-perl is broken". I think that build problems that are due to people using the wrong compiler (like on irix), or problems with gtk-perl (that I am still not aware of) do not warrant such wording as "gimp-perl is broken". Also, gimp-perl not being maintained is news to me. Who claims this?? I was under the impression that I was the maintainer, and I certainly still maintain it. Where do you have this "gimp-perl is not maintained"? Or has the maintainer silently changed without the maintainer knowing it? I really wonder what is going on here, but there is a great deal of confusion and misinformation going on... -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] perl-fu : cannot save image
On Thu, 27 Feb 2003 14:37:36 +0100, Valter Mazzola <[EMAIL PROTECTED]> wrote: > Dear Raphaël > > can you make an example script that calls a script-fu- logo scripts and save it? > > for example this one doesn't save correctly the image: > > (begin > (let* > ( > (image (car ( (script-fu-alien-glow-logo "hello hello" 150 > "-*-utopia-bold-r-*-*-150-*-*-*-*-*-*-*" '(255 0 0)))) ) > ; (image (car (gimp-file-load 0 "/root/clock.gif" "/root/clock.gif"))) > (drawable nil) > ) > > (set! drawable (car (gimp-image-flatten image))) > (gimp-file-save 1 image drawable "/root/a.png" "/root/a.png") > (gimp-image-delete image) > ) ;let > ) There are a few problems in your script, such as the extra parenthesis before the call to script-fu-alien-glow-logo. Also, one thing that is not really obvious is that the script returns one more than the index of the new image (don't ask me why). So here is a modified version of the script that should work: (define (script-fu-blahblah outfile) (let* ((img (- (car (script-fu-alien-glow-logo "hello hello" 150 "-*-utopia-bold-r-*-*-150-*-*-*-*-*-*-*" '(255 0 0))) 1)) (drawable (car (gimp-image-flatten img (gimp-convert-indexed img 1 0 255 0 1 "") (file-png-save 1 img drawable outfile outfile 0 9 0 0 0 0 0))) You can also register this script in the menus: (script-fu-register "script-fu-blahblah" "/Xtns/Script-Fu/Blahblah" "Blah blah blah!" "me" "me" "2003-02-27" "" SF-FILENAME "Outfile" "outfile.png") Or if you want to invoke it directly from the command line in batch mode, then you can replace the "(define ...)" with "(begin ...)" as you did in your example and directly replace the value of "outfile" with the name of the file in which you want to save the results. -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] perl-fu : cannot save image
Dear Raphaël can you make an example script that calls a script-fu- logo scripts and save it? for example this one doesn't save correctly the image: (begin (let* ( (image (car ( (script-fu-alien-glow-logo "hello hello" 150 "-*-utopia-bold-r-*-*-150-*-*-*-*-*-*-*" '(255 0 0)))) ) ; (image (car (gimp-file-load 0 "/root/clock.gif" "/root/clock.gif"))) (drawable nil) ) (set! drawable (car (gimp-image-flatten image))) (gimp-file-save 1 image drawable "/root/a.png" "/root/a.png") (gimp-image-delete image) ) ;let ) thanks, valter On Thu, 27 Feb 2003 14:04:51 +0100 Raphaël Quinet <[EMAIL PROTECTED]> wrote: > On Wed, 26 Feb 2003 22:24:13 +0100, Valter Mazzola <[EMAIL PROTECTED]> wrote: > > ok but io want to create logos using existing script-fu logo script? > > it's possible > > Yes. One solution that does work with the current and future versions > of the GIMP is to write your whole script in Script-Fu. Do not try to > call Script-Fu from Perl (or from any other plug-in, for that matter) > because you will not get the expected results. Instead, write everything > in Script-Fu and you will get your logo as expected. > > Note that I am not engaging in any kind of Perl-bashing here: Perl is my > language of choice whenever I have to write some scripts or even some > rather complex programs. But as it stands currently, Gimp-Perl has some > problems (some of them inherited from Gtk-Perl bugs on some platforms, > some others due to the build/install process and some others due to the > fact that it is not maintained anymore) and will probably not be included > in the next release of the GIMP. So although Perl is a fine language, > the safest solution for the moment is to use Script-Fu, which is less > powerful but works well with the current and future versions of the GIMP. > > The bug report describing the incorrect behavior of Script-Fu when called > from other plug-ins can be found here: > http://bugzilla.gnome.org/show_bug.cgi?id=50649 > > So the short but confusing conclusion is: > - Script-Fu is broken (bug #50649) > - Gimp-Perl is broken and is not maintained > - The problem you see is mainly due to the script-fu bug mentioned above > and not to a problem in Perl, but the best solution is to use Script-Fu > only. > > -Raphaël > ___ > Gimp-developer mailing list > [EMAIL PROTECTED] > http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer -- Valter Mazzola - Software/Databases for Enterprise Web Sites Java, Jsp, ASP, PHP, PERL, Mod_Perl, PL/SQL, Apache,IIS C/C++, Oracle, SQL Sever, PostgreSQL, MySQL, Access. http://SitiDinamici.com/ Phone:(+39) 347/129-07-16. Fax:(+39) 02/700-539-403 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] perl-fu : cannot save image
On Wed, 26 Feb 2003 22:24:13 +0100, Valter Mazzola <[EMAIL PROTECTED]> wrote: > ok but io want to create logos using existing script-fu logo script? > it's possible Yes. One solution that does work with the current and future versions of the GIMP is to write your whole script in Script-Fu. Do not try to call Script-Fu from Perl (or from any other plug-in, for that matter) because you will not get the expected results. Instead, write everything in Script-Fu and you will get your logo as expected. Note that I am not engaging in any kind of Perl-bashing here: Perl is my language of choice whenever I have to write some scripts or even some rather complex programs. But as it stands currently, Gimp-Perl has some problems (some of them inherited from Gtk-Perl bugs on some platforms, some others due to the build/install process and some others due to the fact that it is not maintained anymore) and will probably not be included in the next release of the GIMP. So although Perl is a fine language, the safest solution for the moment is to use Script-Fu, which is less powerful but works well with the current and future versions of the GIMP. The bug report describing the incorrect behavior of Script-Fu when called from other plug-ins can be found here: http://bugzilla.gnome.org/show_bug.cgi?id=50649 So the short but confusing conclusion is: - Script-Fu is broken (bug #50649) - Gimp-Perl is broken and is not maintained - The problem you see is mainly due to the script-fu bug mentioned above and not to a problem in Perl, but the best solution is to use Script-Fu only. -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] perl-fu : cannot save image
On Wed, Feb 26, 2003 at 10:24:13PM +0100, Valter Mazzola <[EMAIL PROTECTED]> wrote: > i'm using mandrake 9.0 and gimp 1.2.3 , removed mail() in exit, > but the saved logo is totally different than the gimp do interactively. Try to call flatten on the resulting image before saving ($image->flatten). If that doesn't help, then add a sleep 3 or so after the call to script-fu and keep your fingers crossed. If that doesn't help either you might look at scm2perl and convert the scheme plug-in to perl (followed by a lot of small adjustments, as script-fu scripts are often rather unclean, due to the lakc of type-safeness of the language). > ok but io want to create logos using existing script-fu logo script? > it's possible With a lot of hacks, it's usually possible. But it often depends on the particular script. It also sometimes helps to open a new image+drawable before calling script-fu, as some scripts seem to have problems with image or drawable ids of zero. Equally often it helps to not have any windows open, as some scripts only work _if_ they open the very first image and/or drawable. Most of these _should_ problems be fixed in 1.2.3, but some probably were overlooked, and debugging these scripts is no fun. > I want to do serious scripting work with gimp, similar to cool text.com, > can you help me to decide in what direction i should go ? Maybe ask whoever does cooltext.com, they certainly had either similar problems or do it difefrently (e.g. with the script-fu server, however, don'T use it unless you have properly firewalled it). > I have not obtained deterministic results till now. That's, indeed, what most people find out quickly when they get in contact with script-fu. > Script-fu, perl-fu , interactions between them, outdated documentations ??? I am sorry, you must be fairly confused by now ;) Actually, it's because script-fu doesn't really behave like any other gimp plug-in. The fact that nobody regularly calls script-fu in normal work (there are few, if any, generic script-fu scripts, so there is rarely need to call them from other plug-ins) obviously made script-fu very low priority over the years. The only people who do call script-fu from a plug-in are mostly people who write logo-generators (like you do), and they often use perl. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] perl-fu : cannot save image
On Wed, Feb 26, 2003 at 07:53:31PM +0100, Sven Neumann <[EMAIL PROTECTED]> wrote: > > I would prefer if people who could know it better would stop > > claiming such bullshit. The perl-syntax is well-documented, and even > > if you insist on using the rather idiotic PDB-syntax, it does work. > > sorry, I heard that it wouldn't work and I remembered the PDB explorer > to document the "rather idiotic" PDB-syntax. Well, sure, but even if you believed that there was no reason to write what you wrote. So what are you sorry for? You do that in about every mail that has something to do with perl, in case you didn't realize it. > > The only solution is to avoid script-fu whereever possible. It has been > > horribly buggy since many years (I don't remember it being working > > ever). > > I don't remember to have seen a bug-report about this. I think it gets reported here or on gimp-user every few months since at least 2000. You probably ignored it because there is often perl code in it, and it's easy to dismiss it as yet another perl problem. It's basically become a FAQ even. > meantime. I'm not sure however if we will ever manage to fix all > Script-Fu problems since it has indeed some rather fundamental flaws. That's true, and I can fully understand that. What I cannot understand is why you reflect these problems on perl again and again. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] perl-fu : cannot save image
i'm using mandrake 9.0 and gimp 1.2.3 , removed mail() in exit,
but the saved logo is totally different than the gimp do interactively.
>The only solution is to avoid script-fu whereever possible. It has been
>horribly buggy since many years (I don't remember it being working
>ever). But obviously it's much more fun to blame gimp-perl for bugs in
>script-fu, or claim thats cript-fu was never written to be used as a
>gimp-plug-in, or other fun stuff.
ok but io want to create logos using existing script-fu logo script?
it's possible
I want to do serious scripting work with gimp, similar to cool text.com,
can you help me to decide in what direction i should go ?
I have not obtained deterministic results till now.
Script-fu, perl-fu , interactions between them, outdated documentations ???
--
use Gimp ":auto";
use Gimp::Fu;
use strict;
sub net {
}
Gimp::init;
Gimp::on_net(\&net);
Gimp::set_trace (TRACE_ALL);
my $i=0;
system ("rm -f image_1.png");
script_fu_alien_glow_logo("hello hello $i", "150",
"-*-utopia-bold-r-*-*-150-*-*-*-*-*-*-*", [255,0,0] );
my $img = &gimp_image_list();
my $fname = "image_1.png";
my $activelayer= &gimp_image_flatten($img);
file_png_save(RUN_NONINTERACTIVE, $img, $activelayer,
$fname, $fname, 0, 9, 0, 0, 0, 0, 0);
# Handle over control to gimp
exit;
On Wed, 26 Feb 2003 19:29:43 +0100
<[EMAIL PROTECTED] ( Marc) (A.) (Lehmann )> wrote:
> On Thu, Feb 20, 2003 at 12:11:29AM +0100, Valter Mazzola <[EMAIL PROTECTED]> wrote:
> > Hello Marc , i want to automate logo creation
> > with the script
> >
> > exit main();
>
> That's the problem. If you use Gimp::init then you should not call main.
>
> --
> -==- |
> ==-- _ |
> ---==---(_)__ __ __ Marc Lehmann +--
> --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
> -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
> The choice of a GNU generation |
> |
--
Valter Mazzola - Software/Databases for Enterprise Web Sites
Java, Jsp, ASP, PHP, PERL, Mod_Perl, PL/SQL, Apache,IIS
C/C++, Oracle, SQL Sever, PostgreSQL, MySQL, Access.
http://SitiDinamici.com/
Phone:(+39) 347/129-07-16. Fax:(+39) 02/700-539-403
On Wed, 26 Feb 2003 19:46:43 +0100
<[EMAIL PROTECTED] ( Marc) (A.) (Lehmann )> wrote:
> On Mon, Feb 24, 2003 at 06:38:42PM +0100, Sven Neumann <[EMAIL PROTECTED]> wrote:
> > I'd say the bug is in your script. But then you could argue that the
> > bug is in gimp-perl since it's syntax defers from the one that is
> > documented :-(
>
> I would prefer if people who could know it better would stop claiming such
> bullshit. The perl-syntax is well-documented, and even if you insist on
> using the rather idiotic PDB-syntax, it does work.
>
> Also, it should be clear even to you that some languages look diferent
> to others. I remember that a PDB call uses different syntax in C than in
> script-fu, for example.
>
> Yes, both might be documented, and the same is true for the perl
> interface. Since you certainly _are_ aware of all that, what's your point?
>
> Maybe I should add dummy array-length arguments to all calls involving
> arrays, because other languages can't handle that?
>
> > > file_png_save(RUN_NONINTERACTIVE, $img, $activelayer,
> > > $fname, $fname, 0, 9, 0, 0, 0, 0, 0);
> >
> > in gimp-perl, you need to omit the image if the drawable
> > ($activelayer) is already specified.
>
> Actually, you don't. Actually, the script works fine on a standard debian
> installation (gimp-1.2 1.2.3-2, with the debian gimp-pelr etc..), WHEN I
> add sleeps at the right place.
>
> What's buggy is, again, script-fu, which returns long before the script
> has run. And the script doesn't work unless you create another image,
> because it doesn't like image ids of zero.
>
> The only solution is to avoid script-fu whereever possible. It has been
> horribly buggy since many years (I don't remember it being working
> ever). But obviously it's much more fun to blame gimp-perl for bugs in
> script-fu, or claim thats cript-fu was never written to be used as a
> gimp-plug-in, or other fun stuff.
>
> Boys, I am really fed up with that never-ending and mindless
> perl-bashing. If you can't try to help people without shoveling mistakes
> and bugs around, then please, keep your mouth shut. Or at leats use your
> brain once in a while.
>
> Blaming perl is *not* the solution.
> Blaming script-fu *is* right.
> Fixing script-fu *is* the solution.
>
> --
> -==- |
> ==-- _ |
> ---==---(_)__ __ __ Marc Lehmann +--
> --==---/ /
Re: [Gimp-developer] perl-fu : cannot save image
Hi, writes: > I would prefer if people who could know it better would stop > claiming such bullshit. The perl-syntax is well-documented, and even > if you insist on using the rather idiotic PDB-syntax, it does work. sorry, I heard that it wouldn't work and I remembered the PDB explorer to document the "rather idiotic" PDB-syntax. > What's buggy is, again, script-fu, which returns long before the script > has run. And the script doesn't work unless you create another image, > because it doesn't like image ids of zero. > > The only solution is to avoid script-fu whereever possible. It has been > horribly buggy since many years (I don't remember it being working > ever). I don't remember to have seen a bug-report about this. If it would have been reported we might have even looked into fixing it in the meantime. I'm not sure however if we will ever manage to fix all Script-Fu problems since it has indeed some rather fundamental flaws. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] perl-fu : cannot save image
On Mon, Feb 24, 2003 at 06:38:42PM +0100, Sven Neumann <[EMAIL PROTECTED]> wrote: > I'd say the bug is in your script. But then you could argue that the > bug is in gimp-perl since it's syntax defers from the one that is > documented :-( I would prefer if people who could know it better would stop claiming such bullshit. The perl-syntax is well-documented, and even if you insist on using the rather idiotic PDB-syntax, it does work. Also, it should be clear even to you that some languages look diferent to others. I remember that a PDB call uses different syntax in C than in script-fu, for example. Yes, both might be documented, and the same is true for the perl interface. Since you certainly _are_ aware of all that, what's your point? Maybe I should add dummy array-length arguments to all calls involving arrays, because other languages can't handle that? > > file_png_save(RUN_NONINTERACTIVE, $img, $activelayer, > > $fname, $fname, 0, 9, 0, 0, 0, 0, 0); > > in gimp-perl, you need to omit the image if the drawable > ($activelayer) is already specified. Actually, you don't. Actually, the script works fine on a standard debian installation (gimp-1.2 1.2.3-2, with the debian gimp-pelr etc..), WHEN I add sleeps at the right place. What's buggy is, again, script-fu, which returns long before the script has run. And the script doesn't work unless you create another image, because it doesn't like image ids of zero. The only solution is to avoid script-fu whereever possible. It has been horribly buggy since many years (I don't remember it being working ever). But obviously it's much more fun to blame gimp-perl for bugs in script-fu, or claim thats cript-fu was never written to be used as a gimp-plug-in, or other fun stuff. Boys, I am really fed up with that never-ending and mindless perl-bashing. If you can't try to help people without shoveling mistakes and bugs around, then please, keep your mouth shut. Or at leats use your brain once in a while. Blaming perl is *not* the solution. Blaming script-fu *is* right. Fixing script-fu *is* the solution. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] perl-fu : cannot save image
Hi, Valter Mazzola <[EMAIL PROTECTED]> writes: > This script isn't able to save correctly the logo in png format, > i've tried othe formats but seesm there are bug in gimp. I'd say the bug is in your script. But then you could argue that the bug is in gimp-perl since it's syntax defers from the one that is documented :-( > file_png_save(RUN_NONINTERACTIVE, $img, $activelayer, > $fname, $fname, 0, 9, 0, 0, 0, 0, 0); in gimp-perl, you need to omit the image if the drawable ($activelayer) is already specified. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] perl-fu : cannot save image
This script isn't able to save correctly the logo in png format, i've tried othe
formats but seesm there are
bug in gimp.
I'm using GIMP version 1.2.3, Mandrake Linux 9.0.
thanks,
valter
--
#!/usr/local/bin/perl
use Gimp ":auto";
use Gimp::Fu;
use strict;
sub net {
}
Gimp::init;
Gimp::on_net(\&net);
Gimp::set_trace (TRACE_ALL);
my $i=0;
system ("rm -f image_1.png");
script_fu_alien_glow_logo("hello hello $i", "150",
"-*-utopia-bold-r-*-*-150-*-*-*-*-*-*-*", [255,0,0] );
my $img = &gimp_image_list();
my $fname = "image_1.png";
my $activelayer= &gimp_image_flatten($img);
file_png_save(RUN_NONINTERACTIVE, $img, $activelayer,
$fname, $fname, 0, 9, 0, 0, 0, 0, 0);
# Handle over control to gimp
exit main();
--
Valter
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
