Re: [Gimp-developer] RFC: Tool Plug-ins
Hi, Nathan C Summers [EMAIL PROTECTED] writes: Some horrible kludge could also be dreamed up involving GTKPlugs. That would move the windowing system dependance down to the GDK level, but would also make things ineligant, and it would be difficult to get it to work in all cases, especially with an unreliable plug-in. GtkPlug is an X11-only thing just as GtkSocket; it is not implemented on any other platform that GDK has been ported to. The only problem with this solution is that the api that in-process and out-of-process components of the GIMP, while similar in nature, are slightly different, especially in terms of the names of the functions used. These differences will have to be reconciled, either by making the functions have the same names, or by writing some kind of wrapper such that they can be used by either. IMO the tool API needs to be reviewed anyway. I'm definitely all for pluggable tools. For the moment I thought about paint tools mainly. Is that what you had in mind too or did you think tools in general? I very much welcome your idea, but I think before any such code is written, we should solve the remaining issues in the tools system. That is mainly GUI/functionality separation. There needs to be a way for the tools to register their parameters so that GIMP's GUI can choose from a bunch of generic tool info widgets and create a tool info dialog. Then, no tool should use any GTK+/GDK functions nor should it receive GDK events directly. Once this separation (that we've already started) is completed, we should have a reasonable tool API and it should be easy to define an interface that can be exported in order to allow plug-in and module tools. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Can't unsubscribe?
Hello all I now for some time tried to unsubscribe from this list. Unfortunately the mechanism to do so is broken. I tried to unsubscribe as told in the mails but got the attached response. Problem is, I don't anymore now my password. So I asked for help and got the answer that I could get my password from http://lists.xcf.berkeley.edu/list...(and.so.on). Problem here is, I can't get a connection to that webserver. I always get a connection-refused message. I tried it on two computers here in germany (one in the university net and one where I work). So. How do I unsubscribe? Sorry to bother you. -- cu --== Jerri ==-- Homepage: http://www.jerri.de/ ICQ: 54160208 ---BeginMessage--- This is an automated response. There were problems with the email commands you sent to Mailman via the administrative address [EMAIL PROTECTED]. To obtain instructions on valid Mailman email commands, send email to [EMAIL PROTECTED] with the word help in the subject line or in the body of the message. If you want to reach the human being that manages this mailing list, please send your message to [EMAIL PROTECTED]. The following is a detailed description of the problems. * unsubscribe Usage: unsubscribe password [email-address] ---End Message--- msg01633/pgp0.pgp Description: PGP signature
Re: [Gimp-developer] BW digital, compose w/weighted color channels?
On Monday 17 December 2001 20:18, [EMAIL PROTECTED] wrote: snip Is there some combination of existing functions that would let you re-compose an image as: 0% red, 50% green, 50% blue (i.e., a red-blocking filter) Is there some way to use blending of layers and opacity to do this? Or some other tools or scripts? Maybe this is more a question for gimp-user, but since it's here...It's possible, but a bit tricky. Here's what I can come up with (using your 0:50:50 example): Decompose the image into R, G and B images. For each channel image, add a greyscale layer, black for 0% for that channel, white for 100%, or anything in between. In your example, red would get a black layer on top while red and green would get 128,128,128-coloured layers. Set the layer mode on these new layers to multiply. Flatten the R, G and B images. Create a new image the size of the others, and add three layers, a red one (255, 0, 0), a green one (0, 255, 0) and a blue one (0, 0, 255). Set the layer mode to addition for the topmost two layers. Now add layer masks to each of the layers, and paste the corresponding channel image into the layer masks. In your example, this would give you 0*R + 0.5*G + 0.5*B, which is the image you're after. The only problem I can see is that you might run into rounding errors, 8 bits isn't that much accuracy, but given the simplicity of the operation I think you should be fine. I think this would also be easy to make into a script, but I'll leave that to someone else. Lourens ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] BW digital, compose w/weighted color channels?
On Monday 17 December 2001 20:47, Lourens Veen wrote: snip - complicated stuff I just realised that you could just add a layer with colour (0, 255, 255) and put it in front of your image, then set its layer mode to multiply. Much easier. Brightness might be a problem though, make sure your highest percentage is always equal to 255 (so for 25%/75% you would do 85/255) and I think it should be ok. Lourens ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Can't unsubscribe?
On 17 Dec 2001, at 20:39, Gerhard Siegesmund wrote: I now for some time tried to unsubscribe from this list. Unfortunately the mechanism to do so is broken. I tried to unsubscribe as told in the mails but got the attached response. Problem is, I don't anymore now my password. So I asked for help and got the answer that I could get my password from http://lists.xcf.berkeley.edu/list...(and.so.on). Problem here is, I can't get a connection to that webserver. I always get a connection-refused message. I tried it on two computers here in germany (one in the university net and one where I work). So. How do I unsubscribe? Sorry to bother you. If all else fails, try to bounce messages that come from the list. With any luck, mailman has been set-up to unsubscribe people whose mail has been bouncing for a few days. -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] RFC: Tool Plug-ins
On 17 Dec 2001, Sven Neumann wrote: Hi, Nathan C Summers [EMAIL PROTECTED] writes: Some horrible kludge could also be dreamed up involving GTKPlugs. That would move the windowing system dependance down to the GDK level, but would also make things ineligant, and it would be difficult to get it to work in all cases, especially with an unreliable plug-in. GtkPlug is an X11-only thing just as GtkSocket; it is not implemented on any other platform that GDK has been ported to. Oh yes, I remember that now. After I rejected GtkPlug I forgot all the reasons why. :) I'm disapointed they didn't make it more windowing system agnostic. Windows, at least, is perfectly capible of something like GtkPlug/GtkSocket. The only problem with this solution is that the api that in-process and out-of-process components of the GIMP, while similar in nature, are slightly different, especially in terms of the names of the functions used. These differences will have to be reconciled, either by making the functions have the same names, or by writing some kind of wrapper such that they can be used by either. IMO the tool API needs to be reviewed anyway. I'm definitely all for pluggable tools. For the moment I thought about paint tools mainly. Is that what you had in mind too or did you think tools in general? Well, tools in general, although the paint tools are an important enough subset that they probably could benefit from special-case treatment. I very much welcome your idea, but I think before any such code is written, we should solve the remaining issues in the tools system. That is mainly GUI/functionality separation. There needs to be a way for the tools to register their parameters so that GIMP's GUI can choose from a bunch of generic tool info widgets and create a tool info dialog. I agree completely. Then, no tool should use any GTK+/GDK functions nor should it receive GDK events directly. Once this separation (that we've already started) is completed, we should have a reasonable tool API and it should be easy to define an interface that can be exported in order to allow plug-in and module tools. I agree to this as well. What specifically do you have in mind to replace the current system of sending the (essentiall) raw GtkEvent to the tool? I thought about them having an identical interface with the PDB to reduce the amount of code needed, but really, scripting and interactive work is different enough that the interfaces that a different interface is needed. Also, I though about making the PDB interface to all tools identical, but the PDB intefaces are really much useable as they are. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
