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] Re: perl-fu : cannot save image
On Fri, Feb 28, 2003 at 01:06:41AM -0500, Carol Spears [EMAIL PROTECTED] wrote: On 2003-02-28 at 0102.48 +0100, Marc A. Lehmann typed this: I really wonder what is going on here, but there is a great deal of confusion and misinformation going on... i miss the perl plug-ins in gimp-1.3. Well, the whole disucssion was about gimp-1.2, and it certainly works for that version (the current release, btw). gimp-perl indeed does not work with the cvs gimp. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] gimp-perl moved into its own CVS module
On Fri, Feb 28, 2003 at 06:07:22PM +0100, Sven Neumann [EMAIL PROTECTED] wrote: Hi, pcg( Marc)goof(A.).(Lehmann )com writes: (2) There are a couple of severe problems with the build that have I didn't know this (but I don't use the bugtracker, since despite a lot of tries I never got an account there, so it's rather useless for me). it seems we suffer from the same problem: I've told you about these problems several times and it seems you forgot about it. It seems this is wrong and only you forgot about it. I went through all bug reports you ever told me about and fixed, or at leats tried to fix them in good faith. I remember having given you feedback on them, too, but maybe in the last year or so some mails slipped through, I don't know. forget that there was a problem calling Script-Fu from anything but Script-Fu. Well, you keep forgetting it, don't you? In any case, arguing about open bug reports (that are long fixed) isn't going to get us anyhwere. Perhaps us two just have too many things to care about... Perhaps. But I don't go out in the public and keep claiming wrong things when I _know_ that I _do not_ know. http://bugzilla.gnome.org/show_bug.cgi?id=20052 This bug report is rather outdated and supposedly fixed since MANY years. http://bugzilla.gnome.org/show_bug.cgi?id=35694 Same issue here. http://bugzilla.gnome.org/show_bug.cgi?id=79751 Oops, this is certainly not something you told me about ever. http://bugzilla.gnome.org/show_bug.cgi?id=81791 This also is rather valid - I missed the change from overwriting prefix to destdir. http://bugzilla.gnome.org/show_bug.cgi?id=104726 Well, this is another case of broken compilation environment (gcc doesn't support the native asm syntax and compiler switches). In any case, the two bugs are really easy to fix - I don't think you ever told me about those. Yes, it's not at all your duty to tell me about these - I am not at all arguing about that, or wanting you to invest even more time and work. My problem is that you are investing too much time with misinformation - something that is relatively easy to avoid, especially since I do tell you about this regularly (oh sorry, for you it's ranting - no wonder you keep ignoring it). -- -==- | ==-- _ | ---==---(_)__ __ __ 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] gimp-perl moved into its own CVS module
On Fri, 28 Feb 2003 16:19:01 +0100, [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote: (2) There are a couple of severe problems with the build that have I didn't know this (but I don't use the bugtracker, since despite a lot of tries I never got an account there, so it's rather useless for me). Strange. I had no problem creating an account some time ago: http://bugzilla.gnome.org/createaccount.cgi Submitting your e-mail address using this form is the only thing you need to be able to add comments to any bug report. If you also want to be able to confirm bug reports, to close them or to re-assign them, then you should send a request to [EMAIL PROTECTED] after you account has been created. It may take a couple of days before this request is honored, but in the meantime you can already use your account to add your comments in any bug report. -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] - Addit. Questions - perl-fu : cannot saveimage
On Fri, 28 Feb 2003 09:52:18 +0100, Valter Mazzola [EMAIL PROTECTED] wrote: Your script is Perfect Raphaël ! Thanks! I've other questions: 1) When i run the script, i've a gimp window with the image created. I want to close it before leaving the script, I've done a (gimp-delete-image img) BUIT WITH NO effects. Search in the DB browser for gimp-display-delete. This is probably what you want. Leep in mind that an image can have multiple views/displays. 2) Can i activate gimp with no visual interface at all AND the script-fu server from the command line and but in in background under linux ? Hmmm... If gimp -i or gimp --no-interface does not do what you want, you can run it with a virtual display such as Xvfb. This is explained in this tutorial: http://gug.sunsite.dk/tutorials/tomcat17/ Also, search for server in the DB browser. You will find the documentation of extension-script-fu-server. -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp-perl moved into its own CVS module
Hi, pcg( Marc)@goof(A.).(Lehmann )com writes: http://bugzilla.gnome.org/show_bug.cgi?id=20052 This bug report is rather outdated and supposedly fixed since MANY years. Now closed at your request. http://bugzilla.gnome.org/show_bug.cgi?id=35694 Same issue here. Same here. http://bugzilla.gnome.org/show_bug.cgi?id=79751 Oops, this is certainly not something you told me about ever. I certainly did; I even added your email to the Cc: which should have caused bugzilla to send you an email about it. http://bugzilla.gnome.org/show_bug.cgi?id=81791 This also is rather valid - I missed the change from overwriting prefix to destdir. If you ever come around to fix this, will you please notice us about your change so we can avoid to have the bug-report open for some more years. http://bugzilla.gnome.org/show_bug.cgi?id=104726 Well, this is another case of broken compilation environment (gcc doesn't support the native asm syntax and compiler switches). Now closed as invalid. Yes, it's not at all your duty to tell me about these - I am not at all arguing about that, or wanting you to invest even more time and work. I'm sure you know how to query Bugzilla for the gimp-perl component of the gimp module. Salut, Sven PS: Thanks to the three bugs closed due to our little flame-war we are now down to rank 7 in the Bugzilla Hall of Shame (http://bugzilla.gnome.org/weekly-bug-summary.html). Thanks! :-) ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp-perl moved into its own CVS module
On 28 Feb 2003, at 18:35, Raphaël Quinet wrote: On Fri, 28 Feb 2003 16:19:01 +0100, [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote: (2) There are a couple of severe problems with the build that have I didn't know this (but I don't use the bugtracker, since despite a lot of tries I never got an account there, so it's rather useless for me). Strange. I had no problem creating an account some time ago: http://bugzilla.gnome.org/createaccount.cgi Submitting your e-mail address using this form is the only thing you need to be able to add comments to any bug report. If you also want to be able to confirm bug reports, to close them or to re-assign them, then you should send a request to [EMAIL PROTECTED] after you account has been created. It may take a couple of days before this request is honored, but in the meantime you can already use your account to add your comments in any bug report. I vaguely remember that Bugzilla needed JavaScript or Cookies or some other extra technology to be enabled before you could use it. It's not set-up very well. -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp-perl moved into its own CVS module
On Fri, Feb 28, 2003 at 08:30:09PM +0100, Branko Collin wrote: I vaguely remember that Bugzilla needed JavaScript or Cookies or some other extra technology to be enabled before you could use it. It's not set-up very well. Just another FUD example. You don't need JS (though it may improve user experience in a few places). You need cookies to log in, so you generally need cookies to change anything (what brower do you use? bugzilla works even in lynx). You don't need anything to search for bugs, wget is enough if you know what you are searching for. Yeti ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: gimp-perl moved into its own CVS module
On 2003-02-26 at 1956.05 +0100, Sven Neumann typed this: Hi, when I saw your mail, I remembered that I haven't yet told you that we finally moved gimp-perl out of the gimp HEAD branch into its own CVS module called gimp-perl. Hoepfully someone will find the time to resurrect its functionality and make it work with GTK+-2.x and GIMP-1.3. Salut, Sven does this mean that someone who actually likes perl can take it over and handle it properly? carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] to rower@MovieEditor.com (unrachable e-mail address)
Sorry for this off-topic posting, but Robin Rowe actually is on this list and had a question. From: Robin Rowe [EMAIL PROTECTED] I tried to reply to your mail, but it seems you cannot receive e-mail: [EMAIL PROTECTED] SMTP error from remote mailer after end of data: host mail.movieeditor.com [66.216.55.1]: 554 E-Mail address goof is not legal. If you provide me with a working e-mail-address I will re-send my mail. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] gimp-perl moved into its own CVS module
On Fri, Feb 28, 2003 at 10:07:30PM +0100, Marc A. Lehmann wrote: On Fri, Feb 28, 2003 at 09:19:17PM +0100, David Necas (Yeti) [EMAIL PROTECTED] wrote: You need cookies to log in, so you generally need cookies to change anything (what brower do you use? bugzilla works even in lynx). Well, certainly lynx doesn't send cookies if you tell it not to. I don't know a browser that always sends cookies, anyways. (Yes, you know that, but assuming that everybody happily lets himself monitor using cookies is not reflecting reality ;) It's OT, but you started about reality: Default lynx behaviour is to ask about each cookie. You can decide to accept exactly the log-in one (it sends a few more). You can make sure it's deleted after session. You can then set your cookie preferencies in the config. The reality is, you have to prove yourself to make any changes, and this is a very logical requirement. The stronger authentization, the better you are monitored. You can't be monitored less. If you are so paranoiac you don't accept cookies from bugzilla.gnome.org, then I can't understand why you bother to read any mail not signed by some trusted GnuPG key (namely gimp-dev), not speaking about responding to them. We are probably all evil hackers monitoring your mailing behaviour. Yeti ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Preview requirements
On 26 Feb 2003 17:29:37 +0100 Sven Neumann [EMAIL PROTECTED] wrote: Hi, Ernst Lippe [EMAIL PROTECTED] writes: The point is the following. In the current implementation the preview widget consists of the following components from top to bottom: the image, the progress bar and the zoom controls. When scrollbars should be added the horizontal scrollbar should be located between the progress bar and the image. So it is not possible to add scrollbars by simply wrapping the entire current preview but the preview itself must be modified. Adding scrollbars makes the layout algorithm more complex. IMO the preview widget should only be the preview, nothing else. If possible it should expose two adjustments so that you can easily add scrollbars. Progress-bar, zoom-control and scrollbars don't belong to the preview widget itself. They can be added by a composite widget. That is already in my current design. There is a bare preview widget that can do scaling and scrolling but has no GUI for these operations. There is another composite widget that can include a progress bar and zoom buttons. Having a standard composite widget makes life easier for developers and gives more uniformity among the plug-ins. Actually if you go for two adjustments and expose them in your API you don't need to deal with signals at all since it should be sufficient to connect to the value_changed and changed signals of the two adjustments. The reason for a separate signal is that this makes it possible to distinguish between between modifications that are initiated by the user via the preview GUI and modifications that were initiated programmatically via the API. When this distinction is never important the requirement could be dropped. Why should a widget behave differently if changed by the user or programmatically via the API? That sounds like a broken concept. Why? This is simply a method to get a hook for trapping operations that the user has performed on the GUI of the widget. A set of previews that you want to synchronize is an example of a constraint based system where you want to solve a set of constraints among multiple objects. The naive implementation of such a system is to let each object synchronize with all others when its value is changed. In general this is not a very good architecture: * It is expensive, you need at least n * (n - 1) synchronizations. * It frequently leads to oscillatory behaviour. As an example where you could get funny behavior, take two previews that show the area around a certain point at different magnifications. Assume that the user scrolls in preview A. Now A will update the position of B. Because B is updated it will attempt to update A's position. In all implementations that I can think of there are choices for the scale factor such that the new position for A is different from the position that was set by the user. So A's position changes again and A will try to update B a second time. Eventually, this will probably stabilize, but when there are 3 previews with different magnifications there are probably cases where the oscillations never stabilize. The standard solution for these problems is to have some central arbitrator that makes global decisions for all objects. When you have a seperate signal for user operations this is a nice hook for such an arbitrator. It is of course possible to implement an arbitrator without these signals but its implementation seems a lot messier. Probably you would need some global arbitration flag and change the way that value-changed signals are handled based on the value of this flag. You would also have to be careful about subsequent operations by the user before the arbitration computations are finished. Requirement 12. The preview must support an API to scroll the preview and change the magnification. This functionality is needed to synchronize multiple previews. and again you get this all for free if you go for two adjustments. Synchronizing two previews would boil down to synchronizing the preview's adjustements. When you have an API call to change both coordinates at the same time, this makes it easier to avoid unnecessary refreshes, otherwise the widget might try to refresh itself between modification of the first and second coordinate. you will have to delegate the actual refresh to idle functions anyway so that shouldn't be a problem. I've worked quite a bit with Delphi that extensively uses its own variant of signals and I found there that is was very usefull to wait with sending signals when you were updating multiple variables. Anyhow, this is more a design than a requirements discussion. BTW, I will leave the requirement as it stands, exposing adjustments to for scrolling and zooming is an API. greetings, Ernst ___ Gimp-developer mailing list [EMAIL PROTECTED]
Re: [Gimp-developer] gimp-perl moved into its own CVS module
It's OT, but you started about reality: I didn't start anything. A very important rule to follow on the 'net or anywhere else: do _NOT_ forward private mails to public forums. ;) bugzilla.gnome.org, then I can't understand why you bother to read any mail not signed by some trusted GnuPG key (namely gimp-dev) Did I say anything about that issue? Maybe I really do bother... I regularly have problems explaining to people why a gpg key that is not signed or verified by anybody (self-signature not counted) is still very useful and still has all the same identification qualities as a trusted (or better: verified by showing your ID card) gpg key. (A trusted key, btw, is something that actually _weakens_ your security. If you are paranoic you should never trust _any_ key. And as a general rule of thumb: if you trust anybody or anything, you are not really paranoic ;) not speaking about responding to them. We are probably all evil hackers monitoring your mailing behaviour. Well, that's probably not true, but wether I am paranoic or not, I _do_ respect it when people send me private (off-topic) mails and don't forward them... F'up in private again, please ;) -- -==- | ==-- _ | ---==---(_)__ __ __ 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
[Gimp-developer] ANNOUNCE: Gimp-Print 4.3.11
Gimp-Print 4.3.11, released February 28, 2003, is a development release of this package. Gimp-Print is a suite of printer drivers that may be used with most common UNIX print spooling systems, including CUPS, lpr, LPRng, or others. These drivers provide high quality printing for UNIX (including Macintosh OS X 10.2 and newer) and Linux systems in many cases equal to or better than proprietary vendor-supplied drivers, and can be used for many of the most demanding printing tasks. This software includes the Print plug-in for the Gimp, and Ghostscript and CUPS drivers, including Foomatic data. The print plugin for the Gimp requires the Gimp 1.2 (later versions of the Gimp are not supported). The CUPS driver requires CUPS 1.1.9 or higher. 1.1.14 or above is highly recommended, as certain translation-related bugs are fixed and it is possible to print true CMYK. The IJS-based GhostScript plugin driver requires GNU Ghostscript 6.53 or later, ESP Ghostscript 7.05 or later, or APFL GhostScript 7.04 or later. Users of Macintosh OS X 10.2 and above can use this package, as the printing system is based on CUPS, which is supported by Gimp-print. Note that Macintosh OS X 10.0 and 10.1 (including 10.1.5) cannot use this package. Please read the README file for full instructions on installing this package. Gimp-Print 4.3.11 contains the following major changes over Gimp-Print 4.3.10: 1) A significant bug fix in the EvenTone dither algorithm significantly improves quality with this option. 2) Paper sizes with tearoff margins (such as Epson 4x6 photo paper) now use the correct margin. This corresponds to bug 409612. 3) The IJS driver can now (in principle) handle all options supported by Gimp-print, rather than a specific subset. This is not tested and not propagated to Foomatic at this time. The src/ghost/README file has not been updated at this time; finding all of the available options will require studying the source code. 4) The number of resolution/quality settings in the Epson driver has been reduced by means of adding a new option for unidirectional, bidirectional, or auto printing. This new option is not available in the CUPS driver; automatic choice of print head direction is always used at this time. 5) The number of paper size choices in the GIMP plugin has been greatly reduced; there is a new global option to show all available paper sizes or just the most common sizes. 6) The LaserJet IIP driver now supports TIFF compression for faster printing speed. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp-perl moved into its own CVS module
fre 2003-02-28 klockan 18.28 skrev [EMAIL PROTECTED]: http://bugzilla.gnome.org/show_bug.cgi?id=79751 Oops, this is certainly not something you told me about ever. The bug activity log for this report (available as a link from the page) very clearly shows that [EMAIL PROTECTED] added a cc: to [EMAIL PROTECTED] for this bug report almost a year ago, 2002-04-24... ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
