Re: [Gimp-developer] ‘no image’ window: prog ress...
Hi, On Mon, 2008-03-17 at 05:38 -0400, [EMAIL PROTECTED] wrote: I think the goal of making the Toolbox a utility window or dock should be addressed directly as an overall goal (THE overall goal?). That would seem the main point of this exercise. Removing the menubar from the Toolbox in and of itself would hardly seem worth all the discussion and effort that has gone into this. It is the goal. However, how well this will actually work with all the different window managers out there, remains to be seen. With regard to the window closure behavior, I don't see the benefit in having the closing of the last image forcing a resize of its window. Once I have placed my windows into a desirable desktop arrangement, I really shouldn't want GIMP to automagically reconfigure things just because I don't have an image open. I agree with that. IMO, the less resizing, the better. But perhaps this is something we need to try and refine later. Let's first implement what Peter suggested and see how well it works. Even upon opening a new no-image instance of GIMP, I am hoping that using the last size and location of the window from the previous session would be offered as a option (in Preferences), rather than having that dynamically chosen. (Presumably the size and location of the image window from which GIMP was quit in the previous session would have been saved.) Yes, I think I would also like such behavior. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Rotation for brushes
Hi, On Sat, 2008-03-15 at 23:02 -0700, David G. wrote: Add a option to rotate brushes to compliment the scaling. In case someone wants to start working on this, here's a rough outline of what needs to be done: (1) Rename the scale() method of GimpBrush to transform(). (2) Add an angle parameter to the transform method. (3) Implement the rotation for all derived brush classes. The difficult part is to do the rotation, efficiently, for pixmap brushes. When we are this far, we can start to consider how the angle should be controlled by the user. As a start one would add methods to GimpContext to rotate the current brush so that keyboard shortcuts can be added for this. Later we can add more sophisticated things then. The next logical step after adding rotation would be to change the GimpBrush::transform method to take a GimpMatrix3 parameter and to allow for arbitrary affine transformations (that includes shearing). I am sure that there is some efficient code for this out there that we could use... Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Congratulations, your organization has been accepted in to the Google Summer of Code(tm) 2008T
On Mon, Mar 17, 2008 at 11:34 PM, Joao S. O. Bueno wrote: I see no number of slots at this point! Sure, you can't see them until after March, 31. The more applications, the more slots. Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Rotation for brushes
it would also be nice to tie in scale and rotate (and any other changes) with gimp-python... ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP to adopt this scripts
I'm still recollecting information of useful filters that could be added in GIMP official builds to the whole world. What I'm talking here is about http://sourceforge.net/projects/gimpfx-foundry/ I'm not going to list all of them but here are some common ones: Light and Shadow Directive: - Color Overlay - Drop Shadow (it's already on GIMP of course, but this one have more flexible controls) - Gradient Overlay - Inner Glow - Outer glow - Glow Selection Artistic: - Quick Sketch - Pastel Sketch - Pencil Sketch This is probably my suggestion list, there are also some very handy Photo effect helpers that are possible to add in the GIMP. I don't know if this GIMP FX Foundry is managed by one of the developers here, but it would be good to have some official releases with this common 'effects' for the general public who doesn't have knowledge about sourceforge, script-fus and technical stuff. Thanks, David -- View this message in context: http://www.nabble.com/GIMP-to-adopt-this-scripts-tp16120294p16120294.html Sent from the Gimp Developer mailing list archive at Nabble.com. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Rotation for brushes
On Tue 18 Mar 2008 09:38:26 jbaker wrote: it would also be nice to tie in scale and rotate (and any other changes) with gimp-python... That part comes last - when it is implemented in the core, calls for this should be added to te PDB (there are missing PDB calls for controling brush scale, and paint parameters as jitter currently). Once it is in the PDB, they wod be available from python, but also, I am working in implementing gimp brushes as python objects, and it would be trivial to add rotation support there once it is in the core. As for the User Interface for this, I think mapping curves from input parameters to brush/tool properties is the way to go. (that is, I can think of a curve mapping painting angle to brush angle :-) ) http://wiki.gimp.org/gimp/SummerOfCode2008ideas http://bugzilla.gnome.org/show_bug.cgi?id=119240 js -- ___ 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] GIMP to adopt this scripts
On Tuesday 18 March 2008 14:39:07 David G. wrote: . I don't know if this GIMP FX Foundry is managed by one of the developers here, but it would be good to have some official releases with this common 'effects' for the general public who doesn't have knowledge about sourceforge, script-fus and technical stuff. Gimp FX Foundry was started and is maintained by me. There are releases to the public, new one is around the corner, I'm hoping to finalize it next weekend. This one will come with docs and single script download option. I do not think gimp needs to come with extra stuff by default. There is more than enough already... What gimp needs is a quick drag-and-drop way to install extras in packs. I have a script that I haven't put into release because it needs certain patterns to be installed too... And theres no way I can make that happen without some pain to users. Best, Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Just wanted to say hi
Hi everybody, I'm new to the list and just wanted to introduce myself. My name's Tom (ok, to correct Thomas ;-) ), 35yo, I'm living in southern germany (near the Lake of Constance) and work as a fulltime sw developer for big company. In my spare time I'd like to code a bit around doin' some stuff on my own. But after I'd listened to a podcast called Chaosradio Express where Gimp was presented (including the story behind, etc) I thought, that I could help a bit in the open source scene - so the decision was clear :) I'm no linux-geek, I'm based on Windows, so I'm interested in helping out in the Win-Parts of Gimp - if there's still some help needed ;-) I checked the bugtracker and found interesting starting tasks, that I'd like to work on - but some problems occured with the compilation of the SVN trunk with MinGW. But that are some questions that I may ask later on :) That should be enough for now - I don't want to bother you any longer :) Regards Tom ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP to adopt this scripts
Wow, didn't notice I was repeating Alexia. Sorry, Alexia :) Although that makes me think -- something like python's easy_install would be terribly handy for resources.. If you're not familiar with it, basic usage is : 'easy_install foo' installs the latest version of foo. This would require a centralized repository (the resources needn't be stored there, metadata would need to be.) Would be a nice backend for a DnD app. Also,.. On Wed, Mar 19, 2008 at 7:43 AM, David G. [EMAIL PROTECTED] wrote: Sorry but I don't agree with that. I think GIMP should be more of a 'out of a box' term than just worrying about sizes and things that could be taken ?? worrying about sizes ?? Oh, you mean distribution size. This is undoubtedly an issue, it is less of a concern than simple cumbersomeness: the amount of files in the GIMP distribution is too much already.. for a sample, look at the plug-ins/common directory in a GIMP source tree. Approximately, each C file produces a plugin, there are a lot of plugins there.. (120+ IIRC); similarly I think we have too many gradients by default, too many palettes, and too many patterns. This is partly because there isn't a 'filtered/tagged' view, so that we only need to consider relevant resources. Also, GIMP developers are required to manage this multiplicity of resources, which becomes harder the more resources there are in the distribution. (there is infrastructure for tagging, and no UI or I/O for tagging, IIRC. I think it might take quite a bit of work to get the tagging UI right.) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP to adopt this scripts
Hi, On Tue, 2008-03-18 at 14:13 -0700, David G. wrote: I'm not saying that GIMP developers should choose the whole project and integrate the scripts because that would make a big mess, but common things like Inner Glow , gradient overlay and so on are things that are used pretty much in every graphic. I am all for adding some scripts and plug-ins that are important for many users. At the same time we should probably drop some not-so-important plug-ins and scripts. Perhaps we should make this a goal for the next development cycle. It would be good to have some well-defined process where plug-ins and scripts are proposed for removal and inclusion. There should be a time-frame for this, at the beginning of each development cycle. At the end of the proposal time we would discuss and decide what is added and what is removed. After that we should still have enough time to polish the new plug-ins and scripts for the next stable release. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] gsoc project
Hi everyone, My name is Rafael, I am an Brazilian student of Computer Engineering from Universidade de Pernambuco and about one year ago i have been studying image processing, so i become interested in working in an gimp project. People usually want to process image for specifics reasons : noise extractions, signatures analysis, historic documents analysis, activation areas detection from an human brain studies, and for so many other reasons. In addition to this, those images can be of n different types. My general idea is to make a plugin to help people doing new Filters, for their specific reasons, without the need of writing new code. The idea consists on creating those filters from basic Morphologic Operators (dilate, erode, opening, closing and morphological gradient) and , in the future, creating new filters based on other filters (combining them). I know that gimp already works with Dilate and Erode operations, but it does not give the possibility of creating new structuring elements for those operands (dilating an image with a cross 13x13 can be much better than doing it with a circle 3x3, depending on the user´s need) and neither of combining them with other operations. There is something similar to what i want to do, in an ImageJ Plugin ( http://svg.dmi.unict.it/iplab/imagej/Plugins/Morphological%20Operators/Morphological%20Operators/MorphologicalOperatorsPlugin.htm- here you can see an image from the interface of Morphological Operators plugin that can help you to understand my idea). I usually work with this tool and i think it is very useful, but it can`t save operators made by user to combine them with other operations in the future. Well, i am waiting a feedback from you. Suggestions/Critics ? is this idea interesting/relevant for gimp ? you can found me on #gimp - Galva and msn - [EMAIL PROTECTED] Thank you very much for your attention :), Rafael ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP to adopt this scripts
Regarding the cycle: Great idea, although it should be a little bit more open, lets say 'surveys'. It will save more time to you developers letting the user choose what features/filters/plug-ins should be implemented in the next version. Its kinda like cedega's way of managing popular games (if i remember correctly when I was a subscriber). If you could set up contacts to all the OSes that distributes GIMP(either by e-mail, or adding a big splash that captures the user, sending via mailing lists) with the survey I'm pretty sure you get a well-defined answer on where to aim. Another thing is that I kinda go with the gegl implementation on some things, then again I don't know if this is a place to propose this to gegl although. (same developers?) so if any mistakes were made then most users wouldn't even need to update the gimp, but gegl. (i don't know if I'm correct, just a hunch) I like to point out again that I'm not a developer or know any programming language. - David -- View this message in context: http://www.nabble.com/GIMP-to-adopt-this-scripts-tp16120294p16134675.html Sent from the Gimp Developer mailing list archive at Nabble.com. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Just wanted to say hi
Tom Bass [EMAIL PROTECTED] wrote: I'm no linux-geek, I'm based on Windows, so I'm interested in helping out in the Win-Parts of Gimp - if there's still some help needed ;-) I checked the bugtracker and found interesting starting tasks, that I'd like to work on - but some problems occured with the compilation of the SVN trunk with MinGW. But that are some questions that I may ask later on :) It would help a lot to have a strong Windows coder participating. Michael Schumacher builds SVN for Windows regularly, and helps to debug many problems, but he doesn't like to write C code particularly, so lots of issues with the Windows build go for a long time without being handled. There is no shortage of tasks waiting for somebody to do them. Building SVN in Windows is quite challenging, and at the moment even more challenging than usual, because of the ongoing integration of the GEGL framework, so don't be embarassed to ask for help if you get completely stuck. -- Bill (I recall your nick showing up on #gimp today -- come back and say hello, please, if you haven't already.) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gsoc project
rafael mesquita [EMAIL PROTECTED] wrote: Hi everyone, My name is Rafael, I am an Brazilian student of Computer Engineering from Universidade de Pernambuco and about one year ago i have been studying image processing, so i become interested in working in an gimp project. [...] Hi Rafael, thanks for introducing yourself. Your ideas are quite sophisticated, but I don't have a clear picture of who would use this capability, or what they would use it to do. Could you explain a little more, please? -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
