Re: [Gimp-developer] Gimp 2.7.3 Compile gdk_win32_window_foreign_new_for_display Issues
On 04/16/2011 07:08 AM, Partha Bagchi wrote: Trying to compile gimp 2.7.3. At least on my system (Windows 7, 64 bit), you need gdk_window_foreign_new_for_display instead of gdk_win32_window_foreign_new_for_display to compile. Is this right? Or Any suggestions? It's wrong. Apparently you are trying to build against a too old GTK+ ciao, --mitch ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP 2.8 schedule update
On 04/15/2011 09:57 AM, Alexia Death wrote: On Fri, Apr 15, 2011 at 9:08 AM, Martin Nordholtsense...@gmail.com wrote: Hi Two new items on the 2.8 schedule has been added: * Bug 647835 - Handle deprecated GTK+ API * Bug 647834 - Stop using deprecated API in plug-ins And one item has been fixed: * Include UI tests in nightly Jenkins builds Bug 304798 - Painting brush outline is slow Work on this bug has progressed considerably. It now performs very well in most cases. There have been plans to have an alternate simplified brush indicator, but that is not the subject of this bug. As far as I'm concerned this bug can be closed. You and mitch are the paint and brush masters, so if it's good enough for you, it's good enough for 2.8. Can you or mitch close the bug report then or at least move it off the 2.8 milestone please? It's just that when I do 1. new image 2. move around the default brush outline on the canvas then one of my CPUs work 100% in 2.7.2 and about 50% in 2.6.11. That it not necessarily a problem, just wanted to point it out. Regards, Martin -- My GIMP Blog: http://www.chromecode.com/ Why GIMP 2.8 is not released yet ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Continuous update of the NEWS file
Hi, Now that 2.7.2 has been released and NEWS is up to date (thanks mitch!), let's make sure to keep it up to date from now on. That means that whenever you make a commit that is worth being mentioned in NEWS, add it to NEWS along with the other changes in the commit. That way making a new release will require less effort since whoever makes a release don't have to go through months of commits history first. Making frequent releases is something we want to be as easy as possible. / Martin -- My GIMP Blog: http://www.chromecode.com/ Why GIMP 2.8 is not released yet ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Continuous update of the NEWS file
On 04/16/2011 02:30 PM, Martin Nordholts wrote: Hi, Now that 2.7.2 has been released and NEWS is up to date (thanks mitch!), let's make sure to keep it up to date from now on. That means that whenever you make a commit that is worth being mentioned in NEWS, add it to NEWS along with the other changes in the commit. That way making a new release will require less effort since whoever makes a release don't have to go through months of commits history first. I second that. Updating NEWS made the release happen weeks later than I wanted. Making frequent releases is something we want to be as easy as possible. +1 --Mitch ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Unified transform tool
On 04/16/2011 04:13 PM, Michael Grosberg wrote: There has been some interest among the GSOC applicants to work on the unified transform tool.there already exists a very original specification for this tool. But I have some reservations about the transform frame being a bit too complex. I wrote an alternative suggestion. This is not a complete spec, just a direction the transform FRAME might be taken to, in order to make it easier to use. You can read it here: http://bit.ly/hIJdxW I'll be glad to hear any feedback you have. Symmetry mode is not well defined... In your drawing, you drag on top-right and the top-left follows (vertical axis), but it could as well have been the bottom-right (horizontal axis), and even the bottom-left (radial). IMHO, your proposal, like the original one, doesn't address a very frequent use of these transforms, which is to match the transformed object with an existing one. In that use-case, having a fixed point elsewhere than in the center for the whole transform is very useful. There is such a thing for rotation (the axis can be moved), but not for scaling (where the fixed point is either a corner or the center). Imagine for instance that you want to graft a new face on a picture: with an arbitrary fixed point for scaling, you would move a pupil over the matching one of the target face, and select that point as the fixed point. The rest of the process in one gesture to rotate/scale the new face so that the second pupils match (that is mathematically very simple since rotation and homotecy have the same center). Without it, it is a long sequence of small steps, because you can't adjust the scale without moving your reference point. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Unified transform tool
I agree with Michael that the design in the proposed specification although looks cool , it can be complex for first time users. Having said that I personally like the original specification as it is more clean and efficient once understood. Inkscape has a more easy approach to this but it doesn't offer that much transformations as required in this tool. The original specification provides all the tools in a single view rather than toggling to different mode for different transformations. For different users the choice may be different. In my opinion tools incorporated in the unified transform tool should be of basic transformations. Adding too many of them can cause more confusion than providing utility. We can also provide an option for users to select between the super frame mode(the original specification) and normal transformation mode (for a simple specification as suggested by Michael) which i think should not be hard enough to implement. The idea suggested by Ofnuts to set different scale point is noteworthy. There should be a provision for changing the axis for different transformations(not only for scaling,rotation but also for perspective and shear) with a reset button to restore defaults. These are just some of my ideas and opinion regarding this. For a better implementation we need to more ideas and suggestion both from users and developers. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
