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
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] B&W digital, compose w/weighted color channels?
On Monday 17 December 2001 20:47, Lourens Veen wrote: > 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] B&W digital, compose w/weighted color channels?
On Monday 17 December 2001 20:18, [EMAIL PROTECTED] wrote: > > 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
[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 --- Begin Message --- 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 [] --- End Message --- msg01633/pgp0.pgp Description: PGP signature
[Gimp-developer] B&W digital, compose w/weighted color channels?
Recently there's been a lot of excitement in the digital camera world among former B&W film afficianodos who are simulating the use of colored filters by manipulating color channels prior to converting a digital image to greyscale. Photoshop has a feature that lets you weight color channels when you recompose them. In Gimp, you can decompose color channels by: Image->Color->Decompose and then later: Image->Color->Compose I understand the function of weighting the channels is not there. 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? ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
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] RFC: Tool Plug-ins
Ahh, the blessed holiday known as finals week has arrived. A wonderful respite from that torture known as homework, when all the programming projects and other assignments that one's professors have seen fit to inflict upon their hapless and unsuspecting pupils have finally come to a much welcomed end. Yes, a week of rejoicing heard from thousands of voices, simultainously exclaiming their utter glee! What better time in the life of a college student could there be? Just as I promised, I have been studying how to implement tool plug-ins. There is a basic tradeoff of stability verses speed and latency that has to be evaluated. Current plug-ins run as a separate process, in a separate address space, so that a buggy plug-in cannot cause the entire gimp to crash. This is highly desirable because a user can run a new plug-in with a high degree of confidence that they won't loose data if it fails. On the otherhand, there are issues of IPC bandwidth and latency that arrise when out-of-process plug-ins are used. On a Linux machine with shared memory enabled, these limitations are not a big deal for plug-ins. This is true (to varying degrees) on other platforms as well. Most machines running any modern Unix in most instances perform quite acceptably under this system. However, latency is far less tolerable in an interactive tool. While much latency can be eliminated with a well designed caching/prefetching scheme, the basic problem is transmitting the mouse events to the plug-in process with minimal latency. I've heard that it's possible to get X to deliver events to another process, and I know that it is possible to get Windows to do so, but this would involve a level of windowing system-specific coding that I don't think is appropriate for the gimp codebase. Depending on such an unusual feature also probably significantly decreases the flexiblity of the source -- or in other words, limits the kinds of systems that Gimp can be ported to. 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. So it seems that the best solution for tool plug-ins, slow as it might seem, is to have the gimp process send the tool plug-in the events using the same gimpwire protocol used for normal plug-ins. This also has the advantage of allowing the maximum amount of code reuse possible. We may very well want to expose event handlers to the PDB, but if so, some kind of system needs to be designed so that the overhead of a pdb lookup is not required for every event. Which brings us to implementation on the gimp side. The obvious solution is to write a stub tool object that knows how to communicate with the tool plug-in. Whenever a tool plug-in registers itself at startup, the tool plug-in, in the form of the stub, gets registered with the tool manager. A better solution for stable tools is to have them loaded into the GIMP process space. This is fairly trivial to do, thanks to GTypeModule. Since it's not possible to know ahead of time whether a given plug-in will be stable and whether a particular user would rather a certain plug-in be faster, it seems best to make it so that tool plug-ins can work as either. This simply requires that out-of-process tool plug-in modules be loaded by a skeleton such as a (much improved) version of plugin-helper. Then a user interface can be made such that the user can decide whether speed or stability is prefered. This should be on an individual basis so that a user can make commonly used tools fast, while making that one tool that keeps crashing run in a separate space. 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. Well, that is enough writing for tonight. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
