Re: [Gimp-developer] Plug-in preview API proposal
On Thu, Apr 03, 2003 at 04:07:34AM +0200, Ernst Lippe wrote: On Thu, 03 Apr 2003 02:15:42 +0200 Excuse me, but which reentrancy problem has been eliminated? Does it mean the render function no longer needs to be reentrant? Yes, just added some book-keeping to preview, and it seems to work. That's great. Then I can answer your original question, yes, as a below-average-plug-in-developer, I'd use it. Just please update the API reference, it still says the render function has to be reentrant in quite a few places. Regards, Yeti ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Plug-in preview API proposal
On Thu, Apr 03, 2003 at 01:15:31AM +0200, Ernst Lippe wrote: P.S. I just modified my preview so that the re-entrancy problem has been eliminated. Excuse me, but which reentrancy problem has been eliminated? Does it mean the render function no longer needs to be reentrant? Regards, Yeti P.S.: Regarding the name, when I've seen the last suggestions, GimpWWAAN (Widget Without Any Acceptable Name) seem to be the most accurate... :-) ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Plug-in preview API proposal
On Mon, Mar 31, 2003 at 10:11:36PM +0200, Ernst Lippe wrote: On Mon, 31 Mar 2003 11:21:06 -0800 (PST) Nathan Carl Summers [EMAIL PROTECTED] wrote: (off-the-cuff) Perhaps GimpThumbnail? It is a nice short name, but I have the impression that a thumbnail is a reduced size version of the original image, and for most plug-ins I would expect that the preview normally shows a small part of the image at its real size. And I'm afraid GimpThumbnail could be useful for something else (e.g., thumbnails ;-) and then this thing would have to receive some other name... What about something like GimpProofView? - it't not longer than GimpThumbnail - it resembles GimpPreview - proof is a relatively good word (though mostly used in printing only, in this sense) - the view is just a tag, but proof alone is strange It's quite easy to invent new words and phrases for me, thanks to my miserable English ;-) but proof view seems to be already invented, according to Google. Regards, Yeti ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] tile row hints (was: caching considerations ingegl)
On Tue, Mar 11, 2003 at 01:07:21PM +0100, Raphal Quinet wrote: On Tue, 11 Mar 2003 09:46:49 +, Adam D. Moss [EMAIL PROTECTED] wrote: [...] The idea of rehash-on-dirty would be to catch identical tiles, even accidentally-identical tiles (like great masses of transparent tiles, presuming that you scrub the RGB data of a transparent pixel; the row-hints stuff has been doing this and potentially breaking the ill-advised anti-erase feature for 100 years now and no-one has complained), that the normal COW routes miss. Hmmm... This is interesting. I didn't know that a side effect of the row-hints would be to discard the RGB data from fully transparent pixels. Of course, this makes sense and this is the right thing to do. But this also means that some plug-ins such as Noisify should definitely never use the invisible RGB data in any operation, because the results could be (very) different if some tiles are swapped out. See the discussion in: http://bugzilla.gnome.org/show_bug.cgi?id=72853 Hm. Though I see the posibility to temporarily make some area transparent just to give some its parts nonzero opacity later as a useful feature, the rest of world obviously thinks otherwise ;-( Yeti ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] caching considerations in gegl
On Tue, Mar 11, 2003 at 07:23:03PM +0100, Sven Neumann wrote: I don't agree. The obvious solution whenever manipulation of the alpha channel is desired is to use a layer mask. For people on this list. But most people I know would be able to find the solution I described -- purely experimentally -- while they don't know there's anything like layer mask, and mabye will never find out. Yeti ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: caching considerations in gegl
On Tue, Mar 11, 2003 at 12:33:14PM -0800, Daniel Rogers wrote: Or, as I suggested in an earlier email, but I don't think was stated very clearly, implement anti-erase as a layer mask (whether or not the user can actually see the extra layer). If you want to implement anti-erase as a layer mask, then for antierase to be available, this layer mask (not shown to user) has to be present all the time (if not, the information needed for anti-erase would be lost). But how this situation differs from separate alpha channel -- except for storing the same data in a much more complex way than necessary? Or did I missed something? Yeti ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: caching considerations in gegl
On Tue, Mar 11, 2003 at 02:53:45PM -0800, Daniel Rogers wrote: Although back on the topic of anti-erase, I think that the only way to do anti-erase correctly is with another layer. Once alpha goes to zero, the pixel no larger part of the sampled image. OK, I could use alpha in a wrong sense, it's a matter of definition, and let's agree on yours (though I wonder how's called the object alpha==0 pixels are part of, because I can draw on them, unlike pixels outside layer boundaries, so they exist and are part of something). But then I, as a user, don't care about alpha, and what I really care about is transparency. So everything what was said can be repeated, only s/alpha/transparency/. My need for pixels retaining their properties even in invisible state didn't disappear. Yeti ___ 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
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] http://developer.gimp.org/
On Mon, Feb 10, 2003 at 03:37:26PM +0100, Sven Neumann wrote: It's broken on Netscape 4.7 (disabling Style Sheets helps, but it looks rather ugly then). There is text behind the image etc. But I guess it's nice if displayed correctly. I don't think we have to care about browsers as obsolete and known-to-be-broken as Netscape 4.7. The best thing one can do with NN 4.x is [IMHO] to (a) detect it with PHP or whatever and don't include style sheets, or include a different one -- this is prohibited IIUC (b) use some dirty trick http://centricle.com/ref/css/filters/ to make it see no/other/only part of the style sheet, e.g. @import url(bigstyle.css) Since people still use NN 4.x, they should be able to display the pages in some readable (not nice) form, so I suggest hiding CSS for NN 4.x with @import. Yeti ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: http://developer.gimp.org/
On Mon, Feb 10, 2003 at 11:31:42AM -0500, Carol Spears wrote: i read of a rather elegant solution. apparently Netscape refuses to read the link/link tag if it contains the media attribute. so you can set it up this way: link rel=stylesheet type=text/css href=/style/dgo-ns.css link rel=stylesheet type=text/css href=/style/dgo.css media=all with quotes please link rel=stylesheet type=text/css href=/style/dgo-ns.css link rel=stylesheet type=text/css href=/style/dgo.css media=all and netscape will happily skip the second stylesheet. OK, and when one wants everything in one CSS file, he/she can make use of NN's inability to parse comments (so-called Caio's Hack), this is probably even better solution: /*/*/ some stuff NN won't see /* */ Yeti ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] gimpbilinear and alpha
Hello,
the gimp_bilinear_rgba () function (libgimpcolor/gimpbilinear.c)
handles alpha channel as if Gimp used premultiplied alpha.
Since all Gimp core uses separated alpha, I suggest the
attached patch (against CVS HEAD). This patch itself seems
to fix alpha handling in two plug-ins using gimp_bilinear_rgba ():
#72876 Incorrect RGBA resampling in Map Object plug-in
#105796 Incorrect RGBA resampling in Lighting Effects plug-in
(this one may be not fully fixed)
Beside that all the remaining functions in gimpbilinear
operate on individual channels (colors) and not pixels.
Plug-in authors using them hardly can handle alpha blending
correctly. IMHO functions operating on whole pixels are
needed more than the existing ones (though they are also
useful).
Regards,
Yeti
--- gimp.orig/libgimpcolor/gimpbilinear.c 2002-11-20 22:29:15.0 +0100
+++ gimp/libgimpcolor/gimpbilinear.c2003-02-07 16:34:55.0 +0100
@@ -173,6 +173,7 @@
{
gdouble m0, m1;
gdouble ix, iy;
+ gdouble a0, a1, a2, a3, alpha;
GimpRGB v;
g_assert (values != NULL);
@@ -188,33 +189,41 @@
ix = 1.0 - x;
iy = 1.0 - y;
- /* Red */
+ a0 = values[0].a;
+ a1 = values[1].a;
+ a2 = values[2].a;
+ a3 = values[3].a;
- m0 = ix * values[0].r + x * values[1].r;
- m1 = ix * values[2].r + x * values[3].r;
+ /* Alpha */
- v.r = iy * m0 + y * m1;
+ m0 = ix * a0 + x * a1;
+ m1 = ix * a2 + x * a3;
- /* Green */
+ alpha = v.a = iy * m0 + y * m1;
- m0 = ix * values[0].g + x * values[1].g;
- m1 = ix * values[2].g + x * values[3].g;
+ if (alpha 0)
+{
+ /* Red */
- v.g = iy * m0 + y * m1;
+ m0 = ix * a0 * values[0].r + x * a1 * values[1].r;
+ m1 = ix * a2 * values[2].r + x * a3 * values[3].r;
- /* Blue */
+ v.r = (iy * m0 + y * m1)/alpha;
- m0 = ix * values[0].b + x * values[1].b;
- m1 = ix * values[2].b + x * values[3].b;
+ /* Green */
- v.b = iy * m0 + y * m1;
+ m0 = ix * a0 * values[0].g + x * a1 * values[1].g;
+ m1 = ix * a2 * values[2].g + x * a3 * values[3].g;
- /* Alpha */
+ v.g = (iy * m0 + y * m1)/alpha;
+
+ /* Blue */
- m0 = ix * values[0].a + x * values[1].a;
- m1 = ix * values[2].a + x * values[3].a;
+ m0 = ix * a0 * values[0].b + x * a1 * values[1].b;
+ m1 = ix * a2 * values[2].b + x * a3 * values[3].b;
- v.a = iy * m0 + y * m1;
+ v.b = (iy * m0 + y * m1)/alpha;
+}
return v;
}
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] IFSCompose and bugzilla question
Hello,
I fixed and improved a few thing in the IFS Compose plugin.
I know I should use bugzilla. The reasons I write here are:
The existing bugreports are 1.2, while I fixed it in 1.3
(except #82472 fix, which I also backported to 1.2), I'm not
sure how to handle this. Some issues were just side effects
of an underlying real problem (#82466, #82473). Bug #82470
I fixed as a side effect of a larger change. The other
things are not in bugzilla at all (like Save/Load), I don't
have separate patches for them, and don't like the
perspective of creating a dozen of individual reports and
separating the patches only for the sake of bugzillization
of the whole thing.
Please critize/check/apply the attached patch (against
1.3.11) and tell me what to do with:
nor #82472 Flip button doesn't act on all selected objects
(I attached the backport to this one)
min #82466 Toggling between Simple/Full in IfsCompose changes preview
min #82473 IfsCompose disable Undo/Redo button when nothing to be undo
enh #82470 IfsCompose filter: location of 'New' and 'Delete' button not...
and what to do generally in situations like this.
IFS Compose changes:
* implemented Save and Load
* made Flip to act on all selected transformations, fixes #82472
* moved New/Delete from action area below other buttons, fixes #82470
* fixed Delete to be insensitive when num of transforms == 2
* Undo/Redo made insensitive when there's nothing to update, and avoided
creation of bogus undo levels during color updates, fixes #82466, #82473,
and other queer undo/redo behaviour
* set alpha of all colors to 1.0 -- ifscompose ignores alpha anyway, and
default value (122???) makes the color selection dialog pretty confusing
* made Undo, Redo, Select All, Recompute Center menu items visible as buttons,
so people who don't try right clicking in the design area know about them
* changed confusing numeric frame title to Transformation n
* changed the button layout to two centered groups (it looked approximately
this way before too, but probably only incidentally)
Thanks in advance,
Yeti
--- gimp-1.3.11.orig/plug-ins/ifscompose/ifscompose.c 2002-12-03 20:42:41.0
+0100
+++ gimp-1.3.11/plug-ins/ifscompose/ifscompose.c2003-02-01 23:25:34.0
++0100
@@ -169,6 +169,12 @@
GtkWidget *stretch_button;
gint stretch_handler;
+ GtkWidget *undo_button;
+ GtkWidget *undo_menu_item;
+ GtkWidget *redo_button;
+ GtkWidget *redo_menu_item;
+ GtkWidget *delete_button;
+
GtkWidget *preview;
guchar*preview_data;
gint preview_iterations;
@@ -278,6 +284,10 @@
gpointer data);
static void ifs_compose_delete_callback (GtkWidget *widget,
gpointer data);
+static void ifs_compose_load_callback (GtkWidget *widget,
+ gpointer data);
+static void ifs_compose_save_callback (GtkWidget *widget,
+ gpointer data);
static void ifs_compose_ok_callback (GtkWidget *widget,
GtkWidget *window);
@@ -300,6 +310,8 @@
static gint undo_num = 0;
static gint undo_start = 0;
+static gchar ifsfile_path[PATH_MAX] = { '\0' };
+
/* num_elements = 0, signals not inited */
static IfsComposeVals ifsvals =
{
@@ -387,8 +399,6 @@
INIT_I18N_UI();
- /* kill (getpid(), 19); */
-
/* Get the active drawable */
active_drawable = gimp_drawable_get (param[2].data.d_drawable);
@@ -786,10 +796,10 @@
GIMP_STOCK_RESET, ifs_compose_defaults_callback,
NULL, NULL, NULL, FALSE, FALSE,
-GTK_STOCK_DELETE, ifs_compose_delete_callback,
+GTK_STOCK_OPEN, ifs_compose_load_callback,
NULL, NULL, NULL, FALSE, FALSE,
-GTK_STOCK_NEW, ifs_compose_new_callback,
+GTK_STOCK_SAVE, ifs_compose_save_callback,
NULL, NULL, NULL, FALSE, FALSE,
GTK_STOCK_CANCEL, gtk_widget_destroy,
@@ -850,10 +860,10 @@
/* Iterations and preview options */
- hbox = gtk_hbox_new (FALSE, 4);
+ hbox = gtk_hbox_new (TRUE, 4);
gtk_box_pack_start (GTK_BOX (main_vbox), hbox, FALSE, FALSE, 0);
- alignment = gtk_alignment_new (1.0, 0.5, 0.5, 0.0);
+ alignment = gtk_alignment_new (0.5, 0.5, 0.0, 0.0);
gtk_box_pack_start (GTK_BOX (hbox), alignment, TRUE, TRUE, 0);
util_hbox = gtk_hbox_new (FALSE, 4);
@@ -891,7 +901,7 @@
gtk_widget_show (alignment);
gtk_widget_show (util_hbox);
- alignment = gtk_alignment_new (1.0, 0.5, 0.5, 0.0);
+ alignment = gtk_alignment_new (0.5, 0.5, 0.0, 0.0);
gtk_box_pack_start (GTK_BOX (hbox), alignment, TRUE, TRUE, 0);
util_hbox = gtk_hbox_new (FALSE, 4);
@@ -924,6 +934,70 @@
gtk_widget_show (alignment);
gtk_widget_show (hbox);
+ /* second util row
Re: [Gimp-developer] Re: alpha vs. transparency / translucency
On Thu, Dec 19, 2002 at 12:08:55PM +0100, Sven Neumann wrote: Side effect, will be RGBA be named RGBT everywhere (in user visible interface)? Is not a bit silly to start renaming basic concepts of a field with something else (aka causing differences with reference docs that existed long time ago)? Just wondering. the user shouldn't be confronted with the term RGBA at all. IIRC, this is the case unless she's writing a script or plug-in in which case she is not a user any longer but a developer. Maybe. But how do you say RGBA in less then five words without using the acronym? I think RGBA is one of the terms a Gimp user could learn. BTW, I'm not sure if someone already pointed out Transparency is the oposite of Alpha, so if we changed Alpha to Transparency, not only the word, but also the meaning would change (think about all the hscales, entries and curves). Yeti ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New Gimp FAQ: Call for questions
On Fri, Dec 20, 2002 at 01:14:01PM +1100, Tim Lambert wrote: Stephen J Baker [EMAIL PROTECTED] writes: My #1 FAQ from people where I work is: Q: I'm trying to paint and nothing is happening - what did I do wrong? Yeah, me too. How hard do you think it would be to have a 'novice mode' where gimp detects this and pops up a tip on how to fix things? And we could also add an obtrusive animated paperclip (or paintbrush) giving users funny advices... But seriously, there's a zillion things user can do wrong, if he/she is clueless, and when you finally find them all, the first user you test your novice mode on will find a new one. IMHO novice mode (if ever implemented) should restrict the things user can do to some sane set (simplifying the interface), and not try to turn the Gimp into Eliza Regards, Yeti ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] gimp_coordinates and value_changed
Hello,
could someone please explain me why gimp_coordinates_callback()
does this (libgimpwidgets/gimpwidgets.c:1036):
if (gimp_chain_button_get_active (gcd-chainbutton))
{
g_signal_stop_emission_by_name (G_OBJECT (widget), value_changed);
It may have some esoteric reasons I don't see, but the
practical outcome is when one connects a callback to the
GimpSizeEntry on value_changed, the callback is called
when only when the chain button is disconnected.
Or is there any other way of getting value_changed
delivered when the value changes, which work regardless of
the chain button state? (Disassembling the GtkTable and
connecting directly to spinbuttons/entries doesn't count,
though it surely is a way).
Thanks,
Yeti
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] tile cache size (was Re: The Occasional BugList)
On Thu, Nov 07, 2002 at 06:56:33PM +0100, Raphal Quinet wrote: - A good rule of thumb for setting the tile cache size seems to be: 90% of the memory available when the GIMP is running for the first time, or total amount of memory - 64 MB, whichever is the largest. So the formula would be something like: min (32 MB, max (free * 0.9, total - 64 MB)) Didn't you mean something more like max (32 MB, free * 0.9, total - 64 MB) ? The way you wrote it no one would get more than 32MB, which probably wasn't the point. Yeti ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] GFlare fixes [patch]
); + //gtk_object_set_user_data (GTK_OBJECT (toggle), (gpointer) GF_CIRCLE); + g_object_set_data (G_OBJECT (toggle), gimp-item-data, + GINT_TO_POINTER (GF_CIRCLE)); gtk_signal_connect (GTK_OBJECT (toggle), toggled, GTK_SIGNAL_FUNC (ed_shape_radio_callback), gflare-sflare_shape); @@ -4138,7 +4140,8 @@ toggle = ed-polygon_toggle = gtk_radio_button_new_with_label (shape_group, _(Polygon)); shape_group = gtk_radio_button_group (GTK_RADIO_BUTTON (toggle)); - gtk_object_set_user_data (GTK_OBJECT (toggle), (gpointer) GF_POLYGON); + g_object_set_data (G_OBJECT (toggle), gimp-item-data, + GINT_TO_POINTER (GF_POLYGON)); gtk_signal_connect (GTK_OBJECT (toggle), toggled, GTK_SIGNAL_FUNC (ed_shape_radio_callback), gflare-sflare_shape); 4. It set polygon entry width to 8 pixels using some deprecated function. It's maybe a little too wide w/o it, but that's much better than unusably thin. --- gflare.orig/gflare.c2002-09-06 22:44:43.0 +0200 +++ gflare/gflare.c 2002-11-05 18:50:16.0 +0100 @@ -4148,7 +4151,7 @@ gtk_widget_show (toggle); entry = ed-polygon_entry = gtk_entry_new (); - gtk_widget_set_usize (entry, ENTRY_WIDTH, 0); +// gtk_widget_set_usize (entry, ENTRY_WIDTH, 0); g_snprintf (buf, sizeof (buf), %d, gflare-sflare_nverts); gtk_entry_set_text (GTK_ENTRY (entry), buf); gtk_signal_connect (GTK_OBJECT (entry), changed, Regards, Yeti ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
