Re: [Gimp-developer] Please bring back the old rectangle selection...
Hi, On Tue, 2006-07-25 at 23:49 +0200, Karl Günter Wünsch wrote: First of all the new one doesn't save it's options. That could be remedied but the amount of changes (I'm a C++ developer and really can't get my head around doing the way object orientation is done in the tool, the documentation for all the stuff that has to be done is lacking or isn't easy located - so I can't do it myself, I tried and failed) seem excessive as the gimprectangleoptions.c is the odd one out and uses a completely different way of storing it's properties to all the other tools - Bug #346683. Fixing this is as simple as adding the GIMP_CONFIG_PARAM_SERIALIZE flag to the registration of the interface properties. This is a simple change and it is already outlined in the bug report. Please stick to the facts, or if you don't know about the implementation details, don't make assumptions about them. If that were not bad enough, the usability is partially much worse than before. The new tools are not ready yet. We know that there are problems and it is nice that you took the time to point them out. But rest assured that we don't plan to release GIMP 2.4 with the selection tools in their current state. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp_pixel_rgn_resize help
Hi, On Wed, 2006-08-02 at 17:57 -0400, Brohan wrote: I'm building a plugin to compare two images side-by-side with panning and zooming, and I'm having a bit of an issue with getting the zooming to work. The way I'm doing it is initalizing a pixel region with the width being (width of preview) / (zoom factor) and soforth. /* Snip */ map_1 = gimp_drawable_get (vals.map_id_1); gimp_pixel_rgn_init (map_1_rgn, map_1, p1_x1, p1_y1, init_width, init_height, FALSE, FALSE); gimp_pixel_rgn_resize ( map_1_rgn , p1_x1, p1_y1, p1_width, p1_height); gimp_drawable_preview_draw_region (GIMP_DRAWABLE_PREVIEW (preview), map_1_rgn); /'* Snap */ What do you expect gimp_pixel_rgn_resize() to do? It doesn't do any scaling if that is what you are trying to achieve. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Please bring back the old rectangle selection...
On Tuesday 08 August 2006 10:00, Sven Neumann wrote: Fixing this is as simple as adding the GIMP_CONFIG_PARAM_SERIALIZE flag to the registration of the interface properties. This is a simple change and it is already outlined in the bug report. Please stick to the facts, or if you don't know about the implementation details, don't make assumptions about them. And now you are making assumptions. The flag only alters the behaviour by resulting in a crash when trying to read or write the properties... This probably is the result of not using the macros every other tool uses to register it's properties. If that were not bad enough, the usability is partially much worse than before. The new tools are not ready yet. We know that there are problems and it is nice that you took the time to point them out. But rest assured that we don't plan to release GIMP 2.4 with the selection tools in their current state. And if you had read the followups on this (partially in the cited bug reports) you would have noticed that I started to work with the developers to fix the problems - part of the patches originate from me. My whole rant here was the result of the lack of feedback to those bug reports, which since has been cleared as a bad timing because of the holiday season... -- regards Karl Günter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] On holidays, and summary of GIMP money
Hi, On Fri, 2006-08-04 at 16:48 +0200, Dave Neary wrote: As I said on IRC last night, in case anyone is wondering, the GIMP currently has roughly $21,000 in the GNOME fund. Wow, I wasn't aware that that much money had piled up. 1. Paying for the GIMP user manual to get into a publishable state, and get it published 2. Paying for travel/participation in certain conferences which have the potential to bring attention, money or people to the project 3. Paying to improve our infrastructure (reminder: there's a $500 cheque waiting for yosh, and I'm waiting for a quote for off-site back-up) 4. Paying for GIMP conferences and get-togethers (although I really think we should fundraise for conferences, as I did this year and in Kristiansand Agreed. I would also like to suggest that we consider paying people to get together for the purpose of GIMP development. That doesn't have to be a full-fledged developer conference. But if two or more people want to devote a weekend to hacking on GIMP or designing new features or user interfaces, we could consider to come up for travel expenses. I am currently talking to some usability people and user interface designers who would like to get further involved in GIMP development, especially when it comes to designing a user interface that leverages the power of GEGL. We will need to bring these people together with experienced GIMP users and I think that this would also be good use for the money that has been donated for GIMP development. Sven Things I don't think we should spend money on: 1. Hardware for individual developers (computers, scanners, cameras, tablets, etc). We should try to fundraise for this when people can fill a specific need (working on GIMP support for a tablet, for example), but in general buying people toys isn't useful 2. A server - in spite of what I said in point 3 above, I think we should be using our great contacts with GNOME, RedHat, HP, Canonical and others to get hosting, get use of servers and services outside of XCF, and make our sysadmin process more transparent, rather than spending money on hardware which could be donated 3. Sending people to any old conference - in general, if you're giving a talk on the GIMP in a conference, we should ask the conference organiser first, the GIMP second for sponsorship. And I don't think it's appropriate to pay for travel from London to Boston for someone to man a stand, even though I was prepared to do this last month. We should instead work on building up a good group of people worldwide who can give GIMP presentations and man GIMP stands, and make sure they're co-ordinating. So that's my summary of GIMP money - there may be some opposition to some of these things, so let's have at 'em. Cheers, Dave. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Please bring back the old rectangle selection...
Hi, On Tue, 2006-08-08 at 10:44 +0200, Karl Günter Wünsch wrote: I have no doubts about this but there is a problem discerning these two by just looking at the code if you are not that much into the GTK way of doing objects. There also is little documentation whatsoever on what parameters mean. The GObject documentation at http://developer.gnome.org/doc/API/2.0/gobject/ is quite extensive and should be considered a must-read if you want to understand the internals of the GIMP core. I debugged that down to the level of an object comparison (by name it seemed) which failed because one of the objects compared was NULL. If you'd like I can give it a try later (tonight after 8pm european summer time) and give some additional informations about this... It doesn't crash for me, but there are critical warnings when the interface properties are being deserialized. I will have a look at gimp_config_deserialize_property(), most probably we are making the wrong assumption here that the properties owner_type is a class. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp_pixel_rgn_resize help
Hi, On Tue, 2006-08-08 at 10:17 -0400, Brohan wrote: Ah, I expected it to do any scaling. Are there any library functions that do do scaling? I was expecting gimp_pixel_rgn_resize() to do the scaling, as resizing the pixel region might entail scaling. Resizing in GIMP terms usually just means to change the dimensions, without touching the pixel data. That is the case here as well. On a side note, is there a way to create an empty pixel region that is not attached to a drawable, or create a drawable that a pixel region can attach to? (This is to dump the scaled thing onto) No there isn't. And you should make yourself clear that the drawable only exists in the GIMP core. If your pixel data is in the plug-in, you can't simply attach it, it needs to be copied to the core. If you need a scaled down version of the drawable, you may want to use gimp_drawable_get_thumbnail_data(). Or use a GimpZoomPreview. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp_pixel_rgn_resize help
Hi, On Tue, 2006-08-08 at 11:36 -0400, Brohan wrote: Ah, its a scaled *up* picture that I need. The problem with GimpZoomPreivew (And I have looked into it), is that there's no way to get the zoom factor to set on another preview. There's gimp_zoom_preview_get_factor() for this purpose. A tiny little source dive didn't pick up any GimpZoomPreview functions, could you point me to where they are. There's nothing indicative of it in ./libgimpwidgets, nor in any of the preview .c's there. I'm running gimp-2.2.12 and using that source. GimpZoomPreview is not in GIMP 2.2, it will be part of the GIMP 2.4 API. Sven PS: Please try to reply to the list also. Others might want to benefit from our discussion as well. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] SoC: only two weeks left - hurry!
MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.3 X-Originating-IP: 69.196.168.218 But after this call destPR doesn't reflect the contents of tempPR. I think that the problem stems from the call to pixel_regions_register called from within copy_region. If the pixel region is initialized using pixel_region_init_data (like tempPR is) then the subsequent call to pixel_regions_register sets the data pointer to an incorrect location. Specifically, pixel_region_init_data sets tempPR-data to the allocated memory, but then pixel_region_register sets tempPR- data to data + y*rowstride + x * bytes, which for this type of pixel region is an error. I figure out that the problem was that I had to re-initialize the pixel region before using it again. Thanks to Pedro and especially to mitch for helping me along. Kevin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] SoC - gimp-ruby project
Greetings. I'm mentoring the gimp-ruby project. This project allows the writing of scripts written in the Ruby programming language. The project has progressed quickly. The project became available via the gnome.org CVS repository on June 20. As of the mid-term evaluations scripts could be written using Ruby but there was no GUI component. Not long after the mid-terms the GUI component was added. All the major functionality is in place. Two sample Ruby scripts are included and some additional sample scripts are in the works. Also, some documentation is being written. Since Scott's e-mail message with the status of the project an interactive console mode was added along with gettext and UTF-8 support. The project is being developed on a machine running OS X and tested in Linux (Fedora Core). It would be interesting to hear from anyone who tries it in a different environment. If you have ever wanted to write scripts for GIMP using Ruby check out the gimp-ruby module from CVS and build/install it. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
