Re: [Gimp-developer] Re branding ....
Christopher Howard-3 wrote: If the devels ever did come over to the other side on this issue, the coolest way to go about picking a new name would be a contest. For example, have a web page where people suggest a name or vote on a list of names. Then the devs could pick from the top 5. Imagine the publicity and recognition the project would get the moment word got out about the contest! It would be on every blog and news site in the FOSS universe! And then a second contest to create a new splash screen with the new name . h... -- View this message in context: http://old.nabble.com/The-name-%22Gimp%22-tp26102353p26207036.html Sent from the Gimp Developer mailing list archive at Nabble.com. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re branding ....
David Gowers wrote: 'jeeples'? lol. I'm sure the FSF people would like it :) How do we verb it though? jeepling? BWAHAHAHAHAHA. (more seriously, G+ is extremely close to the name of the gnu C++ compiler, G++). OK, as I have said I am not a programmer, so I was not aware of G++. I agree that G+ would be much too close. That said, I was just proposing a possible scenario. David Gowers wrote: At the 'G+' point, the major internal renaming would need to take place, and that would require far more developers and far more organization than the GIMP project currently has. Speaking again as a non-programmer, why would anything have to change internally? -- View this message in context: http://old.nabble.com/The-name-%22Gimp%22-tp26102353p26143173.html Sent from the Gimp Developer mailing list archive at Nabble.com. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Re branding ....
Christopher Howard-3 wrote: Its about having a product you aren't afraid to advertise. . As soon as I say GIMP, you can see the doubt on their faces, because they associate the word with being weak or lame. I agree with this. Many people shy away from using products that aren't mainstream, and have little to do with (or knowledge of) open source software alternatives. There is nothing about the current name that inspires confidence or denotes competence. I think that the time to change the name would be when a release comes out that has an option to run in a single window. This is a major change that people have requested for some time and this new configuration is sure to be discussed widely on the internet. That version could be called something like Gimp+. Over time this might become shortened in blogs, forums, etc. to G+, and then a later major release could use that as the name. The whole time, Wilber the mascot would remain basically the same to provide continuity. I'm no ad wizard so I don't claim this is the best naming strategy, but I think it provides an example of how the rebranding process could go. -- View this message in context: http://old.nabble.com/The-name-%22Gimp%22-tp26102353p26139628.html Sent from the Gimp Developer mailing list archive at Nabble.com. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Definition #5 is bad, but what about #1-4???
Lame, crippled, inept, deficient, or sexual deviant . I get that it's an acronym, but that doesn't mean it isn't incredibly strange to want to associate a project that the developers are proud of with any of these interpretations! . Mark John B-12 wrote: I use Gimp frequently, and I find this pretty concerning. http://en.wiktionary.org/wiki/gimp#Noun_2 There is no way I'm wearing a Gimp T-Shirt after reading item #5. Worse, I seem to recall the Gimp mascot being referred to as a gimp in multiple occasions on the website. IMO this would be a valid reason for a name change. Has that ever been considered? John -- View this message in context: http://www.nabble.com/The-name-%22Gimp%22-tp26099828p26103984.html Sent from the Gimp Developer mailing list archive at Nabble.com. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The name Gimp
Patrick Horgan wrote: The same site you cited has the following: Adjective gimp ( comparative more gimp, superlative most gimp) Positive gimp Comparative more gimp Superlative most gimp ( dated , Scotland and N England) Neat ; trim ; delicate ; slender ; handsome ; spruce ; elegant . Patrick So just because some old farts in Scotland may have good associations with the word, you think that renders the rest of the English-speaking world's interpretation silly? %-| -- View this message in context: http://www.nabble.com/The-name-%22Gimp%22-tp26099828p26104291.html Sent from the Gimp Developer mailing list archive at Nabble.com. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Enhancement Proposal: Scrolling of font field in text tool.
I find it very tedious to experiment with various fonts using the current text tool implementation. Rather than clicking on the font button and choosing from the pick list based on the sample Aa shown, I would like to be able to type the text I want on the image, then hover the pointer over the font name field and roll the mouse wheel to cycle through the font options, with the typed text font changing accordingly in the image. In effect, it would perform the same as the blend field does in the layers dialogue, i.e. rolling the mouse wheel on the field scrolls through the options and automatically applies each one in turn. If there is a better way to use the current tool, I'm open to advice. But please consider this request for a future release. -- View this message in context: http://www.nabble.com/Enhancement-Proposal%3A--Scrolling-of-font-field-in-text-tool.-tp24017304p24017304.html Sent from the Gimp Developer mailing list archive at Nabble.com. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Patch] Less cluttered UI, on-demand showing of docking bars
Alexia Death-2 wrote: Now THAT I like. As a NOOB I had serous problems realizing that the thin bars indicate a drop site and their thinness made them hard to hit later. Now both of these are solved making that much easier for a noob to understand and use. --Alexia I had the same problems. In fact, while it might be a bit tacky, making the docking bars (or the text inside them) blink while dragging would add even more emphasis. Without a tool tip, a noob might accidentally initiate a dockable drag, then realize that is not what he/she wants and just let go of the dialog, without ever noticing that the docking bars had appeared. Flashing would help draw their attention to this feature. -- View this message in context: http://www.nabble.com/-Patch--Less-cluttered-UI%2C-on-demand-showing-of-docking-bars-tp21275229p21278456.html Sent from the Gimp Developer mailing list archive at Nabble.com. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Better grouping of layer modes
peter sikking wrote: the only thing I would change is to swap the order of Grain merge and Grain extract. simply because it is explained as a workflow in that order in the manual. I would also like to see a dynamically updated list at the top of the list that shows the last 3-5 used blend modes under a heading of Recent:. This may be outside the scope of the OP's original suggestion, but for many users there are a select few modes that are used frequently, and having to dig through a long list slows things down. -- View this message in context: http://www.nabble.com/Better-grouping-of-layer-modes-tp20279130p20324960.html Sent from the Gimp Developer mailing list archive at Nabble.com. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Allow picking center for rotation?
The LayerTransformArbitrary Rotation function allows you to enter coordinates for a center of rotation, but it would be very handy to be able to pick a point with the mouse. I would like to submit a feature request in Bugzilla to this effect. Any comments/objections? -- View this message in context: http://www.nabble.com/Allow-picking-center-for-rotation--tp19316725p19316725.html Sent from the Gimp Developer mailing list archive at Nabble.com. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Script proposed for inclusion in gimp 2.6
I like this idea. I would use it frequently. In fact, I would suggest calling it Duplicate Visible in the menu, and also adding it to the buttons at the bottom of the layers dialog with a description of Duplicate visible layers as single new layer on mouse-over. As far as real estate on the bottom of the layers dialog goes, I would eliminate the raise/lower layer buttons I don't ever use them since it is easier to drag the layer itself to the new location than to select the layer with one mouse click and then find and click on the raise/lower button. -- View this message in context: http://www.nabble.com/Script-proposed-for-inclusion-in-gimp-2.6-tp18831803p18856989.html Sent from the Gimp Developer mailing list archive at Nabble.com. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] simple suggestion for the UI
Bernhard Stockmann wrote: ...I wanted to suggest that if someone double clicks the main window (the one that is displayed if no other image is opened) the new image dialog should open. How would you propose for this functionality be discovered by the user? -- View this message in context: http://www.nabble.com/simple-suggestion-for-the-UI-tp18419728p18420240.html Sent from the Gimp Developer mailing list archive at Nabble.com. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement idea: Snapshot tool for quick comparisons
Joao S. O. Bueno Calligaris wrote: Hi there - I am improving the layer group plug-in that hacks some layer group functionality in GIMP. You can have a version of it at [1] right now - but I am working on a version featuring a dialog where one can trun the groups visible or invisible with a single click. That will still work on teh same image, but you can do image-duplicate if you need to see diferent versions at once. The problem with turning layers or layer groups on/off is the time required to redraw the image. Today's cameras have more and more pixels, hence larger files. A 100% quality jpeg of these files can be displayed in no time, but it takes many seconds to redraw them in GIMP when (multiple) layers have to be processed. What I'm after is a fast-rendering, easy to use method of flipping through snapshots of my workflow. Shift-clicking on the eye-ball by each layer comes close, but it is slowed by the processing required during rendering. My proposal is a way to get around that and speed things up for the user. The ideal experience for the user would be to be able to add a snapshot to the snapshot list/window at any point after he has made some intermediate edits on his image. He could then continue his workflow, making more edits and occasionally adding more snapshots to the snapshot list. If he wants to see the subtle effects of a step such as sharpening or dodging/burning, he could click back and forth between before and after snapshots. Having them displayed directly on top of each other in the same zoomable,pan-able window will allow him to more easily see these subtle effects than displaying the two snapshots in separate image windows or even side-by-side in the same window. This is the approach taken in two RAW converter packages I've used (RawTherapee and Sony IDC), and it helps greatly because the processing of adjustments to a RAW file can take a great deal of time. I think it has direct application to GIMP because the refresh rate on large files is slowed by layer calculations. -- View this message in context: http://www.nabble.com/Enhancement-idea%3A--Snapshot-tool-for-quick-comparisons-tp18142100p18153277.html Sent from the Gimp Developer mailing list archive at Nabble.com. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement idea: Snapshot tool for quick comparisons
saulgoode-2 wrote: I have written a Script-fu (http://flashingtwelve.brickfilms.com/GIMP/Scripts/snapshot-projection.scm) which might be helpful. The script adds a Snapshot Projection command to the Image menu and when executed, will add a layer to the image's snapshot view (which is actually itself an image). If the snapshot image does not exist, it is created. The layername generated for the added snapshot layer consists of: the total number of layers in the image at the time of the snapshot followed by a colon followed by a period separated list of the positions of the visible layers (top-to-bottom, top being 0). For example, an image with four layers with the layer underneath the top layer in the stack hidden would produce a snapshot layer named 4:0.2.3 Of course you are free to rename the snapshot layer to something more informative should you wish. The script does not expand the snapshot image's canvas size; should this be desired then perform a Image-Fit Canvas To Layers (or modify the script to perform a 'gimp-image-resize-to-layers') on the snapshot image. Each open image can have its own snapshot view. You can save the snapshot image to a file, and even reload it later as long as you don't rename it. If you close your original image and reload it, it will NOT use the same snapshot image (a new one will be created). The same is true if you duplicate your original image: a new snapshot view will be created for the duplicate image. The script has not been rigorously tested but I did attempt to have it return things to their original state. Saul, I tried your script and it actually works very well! I tried it on some 5MP image files and the redraw rate was acceptable. With larger files 10MP+, I'm concerned that the redraw rate might be too slow using GIMP's current process, but this is an assumption on my part based on the processing I assume GIMP must do with layers. What would it take to put any finishing touches on this script and incorporate officially in a future release? Also, would it be possible to add an icon of a camera to the toolbox so that the user doesn't have to access it through the menu structure (similar to Adobe Acrobat)? . Mark -- View this message in context: http://www.nabble.com/Enhancement-idea%3A--Snapshot-tool-for-quick-comparisons-tp18142100p18160037.html Sent from the Gimp Developer mailing list archive at Nabble.com. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Enhancement idea: Snapshot tool for quick comparisons
I tried posting this to the list first, but apparently the list was down, so I went ahead and submitted a bug (#540091). The text below is from that bug report, and I would love to have this idea discussed on the list for possible development. When editing photos I find that it is tedious waiting for the rendering to be completed as I turn layers on and off for comparing the effects of the changes I'm making. I would like to see a new tool/UI that would allow a snapshot to be taken of any currently displayed view and saved for comparison with other snapshots later. It would be good to allow these snapshots to be named. I visualize a list of snapshots, and clicking on each one displays it in a snapshot review window. This window would have zooming and panning capabilities. By eliminating the processing that I assume is required each time a layer is turned on/off, I would think that the snapshots could be displayed very quickly and make subtle differences between snapshots more apparent. Perhaps something like this might be done using the Copy Visible function and creating a display window with a list of snapshots displayed on the side? Comment #1 from Martin Nordholts (GIMP developer, points: 14) 2008-06-25 04:29 UTC [reply] Hi Why not just use Image - Duplicate as the snapshot mechanism? If that doesn't work, please bring this up on the gimp-developer mailing list. Before opening an enhancement request the feature and solution should have been discussed there. Thanks Comment #2 from vabijou yahoo com (reporter, points: 6) 2008-06-25 13:12 UTC [reply] The gimp-developer mailing list has had no activity since June 16, so it does not appear to be working. I've tried posting there, and my e-mails have been returned. I've e-mailed the gimp-developer administrator and had that e-mail returned. I posted it on nabble on June 20 and there it sits. I think I've done my best to work within the system, and the system failed me. Hence, I'm posting it here. Image - Duplicate is an unacceptable alternative. The idea is to create a single window that allows the user to cycle through multiple (named) snapshots in any order he chooses to see large or small changes more readily. Image - Duplicate has so many negatives to this process that I don't know where to start. Two major problems with Image - Duplicate immediately come to mind: 1) It would be a huge waste of memory, since it completely copies the image info (except for the History). 2) It scatters windows all over the place, making comparisons difficult. What I'm after is a fast-rendering, easy to use method of flipping through snapshots of my workflow. Shift-clicking on the eye-ball by each layer comes close, but it is slowed by the processing required during rendering. My proposal is a way to get around that and speed things up for the user. -- View this message in context: http://www.nabble.com/Enhancement-idea%3A--Snapshot-tool-for-quick-comparisons-tp18142100p18142100.html Sent from the Gimp Developer mailing list archive at Nabble.com. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
