[Gimp-developer] dynamic plugin menu
Hi! I've been trying to find a way for a plugin to update menu entries it has initially registered from query() via gimp_install_procedure() When the plugin is being run it wishes to update the menu entries, for instance putting some named presets previously selected in the plugin interface to be easily and directly accessible from the gimp menu without opening plugin interface again. Is there a way to affect menu entries generated by a plugin after it's query() has been called? I thought maybe using gimp_install_temp_proc instead of gimp_install_procedure would do the trick, but documentation says: A temporary procedure is a procedure which is only available while one of your plug-in's real procedures is running. What exactly does it mean while my 'real' procedure is RUNNING? gimp_install_temp_proc does also accept the menu spec, so the procedure should also be available in menu, but at which times? Kind regards ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] dynamic plugin menu
Hello Gena, I tried to browse the source of the script-fu plugin to answer your question, and this is what I came up with: A temporary procedure is a procedure which is only available while one of your plug-in's real procedures is running. That is correct - If you will look at line 107 http://git.gnome.org/browse/gimp/tree/plug-ins/script-fu/script-fu.c#n107, you will see that the plugin is registerd as an extension and not as a regular GIMP plugin. On line 217 and 221, the plugin registers itself as an extension, and this way it allows itself to run from the moment gimp starts up, untill GIMP is exited. When registering an extension instead of a normal GIMP plugin, the run procedure will be called during GIMP's start-up, and the plugin will then be able to register temporary procedures (exactly like the Script-Fu scripts) that will be available untill GIMP exits. Just to show you how the script-fu extension continues to run after it was intialized, look at the list of all the running procedures on your computer and you should see that as long as gimp is open, there is also a procedure called script-fu running. After creating the temporary procedures with your extension, you can unregister them using gimp_uninstall_temp_proc, and the register them again inside another menu. What I suggested is probably not the best way in the world, but it's the only way I can think of. Hope this helps, ~ LightningIsMyName On Tue, Feb 16, 2010 at 10:27 AM, Gena Batsyan gbat...@gmail.com wrote: Hi! I've been trying to find a way for a plugin to update menu entries it has initially registered from query() via gimp_install_procedure() When the plugin is being run it wishes to update the menu entries, for instance putting some named presets previously selected in the plugin interface to be easily and directly accessible from the gimp menu without opening plugin interface again. Is there a way to affect menu entries generated by a plugin after it's query() has been called? I thought maybe using gimp_install_temp_proc instead of gimp_install_procedure would do the trick, but documentation says: A temporary procedure is a procedure which is only available while one of your plug-in's real procedures is running. What exactly does it mean while my 'real' procedure is RUNNING? gimp_install_temp_proc does also accept the menu spec, so the procedure should also be available in menu, but at which times? Kind regards ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] dynamic plugin menu
Hi, On Tue, 2010-02-16 at 14:11 +0200, LightningIsMyName wrote: A temporary procedure is a procedure which is only available while one of your plug-in's real procedures is running. That is correct - If you will look at line 107 http://git.gnome.org/browse/gimp/tree/plug-ins/script-fu/script-fu.c#n107, you will see that the plugin is registerd as an extension and not as a regular GIMP plugin. On line 217 and 221, the plugin registers itself as an extension, and this way it allows itself to run from the moment gimp starts up, untill GIMP is exited. When registering an extension instead of a normal GIMP plugin, the run procedure will be called during GIMP's start-up, and the plugin will then be able to register temporary procedures (exactly like the Script-Fu scripts) that will be available untill GIMP exits. Just to make this clear. The point of being an extension is not being run at start-up. You can have that without making your plug-in an extension. The point of registering as an extension is that your plug-in will install temporary procedures. If you want to be called at every startup, you can get that simply by installing an init_proc handler in the GimpPlugInInfo struct. I don't think though that the extension mechanism should be used for the purpose of being able to install changing menu procedures. It seems like quite some overkill to keep a plug-in process running just for this. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] paint dynamics
I discovered some weeks ago the new Paint Dynamics feature of version 2.7 and the git one, but I would like to find some explanations about its use. One point which bothers me is that I thought there was some way to control the shape of the answer curve between some varying parameter (pressure, velocity, tilt, etc.) and some brush characteristic (opacity, hardness, size, etc.). However, I don't see this anywhere. Where should I search? -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] paint dynamics
On Tue, Feb 16, 2010 at 4:16 PM, Olivier oleca...@gmail.com wrote: I discovered some weeks ago the new Paint Dynamics feature of version 2.7 and the git one, but I would like to find some explanations about its use. One point which bothers me is that I thought there was some way to control the shape of the answer curve between some varying parameter (pressure, velocity, tilt, etc.) and some brush characteristic (opacity, hardness, size, etc.). However, I don't see this anywhere. Curves don't exist in UI yet, because I personally suck at getting GTK to do what I want... If you know somebody with good GTK bending skills willing to help out, direct him/her to us. I could really use some help... -- --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] paint dynamics
Hello, On Tue, Feb 16, 2010 at 4:40 PM, Alexia Death alexiade...@gmail.com wrote: Curves don't exist in UI yet, because I personally suck at getting GTK to do what I want... If you know somebody with good GTK bending skills willing to help out, direct him/her to us. I could really use some help... Can you give some explanations of what is needed? It suprises me that there is a problem with a curves widget, when we can steal most of the code from the existing curves dialog of the curve tool... I would like to know some more about this, maybe this is something that I can do (I probably won't be able to do it since my GTK programming skills aren't so great, but let's give it a try). ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] paint dynamics
On Tuesday 16 February 2010 22:22:17 LightningIsMyName wrote: Can you give some explanations of what is needed? It suprises me that there is a problem with a curves widget, when we can steal most of the code from the existing curves dialog of the curve tool... I would like to know some more about this, maybe this is something that I can do (I probably won't be able to do it since my GTK programming skills aren't so great, but let's give it a try). Curves widget is not a problem. Problem is the general making of Peter's spec[1] so that developers who do know gtk, dont faint in disgust at the sight of the code. for example, one dock needs to hold 2.5 distinct views. the check gird and two very similar variants of curves views switched by the drop down. I cant even imagine a solution for this in gtk terms. [1] http://gui.gimp.org/index.php/Paint_dynamics_specification -- Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] paint dynamics
Hello On Tue, Feb 16, 2010 at 10:45 PM, Alexia Death alexiade...@gmail.com wrote: Curves widget is not a problem. Problem is the general making of Peter's spec[1] so that developers who do know gtk, dont faint in disgust at the sight of the code. for example, one dock needs to hold 2.5 distinct views. the check gird and two very similar variants of curves views switched by the drop down. I cant even imagine a solution for this in gtk terms. [1] http://gui.gimp.org/index.php/Paint_dynamics_specification Wow! This seems to be an amazing idea, and probably extremly long to implement... So let's do some analyzing: 1. We need to implement a check grid. This seems to be pretty simple using a GtkTable (if we pick the simple way), or if we use a GtkTreeView (which can actually show a table) with GtkCellRendererToggle. 2. The painting of the matrix as showed in the specifications seems very hard, and I doubt it worths it. We can easily implement different colors for each row, and users will have to settle for a little border between the columns. If we agree to give up the proposed matrix painting and choose what I suggested, it can be done with GtkTreeView without any special changes, but it will leave the simpler GtkTable our of the question (which is fine with me). 3. Adding the images with the link's color should be a bit tricky, but I assume that it can be done dynamically (by drawing those images after acquiring the link's color, instead of embedding ready bitmaps). 4. Popup window: Part 1 - the curves widget. This can definetly be stolen from the curves tool, no need to work twice. The only needed modification is that we can show some other curves at the background, and that we add min and max arrows. 5. Popup window: Part 2 - switching the tabs. This doesn't seem to bad, especially since we already have similar functionality in the curves tool. only two things seem problomatic: A treeview widget can't have a bitmap in it's header, And adding the bitmaps as the first row is ugly and probably not the right way to do this. The guys on the GTK mailing list will probably be able to help us out here. And another questions is, why do we have the same header images at the bottom? Adding a footer to a GtkTreeView isn't possible. Do we really need that? Here i'm defintly sure it's not worth the coding amount that it will require, and I personally find it confusing. I haven't seen anything that scary in here, but I doubt that I'll have time to touch it in this month. If I implement something like this on a dummy GtkWindow (instead of hacking GIMP's source code, which I don't excel at) as a stand-alone Gtk application, will it help? If so, I'll try to give it a shot. If you want to see how to use the TreeView and the CellRenderer, the gtk-demo program (which comes with GTK) has a nice example under Tree View/List Store. The code is very simple and in one of the columns you'll see the Toggle renderer. for example, one dock needs to hold 2.5 distinct views I haven't understood that sentence. Can you please explain (or, have I referred to it already)? Just one offtopic comment: Some of the icons seem very unintuitive - even as an old GIMP user I'm still confused by the fifth one from the left. What does it stand for? ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] paint dynamics
On Wed, Feb 17, 2010 at 8:24 AM, LightningIsMyName lightningismyn...@gmail.com wrote: Hello On Tue, Feb 16, 2010 at 10:45 PM, Alexia Death alexiade...@gmail.com wrote: 2. The painting of the matrix as showed in the specifications seems very hard, and I doubt it worths it. We can easily implement different colors for each row, and users will have to settle for a little border between the columns. http://www.pygtk.org/docs/pygtk/class-gtktreeview.html Looks like it is possible to disable cell borders (and I think it may be necessary when the cells are small like this-- we want to avoid the borders visually overwhelming the cell content. If we agree to give up the proposed matrix painting and choose what I suggested, it can be done with GtkTreeView without any special changes, but it will leave the simpler GtkTable our of the question (which is fine with me). 3. Adding the images with the link's color should be a bit tricky, but I assume that it can be done dynamically (by drawing those images after acquiring the link's color, instead of embedding ready bitmaps). 4. Popup window: Part 1 - the curves widget. This can definetly be stolen from the curves tool, no need to work twice. The only needed modification is that we can show some other curves at the background, and that we add min and max arrows. 5. Popup window: Part 2 - switching the tabs. This doesn't seem to bad, especially since we already have similar functionality in the curves tool. only two things seem problomatic: A treeview widget can't have a bitmap in it's header, And adding the bitmaps as the first row is ugly and probably not the right way to do this. The guys on the GTK mailing list will probably be able to help us out here. And another questions is, why do we have the same header images at the bottom? Adding a footer to a GtkTreeView isn't possible. Do we really need that? Here i'm defintly sure it's not worth the coding amount that it will require, and I personally find it confusing. I believe that this kind of measure is usually taken when the number of input variables is anticipated to increase (so perhaps you won't be able to see the top and bottom at the same time) I haven't seen anything that scary in here, but I doubt that I'll have time to touch it in this month. If I implement something like this on a dummy GtkWindow (instead of hacking GIMP's source code, which I don't excel at) as a stand-alone Gtk application, will it help? If so, I'll try to give it a shot. If you want to see how to use the TreeView and the CellRenderer, the gtk-demo program (which comes with GTK) has a nice example under Tree View/List Store. The code is very simple and in one of the columns you'll see the Toggle renderer. for example, one dock needs to hold 2.5 distinct views I haven't understood that sentence. Can you please explain (or, have I referred to it already)? I think I understood it: one dockable must hold a) the matrix, b) the input mapping, and c) the output mapping I thought this was a fairly simple problem in GTK terms. 1. Put the matrix inside its own VBox. Pack it at the start of the window. (This may require nesting inside another VBox.) 2. Put the input and output mapping in another VBox (one they share.) in the following manner: 1. Presets (shared between input and output) 2. Inputs selector 3. Outputs selector 4. Curve display (shared?) 5. 'Inputs' label 6. 'Outputs' label 7. Inputs treeview 8. Outputs treeview 9. 'Show current INPUT NAME input' 3. When switching modes, we: 1. If switching to matrix mode, hide the input/output vbox. Show the matrix vbox. Done. 2. If switching away from matrix mode, hide the matrix vbox. 3. If switching to inputs or outputs mode, we need to iterate over the widgets in the VBox; Hide any widgets not specific to the mode in question. I think there is a widget grouping mechanism in GTK that allows for this kind of distinction. That is in fact somewhat ugly. There is probably another solution involving packing the input/output widgets on the fly. That would be neater code-wise, and somewhat slower. I don't know whether the above would argue with the dockable's idea of how tall it ought to be. That might be what Alexia was talking about. Just one offtopic comment: Some of the icons seem very unintuitive - even as an old GIMP user I'm still confused by the fifth one from the left. What does it stand for? It looks like it's probably meant to be 'random'. I got that from the list, not the graphic, though. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Introduction Questions about GSoC2009 Idea: Plugin for image segmentation
Hello guys, I'm thinnking about applying as a student to implement an image segmentation plugin using the technique known as the Image Foresting Transform (IFT) [4], but before that I'd like to introduce myself and ask a couple of questions to make sure our interests match. So here goes: = Introduction = I'm a Computer Science MSc student at UNICAMP (from Brazil, we've a great history of participations on GSoC), and I have been working with Linux for about 4 years. I've just been admitted to the graduate program but I've been researching image processing algorithms (mostly related to object segmentation on images and videos) for the past 2 years. Before that I have worked with robotics, so I have experience on: * Building C/C++ modules applied to indoor navigation of robots for about 2 years as a Research Scholarship Holder -- This project was also applied to the mix of robotics and entertainment, and involved a lot of C/Shell Script hacking and kernel adaptation (also some Java coding). * Developing image and video segmentation algorithms [1,2,3] using the Image Foresting Transform (created by my advisor prof. Alexandre X. Falcão [4]) mostly in C/C++ (some Python) -- Also as a Research Scholarship Holder. * Dealing with libraries such as wxWidgets (Gtk) to implement the GUI of a software used in my image processing research. I am currently doing some code scrubbing on that sw to make it available on the Internet (open source, of course =D). In fact, the last item is where I got the inspiration to develop the GIMP plugin in the first place. IFT is a great alternative to algorithms based on the graph cut technique, and it was proven to provide better results [5]. It is a generalization of the Dijkstra's algorithm, which works quite fast and has served for many purposes in the image processing domain (e.g. image segmentation, CBIR, and morphology). Furthermore, in my research we have been working really hard to make user interaction more effective, faster, and the least as possible. That's it for my technical profile. As for my personal info, I'm not sure what to write about, so feel free to ask me any questions. = Questions = I know there is already a segmentation tool in GIMP, but I feel it could co-exist with this plugin. So, here are my questions: * I like to use SSE intrinsics to optimize some of my code, is it ok if I use it for the plugin? * I do plan to keep working on my research during the GSoC period, which takes me around 25~30 hours each week. Will this be a problem? That's it guys. Sorry for the long e-mail. Hope to hear from you. Best regards, [1] - http://portal.acm.org/citation.cfm?id=1700473 [2] - http://www.springerlink.com/content/7415482725175nm7/ [3] - R. Minetto, J. P. Papa, T. V. Spina, A. X. Falcão, N. J. Leite, and J. Stolfi. Fast and robust object tracking using iimage foresting transform. In 16th International Workshop on Systems, Signals and Image Processing, Chalkida, Greece, Jun 2009. IEEE. [4] - http://www.ic.unicamp.br/~afalcao/downloads.html [5] - http://portal.acm.org/citation.cfm?id=1574529 (Please let me apologize about referencing our papers, but our software is not yet available. If anyone is interested in reading them please contact me.) -- Thiago Vallin Spina MSc Student Laboratory of Visual Informatics Institute of Computing -- Unicamp www.liv.ic.unicamp.br/ http://www.liv.ic.unicamp.br/~tvspina ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Introduction Questions about GSoC2009 Idea: Plugin for image segmentation
Hey Guys, Sorry about the mistake on the subject, I meant GSoC2010 not 2009. I keep forgetting it's a new year =). Best regards, -- Thiago Vallin Spina MSc student Laboratory of Visual Informatics Institute of Computing -- Unicamp www.liv.ic.unicamp.br ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] moving windows in the git version
For several weeks now (I compile the git version every Monday), the windows in normal mode (i.e. multi-window mode) behave in a weird way: I place them where I want them on one virtual screen, and then I move to another one virtual screen. When I come back, the windows have moved to a different place, always the same. I'm with Debian testing and GNOME. -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
