Re: [Gimp-developer] A modest proposal...
On 09/05/11 10:45, Mikael Magnusson wrote: On 5 September 2011 09:18, Noel Stoutenburgmjol...@ticnet.com wrote: Friends, ...or maybe not, since I don't know the code involved. But may I suggest rearranging the left most pane in the dialog windows for the file operations open and save as? Presently, when I use either operation, and want to access a location to which I have a bookmark, I'm obliged to scroll down the screen in the left most pane; what I'd propose is to move the bookmarks (if any exist) to the top of the pane, just below the recently used entry. Or, have I missed a setting somewhere that would let me configure the order in which the items in this pane are listed? ns ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer Yes, it's stupid, but it's not gimp's fault. You can rebuild your gtk+ with this patch http://mika.l3ib.org/patches/gtk-filechooser-only-File-System.diff or modify it to your liking, the code is fairly obvious. Thanks for that patch. I fixed this annoying mess of irrelevant bookmarks that I never requested spamming the interface in 2.6.something but it no long applies cleanly. You saved me the effort of fixing it again. :) Anyone who finds this annoying please bug report to gtk+ (rather than here) . I did open a bug and submitted the patch but it spat out as per usual . If they realise this is unpopular maybe it will get some traction. regards. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP 2.8 icon
On 08/23/11 14:22, Tobias Ehni wrote: Thanks for suggesting some names from the artist scene. That's very helpful for me and the entire project. 2011/8/23 Ramón Mirandamirandagrap...@gmail.com: Thanks a lot for the offer cc5 inator. These icons are very well made. i like them. And i like the idea of a serie of interviews with different artists. I think this could be very interesting for averybody, coders, designers etc. i would suggest some names because i can´t suggest mine (it is not polite, but i am available too if it is required :) ) Guillermo Espertino. http://www.ohweb.com.ar/ some videos here. http://www.youtube.com/user/gespertino More known as gez.he is an Expert in color management and integrates blender inkscape and gimp in his workflow. JesusDA. http://www.jesusda.com/ he only uses freesoftware. he is web designer and FLOSS consultant.he has made a lot of gimp tutorials and it is a reference here in Spain. David Revoy http://www.davidrevoy.com/blog.php freelance Artist from France. Worked in Sintel open source movie and it is involved in lot of projects. Mozart Couto http://blogdodesenhador.blogspot.com/ Fine arts and digital Artist. lot of experience with tablets, programs and techniques. the Word Dicas means tutorial. Voxmortem http://voxmortem.deviantart.com/ he is from poland and has some really interesting pieces of art. LJFhutch http://www.ljfhutch.com/ Specialized in game content creation. 2011/8/23 Tobias Ehnitobias.e...@googlemail.com Hi, thanks a lot for your offer and for providing samples of your work, too. I'm impressed that you did logos for blender and Battle for Wesnoth. I'm sorry that I can't tell you anything about creating the next logo, however there is also another way to contribute to the GIMP community. I'm planning to conduct interviews with graphic / interface / web designers and photographers. The idea is to better understand how users actually work in the field, i.e. what they do and how they do it. The insights from the interviews will be used to improve ease of use / usability of GIMP. Interviews are planned to take place in October, with an interview taking about one hour, via VoIP. I'd be very happy if you decided to help both GIMP team and users by being interviewed about your work. Feel free to contact me if you have any further questions. Kind regards, Tobi 2011/8/22 c55 inatorc55ina...@gmail.com: Hello. I'm a graphic designer with experience in creating Application icons [Like this, this, or this] and I was wondering if I could be of service in helping create GIMP's next application icon. I use GIMP on a daily basis in my work and I'd love to contribute something back to the community. Any information regarding ways I could help would be greatly appreciated :) My work, if you're curious: http://dribbble.com/ollin ___ Oh if there is a competent artist offering to provide a decent looking logo/icon for Gimp , please don't refuse the offer. The current wilber annoys me every time I see it. I installed Gimp for my mother (a working artist) and she demanded that I change the icon on her desktop. Sorry if this was the handy work of someone's girlfriend, mother or beloved eight-year-old daughter but it is high time the project had a more credible image. If someone's offering, please ask for some sample designs. /gg/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Fwd: Re: Unified transform tool (mouse gestures)
oops, only sent reply to Michael. Forwarding to list. Original Message Subject: Re: [Gimp-developer] Unified transform tool (mouse gestures) Date: Sun, 17 Apr 2011 10:33:10 +0200 From: g...@catking.net To: Michael Grosberg grosberg.mich...@gmail.com On 04/17/11 08:31, Michael Grosberg wrote: Ofnutsofnutsat laposte.net writes: Symmetry mode is not well defined... In your drawing, you drag on top-right and the top-left follows (vertical axis), but it could as well have been the bottom-right (horizontal axis), and even the bottom-left (radial). As I did mention, it was not a complete spec. The points you raise are valid, but they are already treated well in the original spec, and I only wanted to present the differences. In distort mode, Symmetry is applied to the larger distort delta of the two axes, i.e. if you distort a corner point 20 px to the right and 10px to the top, the symmetry will be horizontal. IMHO, your proposal, like the original one, doesn't address a very frequent use of these transforms, which is to match the transformed object with an existing one. Actually, the original spec DOES mention that scale from center is toggled by the CTRL key. Moving the center point lets you scale from any given point. Hi, having read the spec by Mitch I like the idea which could remove a hole bunch of icons from the toolbox and make life a bit easier all round. I started getting a bit uncomfortable with all the special keystrokes, this is one area where I find 2.6 confusing, non-inutitive and hard to remember. These are not easy to discover and have no logical connection to their function, you just have to commit it all to memory. Maybe the idea of mouse gestures could be useful here (as used in Opera browser and now available as extensions for firefox). This may be a good short cut for rotation and flip transformations (that does relate to function so easy to remember) . The rotations are a pain at the moment because they require navigating to a submenu, three mouse operations for a trivial action. One could imagine , once the transform tool is in operation mouse gestures could trigger H,V flip , the fixed rotations and mirror: drag down : v flip drag left/right : h flip drag up then left : anti-clockwise 90 drag up then right: clockwise 90 drag up then L/R then down : rotate 180 drag left , right, left : h mirror etc. In the context of Mitch's pre-spec document, these could operate in the outside the box area defined for the free-hand rotation. These could have keyboard equivalents (up arrow , left arrow) for disabled access or special hardware requirements. Some modifier key could be held at same time to differentiate between image transformation and layers If the floater is used , it probably should be interactive rather than display only and be draggable in case its placement is inconvenient. One word of caution , although I like the way the move tool fits into the plan, I think there is a possibility of confusion of this being billed as a transformation. Although mathematically linear translation can be done as a matrix transformation, it probably is not a transformation to a graphics user. A user would skip past it thinking I don't want to transform the image I want to move it ! Some care will be needed in how this is presented to avoid this point making access to the move tool less obvious, not more so. I think the whole idea has a lot of potential for cleaning up the interface and making things more accessible with less of a time spent learning. I like it. regards. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Write basic gegl plugin
On 04/05/11 11:37, Jon Nordby wrote: On 5 April 2011 11:08, Madhav yadavmad.cool.sp...@gmail.com wrote: Don;t we need to authenticate to add new files to the branch?? No, with git you primarily work against your local repository. You can do whatever you like there. Please read a tutorial or two on git, so that you come to terms with the basic concepts. Why wouldn't you want to work *with* your local repo rather than against it ? Because I'm a cool l33t hack3rz type dude , I drink my coffee against a cup. I eat my dinner against a knife and fork. ;) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Announcing AdaptableGIMP
On 03/12/11 00:03, Bogdan Szczurek wrote: It seems most promising! Best regards! thebodzio ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer What seems promising ?! Best not to cut off whatever it was that you are replying to . I don't want to have to go and search and online ML archive just to find out what you comment relates to. ;) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Developer Boot Camp?
On 01/28/11 11:22, Patrick Horgan wrote: * Shouldn't we standardize on a common development IDE (like Eclipse)? If I am missing something in that area . . . let me know. I think the only thing you're missing is that there is no need for we to standardise. If you want to use an IDE that does not really affect how others work. I did manage to import gimp as a project into kdevelop at one stage, though later I could repeat the excersize and since I was then less active in coding gimp I did not spend time trying to fix it. /gg/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP icon stolen by commercial Symbian software on sale at Nokia app store
On 01/19/11 23:15, Ilgaz Öcal wrote: Hello, After spending some time on IRC, I decided this is the best way to report it. I noticed Nokia Ovi Store (an app store) carries a software named SnapMe which is clearly not GPL using GIMP application icon. You should be able to see when you click on following link: http://store.ovi.com/search?q=SnapMe I did my best to report (c) violation to Nokia but from what I hear, their staff is way overloaded. Actual way to report it is at article 7 of following document which requires you to be the actual copyright owner of the image. http://store.ovi.com/legal/terms 7. Allegations of Copyright Infringement You may notify Nokia of copyright infringement on the Service by providing notice (a) by email with “Copyright Notification” in the subject line to copyright.noti...@nokia.com, (b) by a document titled “Copyright Notification” mailed to Nokia, Attn: Copyright Agent, 102 Corporate Park Drive, White Plains, NY 10604, USA or (c) via the online form, if available. Your notice must: (1) identify the original copyrighted work you claim is infringed; (2) identify the content on the Service that you claim is infringing the copyrighted work. Please provide enough detail for Nokia to locate the allegedly infringing content on the Service; (3) provide your contact information, including your full name, mailing address, telephone number, and email address, if available; (4) provide a statement that you have a good faith belief that the use of the content in the manner complained of is not authorized by the copyright owner, its agent, or the law; (5) provide this statement: I swear, under penalty of perjury, that the information in this notification and complaint is accurate and that I am the copyright owner, or am authorized to act on behalf of the copyright owner of an exclusive right that is infringed.; and (6) provide your signature, as applicable. What a joke! It is not for Nokia to impose stringent conditions on those who wish to notify them of possible illegal content in their products. It is their responsibility to ensure they are not breaking the law. You do not need to be the copyright holder to inform them you believe they are breaking the law. If you want to act on this , just send them a written letter by a signed for mail service to one of there corporate offices. I would strongly advise against any sworn statement and suggest you couch everything in conditional disclaimers like it appears that , I believe that etc. so that they can't accuse you of anything. BTW the logo has not been stolen , gimp.org is still in possession of it and still using it. Theft implies dispossessing someone of a physical object. Making a copy does not deprive the rightful owner of possession. Copyright infringement is a civil offence not to be assimilated with theft which is a criminal act. The logo has not been stolen , neither were the climategate emails stolen. That just stupid tabloid newpaper language. /gg So as I know copyright issues should be taken serious, especially by GPL software, I thought I better report it this way. Sorry for off topic message, if it is... Ilgaz Ocal ___ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] unsharp mask
On 12/08/10 19:35, Alexia Death wrote: When we are on the subject already, I have a suggestion. Lets save the countless noobs time and change the menu label of unsharp mask to Unsharp Mask Sharpen? --Alexia Good point but is that any clearer than 'unblur mask blur' ? Until this stupid, cryptic, confusing name gets dumped everyone who has not already met it will be confused. Let's call it something else that makes sense and maybe just put unsharp in the hint in case anyone knows it from elsewhere. /gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] unsharp mask
On 12/08/10 21:57, Sven Neumann wrote: On Wed, 2010-12-08 at 20:35 +0200, Alexia Death wrote: When we are on the subject already, I have a suggestion. Lets save the countless noobs time and change the menu label of unsharp mask to Unsharp Mask Sharpen? Seriously, Unsharp Mask is the correct term and it is widely known and mentioned in pretty much any book/tutorial that covers image manipulation and sharpening algorithms. It doesn't really help to disguise the filter by giving it a different name. GIMP is not really meant to be the application that a noob should use for their casual image manipulation needs. There are other application that fill this need and we should leave it to them to present the user with just a single sharpening algorithm and calling it Sharpen (even though it would most probably be Unsharp Mask). Sven Looking at the present way this is presented: Sharpen ... Unsharp mask Then, because everyone who wants to sharpen an image is likely to look at the option called sharpen this has a hint saying it's not as powerful as unsharp mask. The unsharp mask hint explains that this is the most commonly used way to sharpen an image. Thus it is recognised that this is confusing and counter intuitive to the point where both comments are saying you don't want to use sharpen , try unsharp. While unsharp mask may be the correct term it only makes sense in a photographic lab of a generation ago, it is now jargon. However interesting that may be to know the origins, the term is now a hindrance to usage and a clearer presentation would be better IMHO. While the vision of gimp is to be top-end this should not require all users to have 10 years professional experience or a degree in image processing. It should be top-end in function without being esoteric. I would suggest renaming sharpen to simple or basic sharpen and unsharp to sharpen. That would instantly guide people to the probably required tool. Then use the hints to provide for those seeking more detail to know which they require rather than , as now, using this space to say the names are confusing and you probably don't want this one, use the other one. /gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] unsharp mask
On 11/23/10 08:24, Patrick Horgan wrote:
On 11/22/2010 01:26 PM, Ofnuts wrote:
Well, I wondered too: the radius slider goes from 0 to 120 in .1 steps
so that would be only 1200 values to pre-calculate.
They only do it for numbers less than 10 and the length varies with the
radius (from a low of 5 to a high of 45) as well. The total number of
entries would be 2520 * 8 bytes for a gdouble so it would only need
20,160 bytes of storage, ideally but since C doesn't have variable
length arrays you'd have to declare the array as something like:
static gdouble global_cmatrix[100][45];
which would make the length 4500*8=36000 bytes but of course you'd have
to store the length of each as well. If you wanted to you could store
them as unsigned chars, so it would be another 100 bytes, or a total of
36100 bytes. In a trial it really added 36831 bytes. How would that
affect the usability of the plugin? I've attached an include file that
has the matrices you would need. Then you could use:
static gint
gen_convolve_matrix (gdouble radius,
gdouble **cmatrix_p)
{
*cmatrix_p=global_cmatrix[(int)((radius*10)-.5)];
return cmatrix_lens[(int)((radius*10)-.5)];
}
I don't know if it would be a good idea or not.
Is it true though that the user interface only _allows_ values in tenths
or is it that it only displays values in tenths but returns values in
between?
Patrick
___
What is the aim here? Unless I've missed the point, it seems like a
trade-off between computation time for the matrix and memory footprint
of storing all the possible values that matrix could hold.
That's fairly bit of memory to grab if there's not a real need. How long
does it take to calculate matrix each time? Is this even a noticeable
proportion of the time required to apply the filter to an image?
If I've got the wrong end of the stick, what is the problem with the
current code?
regards.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] unsharp mask
On 11/23/10 18:03, Torsten Neuer wrote: Am 23.11.2010 16:11, schrieb bioster: On 11/23/10 08:24, Patrick Horgan wrote: What is the aim here? Unless I've missed the point, it seems like a trade-off between computation time for the matrix and memory footprint of storing all the possible values that matrix could hold. That's fairly bit of memory to grab if there's not a real need. How long does it take to calculate matrix each time? Is this even a noticeable proportion of the time required to apply the filter to an image? If I've got the wrong end of the stick, what is the problem with the current code? regards. I think they're talking about trading off between spending CPU time computing the matrix and spending memory storing it precomputed. I think I disagree with you about it being a fair bit of memory. 30-40k of memory in't a big deal by today's standards, and when you put that beside a modestly sized image which can easily run a few megabytes, I would consider it entirely reasonable. That's assuming you release that memory after your unsharp tool is done. The computation time is probably in the same class... my computer is fairly brisk and I don't think the time spent computing the matrix is noticable. Don't forget about code size and the size of memory allocated for the matrix - this also takes up a certain amount of memory. Maybe not 30-40k, but the difference between run-time computed and pre-computed values would not be that big, but... So it's not that there's a problem with the current method, they're just pondering whether they can squeeze better performance out of it by making the tradeoff. And this is the real trade-off: trading maintainability of code - just imagine someone wanted to increase the precision of the radius parameter - for a minimum amount of speed. This function IS CALLED ONLY ONCE for the whole filtering progress! Which means that this is clearly the least important place for code optimization in this plug-in, since the speed gained from making the matrix pre-computed will dissolve into nothingness with growing images! How many microseconds does the computation of the matrix take ? Did anyone evaluate this yet ? I mean, before starting to speculate about methods of optimization for a certain part of code, one should first have a look at what can be gained there - in this case: near zero. Torsten I agree , I thinks there's not much point unless someone benchmarks this and shows there is a real problem. However , in reading up on this I found this article suggesting that it is at least 2x faster to do this operation on luminosity in YUV rather than RGB and it often looks better by avoiding odd looking inverse colours. http://www.codeguru.com/cpp/g-m/gdi/gdi/article.php/c3675 I also note that the preview could be streamlined in some areas. 1/ clicking preview on and off clearly redoes the whole operation , this should probably be buffered if the params are the same as the last on state. Clicking on/off is a valid requirement to visually compare before and after. With a large radius this can be quite a long wait. (2-3s on a 2.4GHz Athlon) which impedes a clear comparison. The preview could be saved in a tile and simply restored if none of the parameters change and the window is not moved. 2/ dragging the preview box could poss benifit from storing the matrix but again this could be micro-seconds. 3/ a small drag of preview reverts the whole thing to unprocessed data and starts again. This is a waste of time if the drag is less than the whole preview window size. The drag could copy the already sharpened area and just work on the two rectangles that got dragged in. Keeping the already processed rect would also be a good visual feedback , especially when using the NESW crosshairs to drag the window. some quick experimenting seems to indicate that this is common behaviour on ALL filter previews. While many are fast enough (on fastish processors) convolution based filters can be rather slow. since unsharp is the most useful sharpen filter it may merit some work , especially if it would benefit across all filters. /gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] unsharp mask
On 11/24/10 02:04, Patrick Horgan wrote: If it was, then If I've got the wrong end of the stick would mean, If something bad is happening to me. My brain never stops! lol! best regards, Patrick I think the basic idea is one of making a mistake by picking up a stick by the wrong end , which is covered in shit. I don't know the exact origin. It's a bit like when the shit hits the fan. I don't think you're supposed to ask who's fan and where did the shit come from and how come it gets near the fan anyway? It's just a colourful expression which is a bit more fun that saying if I'm mistaken. We're all agreed that avoiding calculating the matrix is pretty pointless. Any thoughts on what I said about the previews? /gg/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Blocking for...@gimpusers.com
On 11/17/10 17:24, photocomix wrote: On Tue, Nov 16, 2010 at 6:28 PM,g...@catking.net wrote: Hi, the running polemical thread on VG filter has made me aware of what is presumably a new feature on that gimpusers.com blog that allows users of the site direct access to this list via the addressfor...@gimpusers.com Would it be a best to simply block this address? ggcarting i fear that will not solve: I found convenient the gimpusers interface but I am registered on this list from long before was a gimpusers interface. I am sorry to have started such huge debat on such triviality I dont care much of the faith of that filter and the more the debat inflate the less i care about Van Gogh filters photocomix, I was not suggesting banning _you_. I clearly suggested requesting they remove the feature or blocking for...@gimpusers.com , not you personally. What seems inappropriate is the automated interface on the blog. If anything, it should be following to gimp-users ML. gimp-devel has always been open to individuals who want to join the list and get the posts. I'm fairly sure no one has even needed to be banned. This is a new feature on that blog so we can just wait and see. I suspect it will result in frequent user blog-chat polluting the list. /gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Why the Van Gogh filter is still in gimp?
On 11/15/10 19:01, Ofnuts wrote: There was a project gathering usage statistics on an earlier version of Gimp, maybe they have some data on that? Or make the filers crash when used and see if anyone complains:-) :-) I did that a long time ago to clean up a disk full of obsolete utilities. Got very few requests to put some things back:-) That is really a pretty perverted logic. Due to the all too common lack of repect for backwards compatibility in Linux world most people either conclude that a feature is broken/disappeared and live with it or they just conclude that they can't remember how to do it.. The percentage of users that actually take the trouble to search for help, subscribe to a list and post a bug report is very small. Hardly a useful way of polling the user base. As for, which filter to use on a photograph, it depends on the photograph, on the lighting that was used, on the subject matter... Yes, proper filtering requires a lot of education. And there is little pupose of giving people a whole toolbox (that they have to carry around) if they don't know how/why they could use some of the tools inside. Little pupose except _education_ . One sure way to make sure users stay uneducated and don't know how/why to use the tools is to remove them ! /gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] gimp taking out X on kubuntu 9.04
= /usr/lib/libexpat.so.1 (0x7fde1b3b3000) libdl.so.2 = /lib/libdl.so.2 (0x7fde1b1af000) libselinux.so.1 = /lib/libselinux.so.1 (0x7fde1af93000) /lib64/ld-linux-x86-64.so.2 (0x7fde2292f000) libXau.so.6 = /usr/lib/libXau.so.6 (0x7fde1ad9) libXdmcp.so.6 = /usr/lib/libXdmcp.so.6 (0x7fde1ab8b000) I'd normally run from a terminal at this stage but since X gets blown out I never get to see the output from the crash. Is there anything obviously wrong with that output? It was a bit embarrassing have shouted about how good GIMP was to see it disappear in a puff of smoke. Any suggestions? TIA, gg. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] X copy-paste in text tool
Hi, noticed a defect in the text entry tool. I was preparing a few lines of text on top of an image using the small edit window of the text tool. If I select a text segment with the mouse and do middle button to paste the text cursor does not move. This may not be too important in itself but has knock on effects and other related issues since to move the cursor to the new location requires a second click , which in turn clears the buffer, losing the text I had selected. X-window copy paste is so much more efficient than messing with context menus or dropping the mouse twice to use cntl-c cntl-v . This ought to be fairly easy to fix. So I'd like to dig into it. I suspect this may be a bug inherited from gtk , if so can anyone point me in the right direction? Any other tips that may save some time getting into it? thanks. ___ 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/10 06:53, Konstantin Svist wrote: On 09/22/2010 09:05 PM, Abir Sadik wrote: This is some really serious violation going on, and i hope someone will do something about it. Some people who really dont know much about opensource are actually buying from that seller, check his feedback. Wrong. Selling most open source software is perfectly legal, according to the licenses @ Konstantin WRONG: selling the software is not allowed as you would see from the licence snip that you posted. A fee to cover the cost of distribution is permitted. Not the same thing. If this seller was showing a reasonable price for distribution of his CD that would seem ligit but it is hard to see how you can AUCTION a distribution fee. @ Abir: If you want someone to do something maybe you could dig up the FSF page that explains the licence and gives advice on how best to comply. Contact the seller to make him aware of the clear terms of the GPL and any other licence you believe he is not respecting. You could also ask him where he provides the source code for all this software. There's pretty good chance he is not complying at all with that. However, until you see him getting bids that are clearly in excess of a reasonable fee I would not worry too much. regards. GPLv2: *** You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. * You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: [paraphrased] provide source code with object code or an offer to send it for no more than cost of distribution BSD license is even less restrictive than that - to paraphrase, do whatever you want, just attribute this piece to the original author (1 copyright line + 10 lines of text) If they're having any luck selling the software, all the power to them.. though they better respect the license to the letter :P ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] IMPORTANT: GIMP AND OPENSOURCE SCAM ON EBAY!
On 09/23/10 11:27, Alexandre Prokoudine wrote: On 9/23/10, Abir Sadik wrote: This is some really serious violation going on, and i hope someone will do something about it. In my experience there is nothing you can do about that, educating that kind of repackagers is just wasting your time. We in Audacity project tried dealing with this, got nowhere and simply ignore this. It would also be nice if you STOPPED USING ALL CAPS :) Alexandre Prokoudine http://libregraphicsworld.org Hi all, Just for info here is a more successful response to this problem by commercial outfit that release a GPL version of their software. There was also a successful prosecution in the states recently . So it not necessarily the case that all you can do is say pretty please. Here's what appeared on YAFFS mailing list earlier this week. Dear Readers, Aleph One Limited discovered a Far-Eastern company selling data-management hardware through a distributor in Europe that used YAFFS in the software, under GPL. We asked the distributor for sight of the Source Code and they were unable to provide it. With the assistance of the law firms Moorcrofts in Marlow, England, and JBB Rechtsanwalte in Berlin, we pursued the matter with the distributor and negotiated a financial settlement, including an element for damages, to our satisfaction. We are always ready to discuss suitable terms of a Licence to use YAFFS. LvS -- Laurie van Someren, Aleph One Ltd, Old Courthouse, Bottisham, CAMBRIDGE CB25 9BA UK t: +44 (0)1 223 811 679 www.aleph1.co.uk www.yaffs.net ___ 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/10 15:16, Tor Lillqvist wrote: As long as it seems clear that none of the actually affected parties (i.e. the people who hold the copyright to parts of GIMP and other (L)GPL-licensed bits bundled by the scammers) care about the alleged problem or would consider doing anything, this discussion is mostly pointless. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer If that were the case GPL is pointless and adding a copyright message to the source is pointless. Openly suggesting that nobody gives a damn nor would consider doing anything makes it doubly pointless. Presumably those choosing to work under GPL don't think it's pointless. The person in question is probably doing more to promote the project than harm it , though it seems they are not complying with the licence and hence are likely selling counterfeit software on e-bay. Since there seem to be some curiously misinformed opinions about what GPL does allow , even by those quoting bits of it, the discussion may not be futile. It's probably not conducive to the OSS as a whole to promote the idea no-one is prepared to enforce it. That's not the case. /gg ___ 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/10 18:57, Chris Moller wrote: eBay has been notified of both the possible license infringement and also of what they call fee avoidance--charging almost nothing for the product, a percentage of which goes to eBay, and making their money on their exorbitant shipping charges, on which eBay makes nothing. Between these two violations of eBay policy, the auctions are likely to be ended and the selling warned not to do it again. (My wife is a high-level eBay seller and knows about this sort of thing...) Nice move , shop the guy to the Ebay police without even pointing out the source code requirements and asking him to comply with the licence. Who gives a shit if he claws back a bit of ebay commission. They're far bigger crooks. Ebay are quite happy for people to do false bidding and have even made their system so anonymous that it's damn near impossible to tell anything about the bidding history of the phantoms you are bidding against. I long since stopped buying on ebay for that very reason. It a mugs game. False bidding suits them down to the ground because they get more comm. The fact that it is illegal in most countries where they operate does not seem to worry them unduly. Interesting to note that there is means on the site of reporting people fiddling the postage and it's thier number one offence. However you have to jump though hoops to report false bidding. I guess your wife must know a thing or two about that side of ebay as well. Shame no-one found fit to contact the seller and ask him to do whatever it is that Gimp licence requires rather than using some underhand bullshit about ebay rules, that does not concern gimp in the slightest,. to stab him in the back. With that mentality, if your neighbour parks in front of your house I suppose rather than ask him to move it, you'd call the police and report him for not having enough tread on his tires Snidey and pathetic. Hardly the spirit of free software. ___ 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/10 22:07, Tor Lillqvist wrote: selling the software on ebay. In my country (germany) some people do not have access to broadband internet and like to buy a CD of the software. GIMP has been relatively often distributed on CDs that come with relevant magazines, also in Germany. Very recently even, I know because some of these publishers tend to ask for permission (even if they don't have to) Well since they probably weren't putting the source code on the CD they probably do need written permission. Whether you have/had the authority to grant that permission is another question. Maybe someone would like to grass them to the tax office. I'm sure they've done something wrong if they did hard enough. /gg and have asked for my postal address and sent me copies... And like ten years ago I received some Japanese computer graphics magazine (which was not very useful) for maybe a year after giving permission to distribute a Windows build I had done back then... --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP paths - optimization tricks (getting Blender's 2.53 UV layout as path into GIMP).
On 09/13/10 05:47, saulgo...@flashingtwelve.brickfilms.com wrote: Quoting Mirza Husadzicmirza.husad...@gmail.com: Hi all, I came up with solution to import and merge Blender's SVG file as path into GIMP. : : I was quite depressed yesterday, but in the middle of night I got an idea :-) If GIMP cannot draw overlapped lines, then why should draw them *overlapped* after all!? If duplicates are removed, then XOR drawing will not affect path. Yupiee. As a side effect, there will be approx. half of lines less to draw (in case of connected polygons a.k.a mesh) so this is a very good optimization for poor gdk-powered line drawing in GIMP. : : I would like to hear you opinions. Why not implement your removal of overlapping path segments as a separate plug-in which can be executed on any paths, not just imported ones? Doing this would eliminate the import interface offering an option which addresses a hardware/graphics preview limitation which many users would not, and would not care to, understand (and may disappear in the future). hi, a quick look at the bug from 2001 suggests this is the underlying issue that affects more than just the svg problem. XOR is a fundamentally flawed way of dealing with overlapping elements. This bug has been repeatedly kicked into the long grass since it was opened. Presumably the best solution would be to deal with the root cause: xor. Removing duplicates would be a reasonable workaround for the mesh problem. Does it have a wider application? /gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] (no subject) plus dockables
On 08/28/10 07:16, Martin Nordholts wrote: Making the Layers dialog discoverable under the 'Layers' menu and color dialogs below the 'Colors' menu etc.. makes a lot of sense But won't that be a problem? Instead of having all dockable dialogs in a single place, a user would have to go hunt for the one he wants. Regards, Martin I think this is the logical error here from usage point of view. It is not the fact that they are dockable which means they should be grouped together. They should be grouped according to function. If I want to hide a layer I should not need to think : last time I did this what did it look like, what sort of GUI element was it that allowed me to hide a layer, was it dockable, where are dockables hidden? If I want to hide a layer , I go to the layers menu. I find it strange anyone would argue against that. /gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Rotational Motion Blur
On 08/18/10 19:09, yahvuu wrote: On 18.08.2010 12:50, g...@catking.net wrote: On 08/18/10 11:07, Tor Lillqvist wrote: A motion blur is a retinal effect that has a time dependence. Is motion blur actually something people perceive with their eyes and brain, or something that only exists in physical artefacts? (Either intentionally created by an artist to give the impression of motion, or as an direct result of the method the still or motion picture was created.) And we have been so used to it that we know what it means, even if it doesn't correspond to what we actually see? (But yeah, gg's arguments make sense.) --tml Good point, the equal weighting probably is close to what a silver nitrate film camera would record I think so, too. Consider the star trails in a long-time exposure of a night sky: there is no decay visible. However, and whatever the motivation, it's an interesting idea, so here's a quick comparison for a linear motion blur: http://yahvuu.files.wordpress.com/2009/08/blurtest.png Regretably, the mathmap convolve function introduces some artifacts, but i think it can be seen that 'decaying' (or 'soft'?) motion blur is an option of artistical relevance. Tongue in cheek, i shurely wouldn't oppose if someone wanted to get code providing this functionality included into GIMP .- regards, yahvuu The blurtest.png is interesting. The example with the decaying kernel is the only one that suggests movement to me , it definitely has direction. All the others look, well, blurred. Despite the artifacts of the implementation, this suggests some sort of progressive blur may be interesting and may suggest movement better than current photographic blur. /gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Rotational Motion Blur
On 08/18/10 01:20, Bill Skaggs wrote: I just looked over the code -- if I understand it correctly, it creates an arc of the specified angle passing through each point of the image, generates a set of points equally spaced along the arc, uses interpolation to get the color for each of these points, and then averages all the colors together, with equal weighting. The number of points is proportional to the length of the arc, with adjustments if it is too large or too small. If you need more detail, please ask. -- Bill I'm sure you are right in reading the code, so this feature seems more like a rotation blur than motion blur. A motion blur is a retinal effect that has a time dependence. This does not seem to be what is done. The equal weighting is wrong. The retinal retention of the image fades with time (my guess would be exponentially if we're going to be rigorous). This means the weighting of each point should be diminished as we work back along the arc. This reduction should be angular and at least a linear reduction of weight w.r.t. the angular coord would probably be a decent approximation. Otherwise a lookup table of exponential decay would mean very little overhead in doing a fairly rigorous model of the real effect. This effect will vary dependant on speed of the movement (as everyone knows intuitively) so this parameter needs to be adjustable in the tool UI. I assume the same points could be made about the motion blur , though I have not looked at the code. I'd don't have the time to get into coding an improvement but thought it worth noting the apparent shortcomings of the motion blur and how it could be improved. regards. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Rotational Motion Blur
On 08/18/10 11:07, Tor Lillqvist wrote: A motion blur is a retinal effect that has a time dependence. Is motion blur actually something people perceive with their eyes and brain, or something that only exists in physical artefacts? (Either intentionally created by an artist to give the impression of motion, or as an direct result of the method the still or motion picture was created.) And we have been so used to it that we know what it means, even if it doesn't correspond to what we actually see? (But yeah, gg's arguments make sense.) --tml Good point, the equal weighting probably is close to what a silver nitrate film camera would record, which is probably what this was intended to model. /gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gradual zooming!
On 07/17/10 21:47, Cedric Sodhi wrote: Hello again, I'd like to know whether there exist efforts to implement gradual zooming. As far as concerns me 10% steps (or whatever it is) is an absolute no go for artits and makes workflow as fluent as swimming through bricks. I thought this wouldnt require much effort since GIMP apparenty has the capabilitly of displaying abritrary zoom levels! best regards, --MD What do you regard as fluid? each step requires a redraw so it is never fluid , we're just talking about the size of the bricks. Please define. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Optimized Despeckle plug-in
On 07/13/10 19:52, Sven Neumann wrote: On Tue, 2010-07-13 at 10:49 +0200, Martin Nordholts wrote: On 07/13/2010 10:28 AM, Przemysław Zych wrote: Hi, As a part of my student project for Optimizing Open-Source Applications at Warsaw University I have speed up despeckle plug-in for gimp. Original version of the plugin run 56seconds for 1024x768 image with despeckle radius 30 and adaptive flag turned off (on my Intel Macbook 2.1GHz). My optimized version with the same settings completes the task in 3.5 seconds with the same image quality :-) Sources for this optimized plug-in can be downloaded from here: http://students.mimuw.edu.pl/~pz248275/despeckle.c http://students.mimuw.edu.pl/%7Epz248275/despeckle.c What should I do to get this to the gimp repository? Should I change the copyright header? Hi! That sounds great. To maximize chances of getting this into GIMP: 1. Create a regression test for the despecle plug-in that is run with 'make check'. This is a great way to convince us that your optimization in fact does not change the output, only improves performance. Well, as far as I can see the current implementation of the despeckle plug-in does not match the expectations. IMO it is buggy. Thus we should not absolutely require that the result does not change. But it would be desirable to get fixes to the algorithm submitted separately from optimizations. It would also help a lot if the patch followed the GIMP coding style. Please see the file HACKING in the GIMP source tree. Sven hi, I agree. I had to clean up some photos recently and ended up doing most of it by hand. If you code produces the same kind of results with that much of a speed increase a patch would be worth providing. Kudos for achieving that level of speed up. I guess by now you must have got a good feel for the way that part of the code base works so if you can write a despeckle routing that does despeckle that would be a worthwhile contribution as well. Thanks for you efforts. /gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Rotate on the arbitrary line -- feature request
On 06/19/10 10:16, yahvuu wrote: On 19.06.2010 17:50, doug p. wrote: [..] where I can draw a straight line, and say to rotate the image to that line. [..] How can I request this feature to be added. Hi doug, the best way to request user interface improvements is to sketch your idea and post it on the UI brainstorm [1]. I'm aware of two postings which already touch the same problem [2,3]. Improvements are always welcome. That being said, the canonical workaround is to align to the window border or to another window, if necessary. regards, yahvuu [1] http://gimp-brainstorm.blogspot.com/ [2] http://gimp-brainstorm.blogspot.com/2007/10/precise-rotation-using-measured-data.html [3] http://gimp-brainstorm.blogspot.com/2010/06/workspace-continued.html The brainstorm site is a one way process . There's no discussion and rarely any feedback. Also the fact that the submission has to be totally pictorial is a debatable restriction for a purely GUI topic but not well suited to presenting the pros and cons of one rotation method against another. It is acceptable to open a feature request bug once the ideas have been discussed here. So you're doing the right thing. Wait to see what responses you get and what the feeling is about the idea and its feasibility. Unless it gets shot down you could open a feature request bug. /gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Merchandizing for the GIMP.
On 09/06/10 19:43, Alexia Death wrote: On Wednesday, June 09, 2010 20:19:03 Sven Neumann wrote: On Tue, 2010-06-08 at 16:32 +0200, Simon Budig wrote: Hi all. At LGM we threw some ideas around for Gimp-Merchandizing. Since I haven't been at LGM, I have trouble to understand the motivation for doing GIMP merchandising. IT was discussed and two reasons dominated. a) Promotion material for the fun of it. Cheap giveaways, like Wilber stickers you can give away at local meets for fans to show their love for gimp. It boosts the fun index of the project sky high. Heck, I wish *I* had some to stick on my laptop lid. When I finally get a decent printer I might print some paper ones but... Real stuff would be way cooler. Yeah! I have a wilber sticker! Woot, Cool , loads of fun. My life just seemed empty before , how did I live? Yeeha! WOOT again, merchandising is FUN! b) Something a little bit better as a token of appreciation. Google gives the GSOC students shirts... It would be rally nice if we could give them a nice little mug with Wilber on or something. And If someone wants to buy the items, that should ye,s be an option too but it wasn't really the aim. You are certainly not doing this for the money, are you? We have a steady flow of donations coming in and basically nothing to spend this money for. This was proposed as a way to do something with the money that would be fun. Merchandising is usually a way of MAKE money not spending it. Paying for everyone to go out for a few beers sounds more like fun. Perhaps someone can explain why the GIMP developers should even care about merchandising. Im speaking for myself here I guess, but Id like to have something to show off what I do as a hobby ... and spread the Wilber love around. What, you print mugs for a hobby , cool! There seems to be something fundamentally disingenuous in all this merchandising bullshit. I would have thought the best was to promote GIMP, if that needs to be done , is to show off what can be done with the software, not printing mugs , tee-shirts and balloons. I don't think gilbert is particularly good example of what can be done with GIMP and I find this silly mascot rather demeaning and irrelevant. Hardly the focal point of the project. I recall seeing some really impressive computer art that was done with blender. Real art, like as in paintings, not just pulling ellipses and triangles around. It was hard to believe it was done with a computer. It would be more inspiring and more of an accolade to GIMP to show some really top class work created with it rather poncing around with a gimp flavoured handbag and a sticker on your forehead. Perhaps any promotional effort should be made to relate to the project. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSOC: cage based transform tool
On 05/09/10 14:55, Michael Muré wrote: * when the pixel is sent to the target pixels, they not only affect one pixel, but an area of pixel (3x3, or 4x4 pixels) with a gaussian weight or similar * For pixels with no information (which should be rare), the value is computed as a weighted average of the closer neighbour I suggest you look at the catmull-romm code used in GIMP image scaling functions. It is a spline fit to four points that is probably better than averaging . It is pretty light on computation time so achieves good results with minimum overhead. It allows interpolation anywhere between two points so does not introduce extra pixelisation artifacts. The only downside I'm aware of is it tends to overshoot near abrupt changes since the mathematical definition of the spline does not constrain it to the region of the points which define it but does dictate that it pass through each one. Near a step change it will exactly fit each point either side of the step but over shoot around those points. HTH. /gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] project gimp on sourceforge
On 04/23/10 10:36, Michael Schumacher wrote: Von: Liam R E Quinl...@holoweb.net Someone has registered gimp on souceforge - http://gimp.sourceforge.net/ I see there's a Donate Money link, and a non-working download link, both of which may be harmful; maybe it's worth asking sourceforge for this not-gimp project to be deleted? For the moment, yes. We could consider to establish a home page there (although we will most likely not use any of their other ressources), so I'll look into blocking that url for future use. Regards, Michael http://sourceforge.net/project/project_donations.php?group_id=303361 Gimp (gimp) has not opted in to receive donations Seem like no activity since it was set up. Probably someone who smokes too much weed. The most positive way to catch this is probably by joining the project and putting the correct home page, links and info that would be helpful. If it gets deleted it will only get recreated by someone else. /gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GSoC] Replace the GimpSizeEntry widget
On 04/03/10 09:46, Martin Nordholts wrote: I thought choosing unit is a common way. When I first read about the text entry in the idea list page, I have a few questions: - Does the UI need to provide examples for the new text entry, e.g. 40 px or 9 in near the text fields? Not in the UI, rather in the manual. some care should be exercised here. If the interface is to become less clear and it is now necessary to go and read the manual in order to understand how to use such a basic and important input, I would be very inclined to see this as a regression not an improvement. This current interface , despite its shortcomings is clear and explicit about what is available. Replacing this approach with RTFM hardly seems appropriate. regards. ___ 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/25/10 05:02, Jason Simanek wrote: On 03/24/2010 03:21 PM, Karl Günter Wünsch wrote: On Wednesday 24 March 2010, Alexandre Prokoudine wrote: On 3/24/10, Karl Günter Wünsch wrote: This is ludicrous - how would anyone trying to use the keyboard learn the different mnemonics available? This is default behaviour on Windows. LOL It must be the right thing to do then ! Which is the first thing I disable on any Windows installation I do and the users are happy about that. The shortcuts should definitely be shown while using the mouse. Who came up with this idea? I know this isn't the GTK+ mailing list, but seriously, how is this an improvement? Were the drop down menus getting too wide with the included shortcuts? Were they interfering with legibility? Why are they trying to fix problems that don't exist? What percentage of users navigate the menus via keyboard? To me beginners use the mouse to navigate the menus. Experts use keyboard shortcuts. People that are unable to use the mouse use the keyboard to navigate the menus until they learn the shortcuts. It is very awkward for me to learn the keyboard shortcuts if they aren't visible during mouse navigation. I never use the keyboard to navigate the menus. Just my two cents. -Jason Simanek I think your points are entirly valid, this is a bad direction to go in. I strongly suggest you open a bug on GTK+ about this. They are pretty intractable and refractory to any outside suggestions that they may not have made the best choice BUT if no one flags this sort of stupidity it certainly will not get fixed. While there is some overlap of gimp and gtk+ developers since it was originally gimp tool kit, the two are basically separate now, so please bug gtk+. ;) Post a link to the bug here if you like and I'll give it a comment if I can add anything. regards. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Fwd: [Tigervnc-devel] libjpeg-turbo first release (0.0.90 beta)
Hi, I thought this announcement may be of interest: I thought some of you might be interested in the first release of TigerVNC and VirtualGL's JPEG codec as a standalone SDK. The new project is called libjpeg-turbo, and the files are available here: https://sourceforge.net/projects/libjpeg-turbo/files/ Included in the release are pre-compiled SDKs for Linux (32-bit and 64-bit RPMs and DEBs for GLIBC 2.3 and later, and a source RPM), OS X (universal binary supports 32-bit Tiger later and 64-bit Snow Leopard), Solaris/x86 (Solaris 10 package with both 32-bit and 64-bit binaries), and Windows (32-bit, both Visual C++ and GCC flavors.) Additional info about the project can be found here: http://libjpeg-turbo.virtualgl.org/ including competitive performance information. Mailing lists are set up and ready. If you know of other projects that could benefit from this codec, please forward this message to them. I am looking for people to test drive it and let me know what breaks. DRC ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] JPEG quality factor - some remaining odds and ends
On 01/19/10 22:51, Liam R E Quin wrote: On Tue, 2010-01-19 at 22:38 +0100, yahvuu wrote: [...] II. Range of actually useful values for IJG quality value For GIMP's target users less than half of all possible settings are useful: possibly - I've often used values as low as 35% or sometimes lower. The sweet spot depends hugely on your image and your purpose - consider providing a lowsrc alternate image for low bandwidth Web users for example, or a thumnail. Most of the preview images on www.fromoldbooks.org are saved at 75% (usually with smoothing to reduce artifacts a little) 95 . no-go: just wastes disk space -- ever heard of XCF? 100 Actually I use 97% a lot, and 100% too -- because I want jpeg format, not some application-specific thing that won't work for most users. Export is about interchange, the end product, you shouldn't ever use jpg for a file you're going to edit again, and you shouldn't normally use xcf for interchange unless you know they're using (a compatible version of) GIMP... Once a user starts to use jpeg they have to decide what to do with quality setting. Bigger number = better quality is not too hard to get your head around. A bit of experimenting quickly reveals what works best for a particular task. You quickly realise what ranges don't fit your needs and focus on those that do. End of story. I see no use what so ever in creating some new, grouped setting in its place. This would essentially involve exactly the same learning process and reduce control and compromise results. III. Parameter Triaging The Subsampling parameter is more important than its current position inside the advanced parameters section suggests. Yes - in particular it affects colours, especially reds. Liam I agree , this setting could come out be more visible. It's annoying having to dig in there just to check what it is set at. /gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] ceci n'est pas une selection...
Patrick Horgan wrote: Sven Neumann wrote: Hi, On Sun, 2009-11-01 at 09:29 -0800, Patrick Horgan wrote: Yea!!! Seems like an obvious idea now that I've heard it that would make tablet user's lifes more happy:) Although, if you think about why I would be wanting to get rid of the selection, I'm probably going to have to scale or select another layer or something that is also less than optional. If we could have two little buttons it would be much better. The first, the aforementioned selection canceler, and the second, something that does the same toggle as hitting TAB. I love the TAB keyboard shortcut, but to use it I usually have to set down my tablet and reach over to the keyboard, which breaks the flow. I wonder why you need both hands on the tablet. The pros that I have seen working with GIMP always had one hand on the keyboard and the other hand holding the tablet pen. I don't want to offend you in any way, I just would like to understand why using the tablet and the keyboard at the same time is not an option for you. One hand on the tablet and the other on the pen doesn't leave a third for the keyboard. Have to set down the tablet or the pen, and since I usually use my left hand for TAB, and for the tablet, it's the tablet that's set down. I have the tablet, a wacom, in my left hand. I imagine that I could set the tablet down and still use it, but it doesn't feel right. Maybe if I had a bigger tablet? The keyboard goes up to the edge of the desk, where would I put the tablet but holding it? You've really confused me Sven. My insecure side says maybe I'm using my tablet wrong? But seriously holding it works like holding a tablet for me--it's natural. Patrick sounds a bit like holding your mouse mat whilst using the mouse to stop it sliding around. I would suggest finding a _hardware_ solution to freeing up the other hand rather than forfeiting use of the keyboard. regard. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Progressive escalation of help
Martin Nordholts wrote: On 10/25/2009 11:35 PM, Ilya Zakharevich wrote: If you think the dialogue is nagging, it is better to make a checkbox do not show this again, show online help directly. AND, maybe, never show the same dialogue in the same session. It won't nag me less just because I can dismiss it for the future. Either the dialog presents important information that I need to see, or it doesn't and I don't need to see it. These Don't show this any more-dialog boxes is a sign of insecureness in the personality of the application. We don't want GIMP to be like that, we want GIMP to be confident it what it is doing. Regards, Martin There is some truth in this approach but it should not be taken to extremes. It is not a black or white decision. This is all part of the KDE-configure everything v. gnome-we-know-best-so-like-it flames. This binary approach to the issue means both ways run a danger of getting it wrong. Specifically it is not to be regarded as a personality disorder. That's because the situation changes , hence the user's needs may change. Maybe you'd see it better if the checkbox (AHH shoot this man , he said the C word!!) was labelled remember this choice. You can't presume what the correct answer is and impose it on everyone since the answer depends on the user himself and availability of connection (and in view of the size you'd better add available bandwidth). So there's a choice the USER not the GUI designer needs to make. Asking the same question every time he hits F1 may well be a PITA before long. I see a legitimate user for errm . one of the square things with an X in it . We are the knights who say checkbox ! Ni ! Ni! Ni! (cultural reference to Monty Python's 'Holy Grail' for the non English subscribers) It's a user configuration if you will. This could be hidden ten layers deep like setting the mouse wheel to zoom in , a far better solution would seem to let the user configure how he wants to deal with this situation when it is first presented. Maybe a better overall approach would be to pop up the help menu on F1 if no help is available. This presents the full choice of options. Other small defect, Sh-F1 goes into cursor selection knowing full well it can't fulfil. This probably should be trapped on key stoke without letting the user select then telling him there's no help. /gg/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Progressive escalation of help
Martin Nordholts wrote: On 10/26/2009 01:42 PM, g...@catking.net wrote: Maybe you'd see it better if the checkbox (AHH shoot this man , he said the C word!!) was labelled remember this choice. You can't presume what the correct answer is and impose it on everyone since the answer depends on the user himself and availability of connection (and in view of the size you'd better add available bandwidth). So there's a choice the USER not the GUI designer needs to make. This not necessarily true. Which is what I said in the bit you don't quote If the GUI designer is designing an app aiding in translating movies then he can deduct from the target user group that such a dialog box should not be shown. The translator using the app must hear see/hear all words. But we're taking about GIMP help not some other hypothetical case about movie translation. GUI designers always design for a well specified target group. With a well defined user group there is rarely a need to guess what the user of an app will want, the GUI designer knows what the users will want. GUI designers always well defined user group GUI designer knows what the users will want. an impressive collection of fairly meaningless hand-wavy generalities. What is your point w.r.t. whether the user wants to be asked what gimp help format is actually applicable n his actual situation and whether a GUI designer can user pro-active telepathy to know his needs and internet access availability? But there are always exceptions and corner cases of course... / Martin Call it a corner case if you prefer , how does this relate to gimp help? thx. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP T-shirts in our online store
Emil Assarsson wrote: I have to say that I like B best. The ears are not that pointy and the lines are smoother. The mouth is good but the shape could be a little bit more rhythmic with the other lines. Maybe to wide? I like the wackiness of the uneven sized eyes that gives the impression of a happiness close to madness ;-) It's better than the staring eyes of C D. The warmer orange brown is nicer than the grayish. I think that the black or white text is best because it balance that big black nose more. Great work! -- Emil On Sat, Oct 24, 2009 at 11:43 PM, Ismael Barros² razielm...@gmail.com wrote: Greetings, We are FreeWear.org, we print and sell t-shirts with FOSS designs (Linux distros, desktops environments, etc) and donate to each organization a percentage of each sold article. We usually sell via website, but we can also be found in local FOSS-related events. We also cover special orders, like commemorative t-shirts for events. We've been conducting a poll about which T-shirts our customers want, and looks like GIMP is the most popular one (besides Ubuntu), so we'd like to improve our catalog with some GIMP stuff. We've taken the liberty of making some simple designs based on Wilber: http://www.freewear.org/images/release_candidates/propuesta_gimp.png m2c; A unfinished ; B a joke ; C grey looks OK on black with white outline. D similarly looks better with outline. C,D mouth too big , too near to edge. There are some possibilities that look cool, and we would love to have some feedback on which design (A, B, C or D) and tee color (white or black) look best to you. Also, is the font okay? Is there any better font available out there for a GIMP logo? We'd be happy to know what you think :) About donations: With other organizations like Gnome or KDE, we've agreed that they link our website from theirs and we donate 3€ for each sold 14€ t-shirt. If you don't want to place a link, you'd still receive some donation to thank you for letting us use your logo and name, but no fixed amount. Did I miss part of this discussion or is this what you regard as asking for permission to use the name and logo for some arbitrary unspecified sum? The wording suggests you will decide what you donate. Maybe this permission was sought elsewhere. My apologies if that's the case. Not that you've spent a lot of time on the design but shouldn't this start with saying you have customers willing to pay $14 and how much would the project team accept for your profiting from their name and hard work? I would think anyone paying $14 may imagine they are donating the profit on the sale to the project. It seems like the $3 is a sales donation for a direct link leading to a sale. Do you also make a donation if a Gimp referal leads to you selling a Ubuntu shirt ? How is all this followed. I am not a member of the gimp team but I think you owe a bit more clarity and respect to those who's FREE work and brand prestige you wish to cash in on. Maybe you would like to explain better how your accountability for attributing sales and donations works. To and outsider it seems a bit opaque. I'm sure it's just your small scale , easy-going way but the good manners of going about things the right way never hurts. Nice carousel you have for printing BTW. If all your shirts are 5 colour hand printed screen prints you should put that up front. It would help justify the price tag. regards. You can find our website in http://www.freewear.org/ Regards, Ismael Barros ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] [Fwd: Re: Would single-window fix usability nightmares?]
---BeginMessage--- Ilya Zakharevich wrote: On 2009-10-23, g...@catking.net g...@catking.net wrote: If you see a homeless person with his hand out and give him burger, you don't expect him to come back and complain about the sauce. Obviously, you never did this. And one could even think that you never heard about food allergies (or had friends/relatives dying from it...). (OT, of course...) Ilya What you manage to take out of context is this was part of a series of comments about user attitudes to FOSS in this case whether their complaints could be returned with don't complain , you did not pay for it. Maybe this is another Russian/English problem for you but you would not expect does not mean it can't happen it means you would not expect . Obviously, you never did this. Really? Obviously your ability to infer my whole life experience from one phrase is not as reliable as you believe it to be. I spent a couple of years living rough, eating from bins an never saw any of the low life around me complain about the sauce. Obscure food allergies were not one of our major concerns. You may post any more comments about what you assume I obviously did or did not do somewhere more appropriate than gimp-devel. Thanks. ---End Message--- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Would single-window fix usability nightmares?
Graeme Gill wrote: Sparr wrote: is broken, switch (temporarily). Everyone waited for Microsoft to fix the DX problem (which never happened, ATI and nVidia implemented workarounds in their drivers instead). Expecting Blizzard's developers to fix (or even acknowledge) bugs in Microsoft's code is silly[1]. Try looking at this type of situation from the user point of view - it's all finger pointing, and doesn't actually help solve the problem. As soon as you put the user first, then as the vendor of a tool you will try to fix the problem if you can (working around it if you must), irrespective of who is ultimately responsible. [ It's all about attitude. Saying It's not my fault is an unhelpful attitude. Saying Patches welcome is an unhelpful attitude. Saying Stop complaining, you got it for free! is an unhelpful attitude. Saying Too bad, it works for me is an unhelpful attitude. Being unhelpful is a confrontational stance that gets peoples backs up, and convinces them that you are not to be trusted, since you seem to have no empathy for their situation, and seem to have no pride in what you do. ] Graeme Gill. Some of your comments are valid but your basic premise is wrong. There is nothing for sale, so the is NO VENDOR. neither is a GIMP a product in more than the most literal term that it is something which is produced. Applying your marketing terminology and mentality to a FOSS project is wrong . Different motivations are the driving force. The customer is not king. He can be a collaborator. Saying Stop complaining, you got it for free! is an unhelpful attitude. So is complaining. With FOSS you can submit bugs reports if something does not work , request a feature is you have an idea or contribute to the project. The is no channel or reason to deal with complaints. If you see a homeless person with his hand out and give him burger, you don't expect him to come back and complain about the sauce. But it's also true that suggesting something could be done differently is sometimes taken as an affront , that is unhelpful and may hinder improvements being made. Many FOSS projects are refractory to user feedback and ideas coming from outside. /gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp printing future direction
Robert Krawitz wrote: Date: Tue, 18 Aug 2009 11:26:55 -0500 From: Erik Lotspeich e...@lotspeich.org Thank you for the perspective. It seems that the printing part of Gimp is a second-class citizen that doesn't have the refinement of the rest of Gimp. I have always seen Gimp as a Photoshop competitor, so I'm thinking what if my mother-in-law (or any other non-expert computer user) were using Gimp. Would she be able to print? Would she use it instead of buying Photoshop? I would like that answer to be yes. Tor Lillqvist wrote: I have tried all possible permutations of paper size between Gimp and the Windows driver. Since this setup works great for all other applications (e.g. Word, IE, Firefox, etc.), I don't see how the problem could lie anywhere else than Gimp. (The problem is in GTK+ more likely, but that GTK+ is technically separate is mostly irrelevant to end-users.) Yes, it is well known that GTK+ printing (and thus GIMP printing) on Windows doesn't really work that well. My advice is always to use some other application to print images then instead, if GIMP isn't up to it. Opening an image file in another app and printing from there shouldn't take more than five seconds extra. In fact, I would even recommend that, if the situation really is as bad as it seems to be, the print plug-in is made optional (and not selected by default) in the GIMP installer for Windows... Sure, it would be nice if somebody fixed the problems. Volunteers welcome. What might be really nice is if PhotoPrint could be used as a print plugin for GIMP -- it supports everything in Gutenprint except curves, and the UI is much nicer in many ways than the Gutenprint plugin (which I've had to maintain over the years, and I'm not exactly much good at user interfaces). Don't be too hard on yourself . I found Gutenprint interface allows a good degree of control and is pretty easy to use despite the complexity of what it offers. It may not be a work of art , but in terms of user interaction I would say you does a very good job. Sadly, many other projects are run people often very competent at coding but with little understanding of interface design. Equally unfortunate is the impression some of this group have that being able to code puts you at the right hand of God, from where you can look down with disdain on mere mortals who may in fact have a better grasp of human interaction design. You seem to be one of those rare people who are able to bridge the gap between code and UI. Thanks for all your efforts on Gutenprint. Best regards. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] soft handling of X11 errors
Sven Neumann wrote: Hi, On Wed, 2009-08-05 at 08:45 -0400, Martin Cracauer wrote: [Keeping quote below for reference] The is another class of X11 errors that GIMP should survive: when you have a view on another display, these days you can open an entirely new display, on a different computer. Works great as such, I use it regularly. However, if you shut down that display (or the computer that it is running on, or the network or the ssh forwarder) while the view is in use, then GIMP crashes. In both cases, the disappearing display and the disappearing device, what GIMP would need is a resource stack that is supposed to be unrolled on certain X11 errors. At the top of that cleanup stack should be a GIMP that is still running but has forgotten about the device or display that caused the error. No, that is not how this should be addressed. GIMP doesn't even know that it's running on X11. This needs to be handled in GTK+. As far as I know, support for hotplug of input devices is still lacking from GTK+. Support for a disappearing display is available though. So if GIMP is crashing there, then you should file a bug report and attach a stack trace of that crash. We might have to connect to GdkDisplay:close and deal with this on the GIMP side. Sven Whatever the detail, doesn't this indicate insufficient error trapping? Both in gimp and the underlying GTK+ . If gimp is using a pointer to a resource that has been deleted the exception should be trapped and handled cleanly. It should not crash gimp. If neither is trapping the condition both are at fault. /gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] soft handling of X11 errors (Was: Unplugging Wacom crashes GIMP)
Martin Cracauer wrote: wino wrote on Wed, Aug 05, 2009 at 05:12:58PM +0200: Martin Cracauer wrote: [Keeping quote below for reference] The is another class of X11 errors that GIMP should survive: That was my first reaction on seeing the Wacom issue. It sounds to me like a memory object related to the resource has been distroyed and gimp is accessing a now invalid pointer. No, it's not a segfault. It is errors from system calls (as in return -1, set errno) when reading the pipes connecting GIMP through the X11 server to these devices and displays. If this crashes gimp it is a messy bug that reveals insufficient error handling. This sort of exception should be trapped and dealt with without gimp falling on it's arse. But it's messy. X11 error handling is often left at the default error handlers (which exit the application). Explicitly dealing with them will require you to sort out what exactly the error condition was connected to, whether there was a device that caused this and whether it is optional. Then, if it was a device or display that is allowed to go away, you need to clean up the application (GIMP) to remove entries that tell GIMP to communicate with these devices (such as the display draw routine drawing on all displays it knows about) to make them forget about the optional device that reported an error. When you are finished with that you will also have to deal with the fact that errors might come from other conditions than these devices going away. Presumably you'd want to attempt a recovery of some sort in some cases. Just throwing errnous devices out is better that exit(), though. To make the mess complete, X11 error handling inside a GTK+ application isn't exactly the same thing either. Martin oops, cross post with Martins reply to my earlier message that missed the ML due to wrong sender. Thanks for the detailed account , Martin. So whatever the thorough way to completely recover from such an error (which sounds like hard work), should not something be done to prevent gimp just dumping out and losing any current work changes? /gg ___ 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
Martin Nordholts wrote: On 08/04/2009 08:27 PM, Sven Neumann wrote: Well, there have been some good arguments brought up in this thread why saving a clean image may make sense. So perhaps we should change the default for 'trust-dirty-flag' back to 'no' and always save the image? I was about to propose changing the default back to no too / Martin I think that is a good short term solution since it can be done with trivial effort. Although for the next cycle, a more rigourous solution could be better. I think not saving has merit for large files (especially long png compression) on condition this is clearly put to the user. I'd suggest a modal trust me, do it anyway vs OK, forget it choice that could avoid 30s saves at the expense of one click. The reasons have now been well covered. Once such a solution is found (and the parasite bug fixed) trust-dirty could be back on. I have opened a bug about the comment parasite not being detected. http://bugzilla.gnome.org/show_bug.cgi?id=590782 /gg ___ 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
Sven Neumann wrote: Hi, On Mon, 2009-08-03 at 15:51 -0400, Jay Smith wrote: 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. Maybe five seconds is indeed somewhat short. Would anyone object if we increased this to ten seconds? If someone wants to try it, the timeout is defined at the top of app/display/gimpstatusbar.c. Sven I found I had bearly noticed the presence of the message and definately did not have time to read it. I think what actually caught my eye was the fact it disappeared whilst I was looking around wondering why I was not getting the usual progress bar I was expecting. I stress, the reason I knew something was wrong was that the save was too quick , not that the message caught my eye. 10s may help but IMHO this method of notification is far too unobtrusive. The STATUS bar should be for relaying status information. Information that relates to the state of the program. It is used effectively to prompt awareness of hot key combinations etc. This is accessory information that the user may check for or that my just be helpful. The text is small and on the periphery of vision when the focus of attention is on the centre of the screen. 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 ___ 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
Martin Nordholts wrote: On 08/03/2009 11:19 PM, Jay Smith wrote: _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. Hi Jay When you do a File - Save you want to make sure that your changes is safely written to disk, right? If you have made no changes, what is then the point in writing the file again? The user should be able to trust that GIMP does the right thing and it is unfortunate whenever GIMP doesn't. But showing a modal dialog whenever the user presses Ctrl+S twice is to me a really bad idea UI-wise. Regards, Martin Martin, I completely agree that is good not to have unnecessary dialogues and appreciate the work that Peter and others have done in that direction , but Jay sums up well the points I originally made. I generally know when I have not made at least one change. I do not blindly hit cntl_S every 30s just in case. If I save a saved image I'm probably making a mistake and I want to know about it. Maybe the mouse is not over the window I think or the window I'm looking at is not the current one I have altered . Again I am mistaken and need to know. When we can close down bugzilla because gimp no longer has any bugs , your argument about trusting gimp will have more weight. The minor bug I picked up here proves it is too soon to apply that rationale. This feature (unobtrusive messaging) may well be useful in an auto save situation . This may even be the reason it was done this way. In that case I would suggest adding a means for auto save to have an execution path that does not produce unneeded save operations nor warn about the condition. My contention here only applies to a direct user action. regards. ___ 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
Sparr wrote: Maybe I just want to 'touch' the file and saving is the fastest possible way to do that. Perhaps I modified or deleted the file on disk, and want to save the copy that exists in GIMP over whatever is on the disk. I am not sure if GIMP is already aware of this situation Valid point. If I am trying to save to recover a deleted file this becomes a data loss scenario. In some situations, the Save operation produces dialogs from the export plugin, which do not affect the image in GIMP but do affect the saved image. What if I just want to change the decisions that I made there? (again, this may already be handled well). In the same way that I had to make a small edit to save the comment because of the parasite bug, if I want to resave a jpeg with various compression ratios until I get a suitable result , I would presumably have to Save As... to serval new files and clean up with a file manager later. When I have to start looking for work arounds like this , the interface is trying to be too clever. Let me drive ! /gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] nodockables
Martin Nordholts wrote: On 07/24/2009 11:55 AM, gg wrote: Hi, using gimp 2.6.6 I pulled the tool options dlg off the toolbox. Now it won't dock back in. the space says you can drop dockable dialogs here but nothing happens when I do. I remain with two independant windows. I was explaining to someone over the phone , theirs went back , mine didn't. I'm wondering if this is a WM issue. I'm using xfce4 This isn't really gimp-developer material, but gimp-user material. Well I posted it here because I thought it was a bug relating to my using xfce. Now I know how it works, I would suggest it is discussed here to see if there is a way to make it more obvious, or to find another mechanism. Dragging the word paintbrush which is a heading and in no way looks like an active element is very obscure. Also if I select lock tab to dock when the window is free it prevents the docking action. One may think this is something to do with helping to dock it and in fact it prevents it. It seems it is locked into an undocked state. Anway, you are not dragging the WM window title bar, right? You should be dragging the dockable title itself (which is within the window). Yes I know, this sucks, but that's what we have right now. / Martin Thanks for your reply. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] cant save image with new comment
Hi, I added a comment to a png image and pressed Save. I was averted to the fact it failed by the fact it was too quick (a fairly large file). On repeating the save to see what happened I caught a glimpse of a subliminally fast message at the bottom off the screen. I repeated again to have time to read it. Basically it told me it was not saving because there were no changes. I see several problems here: 1/ the most obvious is that there was a change but because it was to the comment and not the image it was not picked up. 2/ there is no way to save save it anyway, trust me! 3/ the noticability here is way too small, had it not been for the fact I knew it had not had time to save the file I would have missed and sent my file without the copyright notice I believed I had just added and saved. possible remedies: 1/ make sure whatever code detects changes looks at all aspects of the file not just the image bitmap. 2/3/ if Gimp is going to disobey orders it had better say so loud and clear and give me an over-ride option. Either I'm making a mistake and need to know or gimp is making a mistake ... and I need to know. This presumably is supposed to avoid possibly lengthy save operations that are not needed. This IMHO is wrong thinking. If I made a slip, be it on my head, I'll have to wait a few seconds and pay more attention in the future. No harm done. It is also possible I have several image open and that I am not saving the image I think I'm saving. Again I need to know. I probably failed to save image I intended. This is all compounded by the obscurity of the message. Eye focus is in the middle of the screen and the message was too quick and away from my centre of attention. I believe this should be a Cancel/Save anyway message box. I know there is a trend to reduce this sort of thing but saving an unchanged image is not part of normal work flow and so it's occurance itself indicates a user error that needs to be flagged, not ignored rather quietly. /gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] nodockables
Hi, using gimp 2.6.6 I pulled the tool options dlg off the toolbox. Now it won't dock back in. the space says you can drop dockable dialogs here but nothing happens when I do. I remain with two independant windows. I was explaining to someone over the phone , theirs went back , mine didn't. I'm wondering if this is a WM issue. I'm using xfce4 /gg ___ 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
Martin Nordholts wrote: Hi Liam R E Quin wrote: Consider (1) open typewriter.jpg that came in from my camera (2) do some fun editing (3) save-as to go to typewriter2.xcf.gz So far so good. (4) now I want to make a jpeg so other programs can use the file, so I can upload it on the Web, etc. Aha! there's File-Export to typewriter.jpg,right there in the file menu. I do this, not noticing that it's using the OLD filename,and the file is overwritten with no confirmation. Because jpeg is lossy, I can't now get back the original (actually it was backed up) The purpose of that menu entry is to allow quick touchups of photos. You open e.g. a jpg, do some change, then export back to the original file. It wouldn't make sense to ask for overwrite confirmation. But we should look into how to minimize the risk of accidental usage since I would say the data loss you describe is severe. So there is a problem between what the purpose was intended to be and the way it is seem by the user who does not know this intended purpose. That would seem to be a clear design flaw and an assumption that the user knows what the designer intended. OK, let's suppose I learned my lesson and change to (4) use file-Export. GIMP has forgotten my new filename (typewriter2.jpg) The filename of the original file has higher priority than the filename of the last saved XCF when exporting, so we'll need to change the spec here if we don't want the current behaviour. Then I think the spec needs rewriting. It is clearly illogical for the user to select save as jpg and get a default filename that is not jpeg. This idea of priority may need re-examining or just that the priority here is not the correct one. , and has also forgotten that where opened the file (and saved the xcf.gz), and wants me to put the new jpeg file in ~/Documents. If you didn't export any file previously to ~/Documents then this is a bug, because as third priority the path of the original file shall be used as the default for the export dialog. Prio one is path of the last export of the file, prio two is the path of the last export of any file. I did a quick test and wasn't able to reproduce the bug, so I will need a step-by-step on how to reproduce this in a new GIMP session. Obviously it's not supposed to work like this. I think it should be (1) I load typewriter.jpg (2) Save would make typewriter.xcf.gz (3) Save-as would change typewriter to some other prefix I chose, e.g. funky-keys (4) export to should now say, Export to funky-keys.jpg Export to is a shortcut to export to the original file or the most recently exported file. I don't think it is a good idea to change its path if you save a file because it would switch all the time. You save, it changes, you export, it changes, you save, it changes again. You would not be able to consistently use Ctrl + S for save and Ctrl + E to export. (5) the export to dialogue should bring up the file chooser in the same directory as funky-keys.xcf.gz but with the new name filled in, and that name should be funky-keys.jpg, because I changed the name. (6) export... should bring up the file chooser in the same directory as funky-keys.xcf.gz, again with funky-keys.jpg by default. First of all, there is no export to dialoge, I assume those are duplicates of the same point. Why is it wrong to assume that the user wants to export to a file in the vicinity of the original file? And if that is wrong, you correct it, and it will make a better guess the next time. I don't think we should change the default path/name/type priorities in this particular situation. (7) after saving, there must be visible indication that the image is not changed since export. E.g. the * should go away from the title, or there could be an annotation in the undo history to show the filename, or the status bar could say exported to funky-keys.jpg in /media/thumbdrive6/typewriters The * should definitely go away after you save. It doesn't do that for you? If it doesn't, then that is another bug. What is the step-by-step in a new GIMP session? (8) if I am saving to a filename other than the CURRENT filename shown in the title bar, and the file exists, I must be warned and asked if I want to overwrite the file. I assume you meant to write .. I must be warned and asked if I want to overwrite the file when I do an Export to? If that is what you meant, then maybe that is a good idea. Peter, what do you think? If you literally meant what you write then yes it should definitely ask you if you want to overwrite a file that already exists and if it doesn't, then that is a bug. It seems to work for me. What is the step-by-step? However, a repeated export to the same file, with no intervening save as to change the filename, needn't
Re: [Gimp-developer] open/save/export
Simon Budig wrote: Liam R E Quin (l...@holoweb.net) wrote: [...] Experienced users are unlikely to want to overwrite the original jpeg, because they know it loses data. Well, no. The Export to filename Menupoint is exactly for the usecase that someone opens a jpeg, does some quick adjustments and fully intentionally wants to overwrite the original file, because he does not care about the full blown XCF data. The point is, that with the semantic change of Save to use XCF always (which is IMHO a very good thing) you lose this kind of non-xcf-load-edit-save possibility for quick and dirty editing. Which is why the Export to filename thing got added to accomodate for this. The problem that arises with this is though, that the user suddenly mentally has to deal with two not-really-but-nearly independant filenames and to predict what a keyboard shortcut will do you have to read the window title. I think I'd prefer a tighter coupling between the XCF filename and the Export-to filename, i.e. changing the XCF filename also changes the basename of the Export-to-filename. That makes a lot of sense. The coupling should include the full path too with none of the Untitled-1 sillyness. (Untitled should only apply to a newly created image that has not yet been saved.) Importing /path/foo.png should create an unsaved /path/foo.xcf with that in the title bar. Subsequent Save as png should automatically set the default file name to /path/foo.png . If gimp is going to force the user to work in xcf end move into the import export business, this seems to be the way it can be made as transparent and painless as possible. Such logic should be kept as simple and unconditional as possible. All attempts to do this or that (or something else again) depending on a number of criteria inevitably makes the programs behaviour inconsistent and unpredictable to anyone outside the team who wrote the code. I have seen this fundemental design error in so much software. Trying to be over helpful and second guess what the user really wants to do in an array of different circumstances ultimately fails because the program does not know what the user wants to de because it's only linked to his mouse, not his brain. Equally but more importantly the user does not know what the program wants to do because he does not know the ins and outs the the double-guessing algo it uses. Bottom line, trying to be too helpful ends up being unhelpful. I think that needs to be considered here when prioritising three of four possible policies for where to save/export a file. regards. Bye, Simon ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [wish] center on focused area on zoom out
The effect of this (fixed point of zoom) is that the relation to mouse when doing inout is preserved. Jernej pointed out that PaintShopPro behaves like I wished for, so they had a reason for this too. I think this is the main point from a GUI design angle. The GUI should be consistant in it's action. Scroll-wheel zooming in and out is a great feature for the most part. The point at which the behaviour changes and it jumps to one side is mentally disrouting and breaks work flow. It seems that there is an implicit assumption in the current behaviour that if the image can fit into the display window it absolutely must be centred. It seems that this assumption needs to be re-examined. Is this always the best behaviour? On opening an image it would seem a logical choice but on zooming out I would maintain that continuity of the mental focal point is the most important for usability and workflow. In this context whether the user wishes to ALSO centre the image in the window is a secondary and largely separate issue. This can be achieved by a shrink wrap for example. I'm glad this subject has come up because this is a constant annoyance when working close in on images. The initial zoom-in is generally a series of zoom-drag-zoom-drag operations. There is no reason why subsequently re-zooming to the same work area should be equally laborious. /gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Procedural call to undo?
peter sikking wrote: David Hodson wrote: That's true, but how does that make undo different from many other functions? undo involves user having a change of heart. a script cannot have a change of heart. No but it can have a conditional execution path dependant on the result of a previous command. resize image save test.png if (size of file) 4GB undo resize. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Procedural call to undo?
Rob Antonishen wrote: Now that could be useful. Call it GIMP-IMAGE-STATE-SAVE and -RESTORE possibly. Or push and pop.. Not undo. If push and pop, it should be limited to the state the image was in when the script/plugin was initiated. Though I'd appreciate examples of use case where programatic image state restoration would breake things. -Rob A. On 5/11/09, Stuart Axon stua...@yahoo.com wrote: Even if you don't have undo as such, it would be useful from a scripting point of view to save checkpoints, which you could revert to within the script. - Original Message From: gg g...@catking.net To: Chris Mohler cr33...@gmail.com Cc: gimp-developer@lists.xcf.berkeley.edu Sent: Monday, May 11, 2009 8:53:43 PM Subject: Re: [Gimp-developer] Procedural call to undo? Chris Mohler wrote: On Mon, May 11, 2009 at 12:31 PM, gg g...@catking.net wrote: peter sikking wrote: David Hodson wrote: That's true, but how does that make undo different from many other functions? undo involves user having a change of heart. a script cannot have a change of heart. No but it can have a conditional execution path dependant on the result of a previous command. resize image save test.png if (size of file) 4GB undo resize. Bit shouldn't that really be: get image size/depth calculate target image size if (target size 4GB) resize image ? I agree that Undo should be reserved for human use... Chris It is not the IMAGE size that matters it's the FILE size. Is there a function that predicts the final size of a jpeg file after compression ?? You may want a script to make a few tries (different compression parameters) and CONDITIONALLY back out the change as a function of the result. that was a trivial example to illustrate that a script may want to change it's mind. It also could be some external events over which the script has no control nor any means of predicting. You are presuming to know a hell of a lot about ALL possible circumstances in saying this is unnecessary. regards I think the whole point of keeping the undo history is that very minor changes can be saved with minimal overhead and quickly undone. Cloning the image could potentially be enormous. Undo is not _necessary_ even in the gui, it's just damn useful. I don't see why all scripts should be deemed to have absolutely no need of this. regards. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] why do I need babl to UNINSTALL gimp?
Hi, I just wanted to clean out multiple gimp installations and went to uninstall a gimp cvs build. make uninstall checking for gmsgfmt... (cached) /usr/bin/gmsgfmt checking for xgettext... (cached) /usr/bin/xgettext checking for iso-codes... yes checking for BABL... configure: error: Package requirements (babl = 0.0.23) were not met: Requested 'babl = 0.0.23' but version of babl is 0.0.22 Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively, you may set the environment variables BABL_CFLAGS and BABL_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details. make: *** [config.status] Error 1 Do I really need to pull babl , build and install it just to UNINSTALL Gimp ?? TIA. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] why do I need babl to UNINSTALL gimp?
Owen wrote: Hi, I just wanted to clean out multiple gimp installations and went to uninstall a gimp cvs build. make uninstall I am not that good at reading Makefiles, but I don't think uninstall does anything and you are just doing a make? Hence the requirement for a newer babl Thanks Owen, that would explain the error but I thought make reported something like no rule for target uninstall if it got fed crap. maybe there's some default target in the gimp Makefiles that matches a non existent target. :? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Shifting rotation grid with center of rotation: need help/feedback
Omari Stephens wrote: Hi, all I'm working on a patch which shifts the rotation grid so that a grid intersection always falls on the center of rotation. The simple use-case for this functionality is when doing a corrective rotation in a photo with a clear horizontal or vertical object. Maintaining an intersection on the center of rotation means that you'd _always_ be able to stick the center of rotation on one end of the straight object, align a gridline along the object, and be done. Currently, this is not always easily doable without futzing with the number of gridlines. My current rough-draft patch (against r28237) is up at: http://ocaml.xvm.mit.edu/~xsdg/stuff/gimp/shift_rotate_grid.v2.patch.txt At the moment I have a few questions: 1) Let C be the coords for center of rotation, and TC be the coords for the transformed center of rotation. At times, it seems like TC is up-to-date and C lags (such as when dragging the center of rotation with the mouse). But other times, C is up-to-date and TC lags (for instance, when adjusting one of C's coords with the spinbox in the dialog). This makes it incredibly difficult to make the offset always correct. I think this happens because gimp_transform_tool_grid_recalc() and gimp_transform_tool_transform_bounding_box() need to be called in differnet orders depending on where the canonical center of rotation coords are stored (C or TC). When you update the spinbox, the gimp_transform_tool_motion() callback calls gimp_rotate_tool_motion() (which sets C from the values in the spinbox), and then gimp_transform_tool_recalc(), calls ..._grid_recalc() and then ..._transform_bounding_box(). So, in this case, TC will be stale at the point when ..._grid_recalc() is called (since TC is updated from C in ..._transform_bounding_box()). When you move the center of rotation by dragging it with the mouse, however, it seems that sometimes ..._transform_bounding_box() is called without an accompanying ..._grid_recalc() call, which means that C is stale but TC is up-to-date. In particular, when this happens, C is temporarily set to the center of the image, which I find incredibly confusing. I'm not sure how or why this happens. Any suggestions for how should I fix this behavior so that it's correct in either case? 2) I want to only enable shifting when we're doing rotation (as opposed to shearing or scaling, for instance). This is as easy as clamping x_off and y_off to zero in gimp_transform_tool_grid_recalc(). From that function, how do I determine if the transformation is a rotation? 3) The bounding box is drawn in a different function. I would like to avoid splitting the shift logic across functions (or duplicating it in both). Any suggestions on how to keep the bounding-box aligned with the grid (including the shift offset), but still allow the bounding box to work when the grid isn't being calculated? 4) Any other questions, suggestions, or feedback? Thanks, --xsdg Hi, I looked at this centre shift issue a year or so ago. You may be able to find it the archive. I found accumulated errors were leading to the image tracking around a central point. IIRC some improvement was made by someone else at that time but since these base transformations will soon be migrated to gegl it was deemed not worth improving the existing code base in this area. I suggest you dig out that thread before investing too much effort. /gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP PDF export plugin
Sven Neumann wrote: Hi, On Fri, 2009-03-20 at 22:04 +0200, LightningIsMyName wrote: 1. How will the user create multi-paged PDFs? Should he choose different images, one for each page? (This sounds like the most reasonable way compared to other ways I thought of). Why would we want to allow the user to create multi-paged PDF files? Perhaps, before anything else, we need to clearly define what the purpose of PDF export is. We certainly don't want to provide a tool to create an illustrated book. That's what page layout applications are used for. Sven Indeed, what is the advantage of pdf export of a single image? Despite the current obsession with this format it is pretty clunky and inflexible. I don't see much point for a single image. PDF would just be a simple wrapper and this would best be done by and pdf editor that fully supports all the pdf features. It's unlikely gimp would want to maintain full functionality just to do this export. The other question is licensing of pdf. IRCC pdf viewing is allowed in a fairly liberal sense but creating pdf is what Abode make money on and retains the rights to. I could be wrong but that was my recollection. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] save + export...
peter sikking wrote: Liam wrote: I had a careful look at this: My own workflow for www.fromoldbooks.org tends to be, 1. scan image with xsane plugin 2. crop if needed 3. save as 306-svens-ankles-raw.png 4. either quit after doing several of these, or continue with one... 5. use levels, curves, rotate, flatten, and save as e.g. 306-svens-ankles-cleaned.png 6. spend up to an hour cleaning up the scanned image, under the same name I guess you realised by now that with the new attitude GIMP prefers that you do all this in xcf, so we can fully support you. Then you can Export to something you consider archival/future proof. Hi, there is a problem with this new attitude. Why does GIMP try to impose this you will work with xcf or die dictate? Sure xcf is a good format and has some useful features. However, if I want to open (and I mean open, not import) a png image make a couple of simple mods and save it, GIMP is getting in my way and trying to impose a one-size-fits-all way of working. Here I want to do some simple editing and save. I do not want to export to a format which the file already had before I opened it, neither be bugged about layers being flattened and compression ratios etc. All I require is open: edit: save , in original format with original options. currently I have to jump through hoops and probably delete an extranious xcf that got created along the way because of a temporary save I did to preserve an edit. This is uncomfortably close the MS approach of we know best so you'd better fall into line. Can't this be made less intrusive? regards. 7. make jpeg versions at various sizes, by 7.1 save as 306-svens-ankles-1.jpg resize image smaller (e.g. to 75%) sharpen, curves etc if needed 7.2 save as 306-svens-ankles-2.jpg undo the resize, sharpen, curves etc 7.3 resize image smaller (e.g. to 56.25%) sharpen, curves, etc. if needed, and save again... and so on, sometimes as many as 10 different sizes. So I don't want to have to re-enter the filename 10 times. we are helping you by keeping the same filename filled in as default in the export. you remind me here that we can even help you for the first export by filling in the filename of the xcf. you also remind me that it is not specified what the default file type should be for export (it cannot be xcf...) it is easy to define it as ‘same as last time’ but what will be the very first default? some truly open format? It's important to me that I can see when I saved something in terms of undo history / workflow. I rely on the * a lot, from when I last saved as PNG. But, it would be even better if Save and Export events appeared in the undo history (even though obviously undo would have to skip over them, you can't undo a save with most file systems!). the * can only help you when saving, that is to xcf. although Save and Export cannot be real undo list items (they are not targets or undoable), I can be convinced to annotate the undo history with the Save and Export moments. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] save + export...
David Gowers wrote: Hello, On Mon, Mar 9, 2009 at 10:09 AM, gg g...@catking.net wrote: there is a problem with this new attitude. Why does GIMP try to impose this you will work with xcf or die dictate? Because it has always been an XCF editor, not an anything else editor. Being able to modify images loaded from PNG, JPEG etc is just because people have created loaders which effectively translate PNG - in-memory XCF. Everything else, including PSD, is too underspecified/basic to handle GIMP images accurately. Sure xcf is a good format and has some useful features. However, if I want to open (and I mean open, not import) a png image make a couple of simple mods and save it, GIMP is getting in my way and trying to impose a one-size-fits-all way of working. That's because you cannot simply open a png, only import. And this has always been the case; what you object to is merely: making an idea that has been implicit in GIMP so far, explicit. IIRC, before (circa 2.2 ?) I could open a png/jpeg ... and save it, with the caveat of the flatten layers nag/warnings. Yes, it seems that in making it explicit it is becoming more cumbersome. Implicit had some merits. I get the feeling that all this import/export business is in danger of making heavy weather of it. Here I want to do some simple editing and save. I do not want to export to a format which the file already had before I opened it, neither be bugged about layers being flattened and compression ratios etc. I believe you are protesting your sudden realization of the inaccurate way you were thinking of things, here. All I require is open: edit: save , in original format with original options. Open, edit, export as XXX (where XXX is original file -- one of the actions described in the spec.), export settings could be taken from the info in the original file. Sounds good. If exporting to original name with original options is readily accessible from a top level menu without having to retype the name that would be pretty good. I am concerned about whether this would require you to 'confirm close' since the image would not be saved as XCF. maybe if the xcf was never saved as such and the work was saved to it's original name, the in memory xcf data could be regarded as an expendable buffer rather than a document that needs to be saved. Thanks for your reply. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] [Fwd: Re: Gimp license]
---BeginMessage--- Marcus Heese wrote: I've just contributed a few lines, too. However, I'm fine with GPLv3, too... I was wondering a long time that the GIMP hasn't changed the license yet. And I hope that the GIMP will stay with GPL in the future, too. Otherwise the developers should think about the name again! ;) ... *IMP best regards Marcus ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer I've always thought the .. or later clause in some gpl wording to be a bit of an odd way to licence something. While FSF seems to be doing a solid job until now I always worry about future GPLs getting knobbbled the way PGP did. If GIMP project decides to move to v3 would it be wisest to state specifically v3 rather than some arbitary unknown or later? This seems an unnecessary risk. /gg ---End Message--- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp license
Alpár Jüttner wrote: GIMP is GPL and has always been. If you don't like the GPL license, for whatever reason, then you should not contribute to this project. Interesting. I knew that GIMP developers must accept GPL as the license of GIMP, but it is new to me that they are also required like it. Regards, Alpar gimp is released under GPL, if someone submits thier work to the project they understand this and hence chose , of their own free will , that the work they submit will be distributed in this way. Most of those who contribute presumably see this as a positive thing rather than something they must accept. They re not required to like it but presumable actually do like it, otherwise it would seem foolish to contribute (unless perhaps they are being blackmailed , tortured or otherwise force to do so against their will). So , no, they are not required to like it, they can actually, really hate it and still contribute under duress. Next(?) time you submit a patch to gimp you may like add a note as to whether you accept GPL as a good thing or really hate it and accept being required to like it. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Feature proposal: Edit paths in external program
Sven Neumann wrote: Hi, On Mon, 2008-12-29 at 10:00 +0100, Iljoa wrote: It would be nice to have but getting this feature to work good requires quite a bit of work both on GIMP and Inkscape. How much work exactly? The point is that given the amount of active developers on GIMP we have enough feature proposals to work on for the next two decades. And each of those features appears more important than adding yet another way to exchange paths between GIMP and Inkscape. So the best thing we can do at this point is to ask the Inkscape developers to add a way to get a path back into GIMP easily. But I see also a problem: The paths in GIMP seem to support only a trackle of the svg format. What do you mean, a trackle of the SVG format? Can you be more specific about this, please? Sven SVG is not just a path.../path but a full blown xml spec that includes javascript and DOM. How much of that is handled by GIMP? I'm also unaware of the word trackle but I think the meaning is clear. /gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] strange tooltip meaning
On Sat, 18 Oct 2008 23:27:08 +0200, Sven Neumann [EMAIL PROTECTED] wrote: Hi, On Sun, 2008-10-19 at 00:06 +0300, Cristian Secară wrote: On the Filters - Distorts - Lens distortion... menu, the tooltip over the Lens distortion says Corrects lens distortion. Isn't this a mistake ? I am expecting that a distortion filter *distorts*, not corrects. The filter can be used for both. It can simulate lens distortion. And it can also be used to correct lens distortions. From what our users say, it appears that most people are using it to correct lens distortions. It would be cool if someone wrote a GIMP plug-in based on the LensFun project (http://lensfun.berlios.de/). That would probably be more useful when it comes to correcting lens distortions. Sven I seems to recall having pointed out a couple of years back that this should be on the enhancement menu. If that's what most ppls are doing with it, that would seem to substanciate my comment. In either case the tooltip probably should be corrected to indicate simulates or corrects lens distortion. /gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Python back-up files
On Sun, 28 Sep 2008 02:21:13 +0200, Chris Mohler [EMAIL PROTECTED] wrote: On Sat, Sep 27, 2008 at 6:16 PM, Samuel [EMAIL PROTECTED] wrote: Another question from me: When I write a plugin, my text editor (kwrite or kate) creates a backup file named plugin.py~. When I start now the plugin in GIMP, it is executing the backup instead the original. Hi, I think you should file a bug against kwrite and kate - while it's a good idea to create backup files, I see no reason why they should have the execute bit turned on (even if the file you are editing is executable). Chris I can see arguements for and against but that is irrelevant on this list. What would appear to be gimp related here is that it is executing a file ending in .py~ , maybe file name is irrelevant. What is the mechanism for gimp ? Does it execute everything in the plugin directory? (I would see this as valid approach on cross platform software since the idea of dots and file extensions has no meaing on linux/unix and should remain so). If that is the case, the correct solution is not to dump your backup files in the gimp pluging dir. The best solution probably being to disable dumb microsoft style automatic backups and backup your work as needed. Both the editors mentioned allow you to disactivate auto backups. Auto backups are overwritten every time you save so in reality they are virtually useless. There's much more chance over recovering from an error with cntl-z The sooner linux world stops trying to ape windows the better. regards. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] improving the tutorials - let's rock!
On Mon, 22 Sep 2008 03:30:03 +0200, Liam R E Quin [EMAIL PROTECTED] wrote: How about a Made for GIMP 2.6 icon to go on tutorials that have been checked? (or Made for 2.8) I hope one result would be that it would be easier to check the tutorials again next time round... Liam [Ankh] -- I think some indication of which version of gimp any particular guide is written for is nearly essential at this stage in view of the major rearrangment and internal changes. Older doc should probably have something added in a conspicuous place indicating either what version it related to (if that can be determined precisely) or a warning that it may be out of date and some features may have changed/moved/disappeared. Good idea, Liam. /gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] concurrent 2.4 and 2.5
On Thu, 11 Sep 2008 08:42:18 +0200, Sven Neumann [EMAIL PROTECTED] wrote: Hi, On Wed, 2008-09-10 at 11:26 +0200, [EMAIL PROTECTED] wrote: I have installed distribution's 2.4 and cvs . I built cvs with --preifix=/usr/local but there is some conflict with 2.4 which refuses to run having detected the conflicting library versions. http://gimp.org/release-notes/gimp-2.5.html mentions quite explicitly that this is not going to work. /usr/local is not a separate installation prefix. Sven Well that's probably the cause of the confusion, it does not _explicitly_ say a separate prefix not in the system PATH which would appear to be the key criterium. Separate presumes separatation from something that is not specified. I took it to mean separate from gimp-2.4 installation since that was subject. /usr/local is a separate prefix from /usr and is separate from where gimp-2.4 is installed. The problem seems to result from this separate prefix being in PATH. README says this: If you want to keep your older GIMP 2.x installation in parallel to GIMP 2.5, you have to choose a separate prefix which is not in your default library search path. This is also somewhat confusing in that it seems to refer to LD_LIBRARY_PATH. That's all probably obvious once you know but then the instructions are not for those who know. Maybe they could be 'explicit'. Now I have just let autogen.sh do it's default /opt/gimp and it's fine. The UI improvements are starting make Gimp a lot easier to work with and to discover. Excellent progress on that. Thanks Sven, Mitch, Owen and all those who replied. -- .*. /V\ (/ \) ( ) ^^_^^ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] gimp print dlg
Hi, where does the current (cvs) print dlg come from. It looks the same as the one used by ffox so I guess it may be gtk+ rather than gimp. Though it has many fancy features it lacks the simple on screen scaling and positioning that was so useful in gimpprint. Is there a way to build recent gimp to use gimpprint/gutenprint plugin for printing? I don't see anything that seems to correcpond in ./configure options. Thanks for any help on that. regards. -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp print dlg
On Wed, 10 Sep 2008 10:54:55 +0200, Michael Schumacher [EMAIL PROTECTED] wrote: Von: [EMAIL PROTECTED] Is there a way to build recent gimp to use gimpprint/gutenprint plugin for It is the other way round - you build gutenprint and tell it to create a gimp plug-in (if that isn't the default if it detects libgimp during configure, that is). HTH, Michael Hi, thanks for the explaination. I've checked and gimp-print is built with gimp option. Should that alter the dlg I get from gimp file print menu? BTW gimp print preview just zaps out (I'll detail that in another post). Thx ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] concurrent 2.4 and 2.5
Hi, I have installed distribution's 2.4 and cvs . I built cvs with --preifix=/usr/local but there is some conflict with 2.4 which refuses to run having detected the conflicting library versions. Here the beginning of ldd for 2.4 /usr/bin/gimp bash-3.2#ldd `!!` ldd `which gimp` linux-gate.so.1 = (0xe000) libgimpwidgets-2.0.so.0 = /usr/local/lib/libgimpwidgets-2.0.so.0 (0xb7e1a000) libgimpconfig-2.0.so.0 = /usr/local/lib/libgimpconfig-2.0.so.0 (0xb7e0b000) libgimpmodule-2.0.so.0 = /usr/local/lib/libgimpmodule-2.0.so.0 (0xb7e06000) libgimpcolor-2.0.so.0 = /usr/local/lib/libgimpcolor-2.0.so.0 (0xb7dfb000) libgimpthumb-2.0.so.0 = /usr/local/lib/libgimpthumb-2.0.so.0 (0xb7df2000) libgimpmath-2.0.so.0 = /usr/local/lib/libgimpmath-2.0.so.0 (0xb7deb000) libgimpbase-2.0.so.0 = /usr/local/lib/libgimpbase-2.0.so.0 (0xb7dd7000) libgtk-x11-2.0.so.0 = /usr/lib/libgtk-x11-2.0.so.0 (0xb7a79000) libgdk-x11-2.0.so.0 = /usr/lib/libgdk-x11-2.0.so.0 (0xb79f8000) libgdk_pixbuf-2.0.so.0 = /usr/lib/libgdk_pixbuf-2.0.so.0 (0xb79e) libgthread-2.0.so.0 = /usr/lib/libgthread-2.0.so.0 (0xb79d9000) libpthread.so.0 = /lib/libpthread.so.0 (0xb79c1000) bash-3.2#echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/kde/3.5/sbin:/usr/kde/3.5/bin:/usr/qt/3/bin bash-3.2#echo $LD_LIBRARY_PATH /usr/qt/3/lib I adapted the way I set this up last time but something did not follow. bash-3.2#which gimp4 /usr/local/bin/gimp4 bash-3.2#cat `!!` cat `which gimp4` #!/bin/sh #PATH=/usr/local/bin:$PATH #export PATH LD_LIBRARY_PATH=/usr/local/lib export LD_LIBRARY_PATH /usr/local/bin/gimp-2.5 $@ I don't see why 2.4 is pulling from /usr/local/lib Any help? Thx ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] concurrent 2.4 and 2.5
On Wed, 10 Sep 2008 13:12:42 +0200, Owen [EMAIL PROTECTED] wrote: Hi, I have installed distribution's 2.4 and cvs . I built cvs with --preifix=/usr/local but there is some conflict with 2.4 which refuses to run having detected the conflicting library versions. Here the beginning of ldd for 2.4 snip bash-3.2#echo $PATH I think all the paths are getting mixed up /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/kde/3.5/sbin:/usr/kde/3.5/bin:/usr/qt/3/bin ^^ before ^^^ bash-3.2#echo $LD_LIBRARY_PATH /usr/qt/3/lib It is picking up /usr/local because that is what you path has first (or before /usr/bin ) You are starting Gimp from a console? You need to set the PATH to see /usr/bin first and the same for LD_LIBRARY_PATH.to see /usr/lib first export PATH=/usr/bin:$PATH and export LD_LIBRARY_PATH=/usr/lib and when you start 2.5, do so from another console with the paths set to pick up the 2.5 libraries first. You should actually keep away from /usr/local, the various bashrc and profile files set up paths to include /usr and /usr/local and it can get confusing. Just build in /opt in accordance with the instructions for paths. Yes, it's the scripts that are prepending things , I'd have though /usr/local should come after but I'll need to dig to get the order corrected. I still don't understand what it's picking from /usr/local/lib since /usr/local/lib is not in path or ld_library_path and ldd shows it loading from /usr/local/lib first no /usr/local. I must have an incomplete idea of the loading mechanism. Your suggestion of /opt is probably the easiest solution. Thanks. (and Micheal too) regards. I adapted the way I set this up last time but something did not follow. bash-3.2#which gimp4 /usr/local/bin/gimp4 bash-3.2#cat `!!` cat `which gimp4` #!/bin/sh #PATH=/usr/local/bin:$PATH #export PATH LD_LIBRARY_PATH=/usr/local/lib export LD_LIBRARY_PATH /usr/local/bin/gimp-2.5 $@ I don't see why 2.4 is pulling from /usr/local/lib -- .*. /V\ (/ \) ( ) ^^_^^ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp print dlg
On Wed, 10 Sep 2008 19:16:36 +0200, Akkana Peck [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] writes: thanks for the explaination. I've checked and gimp-print is built with gimp option. Should that alter the dlg I get from gimp file print menu? Are you building in gimp-print then doing a make install? Is this the latest gimp-print from http://sourceforge.net/projects/gimp-print/ ? Check that make install is really succeeding. If you already have gimp's built-in gtkprint plug-in, and you also build gimp-print from the Gutenprint project, you'll probably end up with two different File-Print... menu entries. One of them should bring up the Gutenprint dialog, the other, the GTKprint one. As long as you're building gutenprint yourself, I'd recommend modifying their src/gimp/print.c: find the line that registers to N_(Image/File/Print...), (line 166 in the latest version) and change the name, e.g. N_(Image/File/GutenPrint...), Then you'll be able to tell the the two plug-ins apart and verify that your gutenprint plug-in is really getting installed. ...Akkana Thanks, a very good idea. I'm building 5.2.0-beta4 and the closest I can find is src/gimp2/print.c , sadly I don't find anything that matches the snippet you posted. What function is it in? thx. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] patch for scale-region.c
On Sat, 06 Sep 2008 00:22:58 +0200, Sven Neumann [EMAIL PROTECTED] wrote: Hi, while I see your points and I appreciate your comparisons of the results, fact is that the current code has bugs that are fixed by my patch. The most apparent problem is that the current code is using the 2-dimensional decimation routines even when downscaling only in one direction. To see this, create a new image, apply a standard grid on it using Filter-Render-Patterns-Grid and scale it down in one direction by a scale factor smaller than 0.5. The one pixel wide grid lines will become blurry. I don't think this is acceptable and so far the only choice we have is to apply either gimp-decimate.diff or gimp-decimate-2.diff as found on http://sven.gimp.org/misc/. So far I am in favor of applying gimp-decimate.diff. Unless someone objects and provides an alternative, I will commit this change this weekend. Sven Clearly trapping the special case of only scaling in one dimension is a worthwhile optimisation. That would seem to be a separate issue from fundementally changing the scaling algo. Could I suggest you break these two changes into separte patches. I had a quick look at the current code during the week and found it hard to recognise the lanczos in decimateLanczos2() . There seems to be some sort of gaussian filter being applied which probably accounts for the softening. I'm not sure this is necessary if reduction is indeed using lanczos since it is in itself a frequency filter. It may however been needed with the current code which appears to use fixed coeffs and therefore cannot presumably be a filter tuned to the specific scaling. In any case the results are quite good and the code seems stable in the limitted testing I've been able to do. I doubt I'll have time to get into coding any changes in the immediate future but if you can split the patch it would make developing a more rigourous filter easier in the future. regards. -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] patch for scale-region.c
On Sat, 30 Aug 2008 19:35:20 +0200, Alastair M. Robinson [EMAIL PROTECTED] wrote: Comparing Lanczos 3% old vs patched: lefthand building roof has bad moire effects that totally obscure underlying detail. Both sets of trees have much less obvious staircasing in the current code. There is an overall impression of sharpness in the new code but this seems really to be just high contrast artifacts with a lack of intermediate tones. I think these are aliasing artifacts caused by high-frequency components in the original image - unless you take steps to remove frequencies higher than the target sample rate before resampling a signal, aliasing will result. And as you noted, it affects my code too. That's exactly what lanczos does. Which is why you don't see any alising and you get smooth transitions. Whether the overall softness of the image is correct rendition and a neccessary feature or due to some minor errors in calculating the kernel may be worth looking at. If the code is close but not quite right some softening would be likely. /gg -- .*. /V\ (/ \) ( ) ^^_^^ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] patch for scale-region.c
On Fri, 29 Aug 2008 21:33:45 +0200, Sven Neumann [EMAIL PROTECTED] wrote: Hi, On Fri, 2008-08-29 at 14:15 +0200, Sven Neumann wrote: I also started to play with some enhancements on top of the patch we are discussing here. Using a steep gaussian filter instead of the plain box filter seems to be a good compromise. It's better at suppressing Moire patterns, at the cost of introducing a little blur. I have not yet finished this patch though and it has some issues. It works for the most common cases though and if someone is interested, it can be downloaded here: http://sven.gimp.org/misc/gimp-decimate-2.diff In the meantime this patch has evolved and now also includes decimation routines that only scale in one direction. But currently I am still in favor of the first patch (gimp-decimate.diff). Long-term we should try to get rid of the multi-pass scaling approach and instead implement the scaling properly. But for 2.6, I'd like to suggest that we apply gimp-decimate.diff. Sven Hi, I have not looked at this code in a while so I can't comment on how it does what it currently does, so I will only comment on the results you posted. I have compared the results by opening the images in separte tabs in Opera at 200% which allows them to be viewed in exactly the same position and switch back and forth with one click. This allows a direct comparison without moving the eye. Any differences become instantly obvious. This seems to be the most effective way for the brain to react to differences. Having looked at the 3% reductions which are probably the most critical (and make the most use of the binarly division in your patch) I not sure the results can be seen as superior. Comparing Lanczos 3% old vs patched: lefthand building roof has bad moire effects that totally obscure underlying detail. Both sets of trees have much less obvious staircasing in the current code. There is an overall impression of sharpness in the new code but this seems really to be just high contrast artifacts with a lack of intermediate tones. Observations are generally the same for the 3% cubic. Similarly, a quick check on 50% cubic , old and patched, again at 200%. Just looking at the top left corner there are two dots. The current code renders them nice and round whereas the patch shows fairly ugly artifacts. Admittedly, these artifacts are high contrast but I see that as a defect not a feature. Surely creating the grey tones necessary to smooth out the pixelisation is the aim of decimation code. Interestingly the blackfive code (thanks for sending the that algo Alistair) seems even harsher but does give some impression of sharpness by apparently accentuating edges. If this is considered from an analytical , data processing perspective I can't imaginge what the frequency responce of this multipass approach must look like. It's hard to see how multipass binary division plus a final decimation filter can preserve more information than one, well designed filter. Just a final obsevation to throw into the mix: I took the 3% lanczos and gave it 25% sharpen. The result is almost identical in overall appearance and contrast to the patched lanczos 3% but without the articfacts. I'm not sure what conclusions to draw from that but it's an interesting result. My weekends scheduled for finishing a P.V. panel heliostat, so back to work now. regards. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] gegl babl trouble
Hi, I just pulled a clean svn gimp and wanted to build with --prefix=/usr/local , I supplied this arguement to autogen.sh and it output both that prefix and --prefix=/opt/gimp , which I presume is the new default. I had the same behaviour from babl , although it did install where I requested bash-3.2#ls /usr/local/lib babl-0.0 libbabl-0.0.la libbabl-0.0.so.0 pkgconfig fpc libbabl-0.0.so libbabl-0.0.so.0.23.0 X11 However, now I try to build gegl it can't find babl: checking pkg-config is at least version 0.9.0... yes checking for BABL... configure: error: Package requirements (babl = 0.0.22) were not met: No package 'babl' found Why can't it see a correctly installed babl? /usr/local/bin is in $PATH. Thanks. BTW INSTALL says to run ./configure which does not exist, should this be corrected to say autogen.sh ? -- .*. /V\ (/ \) ( ) ^^_^^ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Proposal new default layout starting 2.6
On Sat, 23 Aug 2008 21:29:40 +0200, Alexia Death [EMAIL PROTECTED] wrote: and third, a bit of familiarity for the first time users(separate, 2 line toolbox) can not hurt. -- Hi, that's the second time you propose familiarity for a first time user. How can a first time user be familiar with anything? Or is this another Gimp should look and behave like Photoshop proposal? Although I like the aesthetics of your screen shot I find it a lot harder to assimilate icons in two columns than the existing layout. Since an early age I was trained to read in lines , left to right. I can scan lines but not columns. I doubt a new gimp layout is going to have enough impact on my neural networks to change that. It looks nice but it's hard work. regards. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] On-canvas text-editing GSoC project - report
On Wed, 20 Aug 2008 01:51:35 +0200, David Gowers [EMAIL PROTECTED] wrote: The UI team seem to think variation in right-click menu is confusing, but IMO several tools would benefit from it (for example, when you're painting fullscreen, you might want to change the FG color without needing to exit fullscreen to use one of the dockables.) -- Hi, I thought the basic function of a right-click menu was a context menu. By definition it should change to suit the context. Maybe the point about confusion is if it changes in what is basically the same context, like your example, where you are basically doing the same task but with a different window size. I suppose it could be conceivable to add some extra menu entries below what is already there but existing entires must be constant. I can think of several programs (XFE for one) that moves things around and it is very disrupting , I'm never sure where the paste entries is , for example. regards, ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] bug #464466: lanczos corner artifacts
On Thu, 07 Aug 2008 22:20:00 +0200, Nicolas Robidoux [EMAIL PROTECTED] wrote: A student of mine and I have put together a gimp plug-in which ENLARGES images using a method which is analogous to global cubic splines, that is, which gives results analogous to lanczos. Hi, in what way do you mean the results are analogous to lancsoz? Could you perhaps compare results of your plugin with the comparitive results on the kingfisher head shot? http://svenfoo.org/scaletest/133-9.html http://svenfoo.org/scaletest/133Z8g.png http://svenfoo.org/scaletest/133C8g.png and/or the pixel graphic: http://svenfoo.org/scaletest/133-8.html http://svenfoo.org/scaletest/133Z8g.png http://svenfoo.org/scaletest/133C8g.png these two images scaled to 133% seemed to be the best cases in that test group for differentiating cubic and lancsoz. It would be interesting to see your plugin results next to those tests. The originals are provided on those html pages. regards. -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] need help with bug #464466 (downscaling quality)
On Fri, 01 Aug 2008 13:51:02 +0200, David Gowers [EMAIL PROTECTED] wrote:
Pixel art ('block graphics'?) is a
pathological case for most scaling algorithyms, and no algorithym old
or new performed very well on upscaling image #8.
David
yes, this is a good test for scaling alorithms. I had not really
apreciated the nature of this image since, although pixel art, it does
have predominantly degraded edges so it is not quite the sort of block
graphic I was refering to. However, picking out some specific areas, it
does give some good information on the merits of different algorithms for
this kind of image.
Viewing the comparitive for 133% at 200% (in Opera) there is a noticable
difference between cubic and lanczos.
http://svenfoo.org/scaletest/133Z8g.png
http://svenfoo.org/scaletest/133C8g.png
opening these two in adjacent tabs in opera and flipping allows direct
comparison. This difference is quite marked.
Comparing directly to the original at 266% with scaled image at 200% there
is an impressive restoration of detail lost to pixelisation in the orginal.
The eyebrow, hair and eye are well enhanced as it the hand on the blue
figure. The staircasing on the knee and thigh of the yellow figure are
also well smoothed out, though not removed completely.
All parts of this image seem to have been noticably enhanced , I think
it's a good demonstration of the lanczos code.
Although downscaling is probably the more critical test (and the case that
was needing most improvement) it may be informative to add another
enlargement to some oddball ratio (say 3.14159) to see how the detail
comes out when the result is several times bigger.
BTW , has this code been ported to the rotation operation? IIRC, that was
a separte file that closely duplicated the scaling code. Maybe this would
be a good point to unify the two.
In any case I'm very pleased to see the lanczos results on this image.
Very impressive.
regards.
--
.*.
/V\
(/ \)
( )
^^_^^
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] need help with bug #464466 (downscaling quality)
On Wed, 16 Jul 2008 17:15:38 +0200, Liam R E Quin [EMAIL PROTECTED] wrote: On Wed, 2008-07-16 at 22:14 +0930, David Gowers wrote: The one thing I definitely can't do is * Host webpage. I can do that if you want, although gimp.org would be better. As long as it's under a gigabyte or so. Here are some images that may help show some problems -- colour photos tend to hide problems, partly because the eye sees the subject more easily and auto-corrects flaws, and partly because the hardest thing for rescaling is often preserving both texture and sharpness. Of course, most people are working with colour photos these days...) I posted some good test images when I was working on the lanczos part of this code and the rotation distortions. Concentric circles and the like. These geometric patterns make any defect instantly visible whereas it may not be obvious in one operation on a photo-like image. care should be taken not to assume the criteria is one or two simple ops on photos. Gimp vision specifies graphics as well as photos so defects in geometric shapes are highly relevant. I also posted a woodpecker photo that had a near horizontal beak section. I found this was a very sensitive test for staircasing defects that may be relevant here. Search bugs for lanczos or rotation to find these bug reports containing attachments. regards. For potential problems with vertical artifacts, see the 1600x1200 image at http://www.fromoldbooks.org/Green-ShortHistory/pages/0187-Remains-of-Cloisters/ (I had to resize it to 1024x768 using cubic and then sharpen) The 1518x916 one at http://www.fromoldbooks.org/YouthsInstructer/pages/072-New-Post-Office-London/ has near-horizontal lines which are difficult. http://www.fromoldbooks.org/YouthsInstructer/pages/181-Dunluce-Castle/181-Dunluce-Castle-q59-1447x923.jpg has diagonals and is an RGB image instead of grayscale. http://www.fromoldbooks.org/ThomasBewick-WoodEngravings/pages/30-the-horse/1790x1307-q75.html is a fairly clean woodcut. I have some much larger images too if you want them. Liam -- .*. /V\ (/ \) ( ) ^^_^^ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Image color representation?
On Fri, 27 Jun 2008 17:07:32 +0200, David Gowers [EMAIL PROTECTED] wrote: Hi solar, On Fri, Jun 27, 2008 at 11:32 PM, [EMAIL PROTECTED] wrote: On Fri, 27 Jun 2008 03:02:01 +0200, David Gowers [EMAIL PROTECTED] wrote: and is no longer required in today's world of fast CPUs with fast FSBs, large memory, and huge hard drives. Easy on the sweeping assumptions here. Embedded systems are in exponential growth right now and correspond in performance to what you are quickly writing off as old and decrepid hardware that is best ignored. Many embedded systems are reaching a power that allows them to be used for image and even video (CCTV) applications. It's unlikely, though not impossible, that you'd use such a system for GUI image manipulation but Gimp could conceivably be useful here for batch processing images or other tasks. Be careful not to assume all target systems are like your average desktop PC. GIMP doesn't run on embedded systems AFAIK (mainly because of its minimum screen resolution requirements.) In any case, what you said above is true and unrelated. GEGL seems a much better choice for batch manip generally, however even if you would use GIMP, nothing would force you to use high bitdepths.. GEGL allows you to make different versions of an operation for different data types / colorspaces, so you would perhaps need to make 8bit-optimized versions (more likely, GIMP would implement these itself already, since it's a common data type). The difference is that GIMP needn't make that assumption, and thus the overall application is more flexible, accommodating different color spaces and color depths in the one application transparently. In short: optimization reflects an underlying assumption, and the assumption that 8bit is the only efficient choice is no longer true, therefore the optimization of assuming 8bit is no longer appropriate. David Hi, thanks for the reply. IIRC the original comment here was about removal of a structure used for storing 8 bit colours. Maybe that structure should be maintained as a build option. I agree about assumptions. My concern was that the assumption does not become: and is no longer required in today's world of fast CPUs with fast FSBs, large memory, and huge hard drives. today's world is much broader than intel based PCs. regards. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposed solution for: protection from protection from data loss
On Fri, 2008-06-13 at 18:21 +0200, [EMAIL PROTECTED] wrote: The issue of Export/Save/data-loss-protection is in my regard more of a bug which should be fixed as soon as possible than part of UI redesign. As with any fix this might be superseded by a more general solution later on. This is definately not a bug. If you chose to save to a lossy format like jpeg you opt to eliminate some information from your image, you reduce the data , it a trade-off choice for the compression you get. If you chose png or another non-layered format you won't get your layers saved, etc. If you save to gif you only get a palette of 256 colours. Gimp does all these things correctly. It is aimed at a competant user base, it does not try to be a beginner's guide using different formats. I see no sense in dramatising this as data loss. -- .*. /V\ (/ \) ( ) ^^_^^ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposed solution for: protection from protection from data loss
On Thu, 12 Jun 2008 08:36:39 +0200, Sven Neumann [EMAIL PROTECTED] wrote: Hi, On Thu, 2008-06-12 at 02:09 +0200, [EMAIL PROTECTED] wrote: No, i'm thinking of the case where you saved those 25 steps to a jpeg and the next day, sitting in the plane to your customer, you discover that this curve should be tweaked a litte bit more. That is exactly why JPEG should not be offered as a save format. Saving to a JPEG file is clearly an export. No one will be surprised that an exported file can't be edited again. The user needs to save the file to XCF (or whatever the next generation file format will be called). Sven Hi, I agree there is a certain logic to that approach but it should not involve constant importing and exporting as extra steps if working on a foreign file format, png for example. If open png becomes an import then save will duplicate the file as an xcf unless it is explicitly exported again. There's a danger this could all cause a lot of duplication of large files and yet more user interactions to a simple task of opening, changing and saving an existing image , which will almost certainly not be gimp's native format. Anyone wanting to undo changes made to a lossy format like jpeg clearly has no understanding of graphics formats anyway. This request does not even apply to gimp's target user base. If it becomes possible to maintain an undo history across gimp sessions in the native format that would be a nice feature. Beyond that the user had better learn what the characteristics of the different formats he is using are, and the value of keeping backups of different stages of one's work. /gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] More intelligent user protection from information loss
On Sat, 07 Jun 2008 19:46:24 +0200, Alexia Death [EMAIL PROTECTED] wrote: On Saturday 07 June 2008 20:01:17 Akkana Peck wrote: Alexia Death writes: I'm going to echo my support for this. The nags on saves are counterproductive. And often they're not even right -- e.g. The image has transparency, flatten? shows up on anything with an alpha channel even if every pixel is fully opaque. All those dialogs do is train the user to click OK without reading. Exactly! Too many friendly comfirmation dialogues and we find ourselves in MSland where the user just goes yes.. yes.. yes.. without even reading. One big problem I have with my software is a user reports an issue and I ask if there was not an error message. Err , maybe I'm not sure... I think so, I did not read it. This is all a result of MS dumbing down the user. All the pointless confirmations like you just pressed cancel , are you really, really sure you meant cancel? Would you like to try again? just anesthetise the user to whatever pops up. So. first thing to realise is that your user is not a complete imbecile (which is the premise of MS). If the user choses to work in png and it does not have layers we don't need to bug him at every turn. He won't lose his data it will just be less editable next time. Second, if we know the only way to work is xcf it is not the function of gimp to badger the user into submission if he does not want to user that format for whatever reason. Once again, gimp claims to be top end this and that , not grandma's tool for removing red-eye from her birthday snapshots. We should credit the user with some intellegence. Things like this just generally get in the way. Exactly... Witch has bitten me in the ass a few times... Namely the bizare confirmation to save a layer mask pops up right exactly before that. That's another bizare thing about saving... And since the number of dialogs varies between formats has been *click* *click* *click* Close, load Bah! Mask. How often would someone need to save just the mask? How about having a separate save option for that in the menu? -- Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer -- .*. /V\ (/ \) ( ) ^^_^^ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] A question on Gap -frame modify
On Sun, 11 May 2008 18:28:00 +0200, Akkana Peck [EMAIL PROTECTED] wrote: Alchemie fotografiche writes: 1.a # for bourne and ksh users: GAP_DEBUG=y export GAP_DEBUG 1.b # for csh users setenv GAP_DEBUG y Now i don't know if i am a bourne, a ksh, or a csh user, i just know (and not as expert) how to use the terminal of my distro Ubuntu Hardy Heron. If you're a Linux user and you don't know (haven't changed it explicitly), then you're a bash user, which uses the same syntax as Bourne shell. So use 1.a. ...Akkana One thing is fur sure with linux is there's not ONE answer. echo $SHELL should give the console login shell XTERM_SHELL may be different. Linux has more shells than a desert island beach. Each distro has it's own prefs. ;) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] sharefonts dependancy?
On Thu, 08 May 2008 04:36:09 +0200, Akkana Peck [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] writes: This seems pretty marginal usage. Can anyone advise if removing sharefonts will break fu or any other parts of gimp? The freefonts and sharefonts packages disappeared from Ubuntu and Debian quite a while ago (years). Kind of a shame -- there were some nice fonts in those packages. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer you should still be able to find them without counting on apt-get or whatever bunty uses. A quick google finds this: http://linux.maruhn.com/sec/sharefonts.html you should find something there that fits. Probably an rpm . fonts dont need compiling so it's just a case of checking they unpack to the right place (and reading the shareware licence). getting back to the point of the post , does gimp require this package to work correctly? TIA. -- .*. /V\ (/ \) ( ) ^^_^^ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] sharefonts dependancy?
Hi, gentoo devs have just realised sharefonts is incorrectly labelled public domain in thier package manager and is being installed without the user being aware of the licence. They intend removing it. http://bugs.gentoo.org/show_bug.cgi?id=218288 One package that seems to use it is gimp. on http://www.gimp.org/docs/userfaq.html it says The base script-fu package makes extensive use of the freefont package, and at least one font (AlfredDrake) from the sharefont package. This seems pretty marginal usage. Can anyone advise if removing sharefonts will break fu or any other parts of gimp? TIA. -- .*. /V\ (/ \) ( ) ^^_^^ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp memory leak
On Mon, 21 Apr 2008 20:58:36 +0200, Andrei Simion [EMAIL PROTECTED] wrote: Hi, I previously reported a memory leak in Gimp 2.2. I was told to install version 2.4 and the issue doesn't go away. The problem is that I discovered something even worst and it does take place in both 2.2 and 2.4. If one runs a Gimp-Perl script for a number of times, enough to use the whole physical memory, then the Gimp server crashes, it does not create the swap. That's it, no swap file is created. I think there may be a configuration issue. If a test script is needed I can provide it. Thanks, Andrei That would certainly be worthwhile. pls post. /gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp-Perl memory leak
On Sat, 29 Mar 2008 23:26:34 +0100, Andrei Simion [EMAIL PROTECTED] wrote: If I show you a 20 lines script, then you'd have to generate the image maybe a million times to actually increase the swap. As Kevin said, there may be a leak in one of the method calls inside the script. And there are 104 calls. Andrei I think that's the point. It's your task to find out which (if any) of those 140 calls is causing a leak. If you can demonstrate a clearly defined reproducible problem it will get dealt with. If the short script needs to run in a loop that can be arranged or the script can repeat the action if that is what is causing the problem. It's also possible that in simplifying the script you will find an error you have overlooked. In my experience, there's no better way to find a bug in your own software than to draft a detailed bug report about it being due to the other software you are using. As Sven said , there is little point in continuing to discuss this until you can provide something clear and reproducible. I have 630 lines with 140 calls that has a bug but I cant show you clearly will not get dealt with. /gg -- .*. /V\ (/ \) ( ) ^^_^^ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp-Perl memory leak
On Sat, 29 Mar 2008 18:24:59 +0100, Sven Neumann [EMAIL PROTECTED] wrote: Hi, On Wed, 2008-03-26 at 22:11 -0400, Andrei Simion wrote: I run Gimp 2.2 on a Red Hat machine. The Perl scripts delete the images that are created by using gimp_image_delete. Even so, the swap file is created and it inflates significantly. For instance, after creating 250 images its size is of 2.7 MB. That is not much and all it shows is that the image processing you are doing is using more memory than the configured tile-cache-size. I am not sure if I understand your problem at all... I think as Bill pointed out that was a typo, it should have read 2.7GB, I believe that was confirmed. I would be interested in eliminating the swap file or at least limiting its size. I think it should resize itself, but this doesn't happen. The swap file only resizes itself when tiles at the end of the swap file are freed. So you may have to free all tiles before the swap file resizes itself to zero. If if doesn't do that, then your script leaks an image or a drawable somewhere (or it calls a function that leaks). Sven I agree there's not much point in having a complex script like 630 lines of proprietary code and reporting it as a GIMP bug. If there is an leakage issue here , that this rather extencive use is bringing to light, it certainly ought to be fixed but a simple test case that can be published is needed. I think Kevin Cozens, who is familiar with the script, is looking at that. /gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] ?no image? window: progress...
On Fri, 28 Mar 2008 08:54:59 +0100, Sven Neumann [EMAIL PROTECTED] wrote: Hi, On Thu, 2008-03-27 at 15:31 -0300, Guillermo Espertino wrote: About the graying out toolbox, dockers and elements not used when no image is open, I think it breaks a functionality that is already present in gimp: the ability to custumize the interface (moving dialogs to dockers, changing the dimensions and position of elements, etc.) That's, imo, a regression. Having to open an image to be able to customize the interface adds an extra step that has no purpose. You are making some wrong assumptions here. The toolbox is fully functional and so are the docks. Nothing prevents you from doing all the things that you could have done without an image opened. They do all still work and will continue to work. so why are they greyed out ? it is a fairly universally established metaphore that greyed out means disabled. I dont think they should be disabled but the current situation seems to be niether on nor the other and in being a non standard state will confuse the user (as the earlier comment demonstrates). If they are active and have a ligitimate function in this context why are they grey? /gg Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer -- .*. /V\ (/ \) ( ) ^^_^^ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Splash Screens GIMP 2.6 from Dutch GIMPers
On Tue, 11 Mar 2008 03:17:23 +0100, Bill Skaggs [EMAIL PROTECTED] wrote: Leendert Visser [EMAIL PROTECTED] wrote: The members of our Dutch GIMPclub (http://www.dutchgimpers.nl/) have made splashscreens for GIMP 2.6 in a battle. It's great to see all this talent and enthusiasm going into creating Gimp stuff. The Gimp web page doesn't really have a place to put these, but I think it would be very nice if you made the best ones easily available to your users on your web page. (My favorite is #17, except for the word professional.) -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer what images ?! all I see is a forum in a language which I know just well enough to say I don't want to buy any shit , sod off! , NO really , sod off! . Any chance of a link to the images you'd actually like us to look at? /gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] no-image-open redux
On Sat, 08 Mar 2008 08:47:14 +0100, Laxminarayan Kamath [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] [EMAIL PROTECTED] wrote on Sat, Mar 8, 2008 at 6:26 AM : Right-click : remove toolbar for those who find it superfluous a small [x] button on top right of the toolbar might be better. Most people are used to Right click == context menu behaviour. The toolbar disappearing would freak them. Of course, the close toolbar can also be an option in the context menu that could appear when you do a Right Click . Sorry if my post was not clear, I was meaning that rightclick popped up something including the choice to remove the toolbar. This is how Opera does it, which I why I suggested looking at Opera. Obviously just zapping the toolbar on rightclick would be very disrouting. -- .*. /V\ (/ \) ( ) ^^_^^ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] no-image-open redux
On Sat, 08 Mar 2008 04:02:40 +0100, William Skaggs [EMAIL PROTECTED] wrote: Also for what it's worth, I've been a bit worried about including a toolbar like the one I showed, precisely because users who find it useful would want to have it available even after an image has been opened. Hi, that worry could be got around by doing just that , make it available. Right-click : remove toolbar for those who find it superfluous and want to recover the land rights. Opera , for example , has miriad panels and bars available with a resonalbe subset on by default (most of which I bin rapidly to get things the way I like to work). This config is maintained next time I use it and gives me exactly the layout I find efficient for my work load and way of doing things. Right-click on any toolbar or panel gives acces to a global configure toolbars situation. Another useful feature in Opera setup is make everything visible while selecting the elements you need. This is a horrible clutter (since this is not a work mode) and allows you to see all that is available and keep the bits you need and avoids clicking things on and off to find out what they are called. I think Opera's solution is a good example of presenting a very complex set of tools, panels and windows that cater for many different user senarios whilst maintaining almost complete flexibility of screen layout. Since Gimp UI is similarly a constant challenge of screen space vs function accessibility Opera setup may provide some useful ideas. /gg -- .*. /V\ (/ \) ( ) ^^_^^ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] change layout of mode menus?
On Tue, 19 Feb 2008 08:53:16 +0100, Sven Neumann [EMAIL PROTECTED] wrote: but for almost all users and almost all use cases they are unnecessary clutter and make the menu more difficult to use. There's a tradeoff here between being useful every once in a while for a very small minority of users and being in the way for everyone almost all of the time. Slight over statement about making a menu difficult to use! I used Gimp for years without even realising they were a tear off, I thought it was window decoration at the head of the menu. They never obstructed my usage but once I found out what it was I found it very useful. I also think we need to be very careful about such hand-wavy hypothetical statements about how many users do or don't use something. Even now Peter has done some user observation which is valuable, the sample size hardly allows extrapolation of the results to the whole user base. They are a very useful shortcut to the one or two things that a specific work load requires but find them selves buries 3 levels deep in a very crowded menu hierarchy. One would not want to leave them sprinkled liberally around but they do provide a valuable time saving mechanism for tasks which will be as different as each users job. My particular use is Edit | Paste as | Paste as new. This I use all the time. In 2.2 it is on the edit menu, so click-drag-release. Fine. Now all that zigzagging to get the extra menu is a major annoyance. A tear-off for this tiny menu would be great but I no longer see any tear-offs. Maybe I need to spend time finding how to get them back. In any case that's just an example , another guy will want another sub-submenu all the time. My main critisism of tear-offs is the lack of discoverability. The toilet-paper metaphore is less than obvious unless you've met it elsewhere. regards /gg -- .*. /V\ (/ \) ( ) ^^_^^ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] change layout of mode menus?
On Sat, 16 Feb 2008 05:55:33 +0100, Akkana Peck [EMAIL PROTECTED] wrote: Liam R E Quin writes: Seems to me that probably most people will use at most a couple of the layer modes in normal use, so maybe putting the top 7 on the menu and having a more modes submenu is a possibility. Eek, please no! Often the best way to use layer modes is to go down the list one by one, which would become even worse if you had to click through a more submenu each time. Bad enough to have to go to the bottom of the menu then wait for it to scroll. Personally I'd like Bill's side-by-side mode menu, just because it would be faster, and a shorter distance, to get to most entries. But Sven does have a good point that it implies there's a connection between each side-by-side pair of modes. Bill wrote: I don't think I have to persuade anybody that this is less than ideal from a usability point of view. The question is, can we do anything to make this better I don't have a great solution, just a few specifics the gtk widget doesn't do well that I wish the modes menus could handle better. Like the fact that clicking on the button pops up the menu, but not always with the current mode selected -- sometimes it's the mode above the currently selected one, so I can't just arrow down once and assume I'm on the next mode -- I have to look at the current mode before I click, then choose the next one explicitly. And I wish there was a faster way to select them by keyboard than the current click on the button then use up or down arrow ... I wish I could type ad and be on Addition right away. ...Akkana Yes Bill's screenshot shows that huge gap at the top which is a another gtk widget defect. All of these points seem out of reach to Gimp so long as it is restained to use these widgets (GTK+ is notoriously refractory to change or requests from outside). If there's need for functional change the only possiblity is probably for gimp to have its own menu widget, which could be forked from the existing code. This menu is overloaded and more clicking and jiving would not make things easier. Maybe the GUI guys could look at why there is so much content here. Are there maybe different use categories that are all getting called modes and so getting grouped together when functionally they could be separate? I have not looked at this in detail but my gut instinct is that this has grown and evolved and now there's a need to take a step back and look at structure rather than remain concentrated how to change the menu. regards, gg. -- .*. /V\ (/ \) ( ) ^^_^^ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
