Re: [Gimp-developer] A modest proposal...
On 09/05/11 10:45, Mikael Magnusson wrote: > On 5 September 2011 09:18, Noel Stoutenburg 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 Miranda: >> 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 Ehni >>> >>> 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 inator: >>>> 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 On 04/17/11 08:31, Michael Grosberg wrote: > Ofnuts 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 yadav 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 and Sharpening
On 17/12/10 20:23, Liam R E Quin wrote: > On Thu, 2010-12-09 at 09:35 +1100, Jan Smith wrote: >> Hi, >> >> What are the best GIMP tools for sharpening? >> >> Is there a time when someone would use Sharpen instead of Unsharp Mask? To >> me GIMP's Unsharp Mask has a better range and control. > > For example, after down-scaling an image, sharpen of 20% can work well. > Unsharp tends to introduce artifacts if overdone. Yes, I recently had an image, badly lit photo of a page of text that was difficult to improve with unsharp. Basic sharpen worked better. Unsharp is not always the better filter. /gg > > After scanning a greyscale engraving I sometimes do a gaussian blur > followed by a sharpen at 80% or so. THis works better than > colours->threshold if you're going to scale down the image. > >> Will Wavelet Sharpen be included in GIMP 2.8? I find the Luminance setting >> gives even better results than Unsharp Mask. > > Which one are you using? It's not so much the goal to reduce the > number of plugins as to get rid of bad ones and replace them > with better ones.. > > Liam > > > ___ 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 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 11/24/10 17:48, Øyvind Kolås wrote: > On Wed, Nov 24, 2010 at 4:25 PM, Bill Skaggs wrote: >> Maybe it would help to have a general explanation of the principle behind >> the filter. >> >> The basic idea of the Unsharp Mask is to enhance the difference between the >> original image >> and a blurred version of it. The algorithm first blurs the image, then >> calculates the difference >> between the original image and the blurred version, and then alters the >> original image by >> moving each pixel farther away from its blurred value. >> >> The convolution is simply a way of blurring the image. There are countless >> ways of >> doing a blur -- the filter is using a rather crude approximation of a >> Gaussian blur, which >> is the most commonly used blurring algorithm. > > In GEGL unsharp mask is implemented at a higher level of abstraction > than low-level filters and reuses gaussian blur directly, thus speed > improvements to gaussian blur in GEGL will also benefit unsharp mask > directly. See > http://git.gnome.org/browse/gegl/tree/operations/common/unsharp-mask.c > this version of unsharp mask can already be used in GIMP through the > GEGL-tool, it would probably be good if the unsharp-mask in GIMP was > properly replaced with the GEGL one. > > /Øyvind Kolås Hi Øyvind , congratulations on this solid body of work in designing and building the gegl library. I'm sure it will have a lot of benefit as gimp is slowly migrated to use it. It gives a great opportunity to restructure a code base that has to a large extent grown more by evolution than design. There always comes a point where things need a good shake down. I'm sure gegl migration will provide that opportunity. For unsharp filter , yes it does seem considerably quicker at applying the filter to the whole image than the existing gimp filter but unfortunately it has the do the whole image all the time for the preview. Wouldn't it be better to have a preview window similar to the existing gimp preview which vastly reduces the amount of work needed for a preview and also lets the user focus on a particular zone of interest in the image. Most images have a focal point or some other critical area where any effect needs to be optimised. A shot of a person this will nearly always be the face. How it affects the grass behind the subject is often of much less interest. Being able to work on a close up of a critical part is very valuable. I think the preview is doing far more work than is needed and with high quality images being large this can be quite a drag in previewing different parameter values to adjust the effect. The comment I made earlier about the existing preview and the benefit of caching when flipping the preview on and off applies here also. Even more so really since it is processing the whole image. On a larger image it is simply not possible to flip preview on/off to directly compare the two. It can take 10s to process the image but it needs to be fast. The eye (or the brain) is very good at picking up the slightest difference where an image if flipped like that and it is a useful technique to be able to compare them directly. A couple of quick points in passing: 1/ why is there no threshold slider? How is the threshold determined? This can be a useful control. 2/ I find the slider titles and hint texts very unclear. Std deviation is too specific to the coding implementation and is no help to someone needing to process an image. The hint does not really help clarify. std dev is scale factor , yet scale is strength :? The old "radius" seems clearer in terms of what it does to the image (that there is not a radius in the code is irrelevant). The old "amount" was a pretty unhelpful, muddy term but maybe simply "sharpness" would be better than scale. After all this is all about sharpening the image. Could I suggest : radius : range of the effect sharpness: intensity of effect threshold: sensitivity to detail It looks like the underlying code has now reached a maturity where it could be used full time but I feel that there is a slight regression in the level of control of the parameters and the preview which is, of course, very important in terms of usability. regards, 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] 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/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] GIMP & GNU GPLv3/LGPLv3 in general
On 11/22/10 11:04, Michael Schumacher wrote: >> Von: Christopher Curtis > >> *** (Sven, Mitch) *** >> >> This LICENSE text should probably be updated as 'Section 2' of GPLv3 >> doesn't talk about aggregations - it's been moved into section 5. It >> might also be useful to address this issue directly as the GPLv2 is >> generally well understood to allow command line usage as an >> 'aggregation', but GPLv3 seems to muddy this distinction. > > At the moment I'm not even sure if GIMP should be licensed under GPLv3 > without a much better understanding of the license. > For example, the fact that it is now impossible to use GPLv2-only libraries > in plug-in wasn't considered at all. It's not such much the fact that we > can't use them anymore, rather the problem of no one even thinking about it > when we changed the license version to v3. > > I have contacted the Freedom Task Force of the FSF in order to get help, and > they requested more details. Unfortunately my spare time (or the lack > thereof) didn't allow me to write a reply yet. > > > I'd be glad to learn about any additional side-effects of a GPLv3-licensed > GIMP (note that libgimp* is licensed under LGPLv3) that may surprise us - but > please base them on actual FSF information and not mere speculation. > > > Regards, > Michael I did suggest caution when the licence upgrade issue was raised originally. It seems a bit late to start considering whether it has any "side-effects" now. Maybe someone should have read it. /gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] distributing gimp with another program
On 11/21/10 19:06, saulgo...@flashingtwelve.brickfilms.com wrote: > * The user needs to be able to substitute their own version of GIMP > for the one provided by you. If you are providing a modified version > of GIMP, your program's use of GIMP must not rely upon the > modifications you've made. I don't see where you get this part from. Anyone is free to make any modifications as long as they release them under a compatible licence and provide full source code etc. If their other code works with the modified gimp in a GPL way where do you see the requirement to make if function with some / any other version of gimp that may be available previously , now or in the future. This does not seem to make sense. This would be equivalent of saying no one (including the gimp project) could make a script that only worked with recent gimp features. I'm not aware that GPL gives the project special rights to modify the source above the rights of anyone else. Please clarify if I've missed something. /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, 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
[Gimp-developer] Blocking for...@gimpusers.com
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 address for...@gimpusers.com Would it be a best to simply block this address? Anyone wishing to discuss gimp-devel can sign up here and join the list. Letting users spam the list with inane comments form a blog is probably not productive. A request could be made to remove that from the blog but bouncing that address would probably be quicker and easier. regards, 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/16/10 14:07, photocomix wrote: > On Sat, Nov 13, 2010 at 9:13 AM, Martin Nordholts wrote: > >> You can't know for sure that no one uses this plug-in in some script >> somewhere, and if we don't have a good reason to break our plug-in API, >> we don't do it. Impatience is not a good reason :) > > In this case i'm ready to bet 100 Euro that till now any bundled or even > third party script or plugin has Van Gogh as a dependency, > > > > i see most on replies are focused on the general matter > > But this IS a big exception, it is a insult to the Gimp product vision that > such filter is ,after 14 years that nobody use , and not because is too > complex but because is too crappy to be used > > More > 1)from 14 years this filter is misplaced in a totally wrong gimp menu > (Artistic submenu in filter but the filter has nothing to do with a artistic > filter > Would fit better in a RENDER menu > > 2)IT is misnamed the effect has nothing to do with Van Gogh, or any other > painter,nothing to do with a paint or draw effects. > Obviously 1 is consequence of 2, > since was misnamed as "Van Gogh" somebody tough was a artistic filter, so > ended up to be not only in gimp by mistake for 14 years but also from 14 > years mislabelled and misplaced > > And no i will not report to bugzilla because as no bug to be reported > It is impossible prove that doesn't work properly since is impossible guess > what should do > > The only BIG bug to report is the fact that such thingy is still in Gimp > > PS > If has to be preserved till 3.0 i may hope at least to be relabelled,moved in > the right submenu and with a more descriptive tooltip ? > > as example > CRAPPYFIER -tooltip_ this filter will replace all the pixels of your image > with crap > I can't recall having used this filter but since this seems to be such an important (!) issue I had a try on a randomly selected photo. default settings just seemed to give a slight blurring. Not especially interesting but nothing to start a war over. Then taking the time to experiment a bit, I selected convolve with white noise and upped a couple of parameters. The effect was somewhat like an impressionist rendition of my scene though with a bit too much regularity in some areas. So at this point I recall that Van Gogh was an _impressionist artist_ and that perhaps some of what this filter can do is intended to look make the image look like an impressionist painting of the subject. Hence V.G. and the "artistic" submenu. I don't have the time to fully evaluate what it can do since it seems to have a lot of parameters. Since the subtly of the effect seems a bit unfair on V.G. perhaps it should just be called "impressionist". Artistic does seem as reasonable a place as any. The help bubble seems to have been written long after that filter was written and probably by someone who did not understand what it did and could not be bothered to find out. The comment was probably done light-heartedly and maybe ought to be made more meaningful. As for "crap, crap, crap . etc" get a life as they say. You don't like to filter don't use it. This is not going to be a major issue at the next presidential nor is it a major issue for 3.0 Stop wasting everyone's time. There's plenty to be done on Gimp for things that actually _matter_. End of story. ___ 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
libxcb-render.so.0 => /usr/lib/libxcb-render.so.0 (0x7fde1ba29000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0x7fde1b80d000) libpcre.so.3 => /lib/libpcre.so.3 (0x7fde1b5dd000) libexpat.so.1 => /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!
Amid all the shouting has anyone taken to effort to determine whether he has _in any way_ infringed the licence? http://www.gnu.org/copyleft/gpl.html from V3: section 4: You may charge any price or no price for each copy that you convey, and you may offer support or warranty protection for a fee. So, contrary to what I thought earlier he is fully entitile to auction sell or whatever and get what he can for this disk. Postage included! section 6: d) Convey the object code by offering access from a designated place (gratis or for a charge), and offer equivalent access to the Corresponding Source in the same way through the same place at no further charge. You need not require recipients to copy the Corresponding Source along with the object code. If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) that supports equivalent copying facilities, provided you maintain clear directions next to the object code saying where to find the Corresponding Source. Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements. So it would seem that providing a link to an official gimp download (a third party in his context) would fulfill the source requirements. Since most of the "free" world seems to believe in the presumption of innocence , has anyone bought or seen what he is distributing to accuse him of not complying with this or any other requirement of GPL? I don't like the fact he is hiding the program names in his presentation but I don't see anything in GPL that that is infringing. He is distributing free software which would not seem to be contrary to the wishes and intentions of the Gimp project. His customers seem pretty happy with the deal except for the occasional idiot who does like some have done here and start blasting him with neg. feedbacks without even contacting him with a complaint. So has ANYONE proof of infringement ? /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 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] 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 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 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 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] 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 Husadzic: > >> 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] (no subject) plus dockables
On 08/27/10 12:39, yahvuu wrote: > On 27.08.2010 07:32, Martin Nordholts wrote: >> If people have troubles finding the Layers dockable, we should instead >> look into making it more discoverable, like adding a 'Dockables' top >> menu or moving them directly under 'Windows' instead of having a sub menu. > > What about naming it the 'Dialogs' menu? > > -- 'Dockables' sounds like implementation slang to me. And the 'Windows' > menu becomes confusing in single-window-mode. Well dockable is a adjective so it begs the question: dockable what? I agree this is implementation terminology that probably should not be on the GUI. I find calling these dialogs to be part of the confusion (as well as being buried) . A dialogue suggest some kind of direct one-off interaction, like entering image scaling information and pressing OK, not a utility window I put on one side to be used from time to time. Since they are indeed windows , I don't see much wrong with that term. /gg > > > Making the Layers dialog discoverable under the 'Layers' menu and color > dialogs below the 'Colors' menu etc.. makes a lot of sense, but IMHO that's > the job of a 3.0 redesign -- there is a whole lot more to do than just > releasing > the dockables from their current hiding place and distributing them over the > menu structure. (E.g. what use is in displaying the brushes dockable while > the gradient tool is active? etc..) > > > regards, > yahvuu > ___ > 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] (no subject) plus dockables
On 26/08/10 19:50, oli...@first.in-berlin.de wrote: > Bcc: > Subject: Re: [Gimp-developer] scanner support should be File->Acquire > Reply-To: > In-Reply-To: > > Hello, > > On Thu, Aug 26, 2010 at 12:54:38PM -0400, Christopher Curtis wrote: >> On Wed, Aug 25, 2010 at 2:55 PM, Sven Neumann wrote: >> >>> "somewhere else" is not a very intuitive place either. We've had a >>> longer discussion when these items were moved to File->Create and no one >>> came up with a better solution. >> >> I find the 'Create' label non-obvious as well. It makes sense for the >> logo scripts, but I'd suggest considering: > [...] > > The problem is, that file->create as well as file->new do not really create a > file. > > A file is created, when it's written to disk. > > It's an image that is created. > > And getting data from a scanner is importing data to make an image out of it, > which maybe later will be saved to a file (or thrown away/deleted). > > It's the "we are used to misnomed menues since decades" as a heritage of > M$-Windows, which sucks again and again, and will not stop. > So... no wonder those discussions will come up again and again. > > > The only creative GUI that I've ever seen is that of Blender. > > You need time to learn it, because it's so different, > but it's good. > > There are other things in the Gimp-GUI that slows down the workflow, > for example in layer menue and in image menue, transformation tools are at > different vertical positions. So you always have to switch in mind, or look up > it again and again, which is time consuming. > > It would be a good idea, IMHO to have same functionality at same vertical > position, so that it doesn't matter if you want to rotate your image or your > layer: the transformation will always be at the same height in the menue. > > To achieve same vertical position, for menue-fields that are not used one > could > add an empty field. > > This at first might seem strange, because other programs don't do it that way. > But after people will be used to it, it will make the work with Gimp easier > and faster. (Learn from Blender!) > > Ciao, > Oliver I agree, I also find the file-create-screenshot *-scanner options rather forced and I have to do a double take to make sure it really says what I think it says and I have not misread something. File - Create - Xsane: device dialog seems particularly contorted. I don't really see the need for File - New to be on it's own. The amount of work that is done after this action makes one more selection irrelevant. File - New - Image would be fine. File - New -Scan ; *-From clipboard ; *-screenshot would make more sense than the "create" paradigm. File - Create - button , *-logo et al. seem more natural and are fine. Since the subject here is "(no subject)" I will add a related comments on some similar oddities in the menu system I want to comment on how hard/illogical it is to find the "layers dockable dialogue" without knowing what gimp calls it and knowing that "dockable dialogues" are found on the windows menu. This is a recurrent problem that indicates that this is counter-intuitive for me. I go several times round the loop and sometimes just give up not having found what I know is there in the GUI - somewhere. Some comments: If I want to operate on layers , the most logical place to look is on the layers menu. No go. Having done the tour , I may expect to find something about layers in Windows menu. Nope. So now I'm reduced to scanning every submenu to see if I can spot something about layers that is not on the layers menu. As well as going minutely through the layers menu since I have presumably carelessly missed what MUST be there. Finally, I have to know it's called a dockable dialogue before I'm likely to find it There are similar inconsistencies in several areas . The colour picker "dockable" is not on the Colours menu. This would seem to be another case of organisation by programming implementation , not by USER work requirements. These are all tucked out of the way , two layers down in the hierarchy because they are programmed as "dockables", not put where they need to be in terms of function. If I want a colour , I should find it on the colour menu . If I want to select layers I should fine the necessary interface elements on the layer menu. 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 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 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] 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] 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 Quin > >> 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 . I love >>> the 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 , 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/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] 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] 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² 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?]
--- Begin Message --- Ilya Zakharevich wrote: On 2009-10-23, 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 > >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 (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] 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] 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
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] 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
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] 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] 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
[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
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 " 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 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] 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 w
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 in&out 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?
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 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 >> To: Chris Mohler >> 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 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
Re: [Gimp-developer] Procedural call to undo?
Chris Mohler wrote: > On Mon, May 11, 2009 at 12:31 PM, gg 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 ___ 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] 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
[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] 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...
David Gowers wrote: > Hello, > On Mon, Mar 9, 2009 at 10:09 AM, gg 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
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
[Gimp-developer] [Fwd: Re: Gimp license]
--- Begin Message --- 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 ... 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
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_("/File/Print..."),
> (line 166 in the latest version) and change the name, e.g.
> N_("/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] 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 > > > >> 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
[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] 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] 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] 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
