Re: [Gimp-developer] Gimp 2.8.0 - Saving in .jpg or .png hmmmmm
On Thu, 2012-05-17 at 22:49 -0400, Nicolas Robidoux wrote: I agree that Import/Save/Export is likely to make complete sense to the target user of GIMP 2.10. I also have the impression that it may be quite effective at informing soon-to-be-former-users that they are not members of the target club. That is such utter FUD it makes me puke. Really, --mitch ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Gimp 2.8.0 - Saving in .jpg or .png hmmmmm
One thing that can be useful for who does not read release notes is a tip that appear when an image opened from a format different by xfc is saved. The tip can be: Gimp now save images as xfc internal format. If you want to save in different format use Export. If you want save in the original format use Overwrite . The tip has a checkbox where you can chose to don't show next time. PS: Excuse for my English if I'm not very clear Il giorno 18/mag/2012 08:15, Michael Natterer mi...@gimp.org ha scritto: On Thu, 2012-05-17 at 22:49 -0400, Nicolas Robidoux wrote: I agree that Import/Save/Export is likely to make complete sense to the target user of GIMP 2.10. I also have the impression that it may be quite effective at informing soon-to-be-former-users that they are not members of the target club. That is such utter FUD it makes me puke. Really, --mitch ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] Cage-Tool performance
Hi First of all it is a great tool! And I love it. but I found some strange behaviour, so before I start a new bugreport, I wanted to ask you, if this is a bug or just something that's got to do with my system (Linux Xubuntu) First: when I made a cage and want to adjust the knots, I can't. I have to create a new cage. But when I create the cage new and close it, it cuts my picture into bits. The only way to avoid this, yet, is to restart Gimp and load the motiv new. Is there another way around this? Second: I tried out, whether I get a difference in making a cage closer to the motif or leaving a wider gap between motif and cage. Using the adjustment of filling the background with color. Normally, the background becomes transparent, when I use the option, but when I create a cage on the edge of the motif, the background becomes filled with a part-transperent background. I made some pictures of this: http://ws.kreativ-workshops.net/gimp2-8/einst/screens/bild384.png http://ws.kreativ-workshops.net/gimp2-8/einst/screens/bild384.png Thanks in advance. Anke -- Anke Lange An der Landwehr 25 49076 Osnabrück Telefon 0541 6004299 gimp-werkst...@gmx.de www.kreativ-workshops.net www.gimp-werkstatt.de www.kompozer-web.de ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Gimp 2.8.0 - Saving in .jpg or .png hmmmmm
Jason Simanek jsimanek at gmail.com writes: This is getting old. All they gotta do is go use some other FREE graphics application. Most of these complaints could be addressed by simply changing their keyboard shortcuts to use the overwrite command instead. I always change about 60% of the Gimp shortcuts anyway. (need to keep my sanity going back and forth between Photoshop and Gimp) Not a big deal. Here's the problem - overwrite only works once. Then it becomes export. And you can't assign the same keyboard shortcut to both. You'll have to assign two shortcuts, and remember to use one shortcut the first time, and the other shortcut the second, third etc. That is indeed a strange behavior - a command that only works once per file. Say what you will about save vs. export but this has to be fixed. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Cage-Tool performance
ups - the second picture-link was wrong http://ws.kreativ-workshops.net/gimp2-8/einst/screens/bild386.png Am 18.05.2012 08:44, schrieb Anke Lange: Hi First of all it is a great tool! And I love it. but I found some strange behaviour, so before I start a new bugreport, I wanted to ask you, if this is a bug or just something that's got to do with my system (Linux Xubuntu) First: when I made a cage and want to adjust the knots, I can't. I have to create a new cage. But when I create the cage new and close it, it cuts my picture into bits. The only way to avoid this, yet, is to restart Gimp and load the motiv new. Is there another way around this? Second: I tried out, whether I get a difference in making a cage closer to the motif or leaving a wider gap between motif and cage. Using the adjustment of filling the background with color. Normally, the background becomes transparent, when I use the option, but when I create a cage on the edge of the motif, the background becomes filled with a part-transperent background. I made some pictures of this: http://ws.kreativ-workshops.net/gimp2-8/einst/screens/bild384.png http://ws.kreativ-workshops.net/gimp2-8/einst/screens/bild384.png Thanks in advance. Anke -- Anke Lange An der Landwehr 25 49076 Osnabrück Telefon 0541 6004299 gimp-werkst...@gmx.de www.kreativ-workshops.net www.gimp-werkstatt.de www.kompozer-web.de ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Gimp 2.8.0 - Saving in .jpg or .png hmmmmm
Markus Heiler shevegen at gmail.com writes: - What other image-editor can I use on Linux? pixlr. It's a web app, not a standalone app. But it's pretty awesome. It may not have ALL the features Gimp has, but it also has some it doesn't, such as layer styles or some basic shape drawing options. You can work with masks, layers, color corrections, all the things you'd expect. www.pixlr.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Targeted audience of GIMP?
On Fri, May 18, 2012 at 8:13 AM, gfxuser gfx.u...@online.de wrote: Hi, the last thread reminded me of a question, which I had for some longer and I couldn't find the right answer yet: Who is the targeted audience of GIMP? 1) http://blog.mmiworks.net/2006/11/creating-user-scenarios-with-gimpteam.html In the five days before this weekend, Ellen and Kamila had been gathering vital raw material by performing workplace observation. Half a dozen professionals in the field of photography and graphic design were interviewed and observed on the job. These participants had been selected based on the GIMP product vision. 2) http://gui.gimp.org/index.php/User_Scenarios 3) http://gui.gimp.org/index.php/Interview_Partners Does it help? Personally I don't expect every single job out there to be listed. CG industry seems to create a new kind of job every year, for instance. Reading the product vision and the document 'GIMP 2.8 understanding UI changes' I don't see a clear definition of that, but only two groups: artists and scientists. Where are the non-professional artists and spare time enthusiasts? I'm also missing a clearer definition of the expected experience level. Only professionals seem to be addressed. Are the other people not targeted? Clearing this as a part of the product vision would be a big help to avoid misunderstandings. This would be tricky. People can use professional workflows and not be paid for the work they do. Alexandre Prokoudine http://libregraphicsworld.org ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Gimp 2.8.0 - Saving in .jpg or .png hmmmmm
Hi! My 2c on the issue - This change is GOOD not only for the target audience but to the novice too! You would not belive how may times people new to graphics have come to varoius gimp channels asking how i can change text on this here image I saved from gimp yesterday as jpg or png and I have to tell them that they cant! and they are not even aware of the xcf as a format that would allow them to change the composition at any time. In the worst case, they have managed to destroy the original by overwriting it too! The noobs are safe from destructive mistakes and the pro-s are happy because it now works the way that is the defacto industry standard. Only people that complain are the intermediate users that have habbits they have to change now... Very human. And slightly tedious. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Cage-Tool performance
On Fri, May 18, 2012 at 9:52 AM, Anke Lange gimp-werkst...@gmx.de wrote: First: when I made a cage and want to adjust the knots, I can't. I have to create a new cage. But when I create the cage new and close it, it cuts my picture into bits. The only way to avoid this, yet, is to restart Gimp and load the motiv new. Is there another way around this? Yes you can. Close the cage, then in tool options switch to Create or edit mode. Then you can adjust the cage untill you switch back to transform mode. Second: I tried out, whether I get a difference in making a cage closer to the motif or leaving a wider gap between motif and cage. Using the adjustment of filling the background with color. Cage transform is only defined for the interior of the cage. It's a limitation of the algorithm. The fill works based on the pixel under your first point. It's ideal operating environment is an element on a separate layer of a larger canvas with transparent bg. Cage is somewhat special transform. It strives to be shape preserving. -- --Alexia ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Cage-Tool performance
Thanks Alexia that does help :) by the way, the examples I made were made on transparent background, I only added a white layer to make it easier to see the cage. Anke Am 18.05.2012 10:01, schrieb Alexia Death: On Fri, May 18, 2012 at 9:52 AM, Anke Langegimp-werkst...@gmx.de wrote: First: when I made a cage and want to adjust the knots, I can't. I have to create a new cage. But when I create the cage new and close it, it cuts my picture into bits. The only way to avoid this, yet, is to restart Gimp and load the motiv new. Is there another way around this? Yes you can. Close the cage, then in tool options switch to Create or edit mode. Then you can adjust the cage untill you switch back to transform mode. Second: I tried out, whether I get a difference in making a cage closer to the motif or leaving a wider gap between motif and cage. Using the adjustment of filling the background with color. Cage transform is only defined for the interior of the cage. It's a limitation of the algorithm. The fill works based on the pixel under your first point. It's ideal operating environment is an element on a separate layer of a larger canvas with transparent bg. Cage is somewhat special transform. It strives to be shape preserving. -- Anke Lange An der Landwehr 25 49076 Osnabrück Telefon 0541 6004299 gimp-werkst...@gmx.de www.kreativ-workshops.net www.gimp-werkstatt.de www.kompozer-web.de ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] Feature request: Improve the Open file dialog thumbnails
I've been using GIMP to play around with some lighting, color, and GEGL operations on images. What I've noticed is that the Open file dialog is very poorly constructed and it has become a problem. I'm using Win7 x64. Nicely put, it's unintuitive. These are suggested fixes, and you can choose more than one if it permits. 1. Raise the file size limit for autogeneration of thumbnails. Many of my JPEGs are just slightly over 3 MB or whatever the small current limit is. Many of my RAW NEF files are just *under* 10 MB, at a resolution of 10.2 Megapixels. Many dSLR's exceed my camera's resolution, so my recommended upper limit is 20 MB, but doing a progressive scan (priority queue) would work best. Start out with anything under 5 MB, then 10, then 20 MB, so it is a rough priority queue, instead of a fine-grain one. 2. Allow users to multiselect files and explicitly batch-generate thumbnails (just clicking on the thumbnail placeholder with multiple images selected should initiate the process). 3. Use the native Open file dialog. Additional comments: I have seen no other modern program, even open source, that has such an unusable thumbnail generator. If I recall correctly, there is a free implementation in Evince Document reader for a regular thumbnailer (thumbnail grid) and Open file dialog. Bigger Goal: Improve the Open file dialog to include other viewing modes besides a detail list. It's a graphics program after all! Appeal to the senses! -- I'm an FSF member. The Free Software Foundation fights to keep your computer in your control, and only your control. Help protect you and your friends from customer abuse in the technology industry! http://www.fsf.org/jf?referrer=9448 ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Feature request: Improve the Open file dialog thumbnails
On Fri, May 18, 2012 at 11:33 AM, Ryan Johnson wrote: 3. Use the native Open file dialog. and Bigger Goal: Improve the Open file dialog to include other viewing modes besides a detail list. It's a graphics program after all! Appeal to the senses! are mutually exclusive on Windows. And with the latter request you are telling us to patch the upstream GTK+ dialog. Alexandre Prokoudine http://libregraphicsworld.org ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Feature request: Improve the Open file dialog thumbnails
On 18.05.2012 09:33, Ryan Johnson wrote: I've been using GIMP to play around with some lighting, color, and GEGL operations on images. What I've noticed is that the Open file dialog is very poorly constructed and it has become a problem. I'm using Win7 x64. Nicely put, it's unintuitive. These are suggested fixes, and you can choose more than one if it permits. 1. Raise the file size limit for autogeneration of thumbnails. This is in GIMP's preferences, so a different default would be easy to do, 2. Allow users to multiselect files and explicitly batch-generate thumbnails (just clicking on the thumbnail placeholder with multiple images selected should initiate the process). this is already possible, 3. Use the native Open file dialog. and no, just no. Before ever doing that, GIMP should switch to an if you need better file handling, then use your platform's file manager and open images from there approach and ditch the file open dialog completely. I wouldn't be surprised if this was a GNOME user interaction goal, either. I'm using Windows, and I open most file in any program either through their MRU list or via a Windows Explorer window, because all of the file open dialogs are awkward. Regards, Michael ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Feature request: Improve the Open file dialog thumbnails
Am 18.05.12 09:33, schrieb Ryan Johnson: Hi Ryan, I checked your complaints with GIMP 2.8 with the following results: 1. Raise the file size limit for autogeneration of thumbnails. Many of my JPEGs are just slightly over 3 MB or whatever the small current limit is. Many of my RAW NEF files are just /under/ 10 MB, at a resolution of 10.2 Megapixels. Many dSLR's exceed my camera's resolution, so my recommended upper limit is 20 MB, but doing a progressive scan (priority queue) would work best. Start out with anything under 5 MB, then 10, then 20 MB, so it is a rough priority queue, instead of a fine-grain one. There is a solution for you in the preferences dialog. Goto Edit/Preferences/Environment pane. In the middle of the right side you will find the option 'Maximum filesizes for thumbnailing'. That's your friend. 2. Allow users to multiselect files and explicitly batch-generate thumbnails (just clicking on the thumbnail placeholder with multiple images selected should initiate the process). Have you already tried this? I just did: multiselected files in the list of the 'open file' dialog, clicked on 'Click to create preview' in the right pane - and GIMP just created thumbnails for the selected files. Cool, isn't it? ;-) Alexandre wrote: 3. Use the native Open file dialog. and Bigger Goal: Improve the Open file dialog to include other viewing modes besides a detail list. It's a graphics program after all! Appeal to the senses! are mutually exclusive on Windows. I wouldn't say that. On Windows 7 the native 'open file' dialog contains different views: list, details, symbols in various sizes, tiles. Symbols and tiles contain a preview of every file. IIRC it was similar with Windows XP. I think, that's what the OP wants. IMHO using native dialogs has one mantrap: they need to be checked first whether they can fulfill all requirements of the application, like a thumbnail preview. Not every platform may offer all necessary possibilities and keeping track of this could be a hard work. I like the way of the Mac version: there's a 'Show in Finder' menu item in the file dialog, which will start the platforms file manager. Best regards, grafxuser ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Feature request: Improve the Open file dialog thumbnails
On Fri, May 18, 2012 at 12:59 PM, gfxuser gfx.u...@online.de wrote: I wouldn't say that. On Windows 7 the native 'open file' dialog contains different views: list, details, symbols in various sizes, tiles. This is exactly what I was referring to. There's no need to sit down and create a patch for GTK+ which GTK+ team probably doesn't even want, when you could use native dialogs. Personally I've no special opinion on native vs. GTK+ dialogs on Windows. As a non-Windows user I'm fine with both :) Alexandre Prokoudine http://libregraphicsworld.org ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Feature request: Improve the Open file dialog thumbnails
On 18 May 2012 11:18, Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: On Fri, May 18, 2012 at 12:59 PM, gfxuser gfx.u...@online.de wrote: I wouldn't say that. On Windows 7 the native 'open file' dialog contains different views: list, details, symbols in various sizes, tiles. This is exactly what I was referring to. There's no need to sit down and create a patch for GTK+ which GTK+ team probably doesn't even want, when you could use native dialogs. Personally I've no special opinion on native vs. GTK+ dialogs on Windows. As a non-Windows user I'm fine with both :) Please fix GTK+ instead of using some platforms native dialog in GIMP. That way it will work for all GTK+ based applications and on all operating systems supported by GTK+. Remember also that GtkFileChooser is the native dialog for GNOME (and XFCE). Some work was done recently, but never ended up in mainline. https://bugzilla.gnome.org/show_bug.cgi?id=141154 -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Feature request: Improve the Open file dialog thumbnails
On 18.05.12 10:59, gfxuser wrote: I wouldn't say that. On Windows 7 the native 'open file' dialog contains different views: list, details, symbols in various sizes, tiles. Symbols and tiles contain a preview of every file. IIRC it was similar with Windows XP. I think, that's what the OP wants. But for XCF files that's not very useful as GIMP doesn't come with an XCF IThumbnailProvider, so all XCF files would only show the Wilber file icon at it's highest resolution instead of a preview... :( -- Kurt Bernhard Pruenner --- Haendelstrasse 17 --- 4020 Linz --- Austria np: Frittenbude - Heimatlos (Delfinarium) ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Feature request: Improve the Open file dialog thumbnails
On Fri, May 18, 2012 at 2:19 PM, Kurt Pruenner wrote: But for XCF files that's not very useful as GIMP doesn't come with an XCF IThumbnailProvider, so all XCF files would only show the Wilber file icon at it's highest resolution instead of a preview... :( And that's another task for an interested developer. How about making a publicly available list of platform-specific tasks? Alexandre Prokoudine http://libregraphicsworld.org ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Feature request: Improve the Open file dialog thumbnails
Alexandre Prokoudine wrote: And that's another task for an interested developer. How about making a publicly available list of platform-specific tasks? From my point of view a good idea. Something to start from: for Mac: https://bugzilla.gnome.org/buglist.cgi?order=Importanceclassification=Otherop_sys=Mac%20OSquery_format=advancedbug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_status=NEEDINFOproduct=GIMP for Windows: https://bugzilla.gnome.org/buglist.cgi?order=Importance;classification=Other;op_sys=Windows;query_format=advanced;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;bug_status=NEEDINFO;product=GIMP for Linux: https://bugzilla.gnome.org/buglist.cgi?order=Importance;classification=Other;op_sys=Linux;query_format=advanced;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;bug_status=NEEDINFO;product=GIMP This can be simply added to the GIMP website or the wiki. Best regards, grafxuser (who's not just talking ;-)) ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Gimp 2.8.0 - Saving in .jpg or .png hmmmmm
On 05/18/2012 10:24 AM, gg wrote: Calling it save workspace makes it instantly clear that it will not writing back to the source image and that any layers etc and work in progress will be safe. I would expect Save Workspace to save the arrangement of windows and panels. Maybe also the selection of opened files, but not any of the files themselves. Thinking about how the term workspace is used elsewhere, I'm confident a significant percentage of users would have similar expectations. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Gimp 2.8.0 - Saving in .jpg or .png hmmmmm
This is how things work in NIP2. (I am not holding NIP2 as a paragon of beginner friendliness by no means. Just brainstorming, and adapting things a bit to what I understand of GIMP.) Open/Save have to to with loading/saving from/into the file system (the hard disk). Two kinds of objects can be opened/saved: workspaces (which include everything, windows and all) and individual images. (In GIMP, there may need to be a third type: XCF.) If the focus is within the frame of an individual image, NIP2 understand that Save has to do with the image itself, and will ask whether you want png, jpg, ... with a reasonable default. Elsewhere, it would make a lot of sense that Save default to saving the workspace. (I've not checked because I normally use the menu instead of keyboard shortcuts.) - Import/Export have to do with conversion using an ICC profile. By default, NIP2 does not do this automatically, and makes reasonable but minimal assumptions. But it does not involve the hard drive (unless the profile needs to be taken from there). Colourspace conversion is separate from both Open/Save and Import/Export. - Again, this is just to give an example of a system which I find logical, and which IMHO accommodates fairly naturally both naive users and power users. However, it does not address the fact that in GIMP there is a exposed construct that sits between resulting JPEG and the whole workspace with windows, image loaded, some tools at the foregroung...: The XCF file. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Gimp 2.8.0 - Saving in .jpg or .png hmmmmm
Once GEGL becomes the operative system, XCF can be understood as the tree that leads to a specific image. Save tree? ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Gimp 2.8.0 - Saving in .jpg or .png hmmmmm
On 05/18/2012 02:18 PM, Nicolas Robidoux wrote: Once GEGL becomes the operative system, XCF can be understood as the tree that leads to a specific image. Save tree? project would have my vote. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Gimp 2.8.0 - Saving in .jpg or .png hmmmmm
Whimsically, save workspace/XCF/image could be save forest/tree/leaf. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Targeted audience of GIMP?
There are a couple of user scenarios that are not on the list, that I hope can be included. These are: - Creating original art from scratch (basically drawing and painting...this is mainly what I use GIMP for). Actually, it works pretty nicely for this as is...but it would be nice to see it included anyway. :) - Creating textures for 3D (for games or film). This is in many ways a lot like creating original art from found images with a few differences. Such as creating tileable textures, exporting different passes (color, bump, spec maps etc.), and warping images to match UV's. Taken to the extreme it would include painting directly on 3D models, but I think that would be outside the scope of what GIMP is. Cheers, Ragnar On Fri, May 18, 2012 at 9:43 AM, Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: On Fri, May 18, 2012 at 8:13 AM, gfxuser gfx.u...@online.de wrote: Hi, the last thread reminded me of a question, which I had for some longer and I couldn't find the right answer yet: Who is the targeted audience of GIMP? 1) http://blog.mmiworks.net/2006/11/creating-user-scenarios-with-gimpteam.html In the five days before this weekend, Ellen and Kamila had been gathering vital raw material by performing workplace observation. Half a dozen professionals in the field of photography and graphic design were interviewed and observed on the job. These participants had been selected based on the GIMP product vision. 2) http://gui.gimp.org/index.php/User_Scenarios 3) http://gui.gimp.org/index.php/Interview_Partners Does it help? Personally I don't expect every single job out there to be listed. CG industry seems to create a new kind of job every year, for instance. Reading the product vision and the document 'GIMP 2.8 understanding UI changes' I don't see a clear definition of that, but only two groups: artists and scientists. Where are the non-professional artists and spare time enthusiasts? I'm also missing a clearer definition of the expected experience level. Only professionals seem to be addressed. Are the other people not targeted? Clearing this as a part of the product vision would be a big help to avoid misunderstandings. This would be tricky. People can use professional workflows and not be paid for the work they do. Alexandre Prokoudine http://libregraphicsworld.org ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Gimp 2.8.0 - Saving in .jpg or .png hmmmmm
On Fri, May 18, 2012 at 4:18 PM, Nicolas Robidoux wrote: Once GEGL becomes the operative system, XCF can be understood as the tree that leads to a specific image. Save tree? Save the trees Save the bees Save the wales Save those snails (c) http://www.youtube.com/watch?v=eScDfYzMEEw Alexandre Prokoudine http://libregraphicsworld.org ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Gimp 2.8.0 - Saving in .jpg or .png hmmmmm
On Fri, May 18, 2012 at 5:13 PM, Michael Grosberg wrote: If an image is saved to a lossy format, it could be decided that the first time you attempt to do this, an alert will explain to you that repeated saving to JPG corrupts the image. A checkbox in the dialog will enable you to prevent it from showing again. I have a gut feeling that in terms of usability it is considered to be a mortal sin :) Alexandre Prokoudine http://libregraphicsworld.org ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Feature request: Improve the Open file dialog thumbnails
On Fri, May 18, 2012 at 9:01 AM, Jernej Simončič jer...@ena.si wrote: Err, why? I find the Windows dialog boxes infinitely more usable than GTK+'s (especially after the latest improvement with the Recent list). The GTK+ file chooser does seem to be horrible, and I'm not sure why. Here's a usage scenario that continually drives me crazy in GIMP: 1) Create a new image 2) Select File-Save - The Save File dialog opens 3) Navigate to the correct directory 4) Type the filename to save Expected result: The highlighted part of Untitled in Name: Untitled.xcf is replaced with what you type. Actual result: The dialog assumes you want to destroy a file already in the directory and starts selecting from them until you type something that can't be completed using the files in the directory. Then, another little window appears showing you what you're typing. When you finish typing the name you want to save as and hit Enter, the dialog prompts you to overwrite the file that last matched what you were typing. I'm not sure if the GTK+ file chooser really is this stupid, or if GIMP isn't setting some kind of save mode flag. Chris ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Targeted audience of GIMP?
gfxuser wrote: the last thread reminded me of a question, which I had for some longer and I couldn't find the right answer yet: Who is the targeted audience of GIMP? since I am used to doing a briefing on this, for GIMP design projects and also recently the start of a university usability surveying project, I thought I could write some of that down: http://gui.gimp.org/index.php/Vision_briefing --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Gimp 2.8.0 - Saving in .jpg or .png hmmmmm
Hello list I can't really understand what all this fuss is about. All grafical programms I know of work this way. You only save in the programs own format and export to a diffent like png, jpg or pdf... It is only a kind of getting used to it in GIMP, when you have been working with it for some time. I hate little windows popping up asking me if I'm really, really sure to proceed with the decision I made, so they don't really alert me anymore. I guess a lot of user feel that way, espacially on windows-systems where you get even more alert-windows. I think it's a really good solution to stick with the normal way to handle saving-procedures. just my 2c Anke Am 18.05.2012 15:32, schrieb Alexandre Prokoudine: On Fri, May 18, 2012 at 5:13 PM, Michael Grosberg wrote: If an image is saved to a lossy format, it could be decided that the first time you attempt to do this, an alert will explain to you that repeated saving to JPG corrupts the image. A checkbox in the dialog will enable you to prevent it from showing again. I have a gut feeling that in terms of usability it is considered to be a mortal sin :) Alexandre Prokoudine http://libregraphicsworld.org ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list -- Anke Lange An der Landwehr 25 49076 Osnabrück Telefon 0541 6004299 gimp-werkst...@gmx.de www.kreativ-workshops.net www.gimp-werkstatt.de www.kompozer-web.de ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Gimp 2.8.0 - Saving in .jpg or .png hmmmmm
Metaphor: A tree (.xcf) will grow away from the forest (project/workspace), but a leaf (.jpg or .png) cut away from the tree won't. (And yes, I am perfectly aware that in a graph theory sense what I'm proposing to call a leaf is actually a root. The point here is to communicate the key information to non-technical users in a form that they will understand and remember.) ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Gimp 2.8.0 - Saving in .jpg or .png hmmmmm
On Fri, May 18, 2012 at 4:24 AM, gg g...@catking.net wrote: ... In any other context opening a file and then saving it, the user will *expect to be saving the file* . Why try to redefine what the world already does. ... Here is a trivial change that would immediately take care of the confusion that lead to the top post of this thread: Exchange the ACTIONS of open - import and save - export. That is: import/export is for XCF. save/open is for JPEG, PNG, GIF, TIFF, ... If you think about it for a minute, this is not as ad hoc as it first seems, and I suspect that it would preemptively kill a lot of complaints. Sure, some users will shoot themselves in the foot and open/save and ask how can I undo? My guess is that generally they make this mistake once. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Targeted audience of GIMP?
http://gui.gimp.org/index.php/Vision_briefing Beautiful. Clear. Is *speed* really inferred from the vision? tools get out of the way of getting things done and allow for accelerating the workflow This talks of a *non obstructive interface*, which appeals to me, but how is speed a necessity? On Fri, May 18, 2012 at 7:07 PM, peter sikking pe...@mmiworks.net wrote: gfxuser wrote: the last thread reminded me of a question, which I had for some longer and I couldn't find the right answer yet: Who is the targeted audience of GIMP? since I am used to doing a briefing on this, for GIMP design projects and also recently the start of a university usability surveying project, I thought I could write some of that down: http://gui.gimp.org/index.php/Vision_briefing --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list -- * * *Regards, * *Srihari Sriraman * ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Gimp 2.8.0 - Saving in .jpg or .png hmmmmm
On Fri, May 18, 2012 at 6:25 PM, Nicolas Robidoux wrote: Here is a trivial change that would immediately take care of the confusion that lead to the top post of this thread: Exchange the ACTIONS of open - import and save - export. That is: import/export is for XCF. save/open is for JPEG, PNG, GIF, TIFF, ... How does it align to the workflows of professionals? Alexandre Prokoudine http://libregraphicsworld.org ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Targeted audience of GIMP?
On Fri, May 18, 2012 at 6:31 PM, Srihari Sriraman wrote: Is speed really inferred from the vision? tools get out of the way of getting things done and allow for accelerating the workflow This talks of a non obstructive interface, which appeals to me, but how is speed a necessity? This is called a turn-round. It's how fast you can finish a job for one client to switch to the next one. Alexandre Prokoudine http://libregraphicsworld.org ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Gimp 2.8.0 - Saving in .jpg or .png hmmmmm
Yet another completely different (and rather radical) idea: If the user saves as JPEG (say), GIMP automatically and silently saves the XCF alongside it or in a special folder. Then Open/Save does everything you want, and when the beginner user reopens the JPEG, he can be asked if he/she wants to actually get back the XCF. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Feature request: Improve the Open file dialog thumbnails
From my perspective, what kind of filepicker dialog an application uses goes a long way in making it look like a native app for its target platform. Allowing the Windows version of GIMP to incorporate the native Win32 filepicker dialog would be a huge improvement at least in platform-specific aesthetics and user convenience -- if nothing else -- but functionally speaking it would also give GIMP the ability to follow Win32 style shortcuts (.lnk files), because that's part of the filepicker functionality. And GIMP would still be able to customize the dialog box with a GIMP-specific thumbnail panel (which, as noted, more frequently skips generating a thumbnail than not) -- that is what you see in current versions of Inkscape's Win32 platform, Inkscape being another GTK+ app. -- Stratadrake strata_ran...@hotmail.com Numbers may not lie, but neither do they tell the whole truth. Date: Fri, 18 May 2012 09:35:32 -0400 From: ccurt...@gmail.com To: gimp-developer-list@gnome.org Subject: Re: [Gimp-developer] Feature request: Improve the Open file dialog thumbnails On Fri, May 18, 2012 at 9:01 AM, Jernej Simončič jer...@ena.si wrote: Err, why? I find the Windows dialog boxes infinitely more usable than GTK+'s (especially after the latest improvement with the Recent list). The GTK+ file chooser does seem to be horrible, and I'm not sure why. Here's a usage scenario that continually drives me crazy in GIMP: 1) Create a new image 2) Select File-Save- The Save File dialog opens3) Navigate to the correct directory4) Type the filename to save Expected result: The highlighted part of Untitled in Name: Untitled.xcf is replaced with what you type. Actual result: The dialog assumes you want to destroy a file already in the directory and starts selecting from them until you type something that can't be completed using the files in the directory. Then, another little window appears showing you what you're typing. When you finish typing the name you want to save as and hit Enter, the dialog prompts you to overwrite the file that last matched what you were typing. I'm not sure if the GTK+ file chooser really is this stupid, or if GIMP isn't setting some kind of save mode flag. Chris ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Gimp 2.8.0 - Saving in .jpg or .png hmmmmm
Terminology ideas: .xcf: composition (composition suggests result of compositing as well as its process, which is a fitting description, I think) or project Everything (tools, frames, input and output images...): session, workspace or project. .jpg or .png or .tif or ...: image ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Targeted audience of GIMP?
peter sikking wrote: gfxuser wrote: the last thread reminded me of a question, which I had for some longer and I couldn't find the right answer yet: Who is the targeted audience of GIMP? since I am used to doing a briefing on this, for GIMP design projects and also recently the start of a university usability surveying project, I thought I could write some of that down: http://gui.gimp.org/index.php/Vision_briefing Very interesting and thanks for your work. What is 'hyper commercial'? Googling for it led me to a truck rental in South Africa ...*hmm* To me it seems the beginners or 'average users' are not targeted by this vision, are they? Or haven't they just been considered _yet_? To speak for myself, I'm doing graphical art and photo editing, but just for fun and in my sparetime. I wouldn't claim to be a professional. And I think there are a lot more people in just this situation. What would be the benefit for one 'like us' to contribute to GIMP? Will we/they benefit automatically from a redesigned UI? Best regards, grafxuser ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Gimp 2.8.0 - Saving in .jpg or .png hmmmmm
Am 18.05.2012 16:49, schrieb Nicolas Robidoux: Yet another completely different (and rather radical) idea: If the user saves as JPEG (say), GIMP automatically and silently saves the XCF alongside it or in a special folder. this idea was considered and rejected two years ago. However, for a fully geglized GIMP, it seams feasible to write a journal of all user activities -- for crash recovery and re-edit capability across sessions. To give an upper bound of required journal bandwidth, let's say the pointing device input comes in as 2*16bit coordinates at 50Hz rate. That's 200B/s or roughly 7MB for a 10-hour workday of non-stop drawing. I guess with compression and real-world data, it's much less, by factor 10-1000. best regards, yahvuu ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Gimp 2.8.0 - flawed export/overwrite behavior [was: Saving in .jpg or .png hmmmmm]
Going to split this because it really NEEDS some wider discussion. There's no nice way of phrasing it - in the current GIMP this distinction is a total snafu. To: gimp-developer-list@gnome.org From: grosberg.mich...@gmail.com Date: Fri, 18 May 2012 06:45:22 + Subject: Re: [Gimp-developer] Gimp 2.8.0 - Saving in .jpg or .png hm Here's the problem - overwrite only works once. Then it becomes export. And you can't assign the same keyboard shortcut to both. You'll have to assign two shortcuts, and remember to use one shortcut the first time, and the other shortcut the second, third etc. That is indeed a strange behavior - a command that only works once per file. Say what you will about save vs. export but this has to be fixed. When I filed bug #675385 about the export/overwrite distinction the overall response was notabug, but Michael Natterer did also comment that: Michael Natterer [GIMP developer] 2012-05-05 17:05:25 UTC There is a bug in 2.8 that keeps Ctrl+E invokable even if the menu entry is hidden. I fixed that in git, it will be in 2.8.1. Unfortunately this will only exacerbate the problem -- when all you need to do is a quick start-GIMP/import-file/minor-edit/overwrite/exit-GIMP job, this means that your Ctrl+E will either work only once per image session (if assigned to file-overwrite) or not at all (if assigned to file-export). In order to get both sides you'd need a third shortcut, say, Ctrl+Alt+E, assigned to the third command. But why should a third shortcut even be necessary in the first place? This whole distinction between overwrite and export was fundamentally flawed from the start; there is no reason GIMP should need three functions to perform what are essentially only two commands: - Export... - Analogous to the Save As command, but for non-XCF formats. Intended for first-time exports and other situations where you want to export an image to a different filename. You are prompted for a filename and format options before it actually writes to file. - Overwrite - Analogous to the Save command, but for non-XCF formats. Intended for exporting back to the original (non-XCF) file; whether or not there was a previous export within the current session is simply irrelevant. If the file was neither imported nor exported, then it will trade off to the Export... command (also analogous to the Save / Save As distinction). Remember, at any time GIMP only displays two export options in its menu: The first may be called Export to [filename] or Overwrite [filename] but regardless of whichever one is currently shown, it performs ultimately the same function: Exporting back to the same non-XCF file with no questions asked. Why does there even need to be two different internal functions (file-export and file-overwrite) to handle this ONE behavior? -- Stratadrake strata_ran...@hotmail.com Numbers may not lie, but neither do they tell the whole truth. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Gimp 2.8.0 - Saving in .jpg or .png hmmmmm
On 18.05.2012 15:53, Anke Lange wrote: Hello list I can't really understand what all this fuss is about. All grafical programms I know of work this way. +1 Regards Stefan Peter -- In summary, I think you are trying to solve a problem that may not need to be solved, using a tool that is not meant to solve it, without understanding what is causing your problems and without knowing how the tool actually works in the first place :) Jeffrey J. Kosowsky on the backuppc mailing list ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Gimp 2.8.0 - flawed export/overwrite behavior [was: Saving in .jpg or .png hmmmmm]
On 18/05/2012, Richard Gitschlag strata_ran...@hotmail.com wrote: Going to split this because it really NEEDS some wider discussion. There's no nice way of phrasing it - in the current GIMP this distinction is a total snafu. To: gimp-developer-list@gnome.org From: grosberg.mich...@gmail.com Date: Fri, 18 May 2012 06:45:22 + Subject: Re: [Gimp-developer] Gimp 2.8.0 - Saving in .jpg or .png hm Here's the problem - overwrite only works once. Then it becomes export. And you can't assign the same keyboard shortcut to both. Michael Natterer 2012-05-05 17:05:25 UTC There is a bug in 2.8 that keeps Ctrl+E invokable even if the menu entry is hidden. I fixed that in git, it will be in 2.8.1. Unfortunately this will only exacerbate the problem -- when all you need to do is a quick start-GIMP/import-file/minor-edit/overwrite/exit-GIMP job, this means that your Ctrl+E will either work only once per image session (if assigned to file-overwrite) or not at all (if assigned to file-export). In order to get both sides you'd need a third shortcut, say, Ctrl+Alt+E, assigned to the third command. I didn't read the huge paragraph I snipped, but I think you completely misunderstood the reply to the bug. The bug is that ctrl-e doesn't work in 2.8.0 when you import a file until you do 'export'. This is fixed in 2.8.1, you can now always press ctrl-e to export a file. If it is imported, it will prompt for a new name, if you already picked an export name it will silently export to the same name again. -- Mikael Magnusson ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Gimp 2.8.0 - flawed export/overwrite behavior [was: Saving in .jpg or .png hmmmmm]
On 05/18/12 19:47, Richard Gitschlag wrote: When I filed bug #675385 about the export/overwrite distinction the overall response was notabug, but Michael Natterer did also comment that: Michael Natterer https://bugzilla.gnome.org/page.cgi?id=describeuser.htmllogin=mitch%40gimp.org [GIMP developer] 2012-05-05 17:05:25 UTC There is a bug in 2.8 that keeps Ctrl+E invokable even if the menu entry is hidden. I fixed that in git, it will be in 2.8.1. Unfortunately this will only exacerbate the problem -- when all you need to do is a quick start-GIMP/import-file/minor-edit/overwrite/exit-GIMP job, this means that your Ctrl+E will either work only once per image session (if assigned to file-overwrite) or not at all (if assigned to file-export). In order to get both sides you'd need a third shortcut, say, Ctrl+Alt+E, assigned to the third command. But why should a third shortcut even be necessary in the first place? This whole distinction between overwrite and export was fundamentally flawed from the start; there is no reason GIMP should need three functions to perform what are essentially only two commands: - Export... - Analogous to the Save As command, but for non-XCF formats. Intended for first-time exports and other situations where you want to export an image to a different filename. You are prompted for a filename and format options before it actually writes to file. - Overwrite - Analogous to the Save command, but for non-XCF formats. Intended for exporting back to the original (non-XCF) file; whether or not there was a previous export within the current session is simply irrelevant. If the file was neither imported nor exported, then it will trade off to the Export... command (also analogous to the Save / Save As distinction). Remember, at any time GIMP only displays two export options in its menu: The first may be called Export to [filename] or Overwrite [filename] but regardless of whichever one is currently shown, it performs ultimately the same function: Exporting back to the same non-XCF file with no questions asked. Why does there even need to be two different internal functions (file-export and file-overwrite) to handle this ONE behavior? That about sums it up for me. /gg ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Feature request: Improve the Open file dialog thumbnails
În data de Fri, 18 May 2012 12:25:34 +0400, Alexandre Prokoudine a scris: are mutually exclusive on Windows. And with the latter request you are telling us to patch the upstream GTK+ dialog. The Windows Inkscape version uses Windows native file open and save dialog, so some solution appears to exists already. Cristi -- Cristian Secară http://www.secarica.ro ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] Wishlist: gegl Gaussian blur XY settings
Hi All, For the Gaussian blur gegl tool, is it possible to link the X Y size settings so that they scroll together? More often than not, you are likely to use the same value in both directions. Thanks, Partha ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] contribution processes...
In my opinion the language of the draft is not inviting to contribution. At minimum, each of the has tos should be changed to either shoulds or should strive tos. Also, it is unclear whether the final does not have to be perfect trumps any or all of the previous seven bullet points -- if it does not then the requirements are indeed exceedingly stringent. Especially problematic is the sixth bullet. A contributor should not be expected to learn or have access to other platforms just so he can submit code; he should write his code to work on his development system and those with access to and familiarity with alternative deployments should be able to submit patches or propose changes to accommodate their systems. This suggests that the infrastructure to support contributor participation should be hierarchical in nature; i.e., each enhancement/bugfix should be treated as an openly developed subproject in which all are welcome to participate. I would propose something akin to the following: A separate 'gimp-contrib' repository be created in which development of patches takes place. * A potential contributor submits a Bugzilla report outlining his issue and indicating that he/she is willing to work towards its resolution. * Upon approval of the endeavor by the GIMP developers, the contributor is granted branching and commit privileges to the 'gimp-contrib' repository (if not already granted previously). This does NOT offer push privileges to the Gnome-hosted 'gimp' repository. * The contributor solicits whatever support and aid for his project he/she can, through whatever channels he/she wishes. More significant aspects of the development should be inclusive of the official GIMP channels (mailing list, IRC, and the corresponding Bugzilla report), but smaller issues can be handled without interfering with the main project. * They are responsible for keeping their branch in synch with the GNOME 'gimp' module (or 'gimp-help-2', 'gimp-web', 'gimp-data-extras', etc) and following the feedback provided by the GIMP developers and the input of GIMP UI design team. * Notably, contributors neither produce or submit patches; they focus on producing their code, incorporating suggestions, and persuading people to test it. * When the contributor feels his project is in suitable shape for inclusion in GIMP, he/she requests that the GIMP developers merge his branch. The process outlined above provides a solution that allows for distributed development that avails itself of the capabilities of GIT and scales to both the smallest and largest of 'subprojects'. Contributors' abilities to get their code incorporated would ultimately depend upon their ability to attract the support of the GIMP developers but, importantly, they are initially welcomed to participate in the project and can learn incrementally the process of contributing to a large, community-run codebase. The demand placed on GIMP developers to support this infrastructure should be less than the current method. Contributors are permitted to fail without interfering with mainline developme ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
