Re: [Gimp-developer] gimp git considers all predefined brushes as having 100% hardness
There is a patch now attached to the bug that is up for commentary. Feedback welcome. On Sun, Jan 4, 2015 at 3:44 PM, Michael Natterer mi...@gimp.org wrote: On Sun, 2015-01-04 at 10:51 +0100, Hartmut Kuhse wrote: I think, this is related to Bug 741200 https://bugzilla.gnome.org/show_bug.cgi?id=741200 -paint options spacing differs from brush spacing Yes, it's the same issue, it affects not only spacing but also hardness. --Mitch Hatti Am 03.01.2015 um 19:33 schrieb Alexandre Prokoudine: On Fri, Jan 2, 2015 at 6:22 PM, Alexander Rabtchevich wrote: Hello Current git considers any built-in brush as a solid one. Solid? What do you mean? Alex ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list -- --Alexia ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Brush size relative to canvas size
The feature is in GIT now, btw. On Fri, Oct 24, 2014 at 6:30 PM, Richard strata_ran...@hotmail.com wrote: From: jo.y.v...@gmail.com Date: Thu, 23 Oct 2014 14:19:26 +0200 To: gimp-developer-list@gnome.org Subject: Re: [Gimp-developer] Brush size relative to canvas size Instead to fiddle around with units, maybe we could to use Brush dynamics ? Alternatives are welcome. That's an interesting alternative, though it doesn't make much sense to just map Zoom as an input to the dynamics grid ... I don't imagine zoom being a useful value for anything other than brush size, and it's a multiplicatively inverse relationship ... but perhaps on the Size output there can be an option to control whether it is considered absolute or (screen) relative -- Stratadrake strata_ran...@hotmail.com Numbers may not lie, but neither do they tell the whole truth. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list -- --Alexia ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] GEGL operations - GSoC 2013
Hi, Two ops, if done well are enough to apply :) Best, Alexia ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Minor enhancements in the export dialog
On Mon, Nov 26, 2012 at 8:46 PM, Richard Gitschlag strata_ran...@hotmail.com wrote: So then the issue is that out of that priority chain none of steps 1 thru 3 are saved between GIMP sessions. (Okay, step 1 and 2 can't, as they're image-specific, but step 3...) If you simply start GIMP up and select the Export command, the default extension is PNG when that may not be desired. And the suggestion is for a slightly expanded priority chain: 1 - Last export of current image 2 - Extension of current imported image 3 - Last export of any image 4 - User preferences setting 5 - PNG if all else fails This seems quite reasonable - different workflows/uses need a different default. PNG makes sense for a web designer, but not for a photographer/photomanipulator or painter who preffer to export to JPG or for game texture artist who needs to export in a specific third rather esoteric format. Im ambvalent tho between a user set default and just carring the last export over sessions. Both have pros and cons. Set default is good if you have one area of use and preffered format for that, but it's very unflexible if you do both web design and photography in bouts. On the other hand, it will only matter if you have closed GIMP totally, meaning you are starting a new session anyway that has no relation to the last, so carrying over the last exported format may hinder rather than help and set default may work better... ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Minor enhancements in the export dialog
On Sun, Nov 25, 2012 at 6:29 PM, Guillermo Espertino (Gez) gespert...@gmail.com wrote: And this is kept between sessions, but the PNG extension is always used in the filename. If you change the extension to JPG, for instance, when you close and re-open GIMP it will go back to PNG (using the default use extension option, but it won't remember the last extension used). I cant remember since when, but in current git for 2.8, all imported images default to imported format before all other options. Current order in git is for format AFAIK: 1. last export of this image 2. imported extension 3. last export of any image 4. png Original 2.8.0 did not use imported extension at all and it was a nuisance when working with JPG-s. 2.8.2 had the order slightly different, 2 and 3 were switched. -- --Alexia ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Save/export, option to go back to old behaviour
Just pointing this out again - in the future vision, that we are approaching step by step, the export operation with it's tasks, like scale etc should not require you creating a new image for this process... It would just be a view on top of the existing xcf project - very much like a target complation is in IDE-s. But this future can not happen in one single release. It will come iteratvely. This separation is just one step on a long way. First mandatory step... ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] API for time of last change vs. last export
On Sun, Nov 18, 2012 at 3:12 AM, Akkana Peck akk...@shallowsky.com wrote: On the thread-which-shall-be-nameless, when folks were asking for a way to quit GIMP without being prompted to save files that had already been exported, Alexia wrote: Oh, let me throw up this idea for you - you do not need a fork, just a script to override the default close... Very easy to install, maintain and distribute. No fork needed. Alexia, how? I looked into it, but couldn't figure out any way to do it. Good question. I asked mitch if this is possible and he said yes. My idea was to override the close, but now that I look at it, the problem is, that you seem to be unable to get the display for user opened image to close it... -- --Alexia ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Save/export, option to go back to old behaviour
On Sat, Nov 17, 2012 at 4:11 AM, Graeme Gill grae...@argyllcms.com wrote: And loss prevention has little or nothing to do with the decision to save or export. If you track what features an image uses, then you can by default save back to the file format used to open the image. Only if some processing operation is performed that takes the image outside the capabilities of the originally opened file do you have to get the user to decide whether to loose information or save as a different format. Even the act of loading a file into memory as pixel data and then recompressing on save is lossy for lossy formats and grayscale formats outright destroy information if the original is color. It is not realistic to keep track for each format feature by feature, if the image is now restorably exported or not, it would make maintaining gimp code and adding features a horror... Each change anywhere would recquire going over all export plugins making sure their supported feature lists are up to date... This separation makes it clear cut. The project file, the one that keeps ervery feature of gimp intact is the xcf and you save to it. Any rendering you export to. And this distinction will get even more important when we get to gegl backend in full. In short, options were considered, arguments have been had. We didn't do this to anoy anybody, we did this based on alot of consideration and a future of GIMP as a nondestructive image editor. -- --Alexia ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Save/export, option to go back to old behaviour
On Fri, Nov 16, 2012 at 4:11 PM, Matthew Miller mat...@mattdm.org wrote: Simon asked for a usability study. This is no formal study, but there's plenty of direct feedback from actual users. And there is also plenty of people that have showed up with saved files they want to change but cant, because they have them in jpg... And lots of people for whom the current Save/Export paradigm makes perfect sence. They just have no reason to come here and complain... -- --Alexia ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Save/export, option to go back to old behaviour
Oh, let me throw up this idea for you - you do not need a fork, just a script to override the default close... Very easy to install, maintain and distribute. No fork needed. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Save/export, option to go back to old behaviour
On Fri, Nov 16, 2012 at 4:35 PM, Matthew Miller mat...@mattdm.org wrote: Change is good. But listen to feedback as you make it. When there's a clear use case, see if you can cover it without serious detriment to the rest. I just have to make this point... All feedback recived in this manner is biased. People who come to complain are the ones that come here. To have unbiased feedback you would need an unnbiased cross-selection of the users. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Save/export, option to go back to old behaviour
On Fri, Nov 16, 2012 at 5:22 PM, Karl Günter Wünsch k...@mineralien-verkauf.de wrote: If I am editing an image to my liking I usually need several sizes and sometimes even aspect crops. Since sharpening is the last step in almost all of my workflows I end up creating a master (saved as XCF) which I don't want to mess up further. That master I open and scale and sharpen as I like, save the result (err. export the result) and toss it to start again - now it prompts me to create yet another XCF which I will never ever need, I have a master copy - which I may in fact lose if I happen to hit the save short cut because being in a hurry! This is a familiar workflow for me. I do this very often. Exporting a view of the master is a task for the future nondestructive editing. It should not require a creation of a new document. Some day it probably wont. And you will be ble to create several export graphs for your image too... This export/save separation is just one step on this way. We wont get to fully nondestructive editing today, but we will, some day. And unless you do not wish us to release anything for a next decade or two untill we get there, the interim inconvenience needs to just be lived with... -- --Alexia ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] history of great bugs
hi, If you want a fun bug, Id say the drag-and-drop ghost in 2.4 series(I think it got fixed by 2.6?) takes the cake. It eluded people for a while... I think it was Michael Mure before his first GSoC who found the issue... Best, Alexia ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Wilber watch mockup designs
I like the dashed white one and the solid black one for some reason most:) Id buy one when you make it happen :D On Tue, Sep 4, 2012 at 5:34 AM, Mukund Sivaraman m...@banu.com wrote: On Tue, Sep 04, 2012 at 07:45:22AM +0530, Mukund Sivaraman wrote: tigert made some mock designs for the watch: https://staff.banu.com/~muks/tmp/wilber-watch-draft-1.png https://staff.banu.com/~muks/tmp/wilber-watch-draft-2.png I've uploaded a variant of this design too: https://staff.banu.com/~muks/tmp/wilber-watch-draft-3.png Another variant on the black dial: https://staff.banu.com/~muks/tmp/wilber-watch-draft-4.png Kind regards, Mukund ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list -- --Alexia ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] gimp-context-set-brush-size. Why doesn't it work?
On Thu, Aug 9, 2012 at 5:36 AM, Rob Antonishen rob.antonis...@gmail.com wrote: I've started writing a script. Within the script I've adjusted the brush size using gimp-context-set-brush-size. After running the script, the brush size has changed in the Tool Options area but when the script starts the drawing process, it ignores the Tool Options and draws using the brush default size of 180 by 180 pixels. - I ran into the same issue and did some testing. I don't think you can change the brush size of anything but parametric brushes. All scripts have their own context, they dont make use of the UI context. I think its a bug, that the set size operates on the UI context rather than script context. -- --Alexia ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Fedback and personal comments about Gimp 2.8
Hi, Its long and it's late here, so sorry for reading it only for the bits that caught my eye. The issues with dynamics editing are known. All resources suffer from this, even tho its most obvious only with dynamics and vector brushes. However we could not postpone 2.8 further to fix this. The resources system as a whole is in need of some rethink and change. As to your current predicament, how I work with dynamics is having a small number of My dynamics presets for tweaking purposes and a bunch of tool presets that make use of them in sensible manner. These provide a kind of type brush functionality I can customize on the fly... I know it's a workaround, but ... Best, Alexia ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Fedback and personal comments about Gimp 2.8
Some more comments: Making all dynamics writable is within your own power. Its a simple task of copying the resources over from the system folder to your own profile and removing the system folder. III.1. Tablet-specifics, Pen/Eraser consistency First thing I noticed in 2.8 is that I now need to select the eraser tool when I flip my pen to use the eraser. I didn't have to do that in 2.6. Your tablet is not recognized or set up right then. On gimp side, if pen and eraser are reported as separate devices, they can have separate tools. Just tested it on my system(linux, wacom tablet) It works. So whenever I flip my pen and use the eraser, change the brush size, flip it again, have to restore the paint size again...! This is getting obnoxious, really. This is a side-effect of fixing another much more annoying issue - brush size/shape changing when switching tools. Another thing that there was no time to fix properly before 2.8. So we fixed the big annoyance, and left the tablets as they were. You can use tool presets to work around this one. III.2. Tablet-specifics, Unintentional floating A bug, probably. I don't have that issue with the mouse: many times, as I select an item from a drop down list (brush dynamics, brush...) using my tablet's stylus (paint or eraser tool) the list becomes a floating window and I need to dock it again... sighs. This is caused by nature of tablets and what X counts as a drag. Tablets tend to slip a micron during clicks and that registers to GTK as drag. Not much we can do about it. Use the option to lock the tabs to their docks. the annoying bit is, tha you need to do it per tab... We are aware of the issue, it just does not have easy solutions. III.3. Tablet-specifics, dialogs and menus A bug, which was present in 2.6 and is still not totally fixed in 2.8: using menus with the stylus sometimes (in 2.6 it happened all the time) makes dialogs unusable. This one is a known GTK2 bug that WONT be fixed. It will go away when gimp finally gets migrated to GTK3. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Cross-application work-flows and document file formats
On Tue, May 22, 2012 at 9:30 AM, Michael Grosberg grosberg.mich...@gmail.com wrote: Jon Nordby jononor at gmail.com writes: That reminds me - it would be great if the save feature also supported PSD (As opposed to export). I can think of only one showstopper: text layers, which are currently always converted to raster, and a further complication of how to preserve the text data on a text layer that has been modified using another tool. This is defnetly a no-go. Save is exclusively for a format that can save and load ALL gimp features. PSD is not a gimp format, it will never be able to do that. Hence PSD will always be an export. One that supports as much as possible of the PS feature set, sure, but still an export. And gimp already natively supports importing/exporting PSD-s... -- --Alexia ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Cross-application work-flows and document file formats
On Tue, May 22, 2012 at 10:26 AM, Michael Grosberg grosberg.mich...@gmail.com wrote: Alexia Death alexiadeath at gmail.com writes: This is defnetly a no-go. Save is exclusively for a format that can save and load ALL gimp features. It CAN save and load all Gimp features. It doesn't do that in practice, but it CAN. Even in a fully geglified non-destructive GIMP? It may today, but GIMP changes. -- --Alexia ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Gimp 2.8.0 - Saving in .jpg or .png hmmmmm
Hi! My 2c on the issue - This change is GOOD not only for the target audience but to the novice too! You would not belive how may times people new to graphics have come to varoius gimp channels asking how i can change text on this here image I saved from gimp yesterday as jpg or png and I have to tell them that they cant! and they are not even aware of the xcf as a format that would allow them to change the composition at any time. In the worst case, they have managed to destroy the original by overwriting it too! The noobs are safe from destructive mistakes and the pro-s are happy because it now works the way that is the defacto industry standard. Only people that complain are the intermediate users that have habbits they have to change now... Very human. And slightly tedious. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Cage-Tool performance
On Fri, May 18, 2012 at 9:52 AM, Anke Lange gimp-werkst...@gmx.de wrote: First: when I made a cage and want to adjust the knots, I can't. I have to create a new cage. But when I create the cage new and close it, it cuts my picture into bits. The only way to avoid this, yet, is to restart Gimp and load the motiv new. Is there another way around this? Yes you can. Close the cage, then in tool options switch to Create or edit mode. Then you can adjust the cage untill you switch back to transform mode. Second: I tried out, whether I get a difference in making a cage closer to the motif or leaving a wider gap between motif and cage. Using the adjustment of filling the background with color. Cage transform is only defined for the interior of the cage. It's a limitation of the algorithm. The fill works based on the pixel under your first point. It's ideal operating environment is an element on a separate layer of a larger canvas with transparent bg. Cage is somewhat special transform. It strives to be shape preserving. -- --Alexia ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] GIMP FxFoundry using GEGL?
GIMP-s plugin appi is not slated to change afaik, and fx foundry is only scriptfu scripts. They should just work with the geglified gimp... On Wed, May 2, 2012 at 9:59 AM, gfxuser gfx.u...@online.de wrote: Hi, lately I found this very promising plug-in collection made by two well-known persons of this list ;-) Will or need the plug-ins therein be ported to GEGL or do they use GEGL out of the box through the reworked PDP API? Thanks, grafxuser ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list -- --Alexia ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] new heal tool in gimp 2.8
New heal looks better to me. It doesnt blur so much. I dont know why it was changed. It's probably better somhow. You can argue on bugtracker if you want to, but there is nothing I can do about this. On Fri, Apr 27, 2012 at 10:45 AM, Miroslav Talasek miroslav.tala...@seznam.cz wrote: Any results ? and could u tell me why we change healing algo ? On 04/25/2012 07:27 AM, Alexia Death wrote: There was a bug in the heal tool that could cause what you describe that had a fix committed yesterday. you probably can get away with grabbing the latest heal c file from git and building again. On Wed, Apr 25, 2012 at 12:30 AM, miroslav talasek miroslav.tala...@seznam.cz wrote: old and new file is also included in archive with xcf file here http://photo.talasek.sk/special/healtool.tar.bz2 -- MSc. Miroslav Talasek Developer, Team leader Seznam.cz, a.s. Prague Czech Republic tel.:+420 234 694 722 fax: +420 234 694 115 gsm: +420 608 934 724 jabber: mire...@jabber.cz work-email: miroslav.tala...@firma.seznam.cz email: miroslav.tala...@seznam.cz web:http://photo.talasek.sk ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list -- --Alexia ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] new heal tool in gimp 2.8
Can you just make a bug with a comparative test image of what you think is wrong? On Wed, Apr 25, 2012 at 10:55 AM, Miroslav Talasek miroslav.tala...@seznam.cz wrote: No no i grab it from git yesterday after comit http://git.gnome.org/browse/gimp/commit/?id=8cd272bb8024886822185e9c39be276bf1c97a4e if u compare sources in attachment or in tar.bz2 file marked as new (broken for me) u will see also u can make diff between them and between old version and new On 04/25/2012 07:27 AM, Alexia Death wrote: There was a bug in the heal tool that could cause what you describe that had a fix committed yesterday. you probably can get away with grabbing the latest heal c file from git and building again. On Wed, Apr 25, 2012 at 12:30 AM, miroslav talasek miroslav.tala...@seznam.cz wrote: old and new file is also included in archive with xcf file here http://photo.talasek.sk/special/healtool.tar.bz2 -- MSc. Miroslav Talasek Developer, Team leader Seznam.cz, a.s. Prague Czech Republic tel.:+420 234 694 722 fax: +420 234 694 115 gsm: +420 608 934 724 jabber: mire...@jabber.cz work-email: miroslav.tala...@firma.seznam.cz email: miroslav.tala...@seznam.cz web:http://photo.talasek.sk ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list -- --Alexia ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] new heal tool in gimp 2.8
There was a bug in the heal tool that could cause what you describe that had a fix committed yesterday. you probably can get away with grabbing the latest heal c file from git and building again. On Wed, Apr 25, 2012 at 12:30 AM, miroslav talasek miroslav.tala...@seznam.cz wrote: old and new file is also included in archive with xcf file here http://photo.talasek.sk/special/healtool.tar.bz2 -- MSc. Miroslav Talasek Developer, Team leader Seznam.cz, a.s. Prague Czech Republic tel.:+420 234 694 722 fax: +420 234 694 115 gsm: +420 608 934 724 jabber: mire...@jabber.cz work-email: miroslav.tala...@firma.seznam.cz email: miroslav.tala...@seznam.cz web:http://photo.talasek.sk ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list -- --Alexia ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] gimp 2.8 splash screen suggestion
On Tue, Apr 17, 2012 at 4:37 PM, Simon Budig si...@budig.de wrote: Martin Nordholts (ense...@gmail.com) wrote: I like it more, but I still think the white diagonal line is too distracting I am not a fan of this kind of nit-picking. While we have certain requirements for the splash (e.g. to allow for the startup texts etc.) we should try to avoid pleasing everyone with the design, this in general doesn't help, since it dilutes the original artwork. Heh. I would not complain about that line so much, if it wasnt crossing out the label along with the wilber. I like the original translucent wilber more. I dont like the crossing out effect that sharp line gives. -- --Alexia ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] gimp 2.8 splash screen suggestion
In general I like the inital proposal more, if there wasnt that distracting strikethrough line, as is gespertino's v3 wins my favor. On Wed, Apr 18, 2012 at 7:11 AM, Burnie West w...@ieee.org wrote: On 04/17/2012 04:49 PM, Alexandre Prokoudine wrote: On Wed, Apr 18, 2012 at 3:23 AM, Kevin Cozens wrote: On 12-04-17 05:38 PM, gespert...@gmail.com wrote: After some tweaking... http://dl.dropbox.com/u/255376/gimp/gimp-splash_gez-V3.png If a person was to get picky they could point out that GIMP has more than paint brushes in its toolbox. ;-) Personally I wish we had just _one_ splash screen where Wilber goes berserk, bites the brush in half and takes all GIMP haters to cleaners, en masse. Just for fun. Alas, this would not make us look good. I'm with you on that one, Alexandre - - but on the other side GIMP is SO _ O _ O much fun Alexandre Prokoudine http://libregraphicsworld.org ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list -- --Alexia ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] gimp 2.8 splash screen suggestion
Not bad. The dark line going under wilber feels a little bit funny, but I like it in concept. Better than mine in the RC :P On Mon, Apr 16, 2012 at 7:32 AM, gfxuser gfx.u...@online.de wrote: Am 15.04.12 21:39, schrieb Bernhard Stockmann: hey everyone! I made a startup splash screen in GIMP for GIMP 2.8. also filed a bug on it here: https://bugzilla.gnome.org/show_bug.cgi?id=674154 If you like it you can use it! Is there another way to submit splash screens? Or are there any official guidelines? +10 ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list -- --Alexia ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] [Gimp-user] ANNOUNCE: GIMP 2.7.5 released
On Tue, Apr 10, 2012 at 4:50 AM, John A. Wallace jw72...@verizon.net wrote: After downloading that build of GIMP for Windows, I got a malware alert from AVG 2012 about part of it containing a Trojan. I have attached a screenshot of the alert. Any ideas about that? Thanks. Yes, several. a) It's not one of our semi-official builds you get from gimp-win.sourceforge.net, go get one from there. b) Contact whoever provided that build, sometimes there are false positives. However, since its a build from god knows where, id take the warning seriously. Malware distributors just love packing their crap into installers of well known free apps. -- --Alexia ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Gsoc - Slicing Tool
On Mon, Apr 2, 2012 at 8:48 PM, gfxuser gfx.u...@online.de wrote: Hi, I might have overlooked something, but what's the difference to the already existing Image-Map filter (see Filters/Web/Image-Map) and Slice dialog (Filters/Web/Slice...)? Plugins cant have on canvas controls. -- --Alexia ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] looking for advice ( gsoc )
Hi, No projects on paint tools will be done until GEGL porting has happened. And once it indeed has, creating a mirror mode for paint tools should be quite trivial. Just slap a mirror op on top of the layer you paint on. On Sat, Mar 31, 2012 at 8:47 PM, Ofnuts ofn...@laposte.net wrote: On 03/31/2012 07:37 PM, Ursu Dumitru wrote: Hello everyone! I was writing to you earlier, but as far as I understood, some projects can't be done until the UI of Gimp is redesigned. So I was thinking about two new things, but I'm in doubt as they may be too much related to UI, and I am looking for your advice, as I don't know yet the code good enough to figure it out by myself. First one: the mirror painting brush modifier, which enables horizontal or/and vertical painting mirror ( http://imageshack.us/f/35/mirrorpainting.png ) In the sale vein, edge-wrap painting would be useful for those making seamless tiles. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list -- --Alexia ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] An update on the menu search
Srihari Sriraman wrote: We now have it up and working. Still looking to implement loads of features... Do pool in suggestions! http://youtu.be/hGAgG_XRhHc?hd=1 Nice one. We had a failed GSoC project(student disappeared) for something similar. Is it a plugin or is it hacked into gimp core? -- --Alexia ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] How much money to make a dent in GIMP 2.8?
On Mon, Mar 5, 2012 at 10:05 PM, Jeremy Morton ad...@game-point.net wrote: With all due respect, your method of not paying anyone has resulted in 2 years without a stable release of GIMP. What's your point? It's not like things are just rosy and there aint nothing to fix. Failure to release in 2 years is not a problem curable with money. Long development cycle is the result of merging more than a few large features early on that took time to mature and stabilize. It's a result of going for perfect completeness in one go, instead of taking small simple and above all, releasable steps. We will try to address this shortcoming in the next few cycles by trying to keep the main tree in a releasable state at all times and add new stuff in small self-contained functional but perhaps feature incomplete chunks. I know Peter disagrees with me and many others on this, because he wants to see his babies complete, but that's exactly the thinking that got us this long cycle and exactly the thing we need to avoid. Adding more developers, specially paid ones without addressing the causes is not going to improve matters much unfortunately. there will be more things waiting around for those few touches to become releasable pushing the deadline ahead. -- --Alexia ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Gimp and Refactoring
On Tue, Feb 21, 2012 at 12:27 AM, Carlos Andrade carlosvia...@gmail.com wrote: I attempted to verify on achieve mailing lists around March 2011 to observe if the decrease on LOC was related to significant refactoring, however it seemed that 2011 march emails were not available. Only until around 06/2011. Is it possible for us to have access to it or could someone confirm by some other way that GIMP was undergoing refactoring or what caused the significantly LOC decrease? http://git.gnome.org/browse/gimp/log/?ofs=1700 The one source of truth - Git commit log. One commit stands out in particular, the removal of the old preset system. -- --Alexia ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] How is the pressure value from a graphics tablet read in GIMP?
On Mon, Jan 30, 2012 at 1:26 PM, Nick Bolton nick.bolton...@gmail.com wrote: Does anyone know how GIMP retrieves the stylus pressure value from a Wacom tablet? GIMP lets GTK handle such things, as GTK is better suited to handle such things. You will probably find andswers to your questions there, in GTK+ GDK component X11 input module. If you are using a toolkit, its probably better to see what it offers. If not, http://git.gnome.org/browse/gtk+/tree/gdk/x11/gdkinput-x11.c?h=gtk-2-24 may help. Lowlevel X API is one thing I am not inimately familiar with, but I do know this - To get extra information tablet provides, you need to query for Extended events, not the regular ones. -- --Alexia ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] how to modify precisely a guide position ?
On Sun, Jan 8, 2012 at 8:48 PM, g...@catking.net wrote: I hit this recently in the context of cropping out a section of an image. I needed a 1024x1024 for an external FFT application. Doing that with the mouse is not very realistic. Sigh... You guys sure like to go the long way around... Both rectangle select and crop tool have size constraints. In this case, grab crop tool, set it to fixed size, set size to 1024x1024 and crop away. With nice preview of what's in and what's out too... -- --Alexia ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] GIMP 2.8 Feature Request (2)
On Thu, Jan 5, 2012 at 9:03 AM, Liam R E Quin l...@holoweb.net wrote: I suggest a preference, default export format: [same as imported file] [same as last export] [tiff] [jpeg] [png] The current spec states 1. Last export on this file 2. Last export on any file 3. png That's so mindbogglingly annoying, but yeah found out last night that this is how it was specked and there have been rows over this before. I hacked up a quick patch to change that to: 1. Last export on this file 2. Last export on any file 3. Import type 4. png its a tiny patch and man did that make my life nicer. http://to.who.ee/0001-app-Add-import-type-as-third-preference-on-Export.patch - link to the pack. its very easy for those who build git to maintain their own miniforks ;) -- --Alexia ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] RFE: single window mode: always show tab
On Wed, Jan 4, 2012 at 3:27 PM, wwp subscr...@free.fr wrote: Anyway, it's not because you work on one document 99% of the time that 99% of the users do so. People who create original art(painters for example) work mostly on single canvas with lots of docks on the sides using tab to show and hide them. this is no less valid use-case than yours. I would even argue, that your usecase is quite rare, because you hover between one and may images. Photo manipulation use-case as a rule assumes several documents open at all times and photo-correction usually just the one. In another RFE to the bug tracker, I suggested to move tabs to the left, instead of to the top. Since quite all screens are wider than high, this makes way less space lost (at least the impact is less sensible). Docks in gimp are all vertical only. I personally feel that my horizontal space is much more cramped than vertical if I want to keep visible the few essential docks I need. It's so cramped that I usually end up with a barely square or even slightly portrait work area. The tab bar is also seen as a transitory feature. In the future the tab bar will be replaced by image parade concept and its quite possible its position and size will be customizable... --Alexia ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] RFE: single window mode: always show tab
On Wed, Jan 4, 2012 at 5:59 PM, Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: On Wed, Jan 4, 2012 at 7:42 PM, wwp wrote: Vertical tab captions are barely readable. Whoever thinks this is a good solution needs a good night's sleep, a cold shower and a cup of tea in the morning. Abomination.. does this post turn to trolling now? Your second remark started interestingly, but since the tab contents is not text but an image, Wrong :) Please check facts: both text, text and icon and, since 2.7.x automatic choice based on available space are possible. He is talking about the image tabs, not the dock ones ;) -- --Alexia ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] attempt to use the text tool crashes the program (on Windows) and I don't remember the solution
2011/12/4 Cristian Secară li...@secarica.ro: Using the 2.7.3 version from http://sourceforge.net/projects/gimp-win/ , with the text tool selected, GIMP crashes just when I click anywhere on an opened image. I remember it happened the same sometime in the past (more than a year back, I presume), at that time I found a solution (perhaps shared by Jernej Simončič (?)), but I am unable to find the referecne to it. At the same time, the 2.7.4 portable version from Partha's site works ok. Someone to remember something on this ? Its a known bug with the wimp theme engine. disable it and gimp will work fine. I did it by finding and removing libwimp.dll from gimp gtk, but it can be done via the config file as well. -- --Alexia ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Nightly builds now served through HTTPS
On Mon, Nov 28, 2011 at 10:45 AM, Tobias Jakobs tobias.jak...@googlemail.com wrote: On Mon, Nov 28, 2011 at 08:56, Martin Nordholts ense...@gmail.com wrote: Can you ping gimptest.flamingtext.com (203.94.189.170)? Yes, I can reach the address via ping. I'll test it again at home this evening. https://gimptest.flamingtext.com/ displays apache server test page. http variant says connection reset. Perhaps some redirects would be in order? Both HTTP and HTTPS main pages should redirect to somewhere. -- --Alexia ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] features
On Sat, Nov 19, 2011 at 1:15 PM, Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: 8) file browser (like bridge) to classify, tag, organize, photos. Do not want :) To elaborate on that, file management is not graphics editors job. It's a whole separate tool. For photos I use digikam. Really nice tool for managing photo files at least for me. -- --Alexia ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Getting the recognition that GIMP deserves
On Thu, Nov 10, 2011 at 12:07 PM, Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: …or get a fork and… ;) ...a knife and have a good meal. The only fork of GIMP that really survived is Seashore. It's targeted at an essentially different group of users. There's also cinepaint that was geared for movie world and the painter fork that seems to be maintained rather sanely as a set of patches on vanilla gimp. There's a few things that Id like to merge from there, but it's a bit tricky and we are too late in 2.8 cycle. -- --Alexia ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Getting the recognition that GIMP deserves
On Thu, Nov 10, 2011 at 4:05 PM, phanisvara das listm...@phanisvara.com wrote: martin nordholts, in a blog post from 2009 ( http://www.chromecode.com/2009/12/best-way-to-keep-up-with-gimp-from-git_26.html ) : The more people that use the latest GIMP code from git the better. It keeps the required effort to contribute code upstreams small, which in turn increases the likelihood of upstream contributions, and it makes bugs more vulnerable to early discovery which minimizes their impact. Keeping up with git is not the same as installing a dev version for production use! People who build and use git are good the same way as people using dev versions with full awareness of the caveats are good. But if somebody suggested installing git at work, the same objection would apply. Even more so than for dev releases. People who build and use git need to be at least somewhat aware what is going on in development and be ready to interact with developers up on finding bugs. A git snapshot from two hours ago may be obsolete... -- --Alexia ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
