Re: [Gimp-developer] .:: GIMP Command Line Issue ::.
Hi, Mohamed Hassan [EMAIL PROTECTED] writes: most of the time used to load filters/fonts/plug-ins/scripts/extensions how can i dont load these extra with me when running batch file how can i use a single instance of GIMP to run all my command? Try the --no-data and --no-fonts command-line options. And please read the man-page. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and Google SoC
Hi, William Skaggs [EMAIL PROTECTED] writes: Here are some suggestions I have heard that I like. without credit to the people who first suggested them: 1) Color management. Sven and others have made a start on this, but quite a bit more needs to be done. Color management is supposed to be in the 2.4 release so it should be finished before the SoC starts. 2) Resource management. Currently resources such as brushes, gradients etc are shown to the user in an unstructured way, which greatly limits the number of items a user can deal with. People love to make collections of things, so this would greatly enhance the user experience. That sounds like a reasonable project to me. 3) System for saving presets for plug-ins. Sven and Mitch have been clearing the way for this, but there is good bit still to do to make it happen. We definitely want this to happen right after 2.4. I am not sure if it makes sense to declare an absolut must-have as a SoC project. IMO We should rather try to come up with some tasks that would be nice to have but that we can easily live without. 4) Vector layers and tools to manipulate them -- allowing adjustable rectangle and ellipse shapes, lines with arrow, etc. Fine with me. 5) Create a manager widget that will allow all of GIMP's windows to be contained in a single parent window, as requested hundreds of times by Windows users. (This would be optional, not forced on people who don't want it.) I don't think we will need this when we are done with the changes to the window handling that have been started in CVS. It also doesn't fit into the long-term plan. We could however try to make window handling a SoC project but I am not sure how well suited that would be. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and Google SoC
Hi, Dave Neary [EMAIL PROTECTED] writes: - Scripting languages and the GIMP - work on ruby or python bindings Another language binding would indeed be a nice project and the Python binding could also be improved. What's Yosh's opinion on the latter? - Plug-ins: Save for web for example (too small to be a project, but could be part of one) IMO Save for Web is complex enough for a project. - Effect layers - I think this is fairly straightforward with the GIMP as it is, it's a nice chunk of a project, and would be a nice feature for users How is this fairly straightforward with the current architecture? I would rather say that it is currently almost impossible to implement sanely. 1. Feature freeze 2.4 soon (before the end of May), for release during the Summer 2. Create SoC branches for integration of the SoC projects 3. After release of 2.4, merge successful projects to HEAD, and release 2.5.0 (GIMP-SoC) in September. Let the branch harden for a month or so, and release 2.6.0 off that. 4. Start gegl integration on a branch, if needs be, and integrate that work into HEAD straight after the release of 2.6.0. I don't see why we should wait with GEGL integration. There are people waiting for the 2.4 release to start this work. It would be a huge mistake to postpone this. The amount of GEGL integration that is planned for the next release is small anyway and is unlikely going to delay the 2.6 release. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and Google SoC
Hi, Alexander Rabtchevich [EMAIL PROTECTED] writes: What about official Red eye plug-in, possibly with SIOX, as Sven suggested? Also some kind of healing brush can be useful. Yes, I think that a decent Red Eye plug-in would be nice project. Same for a healing brush tool. Also something like PS's Vanishing Point feature would be nice to have. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Binary of Gimp devel branch for Win32
Hello, Do you know if someone maintains a binary of the Gimp devel branch, for Win32 ? Thanks, -- Frédéric http://www.gbiloba.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Re: GIMP and Google SoC (from digest)
Hi, Michael Schumacher wrote: Von: Dave Neary [EMAIL PROTECTED] Hi all, I have registered the GIMP as a mentoring organisation for the Summer of Code (I had been in contact with Google before the announcement), we should be up on the page over the next couple of days. It would have been nice to know this a bit earlier. As you can see in the other thread, we were already preparing stuff... I was away for the weekend, when the announcement was made, but the contact I made was last year when the GIMP wasn't in the mentoring organisations, because no-one had asked. This year, I got in early. I'm not taking this over, by any means. I'd like to have as little as possible to do with it, but I'm happy being an initial point of contact. Bill Skaggs said: Thanks Dave for taking the initiative. Does this mean that you are volunteering to be the coordinator, as described in the SoC FAQ? I'm the coordinator - I have received the information we need to sign up mentors, and anyone who would like to be a mentor for an SoC project should contact me. The role of mentors is to be present in the soc groups during the start-up phase, commenting on GIMP project ideas, helping people refine those ideas, and after project selection, to supervise someone's work, be their shoulder to cry on when things are going badly, their wall to bounce ideas off, their interface to the greater GIMP community. We will need 3 or 4 of these, at least, perhaps more. We should settle on half-a-dozen well-defined project ideas, because having too many choices leads to brain freeze, and people who want to work with GIMP but don't like any of the suggestions are always free to come up with ideas of their own. And it would be nice to put them on a page on the developer web site as opposed to the Wiki. It is much the same thing - the important thing is to have the ideas available quickly. Either way is fine with me. I would go for 10 or 12 decent ideas. I would rule out anything that starts finish Outside of that, there's no need to provide specs, and ideas are there to inspire. They should be realistic, but make people go wow at the same time. I think this timeline is unrealistic, and that it would be better to aim for the results of the student projects being incorporated in the 2.4 release. You're probably right. But we'll need to be a bit slushy about hardening features - 2.4 will be feature frozen when SoC finishes. We can release a slightly buggier than usual 2.4 of course. 2) Resource management. Currently resources such as brushes, gradients etc are shown to the user in an unstructured way, which greatly limits the number of items a user can deal with. People love to make collections of things, so this would greatly enhance the user experience. This and a decent plug-in distribution system are great ideas. Sven Neumann said: - Plug-ins: Save for web for example (too small to be a project, but could be part of one) IMO Save for Web is complex enough for a project. I may be underestimating the effort involved, but I think I could throw together a prototype fairly quickly. - Effect layers - I think this is fairly straightforward with the GIMP as it is, it's a nice chunk of a project, and would be a nice feature for users How is this fairly straightforward with the current architecture? I would rather say that it is currently almost impossible to implement sanely. Ah, but I'm insane. Add a layer type for effect layers, and define 3 operations that you can associate with the layer (to start): curves, levels and colour balance. All the operations are pixel-by-pixel, which should make things easier. Then hack the projection code to add a special case for an effect layer. We'd need to evolve the xcf version number, and it probably wouldn't be possible to do anything useful with the effects layers in earlier versions of the GIMP (ignore seems about the best option). I don't see why we should wait with GEGL integration. There are people waiting for the 2.4 release to start this work. It would be a huge mistake to postpone this. The amount of GEGL integration that is planned for the next release is small anyway and is unlikely going to delay the 2.6 release. I'm not proposing delaying gegl integration. I'm just saying that to get the most benefit out of SoC, you need to release people's code soon after the Summer, and the gegl integration isn't going to ship until next Summer probably. So it seems sane to me that gegl integration start on a branch (made straight after 2.4), and gets merged back into HEAD *after* we ship a stable release with SoC projects included. That said, Bill suspects that 2.4 might not get released until after the Summer (seems pessimistic to me, but I'm a bit far from things to be able to say for certain), and in that case, he has a point. Cheers, Dave. -- David Neary [EMAIL PROTECTED] ___
Re: [Gimp-developer] Binary of Gimp devel branch for Win32
Von: Frédéric [EMAIL PROTECTED] Do you know if someone maintains a binary of the Gimp devel branch, for Win32 ? Yes, Jernej Simoncic. They are available from the same site as the stable versions, but a bit more hidden - on purpose. We're hesitating to have people to use them unless they know what they are doing. HTH, Michael -- Echte DSL-Flatrate dauerhaft für 0,- Euro*! Feel free mit GMX DSL! http://www.gmx.net/de/go/dsl ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Re: GIMP and Google SoC (from digest)
Hi, [EMAIL PROTECTED] (2006-04-19 at 1158.08 +0200): How is this fairly straightforward with the current architecture? I would rather say that it is currently almost impossible to implement sanely. Ah, but I'm insane. Add a layer type for effect layers, and define 3 operations that you can associate with the layer (to start): curves, levels and colour balance. All the operations are pixel-by-pixel, which should make things easier. Then hack the projection code to add a special case for an effect layer. Internally I would say they are blend modes. Make them special so content is fixed and flat (better compression), so only layer mask matters. Then make the formula for the blend mode be curves, levels, colour balance... whatever you can find that is pix to pix (and probably LUT based in many cases, if not all) and make it work in BG while the FG is unused. The settings would be stored in a parasite. PS allows the following types: http://www.bairarteditions.com/pages/tutorials/photoshop/images/layerpalette.gif Except gradient and pattern, all the rest are pixel in, pixel out, without caring about the position. We'd need to evolve the xcf version number, and it probably wouldn't be possible to do anything useful with the effects layers in earlier versions of the GIMP (ignore seems about the best option). It would load a flat colour in normal mode and keep the layer mask, if implemented as above, I think, and maybe lose the parasite? It was time ago when I ported some modes and thus looked at XCF load/save. GSR ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] (no subject)
Your solution is too much complicated. Current situation with hidden binaries is much more acceptable from my POV. As the practice shows, the persons who want to obtain bleeding edge version ask for it at the yahoo win Gimp users group. They obtain the answer - some kind of look through the links at the site. And they find the executable they want. And in you case they would have to compile Gimp themselves or search for the person who would kindly do it for them. P.S. There is still no 2.3.8 compiled at the usual palace ;) If someone, like Paolo, wishes to ease the burden of compiling development versions from source and still be able to contribute then I would suggest that he get together with some like-minded people, share a pre-compiled binary, and discuss amongst themselves the problems they encounter. -- With respect Alexander Rabtchevich ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP and Google SoC
Hi, Alan Horkan [EMAIL PROTECTED] writes: I'd love to see a single unified interface shared by the various Python-fu, Script-fu, Perl-fu etc and it might make a suitable project since it is a limited self contained task. Can you elaborate on this? Single unified interface sounds great but I have no idea what you mean here. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Idea for data flow in gimp and or plug-ins
Hello, When reading about the ideas for the SoC, I was reminded of an idea I got when looking at a collegue showing me the L*bVi*w code development environment. By interactively dragging out various blocks with a different set of inputs and outputs and connecting these with connectors he basically created a dataflow. In LV these are usually used for reading input from various HW sensors and displaying them in dials etc. As I was thinking about other uses for the same idea, I thought of two uses in Gimp. Either as what was mentioned on this list as effect layers or as an alternative way of creating scripts. The layer paridigm seems to be quite limited since it is effectively one-dimensional. I believe that creating a canvas containing effect boxes and connecting wires through which images and parameters would flow, would be an easier interface to comprehend. Sorry for these somewhat disconnected thoughts. Should I write it up more organized in bugzilla? Regards, Dov ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Idea for data flow in gimp and or plug-ins
On Wed, Apr 19, 2006 at 10:29:16PM +0300, Dov Grobgeld wrote: Hello, When reading about the ideas for the SoC, I was reminded of an idea I got when looking at a collegue showing me the L*bVi*w code development environment. By interactively dragging out various blocks with a different set of inputs and outputs and connecting these with connectors he basically created a dataflow. In LV these are usually used for reading input from various HW sensors and displaying them in dials etc. As I was thinking about other uses for the same idea, I thought of two uses in Gimp. Either as what was mentioned on this list as effect layers or as an alternative way of creating scripts. The layer paridigm seems to be quite limited since it is effectively one-dimensional. I believe that creating a canvas containing effect boxes and connecting wires through which images and parameters would flow, would be an easier interface to comprehend. While it would be a quite useful tool for abstract thinking people, I think visually oriented users wouldn't see the use of that - after all, you need a lot of imagination and it is a very structured approach. Great for macro editing though! :-) AFAIK, GEGL is supposed to allow such things by providing the needed building blocks. Hm. SoC project build GEGL visual compisition graph editor? Bye, Tino. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and Google SoC
Okay, we are now on Google's list and have begun to put together a project page, which you can find at http://wiki.gimp.org/gimp/SummerOfCode . A couple of important points: 1) Ideally, a mentor for a project would be somebody who is capable of doing the project him/herself without a lot of false starts and hacking around, and only lacks the time for it. If you aren't at this level, you *might* still be a viable mentor, but only if you make this clear and get a commitment from somebody with more knowledge to give you whatever backup you will need. Just because you are interested in an idea does not mean that you are ready to mentor it. 2) If there is a project on the list that you are ready and willing to mentor, please add your initials, or some other unique identifier, to the description somewhere. Multiple volunteers for a single project are acceptable. 3) SoC students will probably be very enthusiastic and prepared to put in hundreds of hours of work. Don't be afraid to ask for things that are difficult. Conversely, be prepared to give regular guidance -- a student with nothing to do because of lack of feedback will get very frustrated very quickly. All this being said, please add your ideas to the page, or modify the ideas that are there. Sven and Mitch should feel free to delete ideas that they see as bad projects. Ultimately we should get this down to not more than a dozen clearly expressed and well-formulated projects. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP and Google SoC
On Wed, 19 Apr 2006, Sven Neumann wrote: Date: Wed, 19 Apr 2006 21:02:47 +0200 From: Sven Neumann [EMAIL PROTECTED] To: Alan Horkan [EMAIL PROTECTED] Cc: Not Photoshop gimp-developer@lists.XCF.Berkeley.EDU Subject: Re: [Gimp-developer] Re: GIMP and Google SoC Hi, Alan Horkan [EMAIL PROTECTED] writes: I'd love to see a single unified interface shared by the various Python-fu, Script-fu, Perl-fu etc and it might make a suitable project since it is a limited self contained task. Can you elaborate on this? Single unified interface sounds great but I have no idea what you mean here. Script-fu does not look like Python-fu or Perl-fu. Users should not be able to tell from the user interface that a different programming langauge was used. They all have automatically generated user intefaces* but the results look different, and some widgets such as a Radio list are supported in Python-fu but not in script-fu. Not sure I can make it any clearer but hopefully someone else can help explain it. -- Alan H. * Okay some of the Perl scripts have manually written graphical users interfaces but that is a side issue. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
