Re: [Gimp-developer] New schedule for GIMP 2.8
I added a proposed patch to fix Bug 596410 to the bug report a while ago. Do I need to look at that again? Eric On 04/03/2011 03:49 PM, Martin Nordholts wrote: Hi all, I have created a schedule for GIMP 2.8 and put it here: http://tasktaste.com/projects/Enselic/gimp-2-8 Please review the list of tasks and let me know if there are other things than those listed there that you know we need to do before we can release 2.8. In that case I will add those tasks to the schedule. Ideally, all commits pushed to git master should be related to one of the tasks listed there. Being able to make a reasonable estimate for when we can make a GIMP 2.8 release is good for many reasons; one of them is that we need to know when we should enter a string freeze. If no tasks are added and if my estimates are correct, we will release GIMP 2.8 on 2011-10-20. As we all know however, making estimates is hard and 2011-10-20 will not be our release date, but it is the best estimate we have right now. The nice thing with having our schedule on tasktaste.com is that anyone interested in when GIMP 2.8 will be released just needs to visit that web page linked to above to get an overview of how GIMP 2.8 development is progressing and get an updated estimate for when we can make a GIMP 2.8 release. As a side note, I have developed tasktaste.com from scratch during the last few months and the source code is available under the Apache Licence 2.0: https://github.com/Enselic/task-taste / Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] How to best use Bugzilla
On 03/18/2011 04:03 AM, Michael Natterer wrote: Generally, I rather like to have more than less bugs on a milestone, because there is nothing more frustrating than a huge list of bugs with milestone ---. It looks as if we simply don't care at all. For a bug reporter,it would be frustrating to have a bug accepted with milestone X only to have it then pushed out to X+2 or later. But I agree that for everyone else, the milestone indication helps acknowledging that the bug is recognized as real and there is an intend to fix. Both as a developer and a user I like Bugzilla and the information it gives me; the more information it provides, the better. If there are many bugs with a 2.8 milestone, I would be more encouraged to try and help out by researching and addressing some of them. Eric ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enabling a 2.8 release: planning for a 2.10 release
FYI, I have code to fix #596410, following the guidelines Martin gave me, but I don't want to submit that patch until I can actually compile Gimp again. Eric On 03/14/2011 04:22 AM, Martin Nordholts wrote: Hi everyone, As you all know, getting 2.8 out is highest priority right now. There are however some things that we want to fix before we make a 3.0 release. Thus, we must plan for a 2.10 release. I have updated our milestones in bugzilla with this. After the update, there are only 7 bugs on the 2.8 milestone: 642728 - Function `gdk_gc_new' implicitly converted to pointer causes build failure 631766 - Bad performance when moving brush outline on canvas 612931 - Moving individual layer in layer group not possible with Move Tool 603848 - Single-window mode is not properly session managed yet 600554 - Implement layer group transforms 596410 - gimp-image-get-filename returns NULL for imported files 51112 - clipping groups or masking groups (like in Photoshop files) Let's focus our efforts and smash these last bugs so we can make a 2.8 release as soon as possible. To see what we should fix for the 2.10 release, refer to the 2.10 milestone and our roadmap: 2.10 milestone: https://bugzilla.gnome.org/buglist.cgi?product=GIMPbug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDtarget_milestone=2.10 Roadmap: http://gimp-wiki.who.ee/index.php/GIMP_Roadmap / Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Parasite questions
Thanks, Bill. That makes sense. Let's see if I understand this correctly: app/core/gimpimage.c defines the function gimp_image_parasite_list, which actually implements the functionality of getting a list of parasites. libgimp/gimpimage.c also defines a function called gimp_image_parasite_list, which tries to retrieve a list of parasites; this is what should be used by the plugins. However, this function tries to call a function called gimp_image_get_parasite_list, which doesn't exist. Hence the undefined references I'm getting. tools/pdbgen/pdb/image.pdb defines a function called gimp_image_get_parasite_list, which calls the function gimp_image_parasite_list. I assume this is supposed to reference the version in app/core/gimpimage.c The thing I don't understand is how this can possibly compile at all? I'm only getting the errors if I add functions to image.pdb. If I leave image.pdb as it comes from git, everything compiles. The other thing I'm not sure about is whether the code I described above can even work. Can there be functions with the same name defined in app/core, in libgimp, and in pdb? Thanks, Eric On 03/13/2011 12:24 PM, Bill Skaggs wrote: Pdbgen is part of the gimp application core. Libgimp is an interface library designed to be used by plug-ins -- it is not and cannot be used inside the core. The functions that can be used inside the core are documented at http://developer.gimp.org/api/2.0/app/index.html . In many cases they correspond pretty closely to libgimp functions, but the function names are sometimes different, and the arguments are almost always different. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Parasite questions
Thanks, Bill. I finally figured it out. At the bottom of tools/pdbgen/pdb/image.pdb, a hard-coded subset of the @proc array is passed as the series of functions to add to the library. By adding new functions, the bottom ones were no longer included, and so resulted in unresolved references. I will include a couple of lines of comments that explain what is going on in the patch I will be submitting. I should also submit a patch for the README_NEW_PDB_PROC document to include this information in the documentation... Eric On 03/14/2011 01:17 PM, Bill Skaggs wrote: It compiles because Gimp plug-ins (unlike PhotoShop plug-ins) are separate executables, which communicate with the main Gimp app via a shared memory channel. As separate executables, they are compiled separately and don't necessarily need to avoid function namespace conflicts with the main app. (Although in my opinion it would be better design to avoid such conflicts.) The libgimp function gimp_image_get_parasite_list is actually just the C hook for the function image_get_parasite_list_invoker, whose autogenerated source code you can find in app/pdb/image_cmds.c. The PDB actually consists of a large set of invoker functions of that sort -- libgimp is simply the C language binding that C plug-ins use to access the PDB. Other languages such as Python and Ruby have their own bindings -- the function of a binding is to transform a native language command into a call to one of the invoker functions that belong to the PDB. (Libgimp also contains some utility functions that are useful for C plug-ins but don't involve the PDB, but that doesn't affect the main point.) -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Parasite questions
Hi, I'm running into compile errors when I'm adding a function to tools/pdbgen/pdb/image.pdb: undefined reference to 'gimp_image_detach_parasite' undefined reference to 'gimp_image_get_parasite_list' undefined reference to 'gimp_image_get_parasite' Delving deeper into this, I'm finding two function: - gimp_image_parasite_list() - gimp_image_get_parasite_list() According to a comment in libgimp/gimpimage.c, the version without the get in the name is deprecated and the one with the get should be used instead. The version without get is implemented here by calling the one with get. However, in tools/pdbgen/pdb/image.pdb, the version with get is implemented by calling the one without get. This seems a bit circular to me. Something seems to be strange with the parasite functions... everything compiles fine when I get the source straight from git, but starts to break when I add functions to image.pdb. So my question is: am I doing something wrong by adding functions to image.pdb, or is there actually something wrong with the parasite functions? The changes I'm making to image.pdb are: - mark image_get_filename deprecated - mark image_set_filename deprecated - change description of image_get_uri - add image_set_uri - add image_get_imported_uri - add image_get_exported_uri The error output when compiling: make[4]: Entering directory `/mnt/lincoln/d3/gimp/source/gimp/plug-ins/script-fu' CC script-fu.o CC script-fu-console.o CC script-fu-eval.o CC script-fu-interface.o CC script-fu-text-console.o CC script-fu-script.o CC script-fu-scripts.o CC script-fu-server.o CC scheme-wrapper.o CCLD script-fu /mnt/lincoln/d3/gimp/source/gimp/libgimp/.libs/libgimp-2.0.so: undefined reference to `gimp_image_detach_parasite' /mnt/lincoln/d3/gimp/source/gimp/libgimp/.libs/libgimp-2.0.so: undefined reference to `gimp_image_get_parasite_list' /mnt/lincoln/d3/gimp/source/gimp/libgimp/.libs/libgimp-2.0.so: undefined reference to `gimp_image_get_parasite' collect2: ld returned 1 exit status make[4]: *** [script-fu] Error 1 make[4]: Leaving directory `/mnt/lincoln/d3/gimp/source/gimp/plug-ins/script-fu' Eric ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Photoshop ?compatibility? mode
ROFL On 02/01/2011 03:54 PM, Ofnuts wrote: On 02/01/2011 06:25 PM, Alexandre Prokoudine wrote: On Tue, Feb 1, 2011 at 8:16 PM, Michael Grosberg wrote: I will refrain from expressing my opinion on undocumented, undiscoverable features. Now only a help page is needed. I think I'll go and join the Gimp-Docs mailing list and take it from there. This is an area in which I have a lot of experience (I've been documenting graphic apps for several years now). So far it looks like the best outcome of the thread :) Thank you. Let's remove one stroke from the name of the program. Let's call it GINP. GINP Is Not Photoshop. ___ 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
[Gimp-developer] Developer Boot Camp?
I am getting the impression that the Gimp project is trapped in a chicken-and-egg problem with regard to attracting new contributors, where the few core developers are too busy maintaining the product to spend a lot of time helping new developers come on board. Gimp is an extremely large and complex system. I am a fairly experienced coder myself, and have recently submitted patches for two open bugs. But those were easy ones, not really related to any Gimp structures but basic C bug fixing. I have looked at some of the other outstanding bugs and for most don't have a clue where to start, or how to make sure that my fix fits in the vision, or that it doesn't break something else. At this point, knowing how busy the core Gimp developers are, and recognizing that it will take more time for them to walk me through a problem and a solution than it would take them to just fix the issue themselves, I am hesitant to ask for a lot of help. On the other hand, the idea of just delving in and figuring it out myself is quite daunting. Which is where my thought of a boot camp came in. What if there was a group of potential new developers all struggling with the same learning curve? Wouldn't it be great if an experienced Gimp developer could lead the whole group through a series of exercises, designed to gain experience and understanding of the Gimp and Gegl internals. This would require some serious commitment of time by one or more of the Gimp developers, and would mean other work wouldn't get done. The potential payoff however in the form of bringing one or more additional Gimp developers up to speed could be significant. Eric ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Developer Boot Camp?
On 01/27/2011 05:29 PM, Øyvind Kolås wrote: Feel free to drop by the #gimp and #gegl IRC channels to ask directed smart questions for understanding the code. Also be aware that some of the existing core contributors both dislike email in the first place, and are cursed by knowledge thus not the best people to write introductions to how things work; new-comers are in a better situation to do this. For the last few years GIMP (and GEGL) have been involved in Google Summer of Code which can be considered some form of such a boot camp - some of the students have also stuck around after their last money from google arrived, the common practice in the last years has also been that the domain experts have not neccesarily been direct mentors for students but meta-mentors, giving guidance on irc in the public channels for any problems that might crop up. I've tried asking questions in the #gimp channel, but rarely get an answer. I guess the right people would have to be on-line for that to work. I'm thinking that maybe most contributors are in Europe or on the US West Coast. By the time I get off work (US East Coast), it's past midnight in Europe... I'm not saying that the boot camp idea is the best solution. But I do have the impression there is a bit of a problem. I've noticed a lot of complaining about there not being enough people to contribute, and about it taking too much effort to bring new contributors up to speed... Another thought: I do have some technical writing skills (although it is not my profession). If there are areas where I could write documentation, having support from the experts on my many questions, and have it end up on the developer.gimp.org, maybe that would help. Eric ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Submitted patches for bug 596410
Hi, I submitted a series of patches to bug 596410. This is my first time working on Gimp and I'm new to git at well. I am very open to suggestions on how to do things differently (better). Eric ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Coding Convention Question
Hi, I'm looking at bug #596410 and in order to get to the import source in gimpimage.c, I seem to have to #include ../file/gimp-file.h (to get to the GIMP_FILE_IMPORT_SOURCE_KEY constant). Is it appropriate to include a header file from a sibling directory this way? Thanks, Eric ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
