[Gimp-developer] Preview requirements
A preview widget for plug-ins is one of these items that has been on the Gimp todo list for a long time. In order to get some feedback from other developers we have compiled a list of requirements for a preview widget. The list is based on our own experiences and previous discussions on this mailing list. Our goal is a preview widget that could be used by most plug-ins. We would like to hear your opinions on the following points: * Is the list complete? * Are the requirements sufficiently clear? * Are there any unnecessary requirements? We are currently working on the API and a prototype implementation. Our current implementation is based on Shawn Amundson's GimpPreview widget. It covers most of the requirements in this list, but is still mainly alpha code. When there are no major additions to these requirements we hope to publish an API proposal in the next weeks. greetings, Ernst Lippe [EMAIL PROTECTED] Maurits Rijk [EMAIL PROTECTED] Requirements for a GIMP plug-in preview widget == This document gives a possible list of requirements for a preview widget that can be used by GIMP plug-ins. This is the version 1.0. This document was written by Maurits Rijk [EMAIL PROTECTED] and Ernst Lippe [EMAIL PROTECTED]. Requirement 1. A plug-in author must be able to write a single version of the rendering function that can both be used for rendering to the plug-in and for rendering to the final drawable. Far too many plug-ins that have a preview contain two different versions of the rendering algorithm: one for the preview and another one for the final result. For plug-ins that don't have a preview yet it is very desirable that the interface for generating a rendered image for the preview is very similar to the interface for generating the final results. Requirement 2. The preview must support a GUI for scrolling through the image. There are two possible GUI styles: dragging in the preview and using scrollbars. These could also be combined. Open issue: Scrollbars make the widget visually bigger and makes its internal structure more complicated. The alternative of giving the preview widget two GtkAdjustments, that can be used by the developer to wrap the widget with scroll-bars, does not work when the preview widget has a visible scroll-bar and/or zoom controls. Scroll-bars will not be supported in the first release of the preview widget. Requirement 3. When dragging can be used to scroll the preview it should show a move cursor in the preview image. This gives visual feedback to the user that the image can be scrolled. Requirement 4. During scrolling the preview should optionally show a (possibly scaled) version of the original image. In many cases rendering algorithms are too slow to support real-time scrolling. It must be possible to turn this feature off. This would be better when the rendering algorithm is fast and when the rendered result bears little resemblance to the original image. Requirement 5. The preview must support zooming. Viewing a rendered image at different scales is very useful for a wide range of plug-ins. Open issue: Should the preview accept arbitrary floating point numbers as scale factors or should it only accept a more limited set of different magnifications, e.g. of the form 1/n and n, where n is an integer. The latter approach can be more efficient in the implementation. It would even be more efficient when the preview only accepted only a limited set of magnifications, e.g 1/16, 1/15, ... 1/2, 1, 2, ... 16, because specialized code could be written for each magnification. Requirement 6. The preview must contain an optional GUI for zooming. A standard GUI for zooming the preview increases the uniformity of plug-ins and makes life easier for plug-in writers. It must be possible to hide the zooming GUI for previews that either don't support zooming or use a different interface. Open issue: What should the GUI look like? A commonly used approach is to have a + and - button and a label to show the current scale. Another suggestion was to use spin-buttons. Because it seems most desirable that the scaling factors are more or less exponential the standard Gtk spinbuttons are not very useful. The first release of the preview widget will use + and - buttons. Requirement 7. The preview must be able to handle both scaled and unscaled rendered data. In some cases the rendering algorithm may be able to produce a scaled version of its outputs. In many cases the rendering algorithm cannot easily produce scaled data and then the preview should do the scaling. Requirement 8. The scaling algorithm must be stable under scrolling. The user must have the impression of scrolling through a fixed scaled version of the image. When the scaling algorithm is not stable, the preview will flicker during the scroll, which is highly annoying. In most cases this is caused by rounding errors. It is surprisingly difficult
Re: [Gimp-developer] Preview requirements
* Ernst Lippe [EMAIL PROTECTED] [030226 14:04]: Non-requirement 1. Preview the rendered results in the original image window. The rendered image should be shown in the original image window. Comment: This is one of the suggestions from the GUAD3C meeting. It does not seem relevant for the preview widget. It is relevant in terms of providing a consistent user interface, the place in a plug-in's GUI it is natural to place a toggle that controls wether the canvas is updated with the preview or not. Is in relation to other preview controls. The code neccesary to do this at the moment is quite complex, and involves creating temporary layers, messing with the undo state of gimp and such. The preview code already wants to be a proxy for rendering smaller previews using the same API calls as for already modifying the actual image, it thus seems like a natural place to add, or at least think about such functionality. /Øyvind K. -- .^. /V\Øyvind Kolås, Gjøvik University College, Norway /(_)\ [EMAIL PROTECTED],[EMAIL PROTECTED] ^ ^ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Preview requirements
Hi, Ernst Lippe [EMAIL PROTECTED] writes: There are two possible GUI styles: dragging in the preview and using scrollbars. These could also be combined. Open issue: Scrollbars make the widget visually bigger and makes its internal structure more complicated. The alternative of giving the preview widget two GtkAdjustments, that can be used by the developer to wrap the widget with scroll-bars, does not work when the preview widget has a visible scroll-bar and/or zoom controls. Scroll-bars will not be supported in the first release of the preview widget. I don't understand the problem here. IMO using two adjustments to control the displayed area is very convenient and makes it perfectly easy to add scroll-bars. I'd suggest you try to come up with an API that uses adjustments. Perhaps you could outlines what problems you see here. Open issue: What should the GUI look like? A commonly used approach is to have a + and - button and a label to show the current scale. Another suggestion was to use spin-buttons. Because it seems most desirable that the scaling factors are more or less exponential the standard Gtk spinbuttons are not very useful. The first release of the preview widget will use + and - buttons. please consider to use the icons provided by GTK+: http://developer.gnome.org/doc/API/2.0/gtk/gtk-Stock-Items.html#GTK-STOCK-ZOOM-IN-CAPS http://developer.gnome.org/doc/API/2.0/gtk/gtk-Stock-Items.html#GTK-STOCK-ZOOM-OUT-CAPS Requirement 10. The preview must emit a signal when the user has scrolled or zoomed the preview. This signal can be used to synchronize multiple previews (e.g. see Filter Pack). This signal should contain information about the new position and/or scale. This signal will be emitted before the preview attempts to update the rendered image. The signal will only be emitted when the preview was scrolled by the user via the GUI. The signal will not be emitted when scrolling or zooming through the API. I'd suggest not to include information about the new position and/or scale in the signal but to provide a way to retrieve this information from the preview widget. 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. Requirement 11. The preview should have an option to emit signals about the scrolling position while the user is still scrolling the image. For efficiency reasons it is in general desirable that the scrolling signal is only emitted when the user has stopped scrolling. However, when the plug-in developer wants to synchronize scrolling multiple previews this signal must also be emitted during the scroll. You should probably model this after gtk-range-set-update-policy(): http://developer.gnome.org/doc/API/2.0/gtk/GtkRange.html#gtk-range-set-update-policy 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. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Preview requirements
Hi, Øyvind Kolås [EMAIL PROTECTED] writes: * Ernst Lippe [EMAIL PROTECTED] [030226 14:04]: Non-requirement 1. Preview the rendered results in the original image window. The rendered image should be shown in the original image window. Comment: This is one of the suggestions from the GUAD3C meeting. It does not seem relevant for the preview widget. It is relevant in terms of providing a consistent user interface, the place in a plug-in's GUI it is natural to place a toggle that controls wether the canvas is updated with the preview or not. Is in relation to other preview controls. The code neccesary to do this at the moment is quite complex, and involves creating temporary layers, messing with the undo state of gimp and such. The preview code already wants to be a proxy for rendering smaller previews using the same API calls as for already modifying the actual image, it thus seems like a natural place to add, or at least think about such functionality. I think that we should not attempt to implement this feature in this development cycle. It's already almost too late for the preview widget as it is proposed here. Let's don't make it even more complex. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Preview requirements
On 26 Feb 2003 14:24:17 +0100 Sven Neumann [EMAIL PROTECTED] wrote: Hi, Ernst Lippe [EMAIL PROTECTED] writes: There are two possible GUI styles: dragging in the preview and using scrollbars. These could also be combined. Open issue: Scrollbars make the widget visually bigger and makes its internal structure more complicated. The alternative of giving the preview widget two GtkAdjustments, that can be used by the developer to wrap the widget with scroll-bars, does not work when the preview widget has a visible scroll-bar and/or zoom controls. Scroll-bars will not be supported in the first release of the preview widget. I don't understand the problem here. IMO using two adjustments to control the displayed area is very convenient and makes it perfectly easy to add scroll-bars. I'd suggest you try to come up with an API that uses adjustments. Perhaps you could outlines what problems you see here. 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. I am not a great fan of using scrollbars for the preview. They make the widget a lot bigger and scrollbars are not easy to use with small previews. When there really is an overwhelming demand for scrollbars, we will probably add them. BTW, the most recent implementation uses adjustments for the position and the scale. Open issue: What should the GUI look like? A commonly used approach is to have a + and - button and a label to show the current scale. Another suggestion was to use spin-buttons. Because it seems most desirable that the scaling factors are more or less exponential the standard Gtk spinbuttons are not very useful. The first release of the preview widget will use + and - buttons. please consider to use the icons provided by GTK+: http://developer.gnome.org/doc/API/2.0/gtk/gtk-Stock-Items.html#GTK-STOCK-ZOOM-IN-CAPS http://developer.gnome.org/doc/API/2.0/gtk/gtk-Stock-Items.html#GTK-STOCK-ZOOM-OUT-CAPS OK. Requirement 10. The preview must emit a signal when the user has scrolled or zoomed the preview. This signal can be used to synchronize multiple previews (e.g. see Filter Pack). This signal should contain information about the new position and/or scale. This signal will be emitted before the preview attempts to update the rendered image. The signal will only be emitted when the preview was scrolled by the user via the GUI. The signal will not be emitted when scrolling or zooming through the API. I'd suggest not to include information about the new position and/or scale in the signal but to provide a way to retrieve this information from the preview widget. This is just my default multi-threading paranoia. When you have multiple variables that can be updated in a multi-threading environment, it is in general wise to use copies that are known to be consistent with one another. I don't really know how Gtk uses threading, so perhaps it is not useful to include the information. 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. 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. greetings, Ernst ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Preview requirements
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. I'd suggest not to include information about the new position and/or scale in the signal but to provide a way to retrieve this information from the preview widget. This is just my default multi-threading paranoia. When you have multiple variables that can be updated in a multi-threading environment, it is in general wise to use copies that are known to be consistent with one another. I don't really know how Gtk uses threading, so perhaps it is not useful to include the information. Using threads with GTK+ is a pain to get right and in almost all cases it is unnecessary. If an application has a need for threads it is desirable to code it in a way that assures that only one thread updates the GUI directly. That said, I don't think you need to worry about threads here. The solution I suggested would still be sufficiently thread-safe. 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. 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. 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, pcg( Marc)@goof(A.).(Lehmann )com 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
[Gimp-developer] gimp-perl moved into its own CVS module
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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Error in Script-fu !
When executing from the script-fu console, don't supply a value for the run_mode flag. Be sure to supply a number and not a string for the value of font size. Like this: (script-fu-alien-glow-logo hello 150.0 -*-utopia-bold-r-*-*-150-*-*-*-*-*-*-* '(255 0 0)) Helvetix On Wed, Feb 26, 2003 at 09:43:29PM +0100, Branko Collin wrote: On 26 Feb 2003, at 10:30, Valter Mazzola wrote: i'm executing this line in gimp 1.2.3 Script-Console , linux Mandrake 9.0 intel: = (script-fu-alien-glow-logo 0 hello 150 -*-utopia-bold-r-*-*-150-*-*-*-*-*-*-* '(255 0 0) ) the console gives: ERROR: wta(1st) to quotient (errobj hello) I don't know, it looks like it should work, but it doesn't. -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ 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 +--
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
-=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
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] Status of MMX code in The GIMP
Folks, I haven't seen anyone respond to Sven's message. But this is about the right sized thing for me to help with. So barring the advent of someone with more time, I am willing and able to take on the MMX code implementation for GIMP. My recommendation is that current development proceed without expecting the current MMX code to work. Sven, et alia, can either remove it or leave it in place as a warning to others. When I have something ready to be integrated, we can syncronise then. Hopefully, that will be before 1.4 in a reasonable amount of time. But if not, it will be just as fine post 1.4 as well as to use it with GEGL. Helvetix ___ 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] Preview requirements
On 26 Feb 2003, at 14:03, Ernst Lippe wrote: A preview widget for plug-ins is one of these items that has been on the Gimp todo list for a long time. In order to get some feedback from other developers we have compiled a list of requirements for a preview widget. The list is based on our own experiences and previous discussions on this mailing list. Our goal is a preview widget that could be used by most plug-ins. I am not a programmer, and I don't know if the following is part of what you're trying to build. Sometimes, a rendering algorithm is very slow. A user should be able to switch off the automatic rendering of a preview. -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Error in Script-fu !
On 2003-02-26 at 2143.29 +0100, Branko Collin typed this: On 26 Feb 2003, at 10:30, Valter Mazzola wrote: i'm executing this line in gimp 1.2.3 Script-Console , linux Mandrake 9.0 intel: = (script-fu-alien-glow-logo 0 hello 150 -*-utopia-bold-r-*-*-150-*-*-*-*-*-*-* '(255 0 0) ) the console gives: ERROR: wta(1st) to quotient (errobj hello) I don't know, it looks like it should work, but it doesn't. i wonder where you got your fonts from. utopia is missing from the sharefonts i got from debian. carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] help needed for reorganization of Preferencesdialog
On Tue, 2003-02-25 at 13:26, Sven Neumann wrote: Do you have any specifics on what you're looking at changing - are there some bug reports that suggest a change is needed in the Preferences? It would help if there were since, at present, I haven't see many problems with the Preferences layout from my own perspective. I've added one more entry to the Image Window page today and found that it grew too large while other pages are somewhat empty. I think it should be possible to get a more balanced layout. I'd also appreciate if a native speaker could review the individual entries. Of course if you say that all is fine as is, that's OK with me as well. You should perhaps announce that you are working on this on gimp-developer... I've grabbed the CVS stuff (had to update a few build tools, but that went smoothly) and have built the latest. I'll be looking over the prefs stuff this week and, with luck, will get you some feedback early next week. PS: I forwarded this to the list, so they know I'm working on it. -- Michael J. Hammel | If I ever get rich, I hope I'm not mean to poor The Graphics Muse | people, like I am now. [EMAIL PROTECTED] | Deep Thoughts by Jack Handey http://www.graphics-muse.com ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
