Re: [Gimp-developer] Developer Boot Camp?
On 01/27/2011 04:43 PM, Eric Grivel wrote: I am getting the impression that the Gimp project is trapped in a chicken-and-egg problem with regard to attracting new contributors, where the few core developers are too busy maintaining the product to spend a lot of time helping new developers come on board. Gimp is an extremely large and complex system. I am a fairly experienced coder myself, and have recently submitted patches for two open bugs. But those were easy ones, not really related to any Gimp structures but basic C bug fixing. I have looked at some of the other outstanding bugs and for most don't have a clue where to start, or how to make sure that my fix fits in the vision, or that it doesn't break something else. At this point, knowing how busy the core Gimp developers are, and recognizing that it will take more time for them to walk me through a problem and a solution than it would take them to just fix the issue themselves, I am hesitant to ask for a lot of help. On the other hand, the idea of just delving in and figuring it out myself is quite daunting. Which is where my thought of a boot camp came in. What if there was a group of potential new developers all struggling with the same learning curve? Wouldn't it be great if an experienced Gimp developer could lead the whole group through a series of exercises, designed to gain experience and understanding of the Gimp and Gegl internals. This would require some serious commitment of time by one or more of the Gimp developers, and would mean other work wouldn't get done. The potential payoff however in the form of bringing one or more additional Gimp developers up to speed could be significant. Eric I think there are some good points in Eric's comments. I don't know quite how to describe it, but if the boot camp were virtual in some manner that others coming along in the future could learn from, but not be buried and obsolete issues a few years from now, that would seem to be the best of all worlds. Perhaps something along the line of a highly structured web-based (not particularly email) discussion forum approach (using out-of-the box forum software) wherein each issue/subject/lesson was a tightly managed thread that allowed on-subject question/answer, but then the net of each answer gets integrated back into the initial lesson, making the lessons stronger over time. And if a thread becomes obsolete due to advances in Gimp, etc., the thread can be archived. Unlike a normal discussion forum, the managers would edit, amplify, rearrange or remove both questions and answers as appropriate to strengthen the lesson. After all, the intent is not a real discussion with expression of opinion, etc., the intent is a directed learning experience in which the teachers and students interact to hone the usability of the lesson. Anything that will help to capture the knowledge and experience of the core developers can only help to keep Gimp vital in the coming years. We never know when any individual will no longer be available in Gimp's future, thus capturing that knowledge is really important. Jay ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] IMPORTANT: GIMP AND OPENSOURCE SCAM ON EBAY!
On 09/23/2010 02:00 PM, Alexandre Prokoudine wrote: That basically boils down to Why is there no GIMP Foundation? In my sick and screwed imagination the answer would be Because there is nobody willing to do all the bloody boring daily work required to ensure prosperity of such an organization. It is amazing how *NOT* bloody boring things are when one is well compensated for it. If it were a paid position, supervised by a volunteer board of directors, there would be no end of applicants. I suspect that a paid Foundation position might annoy some developers who have been busting their tails for years, for free. Oh well. Jay ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Fwd: GTK+ 2.20.0 released]
On 03/24/2010 10:00 AM, saulgo...@flashingtwelve.brickfilms.com wrote: Quoting Sven Neumann s...@gimp.org: just forwarding a few aspects of the GTK+ 2.20 release notes that are of interest for GIMP: GTK+ 2.20.0 is now available for download at: : : : Congratulations and a lot of thanks to the GTK+ team for this release. Though perhaps minor, the improvements made to the keyboard mnemonics (the underlined letters in menus and dialogs) seem very elegant and intuitive. From the description on http://blogs.fedoraproject.org/wp/mclasen/2010/03/24/mnemonics/ : * no mnemonics are shown when menus are opened with the mouse * interacting with the menus via the keyboard (opening a menu with keyboard shortcut, or navigating with arrow keys or similar) will make mnemonics visible * mnemonics which cannot be activated are not shown; this includes insensitive controls * moving the mouse over a non-activatable menu item does not change which mnemonics can be activated Thank you, GTK+ team. This feature: * no mnemonics are shown when menus are opened with the mouse is quite UNfortunate and to my way of thinking, inappropriate. IMHO the way people learn the mnemonics is by seeing them. It is the mouse-users that most need (should) learn them to increase their productivity and reduce visits to the doctor for mouse shoulder. Just my 2 øre worth Jay ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP distributing sRGB profiles: license issues?
On 03/10/2010 09:40 AM, Jason Simanek wrote: On 03/10/2010 02:37 AM, Sven Neumann wrote: Some file formats, such as PNG for example, allow to tag the file to be in a particular well-known color space. The color profile is not embedded then, it is assumed to be well-defined. Instead of distributing the profile with the image file, there is just a flag saying this data should be interpreted as sRGB. Ah, so the color problems I am having with images created by Gimp are due to the PNG files being 'tagged' as sRGB. The color profile isn't embedded to the image, it's just specified and, since it's a well known color profile, any program that attempts to display the image will do so as though the PNG had an embedded sRGB profile. Thanks for pointing that out. To summarize: Tagging is great because it specifies a color profile without increasing the image file size. Assuming that the destination system applies the correct profile. Embedding is great because you have greater flexibility for an endless variety of custom color profiles. The end result of the two is the same though: the image will be color managed. -- As for gballard's recommendation for not including color profiles in web images: He's only saying that because his ultimate goal is color consistency across all platforms/browsers. I, as a professional web designer, think he's right when it comes to page element images that are intended to match colors defined in HTML or CSS. Otherwise all of the Safari users that visit your site are going to doubt your design capabilities. For photographs I think it's fine to include color profiles. Browsers that don't color manage are going to show you the same limited gamut either way, but browsers that DO color manage will display an enhanced image with a wider gamut of colors. Progressive enhancement. You do have to also keep in mind that profiled/tagged sRGB and un-profiled/un-tagged RGB images will display differently in color managed browsers/environments. The assumption that Gimp currently makes (for historical reasons, explained by Sven previously) about 'assigning sRGB color profile' being the same as 'having no color profile' is misleading. -Jason Simanek Jason, You are going to hate this suggestion, but as long as certain browsers are causing you a problem, you may have to do browser sniffing and serve those users different content. In other words, different image files get called for different browsers. Of course, everything about that is wrong, but it solves your problem. Jay ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Adding ability to reverse curves dialog
On the GIMP-USER list On 03/09/2010 03:02 PM, Brendan wrote: On Tuesday 09 March 2010, Sven Neumann wrote: On Tue, 2010-03-09 at 14:49 -0500, Jay Smith wrote: The Color Curves dialog has the black in the lower left corner and the white in the upper right corner. This is the opposite of another program that I also have to use. Is there a way to reverse this default? GIMP is Free Software. You are given the source code and the right to modify it according to your needs. Oh, Sven, how users love your answers. To the OP: no, there is no option to switch it. You would have to change the source code and recompile. The above exchange occurred today on the Gimp-User list. I am posting here for discussion prior to posting an Enhancement Suggestion on Bugzilla. For a future version, I wish to propose adding the ability to reverse the direction of the black/white in the Curves dialog. A toggle button. Given that Gimp has such a great feature for storing past Curves adjustments, I am concerned that the toggle state would need to be added to that information storage. Does anybody other than me think that it would be a useful feature to add the ability to reverse the Curves black/white direction? Thanks. Jay ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Adding ability to reverse curves dialog
On 03/09/2010 04:12 PM, Alexia Death wrote: On Tue, Mar 9, 2010 at 10:51 PM, Jay Smith j...@jaysmith.com wrote: Does anybody other than me think that it would be a useful feature to add the ability to reverse the Curves black/white direction? I find it about a useless as a feature as it gets. Standard curve direction is black bottom left and white top right. If there is a problem about understanding the curve, that might be made more clear, but not by switching directions. Just my personal opinion here tho. Hi Alexia, I am not sure where the standard that you mention comes from. I had never seen black at bottom left (by default) until I started to use Gimp. Is there some actual scientific standard underlying that? Or just majority of programs? Or the programs you have used? Or? Maybe the programs I have used in the past were backward. Jay ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Adding ability to reverse curves dialog
On 03/09/2010 04:12 PM, Sven Neumann wrote: Hi, On Tue, 2010-03-09 at 15:51 -0500, Jay Smith wrote: The above exchange occurred today on the Gimp-User list. I am posting here for discussion prior to posting an Enhancement Suggestion on Bugzilla. For a future version, I wish to propose adding the ability to reverse the direction of the black/white in the Curves dialog. A toggle button. The reason that I suggested that you do this change to your local copy of GIMP is that I don't think that this change would be useful for a large part of our target user base. Adding this option to the source code will make the code harder to maintain and will increase the likelihood of bugs being introduced (by that particular change or at a later point in time). Adding a toggle button will make the user interface more complex and will degrade the user experience for most users. So unless you can persuade us that this feature is in-line with the product vision that we have for GIMP and that it is indeed important enough to outweigh the disadvantages that I explained above, we are not going to consider it. Sven The greatest benefit that comes to my mind is that it puts the user in control and allows the user to align the program to their way of thinking/working. However, *if* Alexia is correct and that the standard is to do it as Gimp currently does (black in lower left), then making such a change is not as useful to most users as it would be to me. While putting the user in control may or may not (?) be part of Gimp's product vision, I suggest that it should be. The same can be said for things like having the program remember various dialog settings the user has changed. (I posted about one of those in the Gimp-User list today.) The general arguments you raise such as code harder to maintain and interface more complex are all perfectly legitimate and could be said of virtually any program change. However, they are not a shield from change. Rather, they are a filter which must be passed as part of a cost/benefit analysis. Jay ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Adding ability to reverse curves dialog
On 03/09/2010 04:39 PM, Jon Senior wrote: On Tue, 09 Mar 2010 16:30:58 -0500 Jay Smith j...@jaysmith.com wrote: I am not sure where the standard that you mention comes from. I had never seen black at bottom left (by default) until I started to use Gimp. Is there some actual scientific standard underlying that? Or just majority of programs? Or the programs you have used? Or? Maybe the programs I have used in the past were backward. I would suggest that they were. The curves are graphs plotting value in (x) against value out(y). Traditionally a graph starting at 0 for both axes would be drawn with the origin in the bottom-left. This naturally leads to a curves graph where black (0) is in the bottom-left and white (255/1023/...) is in the top-right. What programs have you used where this situation was reversed? Jon Jon, That is certainly possible. The one that most comes to mind is Photoshop 5.x. I have no idea what modern Photoshop and successors do. Jay ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Adding ability to reverse curves dialog
On 03/09/2010 09:06 PM, David Gowers wrote: On Wed, Mar 10, 2010 at 8:19 AM, Jay Smith j...@jaysmith.com wrote: On 03/09/2010 04:39 PM, Jon Senior wrote: On Tue, 09 Mar 2010 16:30:58 -0500 Jay Smith j...@jaysmith.com wrote: I am not sure where the standard that you mention comes from. I had never seen black at bottom left (by default) until I started to use Gimp. Is there some actual scientific standard underlying that? Or just majority of programs? Or the programs you have used? Or? Maybe the programs I have used in the past were backward. I would suggest that they were. The curves are graphs plotting value in (x) against value out(y). Traditionally a graph starting at 0 for both axes would be drawn with the origin in the bottom-left. This naturally leads to a curves graph where black (0) is in the bottom-left and white (255/1023/...) is in the top-right. What programs have you used where this situation was reversed? Jon Jon, That is certainly possible. The one that most comes to mind is Photoshop 5.x. I have no idea what modern Photoshop and successors do. http://www.adobe.com/designcenter/photoshop/articles/phscs2at_learncurves_02.html White on the right, Same as GIMP, PSP, etc. Thanks David, Yep, that's what that picture shows. BUT... that little double-arrow thingy at the bottom of the curves graph reverses black/white positions. It is entirely possible that umpteen years ago when we first installed Photoshop on Windows 95 that that double arrow got clicked and we have used it reversed ever since. Or maybe back then white was at the upper right. Okay, if the world says black is lower left, we will use it that way. Thanks. Case closed. Jay ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Option to save images without embedded ICC profile
On 03/03/2010 09:22 AM, Jason Simanek wrote: Hello, snip For web designers it is essential to have the option to either include or exclude color profiles on images that are created with Gimp. It would be great to have a checkbox on the save/export dialog or the Save for Web plugin dialog that would allow you to exclude the color profile. snip Please excuse this ignorant question, but Could someone please explain or supply a link/reference that gives more background to the statement For web designers it is essential to have the option to either include or exclude color profiles on images I am sure I am missing something important. Why would you specifically want a color profile to NOT be present ... specifically for web-use images? Thank you. Jay ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Option to save images without embedded ICC profile
On 03/03/2010 10:08 AM, Jay Smith wrote: On 03/03/2010 09:22 AM, Jason Simanek wrote: Hello, snip For web designers it is essential to have the option to either include or exclude color profiles on images that are created with Gimp. It would be great to have a checkbox on the save/export dialog or the Save for Web plugin dialog that would allow you to exclude the color profile. snip Please excuse this ignorant question, but Could someone please explain or supply a link/reference that gives more background to the statement For web designers it is essential to have the option to either include or exclude color profiles on images I am sure I am missing something important. Why would you specifically want a color profile to NOT be present ... specifically for web-use images? Thank you. Jay I have answered my own question, but it took about half hour of searching to find this. Here is a great reference site exactly on this subject http://www.gballard.net/psd/go_live_page_profile/embeddedJPEGprofiles.html For people like me, I recommend reading it thoroughly AND following all his links. It does go on a bit, but there are many pearls in it. Too bad he does not seem to talk about Gimp, but the content is still great. Jay ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] cant save image with new comment
On 08/03/2009 03:28 PM, Alexia Death wrote: On Monday 03 August 2009 22:20:29 Sven Neumann wrote: On Sat, 2009-07-25 at 17:41 +, Omari Stephens wrote: More specifically, once I hit Ctrl+E and see the status message not saying anything about exporting, I expect the file to have been saved. If GIMP thinks there were no changes, it should say no changes to save in a way that is visible, easy to notice, and easy to read. It does exactly that. It will display the text No changes need to be saved in the status-bar and this text stays there for five seconds unless it is replaced by a more important status-bar message before this timeout expires. If that doesn't happen for you, then this code broke and there should be a bug report filed. Why only 5 seconds? why not until something else happens? IMHO 5 seconds is not enough. --Alexia Alexia, One of my annoyances with a couple of other programs that I use a lot is that such types of messages stay around too long in those programs. What if you look at the screen 30 seconds or 5 minutes or 2 hours later that message is still there? It is now completely out of context! While maybe 5 seconds might be a little quick, conceptually I agree that it should not last very long. Maybe 8 or 10 seconds or even 15 seconds. But not longer. Jay ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] cant save image with new comment
On 08/03/2009 05:04 PM, gg wrote: snip lots It is NOT an effective way of displaying important error messages that NEED to be seen. As I said in my original post , this is not a by the way the image was not saved it is an error condition what warrants an modal dialogue and a user response. If the error is irrelevant then the current mechanism is probably OK. I maintain that it is non trivial and requires full visibility. /gg I second this motion (or emotion). I would rather have to dismiss a dialog box than to think I have saved something that has not been saved. Jay ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] cant save image with new comment
On 08/03/2009 05:12 PM, Martin Nordholts wrote: On 08/03/2009 11:04 PM, gg wrote: As I said in my original post , this is not a by the way the image was not saved it is an error condition what warrants an modal dialogue and a user response. Please let's not bombard the UI with modal dialogs. They are excellent for interrupting workflows and annoying users. The proper solution is to make changing the comment dirty the image, it is not to show a modal dialog when the image is not saved. / Martin Martin, I appreciate your thinking on this and what you suggest in this particular situation is a great way to deal with that specific case. However, I would like to point out that if a user _intends_ to save the file because the _user_ believes a change has been made, then should not the user be notified that either a) the user is incorrect and no change has actually been made [and thus the user probably needs to do something that the user has failed to realize has not been done], thus the file is not going to be saved OR b) the program is incorrect in thinking that no change has been made (as was the case in this situation). _I_ would want my workflow interrupted if the program was not going to do what I had asked it to do. Maybe that's just me. As long as the focus in the modal dialog is on the dismiss button, then it is easy enough to hit [Enter] and it goes away. That would be my preference. Jay ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] open/save/export
On 06/10/2009 04:33 PM, Simon Budig wrote: gg (g...@catking.net) wrote: Subsequent Save as png should automatically set the default file name to /path/foo.png . *Please* try to be exact in this discussion. You *cannot* Save as PNG, you can only Export as PNG. The *only* format you can Save to is XCF and its compressed variants. Thanks, Simon I have tried to stay out of this, but I can't resist any longer. It is likely my own ignorance and/or not having seen a previous related discussion, but. Why is there such a strong distinction between Save As and Export? To the _user_ what benefit is this distinction? My 2.6.6 (on Ubuntu Linux) does _not_ have an Export on the menu that I can find. If I open a JPG, add a layer to it, and then use the Save As menu item to get the Save As dialog and if I change the extent to .PNG, I then get a dialog regarding Export. All well and good. But to the _user_ that is just another necessary step in the process of Saving As a file to a format that cannot handle whatever features (layer, in this case) are currently in the working (unsaved) file. Exporting it is not something that (at least that I can find in my Gimp) the user can do from the menu. However, I have used a number of other programs where Export is a menu item -- and I have not really understood why that Export was offered separately. In those programs, one could Save As to a few dozen formats, but had to use Export to accomplish a similar goal to a few other formats. To the _user_, additional exporting steps are required, in this case, in the process of doing Save As. But to speak of Export as a distinct task I do not quite understand. Nor do I understand why it seems to be an issue as a distinct task. What am I missing? (I am not referring to why this discussion has been ongoing, i.e. how it works; I am just wondering about the semantics and trying to better understand what the posters are wishing to accomplish with their choice of words.) Or is this discussion / plan headed toward adding Export as a distinct menu item. But, if so, why? How does that help the user? My understanding of all uses of Save As is: A new file is created that includes any changes made to the old file (within the scope of the capability of the new filetype), and unless that new file specifically overwrites the old file, the old file is closed without saving possible changes that might have been made to the old file. BTW, that Export dialog has a Help button. I think there is a bug or not-yet-implemented feature, because that Help button gets an Eeek! page on my system: /usr/share/gimp/2.0/help/en/help-missing.html whereas the Help button on the actual Save As dialog _does_ get a proper page of help info. Should this be reported on Bugzilla or is it just one of those things still in process? Jay ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [wish] alignment rotation
On 05/14/2009 11:51 AM, Alexandre Prokoudine wrote: On Thu, May 14, 2009 at 7:43 PM, Liam R E Quin wrote: Go to tool options, choose corrective mode and preview grid. Now, align the grid with the item in your picture that you want to be horizontal or vertical, and click rotate. In fact every time you will also need to create a different number of grid lines so that one of them would be as close as possible to a potentially horizontal/vertical feature. Straightening with a line the way Maciej described it would make it much easier. Alexandre Alexandre, We use this Gimp feature on virtually every image we create, sometimes _hundreds_ per day. Once we originally set the number of lines in the grid, we have felt no need to make a change for months ... thousands of images. However, I do have to say that the Photoshop 5.5 feature of simply drawing a line with the measure tool and then doing the rotate command is more efficient. And I do like the suggestion of clicking on the first point and then the second point, rather than having to draw a line as in Photoshop. I would like to see this feature _added_ to Gimp, while still retaining the grid mechanism also. My desire would be for: click (on first point) click (on second point to finish the line) do a keystroke command that can be accomplished with ONE hand to execute the task (I would prefer not to have to hit the Enter key) That would be most efficient. Jay ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [wish] alignment rotation
On 05/14/2009 12:36 PM, Martin Nordholts wrote: Jay Smith wrote: However, I do have to say that the Photoshop 5.5 feature of simply drawing a line with the measure tool and then doing the rotate command is more efficient. Using the measure tool for this seems like a UI hack to me. IMO we need a better solution for GIMP, something that is more discoverable. / Martin Martin, That is a very good point. I have to admit that I was using Photoshop for a couple of _years_ and had done perhaps 20,000 rotations before I learned about that method (and I found out from a friend, not from the program's help or manual, though it was probably documented). In any case, the same concept (preferably with BOTH method possible: draw a line or click start, click end) in a more discoverable way would sure be great. Jay ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] File Creation Permission Problem ONLY for TIF files: Creating as 644 (rw-r--r--) when should be 664 (rw-rw-r--)
Sorry to bump this, but after 8 days on this list and on gimp-user, there has been absolutely no comment. Can anybody confirm or deny that this is also happening on their linux systems? Or is it _just_ me? Should I file a bug report on this? I don't want to clutter up bugzilla if I am missing something silly. Thanks. Jay On 04/02/2009 11:58 AM, Jay Smith wrote: [I hope it is appropriate to post this here. I posted on gimp-user and got no feedback on this. I did not want to post as a bug on bugzilla yet in case I am missing something simple.] Using Gimp 2.6.6 on Ubuntu 8.04 (Hardy) Linux. TIFF ONLY This problem seems *only* to be happening when creating/saving TIFF (.tif) files. If the filetype is something else, then the problem is not happening. On two different workstations, being run by two different login users, creating files in various different directories, Gimp is creating the files with permissions that are incorrectly too restrictive: Gimp is making as 644: -rw-r--r-- 1 jay jsa 1919194 2009-03-31 12:10 tmp.tif When it should be making as 664: -rw-rw-r-- 1 jay jsa 1919194 2009-03-31 12:10 tmp.tif ONLY Gimp is doing this. Creating files in the exact same manner and saving them to test.png or test.jpg results in _correct_ permissions. It only is a problem with .tif files (so far in my testing). a) The directories that the files are being created in have perms of 6775: drwsrwsr-x 3 jay jsa 4096 2007-05-28 15:57 testdir Files created in a directory with those perms are _supposed_ to be created as 664 which is rw-rw-r--. b) When any other program, such as vi or touch, makes a file in the very same directory, it is making the perms correctly. c) I have double checked the user's umask which is correctly 0002 which would result in file creation as 664. d) We have never had this problem with any other program (when the directory perms are correct, which they are in this case). e) An associate on a completely different, but virtually identically configured Ubuntu linux system (all same versions). has been able to replicate the exact same problem. ??? 1) Is this a (known?) bug? 2) Is this configurable somewhere in Gimp? I can't find it if it is. 3) Is this configurable somehow in the .gimp* rc files and/or from the command line? Jay ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] File Creation Permission Problem ONLY for TIF files: Creating as 644 (rw-r--r--) when should be 664 (rw-rw-r--)
Martin, Sorry, if I was not clear. You said Don't top-post please. My question Please advise me what I am to do in such situations? What is the correct method? I wish to follow the rules. was asking what am I supposed to do if I am not supposed to bump (is that the same as top-post?) but there has been no reply or interest in the subject, yet the subject (as you thankfully proved) is worthy of attention? Sorry for being unfamiliar with the rule on this. I have posted the bug. Thanks for taking the time to confirm that there was an actual problem. Jay On 04/10/2009 12:22 PM, Martin Nordholts wrote: The correct method for what? Filing bug reports? Take a look at http://www.gimp.org/bugs/ And I would prefer to keep the discussion on-list - Martin Jay Smith wrote: Thank you for your reply and information. Again, I apologize for bumping the topic. Please advise me what I am to do in such situations? What is the correct method? I wish to follow the rules. Jay On 04/10/2009 11:36 AM, Martin Nordholts wrote: Jay Smith wrote: Sorry to bump this, but after 8 days on this list and on gimp-user, there has been absolutely no comment. Hi! Don't top-post please. This happens to me as well and from looking at the code it also happens for gbr, gih, pat, pnm and raw which opens a file for writing like this: fd = g_open (filename, O_CREAT | O_TRUNC | O_WRONLY | _O_BINARY, 0644); E.g png instead uses fp = g_fopen (filename, wb); This inconsistency doesn't make any sense, feel free to open a bug report. The latter is identical to the former apart from the permissions, so we probably want to use the latter for all plug-ins. - Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] RFE: Changing/Remembering/Setting Dialog Defaults for Image... Canvas Size...
[I hope it is appropriate to post here though I am not qualified to be a developer. I posted this on gimp-user and got no feedback. I noted on bugzilla that somebody with an RFE was scolded for not bringing up the subject here first.] I am Using Gimp 2.6.6 on Ubuntu 8.04 (Hardy) Linux. I have not been able to find any way to: Set Preferences defaults (either through GUI or rc files)... Get Gimp to remember settings within a user session... Get Gimp to remember from one Gimp session to another... for the following... In the dialog box: Image... Canvas Size... - Layers... The dialog _always_ seems to default to None instead of All Layers. I want to set a default of All Layers. - Canvas Size... The 'link' symbol at the top, between the two pixel sizes, reverts every time to linked status. It seems that it has to be unlinked every time if you wish to change only one of the dimensions of the canvas (or change them differently). I want to be able to have this default to unlinked so that I can change them independently without having to click the link/unlink. - Canvas Size... The method of measurement always defaults to pixels. For my work, it would be easier for me to see/manipulate inches or cm. I have to do highly repetitive work involving thousands of images, thus a small thing like link/unlink means clicking thousands of times. I thought that certainly there must be a way to change such defaults for a particular Gimp installation or at the very least, for a particular user session of running Gimp. Am I missing something? Is there an rc file that I can create (or add to) that will give this type of control. Does this require a plug-in? Is there one that will do it? Is there a plug-in that will allow the user control over _all_ the defaults? (The model that comes to mind is the firefox/thunderbird about:config setting methods.) Jay ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] File Creation Permission Problem ONLY for TIF files: Creating as 644 (rw-r--r--) when should be 664 (rw-rw-r--)
[I hope it is appropriate to post this here. I posted on gimp-user and got no feedback on this. I did not want to post as a bug on bugzilla yet in case I am missing something simple.] Using Gimp 2.6.6 on Ubuntu 8.04 (Hardy) Linux. TIFF ONLY This problem seems *only* to be happening when creating/saving TIFF (.tif) files. If the filetype is something else, then the problem is not happening. On two different workstations, being run by two different login users, creating files in various different directories, Gimp is creating the files with permissions that are incorrectly too restrictive: Gimp is making as 644: -rw-r--r-- 1 jay jsa 1919194 2009-03-31 12:10 tmp.tif When it should be making as 664: -rw-rw-r-- 1 jay jsa 1919194 2009-03-31 12:10 tmp.tif ONLY Gimp is doing this. Creating files in the exact same manner and saving them to test.png or test.jpg results in _correct_ permissions. It only is a problem with .tif files (so far in my testing). a) The directories that the files are being created in have perms of 6775: drwsrwsr-x 3 jay jsa 4096 2007-05-28 15:57 testdir Files created in a directory with those perms are _supposed_ to be created as 664 which is rw-rw-r--. b) When any other program, such as vi or touch, makes a file in the very same directory, it is making the perms correctly. c) I have double checked the user's umask which is correctly 0002 which would result in file creation as 664. d) We have never had this problem with any other program (when the directory perms are correct, which they are in this case). e) An associate on a completely different, but virtually identically configured Ubuntu linux system (all same versions). has been able to replicate the exact same problem. ??? 1) Is this a (known?) bug? 2) Is this configurable somewhere in Gimp? I can't find it if it is. 3) Is this configurable somehow in the .gimp* rc files and/or from the command line? Jay ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
