Re: [Gimp-developer] Camp Ticket Presale Closing
Michael Natterer (mi...@gimp.org) wrote: everybody who wants to come to the camp should buy a ticket until *tommorow* the 20th of July: I ordered mine a while ago already and I can only wholeheartedly recommend this event. Bye, Simon -- si...@budig.de http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Example: Vala as code generator
Martin Nordholts (ense...@gmail.com) wrote: I'm trying hard to find time hacking on GIMP, and not having to waste time on GObject C boiler plate means a lot to me. At first I was thinking what the hell, I'll just come up with the the damn boilerplate code manually then. But right after I began doing that I started to feel like I was wasting my time, and I can't stand that feeling. Hm. This paragraphs leaves me a bit perplexed, because it gives the impression that the most important thing about including vala is to make you more comfortable with our codebase. You blame mitch for a blunt dismissal, but this reads a lot like bluntly forcing down something through mitchs throat. Not sure if that is any better. I must say that - while I have my share of frustrations with the gobject boilerplate code - I don't think that adding vala helps the quality of the Gimp codebase. And this is IMHO what should be in our focus. From reading a lot of code in a lot of different free software projects I have to say, that Gimp still is one of the shining examples regarding consistency and quality of the source code. This has a lot to do with mainly Sven and Mitch investing countless hours into refactoring and restructuring the code, enforcing a common code structure and generally fighting against sloppiness. I don't see how mixing this code with code written in a new language will help the quality of the source. Vala code will inherently develop a set of patterns that differs from the C code (and don't underestimate the value of grepping through the code base). Also new contributors will not only have to learn about GObject and GTK+, they have to learn vala as well. And adding vala *is* adding a new entry barrier, vala is by no means a lingua franca. Bye, Simon -- si...@budig.de http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Developer Meeting #3 - March 28, 2011
Martin Nordholts (ense...@gmail.com) wrote: 2011/3/27 Michael Natterer mi...@gimp.org: And this is *exactly* the problem. We would end up with programmers that quickly learnt vala, having no clue about GObject. That's absolutely horrible. How is it a problem that our code becomes so easy that even dumb programmers can understand and improve it when we are not forced to include patches from such dumb programmers? They're bound to hit problems that out of their scope, leaving them perplexed. My experience with vala is deeply tainted by the (now resolved) bug https://bugzilla.gnome.org/show_bug.cgi?id=587683 Bye, Simon PS: I don't like how you rephrase mitch's argument with offending words. -- si...@budig.de http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp_vectors_bezier_stroke_lineto() working backwards?
Ofnuts (ofn...@laposte.net) wrote: Why is gimp_vectors_bezier_stroke_lineto(vectors, stroke_id, x0, y0) (and Stroke.lineto(x,y)) working backwards? If I add a lineto() to the stroke, the point of origin (the one returned by gimp_vectors_stroke_get_point_at_dist(0,..)) changes... I'm sure there is a good reason, but I can't find it. Can someone enlighten me? The reason is simply the internal data structure as well as a (possibly over-)optimzation in the code. A lineto basically needs to add three anchors to the list of anchors. If the current point is the beginning of the list, you can add these three anchors in an O(1) operation. If you'd append them to the end you'd have to first search for the end, making this an O(n) operation (unless you of course keep track of the other end). The API does not guarantee consistency for the distance-point mapping when the length of the total path changes. When I designed the API I tried to avoid the idea of a specific start and end for each stroke, since this would introduce a directionality which would not be visible in the User Interface. Do you need to have get_point_at_dist(0...) staying constant while constructing the stroke with the _lineto-family of commands? Bye, Simon -- si...@budig.de http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Bug 325564] Use CIE LCH instead of HSL for layer mode Color
Charlie De (charlieco...@yahoo.com) wrote: Could you please demonstrate your sincerity by escalating the 'bug' to critical? It would demonstrate commitment to really having this in 2.10, rather than just 'looking at it'. I think you owe it to the developer to make that gesture at the very least. critical in Bugzilla has a specific meaning: It means that the bug can cause the application to crash and cause e.g. data loss. There is the target milestone for the purpose of indicating in which version this is supposed to be fixed, but this already is set to 2.10. Bugzilla is a tool to manage bug reports and/or accepted feature requests, and we try to use it as such. Overloading random bug attributes with different meanings does not help here. Bugzilla is not a tool to demonstrate commitment or to fulfil other social purposes. I think it would be the wrong place. Bye, Simon -- si...@budig.de http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] scanfs without field width limits making Gimp crash
Nelson A. de Oliveira (nao...@gmail.com) wrote: While testing gimp with cppcheck I saw a lot of warnings caused by the usage of scanf and fscanf without specifying a width limit. For Gimp itself there is a bug report on this issue at https://bugzilla.gnome.org/show_bug.cgi?id=639203 I guess I'll commit the patch attached to the bugreport soon unless someone has a better suggestion. Bye, Simon -- si...@budig.de http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] scanfs without field width limits making Gimp crash
Nelson A. de Oliveira (nao...@gmail.com) wrote: On Mon, Jan 24, 2011 at 8:26 AM, Simon Budig si...@budig.de wrote: For Gimp itself there is a bug report on this issue at https://bugzilla.gnome.org/show_bug.cgi?id=639203 I guess I'll commit the patch attached to the bugreport soon unless someone has a better suggestion. But here, for example (from your patch): snprintf (fmt_str, sizeof (fmt_str), %%d %%d %%%lds, sizeof (endbuf) - 1); if (sscanf (line, fmt_str, t-majtype, t-type, end) != 3) Won't it still be affected by a very large integer (like the example that I sent on my initial message) at the first or second position in the file? Ah sorry, should have mentioned that. The bug report is older than your mail to the list. We had a report on the %s conversion earlier which is what the patch attached to the bug attempts to fix. The %i problems are new to me and I tend to think that these are bugs in the libc and should be fixed there, although it probably would not hurt to add some more length specifiers... Bye, Simon -- si...@budig.de http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GUI enhancement patch from GIMP UI brainstorm blog
Mathias Lindner (monocero...@googlemail.com) wrote: Can I add something? Sure. :) All fine to now, two controversial opinions that may be solved by some trade-off... But I still have to give some critique: I have experienced similar incidents quite a few times. Again, you may all be right and I understand your perspective. But if you want to get/keep contributors you want to consider *how* to stress your workflow. Please try some empathy: somebody invests a lot of time (and even more important does the step to actually start doing something) and is rejected with not too much thankfulness. Or at least it sounds like that. I know about some people that wanted to contribute but also gave up due to bad help and harsh conversation. I understand your concerns and I do share them - at least partially. So with all clearness: I do appreciate the effort from しげっち (I hope that comes out correctly... :) and I love the fact that he actually dived into the code and made this work. We get a lot of why don't you? It is easy! requests, and having some existing code is nice for a change. Unfortunately we have a tendency to be a bit blunt in our wording and rejecting stuff - even for hopefully good reasons - is hard. It does have the advantage of being very clear, but yeah - it can put people off, which is something I hate. Especially with regards to the UI we currently are in a tricky situation: On one hand the collaboration with Peter is very fruitful and we got some enthusiastic responses to the stuff that has been developed with his help. Since it is clear that a consistent UI does not happen with people developing on random bits in the UI we - in my opinion - need a person that coordinates the efforts in the UI, and that person is Peter. On the other hand, yes, this unfortunately creates a bottleneck (which scares me), but I don't see a good way around this. So I really recommend to discuss stuff (on this list, in irc etc.) before investing lots of time into code, that might get rejected for the reasons mentioned above. This not only applies to GUI stuff, but to other functionality as well. In my opinion the current Gimp source code is in a very good state and I tend to attribute this to strong maintainership and a reluctance to accept random patches. Yes, this is sometimes hard on new contributors (which we urgently need), but I don't think just opening the floodgates would be a good strategy here. What currently is needed is some more work on the single-window mode. AFAIK there are some bugs in there and Martin (Enselic) can no longer dedicate as much of his time to it as he used to. It would be awesome if this work could be picked up and continued, I think a lot of the GUI issues have been worked out already and there is a spec for it at http://gui.gimp.org/index.php/Single-window_mode_specification . Thanks, Simon -- si...@budig.de http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GUI enhancement patch from GIMP UI brainstorm blog
sigetch (sige...@gmail.com) wrote: Well, you don't permit the GIMP to have the toolbars even if it is OPTIONAL and it doesn't replace or overwrite any existing GUI policy ? Each and every optional thing is a burden. Even if disabled it clutters the preferences dialog, it makes inconsistent User-Interfaces across installations (think about telephone support where you first have to figure out how the user interface on the other side actually looks) and it has the potential of confusing users. So before adding a new option we need to make sure that it is really necessary. I think it can be merged as an optional code, and safely ignore that feature in compile time of runtime switch. (currently I don't implement any switches though.) Compile-Time switches are a maintenance nightmare: If larger chunks of code are not compiled by default, the code quality tends to degrade with the time, since it does not automatically follow the rest of the code in the case of API changes etc. So another burden, which - given our very limited development ressources - is not a good idea to have. I think open source project can have several policy as a optional implementations, and it can provide alternative way for users who has alternative demands. I don't get how open source maps to several policys. Except maybe that one easily can fork an open source project, if the predominant policy feels wrong or unsuitable. Which btw. you're free to do (although I'd consider this a bad idea). I hope this helps, Simon -- si...@budig.de http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Fwd: Drawing per Script
Joao S. O. Bueno (gwid...@mpc.com.br) wrote: On Sun, Sep 12, 2010 at 8:58 AM, oli...@first.in-berlin.de wrote: (I also saw, that what on the GUI are Paths internally are called vectors. To make things better undesrstandable, it would make sense to give things the same name... but maybe there is more to vectors and I don't see it so far. Why are there different names?) will leave that up to Simon :-) There already is an internal API that uses the gimp-path-prefix and I wanted to avoid confusion. The new shiny vectors API should have its own namespace, to clearly separate it from the old pesky gimp-path-*-API :-) Also, the vectors infrastructure was designed to allow future extensions that go beyond simple paths. The goal was to have a vectors object as a container for strokes (i.e. connected bezier segments) or circles/ellipses or contrast-following-segments. So it theoretically could contain other stuff as well, going beyond plain paths. That aspect has never been fleshed out, mostly due to UI-confusion-considerations. Bye, Simon -- si...@budig.de http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP paths.
Mirza Husadzic (mirza.husad...@gmail.com) wrote: Can you please open a bug-report and attach the most simple test case that you can come up with? We need a small .svg file that illustrates the problem. I am pretty sure that the problem can easily be fixed then. Here it is: https://bugzilla.gnome.org/show_bug.cgi?id=629318 Fixed in GIT. We miscounted the numbers in the points string when it had additional whitespace at the end, resulting in a rejection of the data, since an uneven count means invalid data. Bye, Simon -- si...@budig.de http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP paths.
Mirza Husadzic (mirza.husad...@gmail.com) wrote: I think that better solution is that 'librsvg' do the parsing job and that GIMP can fetch points from the lib to render. Using which rsvg function calls exactly? Bye, Simon -- si...@budig.de http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP paths.
Mirza Husadzic (mirza.husad...@gmail.com) wrote: Using which rsvg function calls exactly? I checked the 'librsvg' and yes, there is no API exposed to satisfy this. Maybe the 'librsvg' can be subtly redesigned to expose this API? ;-) I did not look at the librsvg internals, but interpreting svg data in a way that results in a bitmap image is something very different from preparing SVG data for easy consumption by an application. Just as an example: Librsvg could just offload all the transformation stuff to cairo for rendering the image. To provide path coordinates flattened (with all transformations applied) it would have to compute the transformations itself. So it is not obviously clear, that librsvg *has* the data readily available for the use in the GIMP. I don't see a good reason to abandon our own parser. If it has problems we need an isolated testcase of a compact, validated SVG that results in bogus paths. Then we can track this down. Bye, Simon -- si...@budig.de http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Lab conversion, GEGL, RGB space, Illuminant
Rupert Weber (g...@leguanease.org) wrote: D50 vs D65 == Another question during transformation to Lab is, which illuminant or reference white to use. That part, I don't quite understand yet. Does that depend on the source data, or simply on how the monitor is calibrated? Well, Lab as a color space is not fully defined. Without further information it is not possible to have a Lab color calculated back to e.g. sRGB. The problem is, that the white in Lab (100%, 0, 0) has no absolute color coordinates. You don't know if this is a reddish white of a light bulb or the blueish white of a fluorescent tube. In that sense Lab is not an absolute color space, unless you define what you actually mean by white. So if you have a sRGB image (where sRGB defines D65 as the white point) you can easily transform this into an Lab image, but you need to attach the information the white is actually D65 to the result, to be able to meaningfully be able to transform the image back. Maybe this helps a bit, Simon -- si...@budig.de http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Merchandizing for the GIMP.
Hi all. At LGM we threw some ideas around for Gimp-Merchandizing. I am a little bit involved in this, since the company I work for - kernel concepts - has a lot of experience with doing these things for various free software projects. I am usually the person, preparing artwork provided by the projects into something suitable for the product in question. While I am convinced that we do a good work there and I'd very much welcome doing stuff for the GIMP please understand that I want to leave the selection of a partner for merchandizing stuff to you, by no means should my involvement with the GIMP imply in any way that GIMP should do the stuff with us. Having said that, here are some ideas what we have done already and what could be explored. Also have a look at our shop, where some of the stuff we have is presented: http://shop.kernelconcepts.de/product_info.php?cPath=22_30products_id=75 Options: - T-Shirts and hoodies. We prefer silk-screen printing for T-Shirts, which gives a great durability of the shirt. It might be possible to create special effects like e.g. night-glow paint or colors with glittering stuff in them. (we did this for some LinuxTag-T-Shirts, but this may have to be re-evaluated, since our printing-provider recently changed his color-source) - Mugs. We prefer silk-screen printing for the mugs. The openstreetmap mugs we did some time ago are done in some sort of transfer-print, and it turned out that the quality is not as good as we expected. We also have done some frosted-glass mugs, which can be printed on in clear. - Pins. In fact we did a Gimp-Pin as the very first pin and grossly overestimated the sellability of a gimp pin. As a result we're now sitting on 100's of Gimp pins, which don't sell. So there might be an option for a special deal :) They're silk-screen printed in 5 colors and beautiful. These are something I hand out frequently on community events, unfortunately I did forget them at this LGM. - Stickers. We have a contact, who creates stickers with an epoxy cover, pretty much as you know them from PC case stickers. They are not cheap but can be manufactured in small quantities and can be arbitrarily shaped. Regular stickers for distributing are something we still need to evaluate a bit. We once created a set of custom shaped linux penguins: http://shop.kernelconcepts.de/images/tux_aufkleberbogen.png However, creating a custom shape for mass-printing stickers is expensive. It might be possible to ask for a standard layout of a page full of stickers. We did not do this yet, but it should be fairly easy to figure this out. - Keyrings and other small stuff: the guy creating the epoxy-stickers also offers products, which provide a place for the epoxy stickers. Some of you know the key rings with a shopping-basket-chip I handed out to some people. This kind of stuff. This could be an interesting option, since there is no setup cost and manufacturing can happen in fairly small quantities. - Pens. For the FSFE we did a pen with analog printer printed on it. I wonder if it would make sense to have real world brushes and/or pencils with some reference to GIMP on it. - Ties. Michael keeps asking for them. We once did a Tie with the BSD-Daemon on it. They're not cheap, minimum order is about 40, and I am not *that* happy with the quality, they feel a little bit weird. - We also evaluated pins with blinking LEDs on them. Unfortunately we tend to care about regulations in Germany and when confronted with the requirements for the Elektro- und Elektronikgerätegesetz our supplier promptly retracted his initial offer, remarking oh, you're the first one to ask for this... Please feel free to continue the brainstorm. We're not scared of new challenges :) Tomorrow LinuxTag is starting again in Berlin and kernel concepts again manages the merchandizing booth there. Feel free to drop by (I'll be there on Friday and Saturday) and evaluate stuff. Bye, Simon -- si...@budig.de http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Notes of the GIMP BOF meeting at the LGM 2010
Hi all. Thanks to all attendants to the LGM 2010, it was a tremendous conference, I enjoyed it a lot. And thanks to the organizers for coming up with the note taking service: for our GIMP BOF agnez did jot down what was discussed, thanks a lot for this. I mostly left the notes unedited, except for filling in some missing names. If you attended the BOF please feel free to fill in stuff you feel is missing, and if one of the non-attendants wants to have some clarification, please ask on the mailinglist. Thanks, Simon annual gimp developer meeting organizational meeting collecting topics agenda - decide about future gimp website www.gimp.org not updated any more... and other sites - improve to get non developers involved - merchandising, gimp brand - introduce google summer of code project - coming gimp releases, generic chat about releases - group photo introductions - Michael [schumaml], building gimps on windows admin german gimp forum, taking care about agenda, organise summer of code... - Peter [guiguru], interaction architect, effort of renovating gimp ui, multiprocess - Alexia [Death], estonia, paint tools, - Simon [nomis], 13 years gimp involvement, no current projects - Tobias [tobi], gimp user since 1.2, moderator german gimp forum - Alexander [prokudine], using since99, technical support for russian users , russian documentation - Agnez, note taker - Tor [tml], finnalnd, no gimp involvement, gtk on windows - Øyvind [pippin], gegl project - Lukáš, krita, here for steeling gimp ideas - Boudewijn, krita, here to see how gimp community works - Michael [Bat`O] student, contributing code - Joao, trying to keep functionalities - Akkana [akk], user support, writing books about gimp - Jakub [jimmac], not involved for over a year, getting into the dialogue -- future of gimp websites www.gimp.org, current release announced there is not up to date. the site is running on a replacement system, parts of the site are broken for several months, not going to be fixed on the actual server, - same problem for wiki, spammed and not maintained, down now - needed: new server, rent server service, no problem to pay, dedicated server, - needed: admin or maintainer is needed paying someone full time is not foreseen, no one feels responsible for taking care of this problem at the moment - site maintainer needed - hard deadline needed? - who owns the domains? - Shawn Amundson, old gimp member, can be asked to redirect or create sub-domains without problem ?? set up a gimp foundation? there was a call for ideas and actions, no feedback came fo that idea domain name should be owned by a foundation - problem that Shawn owns the domain name? no problem per se, it worked fine for yeas, but would be more appropriate via gimp foundation. money is not a problem, flow of donations is large, need to figure out how to spend it. the money is there for a sysadmin - hardware is more pressing problem than domain name discussion - dedicated server - existing custom build system for the websites - buying hardware, or renting server, not important - what hosting company? what software? - hi traffic shouldn't be a problem, good quality hosting needed, not choosing the cheapest!!! ?? who is going to lead the web projects? traditionally : if someone starts to take a responsibility many will follow and take decisions. - alexia can take over some responsibilities, has been doing some of [admin work] before, take care of technical part - organizing migration to new technical hardware - who asks Shawn about dns matters. joao can take care of that? - choosing a hosting provider, do we care about the hosting country? no us. export regulations autralia? what can be taken of the site? what is going to be maintained? some parts have been sleeping for a while www top priority registry.gimp.org for uploading scripts and other resources. has been started by someone not close to gimp community but working good. has been drowned by it's success, heavy to use, ?? www.gimp.org running on a cms system? we need internationalization!! more system admin work? no complicated roles for contributers!! blocking everywhere take out the static part, throw away the python part, making adding news easy dynamic and localize site that can involve people into gimp (content contributors)? cms can be pain in the a**, but the actual site (git) is to technical for many contributors cms is going to get hacked, dock books plain html is blocking people, keep it as simple as possible basic machinery of the site should be founded in simple html, wikis etc can be connected to it.use git for contributing site going to stay static jakub volunteering for taking care of the website moderator access actually maintained by ingo (not present) also taking care of content cleanup ask him how the admin works, who has access to what? how is maintaining working? requirement set registry as a one click install site what happens if server crashes? there are
Re: [Gimp-developer] New on this list... how to start juming into Gimp-dvelopment?
Oliver Bandel (oli...@first.in-berlin.de) wrote: I'm new on the developer list. Welcome. I would like to help in pushing into the direction of overcoming the 8-Bit limitation. Also interesting would be for me to have more knowledge on the plugin-stuff; I had already written some little Python-plugins, but to know more about that would be fine I also think about implementing a foreign language interface for OCaml. For the 8-bit limitation the important keyword is GEGL, which is the project we want to base on for higher bit depths. Pippin is the person in the know there. At the moment I'm using Ubuntu and used the apt-get source gimp to download the sources of the current Gimp on my distribution. I looked for the necessary tools, which were not all installed. So then I installed them. I suspect this is not the current gimp source you're getting there. For development you really need to look at the stuff in the git repository. Of importance are the three git repositories babl / gegl / gimp, which need to be built and installed (in your own prefix, not (!) parallel to the system installed babl/gegl/gimp versions). For gtk+ and glib development code the system stuff *might* be too old, we have debian testing as a rule-of-thumb of the versions we depend on. A lot of other information is available at http://developer.gimp.org/faq.html and the surrounding pages. Probably does not answer *all* questions but hopefully enables a start. It looks like a lot of code... It is. But it is IMHO really good code... :) If you drop by in #gimp on irc.gimp.org (aka gimpnet) ask questions (and wait patiently, it is not really a real-time-response channel) a lot of questions could be answered live if you manage to catch the right persons (which is not too hard if you ask specific questions). Hope this helps, Simon (aka nomis in IRC) -- si...@budig.de http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Bug #164774
David Gowers (00a...@gmail.com) wrote: On Fri, Sep 11, 2009 at 6:54 PM, peter sikking pe...@mmiworks.net wrote: can somebody tell me why we have a tiny replacement for the menu bar right below the menu bar? The obvious answer here is that it's visible when the menubar is not. Well, it has been introduced in the times where there was *no* menubar and tablet-users (with no RMB) needed a way to invoke the menu. Bye, Simon -- si...@budig.de http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] connecting to update signal in uimanager
Jordan Stinson (jordan.stinso...@gmail.com) wrote: I'm trying to hack gimp. For my purposes, I want to be notified when certain actions become sensitive, or insensitive. The way I wanted to do this was to store the actions I wanted to keep track of and connect to the UIManager's update signal. That way, when an update happened, my callback function would be called and I could loop through my list and check the sensitive property of my actions. Wouldn't it make more sense to connect to notify::sensitive on the actions you're interested in? Bye, Simon -- si...@budig.de http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Raw notes from the LGM2009 BOF meeting
Hi all. I am sorry, but I forgot about the notes I took at the LGM2009 GIMP bof. I'll just send them around in the state I took them during the BOF in the hope that they are useful. If you have the impression that there is stuff missing or that I misrepresent some of the discussions then please feel free to comment. Sorry for letting this slip. Simon Roadmap 2008? - trying to do 2.8 before SOC 2010 * Merge vector layer branch - might need some work, especially in the UI - undo is broken -- mitch, nomis? -- End of May Univ.-Project with Peter, possibly Vector Layers? try to get it in 2.8. * Polish/finalize new features - on canvas Text editing must have in 2.8. - tagging no real problems at the horizon. Internationalization? (Jon: CREATE-Discussion) Support for Default-Tags? Multi-Select-Tagging? -- later. * Default Tags for Default ressources - Alexia + Rore are working on it / Data Extras not suggesting any specific workflows, purely descriptive also avoid culture-specific references. * finishing Save Export how to get a unified dialog? (GtkPlug/Socket? Sounds evil. Supported on Windows? No.) (Review of current plugins, which are the most important ones? can we come away with widget-descriptions, similiar to script-fu?) (we're trying for 2.8 -- Enselic) * unified transform tool (optional for 2.8) * Cairo Drawing on Canvas -- Sven? -- so that we can do the unified transform tool? * Summer of Code projects, integrate them into the codebase - python binding improvements (2008) FFTW3 is a GPL library, so we have a licensing problem with Frequency-Domain GEGL operations SOC, needs to wait for out-of- process GEGL ops. SOC 2009 final evaluation is on Aug. 24th - improved brush dynamics UI-- alexia - improved foreground selection GEGL performance improvements (!) - API is stable - Gimp doesn't use GEGL in a good way. - second view with gegl widget? - nobody currently working on it - not relevant to the 2.8 release Other SOC projects are basically about GEGL and don't directly affect GIMP. Stani: Python 3.0: any plans? - there will be differences - depends also on pygtk et al. Stani: Buffer-protocol for Gimp? - also in Python 2.6 - Joao wants to include the SOC2008-Python-Code into mainline - separate module to not have to depend on python 2.6 -- si...@budig.de http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Hacking GIMP - Gimp top level menu
Jordan Stinson (jordan.stinso...@gmail.com) wrote: Hi,I'm trying (for starters) to make the hue saturation tool visible in the toolbox. Uhm, actually there is no need to start hacking for this: 1) Go to Windows - Dockable Dialogs - Tools 2) toggle the eye icon next to the hue-saturation tool 3) watch it appear in the toolbox. Hope this helps, Simon -- si...@budig.de http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Support for SpaceNavigator
Håvard Tørring (htoer...@gmail.com) wrote: Hello, I have a 3dconnexion space navigator that I would love to be able to use to pan and zoom the images in gimp. Yay, I have one of these as well. Please hack on that :-) The problem with this approach is that gimp ignores the value of the events, making it unusable. Browsing around the source code, I have identified that the events from the navigator are correctly identified in controller_linux_input.c, but when mapped to actual events, such as panning, the values from the controller are ignored, and the panning is performed with a fixed pixelcount per event. So my questions are as follows: - Are there any ongoing work with this controller that I should be aware of? I am not aware of any current work in that area. - Are there someone that could give me a brief description of how the events from the input controller are communicated through the software? I have been unable to identify where in the code the calls to the panning and zooming functions are generated. The linux input controller module has a mapping, that maps events to so called actions, which are the same thing that e.g. get attached to the menu. The mapping from event to action happens in app/widgets/gimpcontrollerinfo.c in gimp_controller_info_event, which - if it has a mapping - emits an event-mapped signal. This in turn gets handled in app/widgets/gimpcontrollers.c, there you also see the logic how events with values are handled. Basically the assigned action needs to be an GIMP_ENUM_ACTION for the reported value to have an effect. It is perfectly possible that the actions used to scroll the view are not ENUM_ACTIONs and need fixing for this to work as expected. I hope this helps, Simon -- si...@budig.de http://simon.budig.de/ ___ 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
Graeme Gill (grae...@argyllcms.com) wrote: peter sikking wrote: what we really must avoid is the old confusion that users think that what they see in the window is just the jpg. it is not, else there would be no possibility to add a layer, a path, etc. If they've not actually added any of those elements, then it is actually just a jpg - ie. it should be possible to save a file without additional warnings to any format that is capable of representing all actually used elements. No it is not. It is decompressed pixel data. It would be a pure accident if a recompression to JPEG would result in the same file. The decompressed pixel data lives in a layer object, which has properties like e.g. a name. The layer itself lives in a container object, which also can contain channels and paths. There possibly are attached parasites, containing thumbnail and comment information. A default color profile has been attached if none was specified. Etc. pp. It just no longer is a jpeg. Bye, Simon -- si...@budig.de http://simon.budig.de/ ___ 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
Hi all. Some random thoughts from me. Not sure if they form a coherent picture though... :) peter sikking (pe...@mmiworks.net) wrote: [Liam 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 (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) it is ironic that this tripped you up, because we spent s much time optimising this for that other substantial group that insists to really under all circumstances export back the xcf they have in their window (it is never a jpg or png...) to the original file. The spec has the reasoning A much better reason for optimising are situations where high-end GIMP users have to do some quick touch-ups on graphic files for mates or clients, and send them back. This is a Workflow, where I don't see a xcf-file (in the file system) involved at all, i.e. the artist imports a PNG, does some touchups, exports back to the same file and quits Gimp/closes the image, not caring about not having saved his work. Liams workflow had a step in it, where he conciously changed the perceived identity of the image he is working on, by *changing* the suggested filename. To me it would be reasonable to assume, that he did this to protect his original file. (A kind of related irk for me is btw., that an image imported from a flat file format is Untitled and has the same naming state as a blank slate created with File-New. It feels like throwing away information. It is a bit unfortunate, that the Title is basically the same as the filename, inkluding extensions. If we would change this to use e.g. the basename with stripped extensions it would be natural to have - after importing typewriter.jpg - a title of typewriter, which results in the default suggestion of typewriter.xcf for saving and exporting (back) to typewriter.jpg) Upon saving as funky-keys.xcf - i.e. a conscious change of the title - the default export-filename-suggestion could change to funky-keys.jpg (Format derived from the originally imported file). Note that this does not at all change the workflow in the spec for quick touchups with no concious name changing involved, esp. if not at all saving your work. Bye, Simon -- si...@budig.de http://simon.budig.de/ ___ 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
gg (g...@catking.net) wrote: Subsequent Save as png should automatically set the default file name to /path/foo.png . *Please* try to be exact in this discussion. You *cannot* Save as PNG, you can only Export as PNG. The *only* format you can Save to is XCF and its compressed variants. Thanks, Simon -- si...@budig.de http://simon.budig.de/ ___ 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
Jay Smith (j...@jaysmith.com) wrote: On 06/10/2009 04:33 PM, Simon Budig wrote: gg (g...@catking.net) wrote: Subsequent Save as png should automatically set the default file name to /path/foo.png . *Please* try to be exact in this discussion. You *cannot* Save as PNG, you can only Export as PNG. The *only* format you can Save to is XCF and its compressed variants. Thanks, Simon I have tried to stay out of this, but I can't resist any longer. It is likely my own ignorance and/or not having seen a previous related discussion, but. I'll make it short to not distract from the original point of the discussion, if there is a need to discuss this in more depth, please open a new thread. Why is there such a strong distinction between Save As and Export? To the _user_ what benefit is this distinction? We want to make it absolutely clear to the user, that with basically all fileformats you lose more or less information. We want the user to make a conscious descision on that. If some programs have both Save and Export and offer multiple options in both of them, then hopefully all the options in Save can store all the aspects of the document you're working on and load them back properly. More on the reasoning can be found in the spec: http://gui.gimp.org/index.php/Save_%2B_export_specification Bye, Simon -- si...@budig.de http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Wanted: Gimp Modification for Kids Product
Jackson Tam (j...@sditech.com) wrote: We want to simplify things so that a kid could : Actually you might want to have a look at tuxpaint, which seems to have the same target audience as you. Hope this helps, Simon -- si...@budig.de http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Changelog inactive or developers inactive?
Lars Lindley (lind...@coyote.org) wrote: I usually follow the http://developer.gimp.org/ChangeLog site to see what's happening in gimp. The last update there was on april 13:th and I guess there has been _some_ work done since then... Has that site been discontinued or has there actually been no develompent for a couple of months? Don't worry, development is alive and kicking. However, the software repository has changed from svn to git and that makes it inpractical to continue the changelog in the same manner as up to this time. http://git.gnome.org/cgit/gimp/log/ is the best link I find right now. Not sure if there is a link where the commit messages have an expanded description... Hope this helps, Simon -- si...@budig.de http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp interface changes
Nathael Pajani (g...@nathael.net) wrote: Right. Because I do not see why there are now two windows at startup. Yes, you pointed to the wiki explanation already. It seems you are all OK for this empty unuseful window at Gimp startup Please don't confuse your opinion with facts. This window is useful and why it is useful has been discussed already or is described in the spec. With screens becoming wider, a vertical toolbox is not too much space wasted, but that big empty window is here for nothing. You even had to specify what it should look like for it not to be mistaken for an image window. This was impossible with the toolbox window. But the toolbox window cannot fulfil the tasks of the no-image window. For a start it cannot show the proper global menu. If the complexity increases logarithmic or linear is not that impotent. But I don't understand, why you are trying tu discuss facts. Every option is expensive. It costs time in programming, testing, documenting, supporting ... And ? Gimp is not a paint. I thought free software were not bound to create releases in time at the lowest possible cost. Gimp not being paint - which in itself is a polemic and not-helpful non-comparison - does not mean that we *have* to make our life harder than necessary. [...] Right and wrong. Right, the UI must not come as an afterthought. But the UI is not the main part of an Image manipulation program, it's here to give access to it's capabilities. Have a look into the code, the UI is the biggest part in GIMP. The number of lines of code has nothing to do with what is important. Gnome is a UI Window managers are UI GIMP is an Image Manipulation Program The User interface is here to allow access to it's capabilities as an image manipulation program. Or am I mistaken again ? Count the numbers of people using gimp as a programmatic backend and compare it to the number of people using gimp via the GUI. Then you have a rough estimate if the UI of Gimp is important or not. (Hint: There is a reason why we recomment imagemagick to people for certain tasks) The UI actually is the main part of an Image manipulation program; NO at least, it's the main part of GIMP. NO again, because you are confusing it's goal, and the number of lines of code related to each part. Why are you trying to argue against our own perception of the Gimp? Isn't Gimp what the Gimp developers think it is? An other reason for keeping the 'New Image' at top is, that it is the recommended place from the Gnome HIG. And ? Gimp will become GNOME dependent ? (And the Apple HIG) Apple dependent ? I guess we should follow the NHIG - i.e. The Nathael Human Interface Guidelines. Because there is nothing that is researched better. /sarcasm Bye, Simon -- si...@budig.de http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Please restore removed crop tool functionality
Sampo Niskanen (spnis...@cc.hut.fi) wrote: The point is changing the canvas size, but leaving the layers uncropped. The current crop tool always crops the layers to the selected area, so you cannot fine-tune the position afterwards - previously there was the option of cropping only the canvas, and the layers still stretched beyond the canvas. The current development branch has the menu entry Image - Fit Canvas to Selection, which - together with the rectangle select tool - does provide exactly this functionality. I hope this helps, Simon -- si...@budig.de http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] new feature request - gimp
Jim Michaels ([EMAIL PROTECTED]) wrote: Akima spline curves give drawing freedom, at least some kind of interpolating spline curve where you can just simply lay the points down and the curve follows along the points - I have a hard time getting bezier curves to do what I want. It's like Alice in wonderland using a flamingo for a mallet in a game of croquet. unweildly. Oh well, that all kind of depends on how you implement it. In the Curves dialog we also use bezier curves and you don't really notice it, because the control handles get determined automatically. Bezier Curves were introduced into Windows NT. It seems like a lot of paint programs began including Bezier Curves as a drawing method after that. Bezier Curves have a lot of (computationally) nice properties, making it easy to implement it. Plus it really is nice how you can control them in quite detail. Akima spline curves are cool. just put points along where you want the curve. simple. you just need more points around sharp edges, or you get a ringing effect around that area. (See discussion and visuals link). Yeah, just laying down nodes is a cool way to edit curves. From your links it seems that Akima-Splines have a better locality and are more stable than e.g. Spiro curves. The thing is that there are dozends of interpolation types that have this laying down nodes editing property and it is hard to put a finger on which one to choose. We do know that spiro curves have been developed to create visually appealing curves by requiring certain smoothness properties. That makes them an appealing choice for design oriented programs. The instability of spiros however might kind of hamper their adoption for real use though. Do you know of any study on how suitable Akima splines are for graphic design? It would be nice to have a comparison of different spline types for this kind of application. I believe the criteria you mentioned above (locality, interpolates all control points) are not necessarily enough to judge on that. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [wish] provide transparent color
Maciej Pilichowski ([EMAIL PROTECTED]) wrote: Please, provide transparent color or in other words -- treat transparency _also_ as a color. I don't think that this is a sensible approach in general. We currently use alpha to do proper antialiasing, compositing existing photos on top of each other and in all of these cases a coupled alphacolor (= color + alpha value) would be cumbersome and unhelpful. Such metaphor is more accurate to real world and thus more appealing to weekend artist (who would like to do some things in simple manner). Note, that Gimp is not designed with the weekend artist in primary focus. But even taking him into account the current model has served us well for the last years and there has been very few discussion about this specific problem, if it cropped up it was in the context of indexed PNGs with alphacolors or generating textures for renderers. For the general public the current model seems to generally work and I don't see a compelling reason to change this. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [wish] provide transparent color
Maciej Pilichowski ([EMAIL PROTECTED]) wrote: From: Simon Budig [EMAIL PROTECTED] But even taking him into account the current model has served us well for the last years and there has been very few discussion about this specific problem, if it cropped up it was in the context of indexed PNGs with alphacolors or generating textures for renderers. For the general public the current model seems to generally work and I don't see a compelling reason to change this. Well, one thing is history -- everything (in general) worked in the past -- why introduce cars when horses... etc etc etc :-) Well, historically new stuff always had to proove that it is better than the old stuff and I personally don't think that is a bad thing. I guess I have not yet understood what you actually want to achieve. The second thing is potential benefit -- and I believe less time spent on creating an image _is_ benefit. Note, that it will not introduce new features per se, it only could only change the way you work (if one wishes so). You can work with colors with color tools and you can only work with alpha channel with alpha channel tools. It is narrowing possibilities -- why not pick up brush, shape, pressure and polish a picture edges with transparency (as color)? So how do you want to work with transparency? What should happen if you have a semi-transparent red and you paint on top of blue? Currently it gets blended on top of the blue resulting in some kind of violet and that is a widely used feature to do natural looking paintings. I understand your proposal, that you actually want to have a semi-transparent red in the image after painting? How is your new feature supposed to interact with tablets with varying pressure devices like tablets? Right now you can map the pressure information pretty naturally to the opacity. Your replacement approach for alphacolors would directly influence the images alpha channel, making it pretty tricky to lift off the pen without leaving a transparent spot (tablets tend to add some events at the end et the stroke with very low pressure). How is your replacement approach supposed to work with multiple layers? I see lots of open questions here and I have doubts that your desired workflow is an improvement over the current one. Also I think that most of the tasks you mention in other mails - like cleaning up edges - can nicely be done with the current gimp, provided that you don't need 100% exact control over the alpha values (like the texture guys seem to need it, but they are not the main target audience). So I still don't see the problem here that needs to be solved. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] what means EEK ?
Cristian Secară ([EMAIL PROTECTED]) wrote: On Mon, 2 Jun 2008 12:12:53 +0200, Simon Budig wrote: http://www.levien.com/gimp/jargon.html: * eek An expression of shock. Even better is to make Burrito eek. He does it so nicely. Derived from Eeek, a German, the standard greeting whenever jtl logs on. Ok about EEK (thanks), but then ... what is Burrito ? This seems to be a Mexican food, how can a food have an expression of shock ? Or is this some cartoon character ? (this appears to be too cultural-dependant for successful internationalization) http://www.levien.com/gimp/jargon.html: * Burrito One of the #gimp's two beloved bots. Burrito is based on the same code as Xachbot, and is run by yosh. One of Burrito's most important extensions is its ability to eek. It also has a database of 2-letter country codes. Yeah, cultural-specific, but the culture is the Gimp IRC-Channel culture. The text of that error message is probably not really useful to translate since it is never shown to the user anyway (unless something is very broken in the Gimp code)... Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Adding SpaceNavigator support
Sven Neumann ([EMAIL PROTECTED]) wrote: On Wed, 2008-02-27 at 19:16 -0800, Ettore Pasquini wrote: After fixing that I was able to map the device actions and it works! Panning is pretty good, although there is no acceleration (moving the device hard or soft makes no difference). Does moving the device hard or soft make a difference in terms of what input events the Linux kernel delivers? The value element of the struct input_event may contain values with an absolute value 1. I found it a bit tricky to work with these events. On one hand it absolutely makes sense that the SpaceNavigator delivers relative events, at least for the intended purpose. But this means that the amount of pressure you apply controls the *rate* of the events, which is a bit tricky to measure. For me it would be easier to get absolute events from the SpaceNavigator and - if needed - convert them to a series of relative events myself. The other way around is not as trivial I think. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Adding SpaceNavigator support
Ettore Pasquini ([EMAIL PROTECTED]) wrote:
On 3/2/08 8:46 AM, Sven Neumann [EMAIL PROTECTED] wrote:
On Wed, 2008-02-27 at 19:16 -0800, Ettore Pasquini wrote:
It turned out to be a couple wrong assumptions on my side. First the linux
device file /dev/input/eventN was for some reason not readable by anyone
but
root.
I usually fix this by adding a udev rule that changes the device
permissions for all usb input devices to allow the group plugdev to
access the device.
Yep, that's pretty much what I did. I added a post to our forum:
http://www.3dconnexion.com/forum/viewtopic.php?t=1917
For helix I have prepared the following udev rule:
KERNEL==event[0-9]*, ATTRS{name}==3Dconnexion Space*,
SYMLINK+=input/3d-nav, MODE=0666
This matches the USB device name against 3Dconnexion Space*, which
should cover all 6DOF devices from 3Dconnexion. It also symlinks that
device to a fixed position so that programs can make assumptions about
the device name without probing the linux input layer.
Maybe this is useful for you.
Bye,
Simon
--
[EMAIL PROTECTED] http://simon.budig.de/
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Adding SpaceNavigator support
Hi Ettore. Ettore Pasquini ([EMAIL PROTECTED]) wrote: I work for 3Dconnexion (a Logitech company) and we make 3D input devices. We also care about popular 2D apps that could use the high sensitivity of our SpaceNavigator for panning and zooming. GIMP was under our radar and now we are considering to add support for our devices. I am new to the GIMP code base so I wanted to ask some questions about the architecture first. What would be the best way (from a pure engineering standpoint) to integrate my code? Meaning, via a plugin or just into the main app? Are there modules for I/O events (to deal with tablets, controllers, etc) that I should start with and expand? BTW let's not worry about licensing issues now. My code will obviously be shared and our devices are HID compliant, so no need to mess with proprietary drivers. yeah, except for at least one quirk :) (I wrote the patch to enable the LEDs for the Linux-Kernel :) On what Operation System are you working btw.? There already is a HID input module for the Gimp, you can find the source code in the top-level modules directory, relevant are the controller_*-files. We have various input modules, also available is a MIDI input module. The current architecture unfortunately does not yet allow you to hook into the (paint)-Tools directly, you can only invoke actions. There are lots of actions and it is easy to e.g. control the opacity. However, you can not control the pointer position in this way. Have a look into this, I'd be glad to help you to work on this. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] MIDI input controllers on Windows.
barney holmes ([EMAIL PROTECTED]) wrote: Does MS Direct X input include Midi device support ? My USB Midi device and normal Midi did not show up in the list ... but maybe they can be supported through Direct X ? There is a MIDI module for Gimp on Linux where you can map Midi events to Gimp actions. I have no clue about MIDI on Windows and/or DirectX. But if you figure out a way to get access to the raw MIDI Bytestream it should be fairly easy to adapt the MIDI module. Maybe this helps (and sorry for not spotting this message earlier) Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] next generation size entries
Martin Nordholts ([EMAIL PROTECTED]) wrote: Simon Budig wrote: Martin Nordholts ([EMAIL PROTECTED]) wrote: I'm currently interested in looking into this, mostly because I think this needs a clean solution before I will be able to cleanly finalize the GimpRectangleTool. I have a prototypeish parser running here, specified with yacc: If you're curious I'll put the code online somewhere. Please do, it would be useful to have a look at it. http://www.home.unix-ag.org/simon/files/parseunit.y I am not really convinced that it is a good idea to track the dimension of the entry with the grammar, it probably is easier to do this generically in the code and later check that the final result has dimensions 1 or 0 (default unit). Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] next generation size entries
Martin Nordholts ([EMAIL PROTECTED]) wrote: I'm currently interested in looking into this, mostly because I think this needs a clean solution before I will be able to cleanly finalize the GimpRectangleTool. I have a prototypeish parser running here, specified with yacc: $ ./parseunit 2m + 3in Result: 2.076200 m 40cm / 2in Result: 7.874000 2m * 3ft syntax error 2m * 3ft / 2in Ergebnis: 35.998171 m It kind of tries to track the dimension of the value entered and currently bails out for dimensions 2. Not very reliable but it might help for a good start of the parser. If you're curious I'll put the code online somewhere. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] momentary shortcut to the zoom tool?
Sven Neumann ([EMAIL PROTECTED]) wrote: On Sat, 2007-11-03 at 10:25 -0400, Daniel Falk wrote: There doesn't seem to be a way to temporarily switch to the zoom tool while a button is pressed. For example if I hold down ctrl + space, it would switch to the zoom tool, I could click-drag a rectangle to zoom, and let up on the ctrl + space, and it would switch back to the tool that was selected previously. There is code in GIMP to temporarily switch tools. We used to use it for switching to the Move tool when Space is being pressed (this can still be enabled in the Preferences). I guess that code could be used to implement the described behavior. But I can't tell if that is a good idea or not. Or if it is likely to collide with other tools. Or with changes planned for other tools. I am actually unsure if the Zoom tool really should be a tool. It is the only tool that does not affect the image, but the display of the image (the measure-tool at least lets you create guides). At least for me it is an annoyance: I never really use it and if I use it I am annoyed that it does not switch back to the previously used tool. I tend to think that it should be moved to the display of the image to make it easier to fluently change the view/zoom on the image without interrupting the current workflow. -- UI team :) Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Vectors Object Documentation
Sven Neumann ([EMAIL PROTECTED]) wrote: On Mon, 2007-09-10 at 21:04 -0700, Barton wrote: That's the gotcha that got me on this one. Another minor issue is that immediately after running draw_circle, the stroke appears in the layer dialog but it does not appear in the image itself unless you toggle the layer's visibility off and on. Does your script call gimp-drawable-flush()? If it doesn't, then it's not surprising that the image view is not updated. Right, I forgot about this - The script I posted did not have the (gimp-displays-flush) in it. Also note that for general bezier paths it is a bit different - there you would create a new stroke using gimp-vectors-bezier-stroke-new-moveto and then pass its return values to functions like gimp-vectors-bezier-stroke-lineto, -curveto, -conicto etc. to iteratively construct the stroke in the vectors object. I hope this helps, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Vectors Object Documentation
Barton ([EMAIL PROTECTED]) wrote: I've tried translating the draw_circle script-fu to python, and also checked the script-fu itself in my 2.3.18 installation without success; the circular path is created but it isn't stroked. Simon, did you write your sample script-fu for 2.3.19? I created it for the current svn version. It shouldn't be a that big difference, but I found a bug while writing it, which is fixed in current SVN - this bug created artefacts in the created stroke, but you should get a visible somethign. Make sure that the context you're using for stroking is set up correctly and make sure you're not stroking white on white or whatever. Hope this helps, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Vectors Object Documentation
Barton ([EMAIL PROTECTED]) wrote: I've been doing a little python-fu lately and find that in 2.3.18 stroking paths uses vector objects. So far I haven't turned up any practical examples of the use of the various pdb vectors functions in the source or on the Web, nor had any success through trial and error. Could someone point me to documentation for the pdb vectors procedures and/or post a brief sample python-fu snippet that creates a circular path and then draws a circle by stroking the path/vector? Here is a simple script-fu script to construct an circle and stroke it, It should be possible to convert it to python easily. Note that you right now cannot control every aspect of stroking, since the gimp context does not yet store stuff like e.g. a dash pattern. I hope this helps. Simon -- [EMAIL PROTECTED] http://simon.budig.de/ (define (script-fu-draw-circle image layer) (let* ( (w (car (gimp-image-width image))) (vectors 0) ) (set! vectors (car (gimp-vectors-new image circle))) (gimp-image-add-vectors image vectors -1) (gimp-vectors-bezier-stroke-new-ellipse vectors (/ w 2) (/ w 2) (/ w 3) (/ w 3) 0) (gimp-edit-stroke-vectors layer vectors) ) ) (script-fu-register script-fu-draw-circle Draw Circle Sample script to draw a circle Simon Budig (c) 2007 Simon Budig 4. 09. 2007 * SF-IMAGE input image -1 SF-DRAWABLE active drawable -1 ) (script-fu-menu-register script-fu-draw-circle Image/Filters/Render) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Feature request, - liquid resize
David Gowers ([EMAIL PROTECTED]) wrote: Anyway, if you give a link to a paper describing the exact workings of the algorithym, then it's much more likely that something will get done in relation to it. It seems to be fairly straightforward and the results are beautiful. The related paper is available at http://www.faculty.idc.ac.il/arik/imret.pdf - but since this page is pretty slow try these URLs: http://www.faculty.idc.ac.il.nyud.net/arik/imret.pdf http://www.faculty.idc.ac.il.nyud.net:8080/arik/imret.pdf Would be cool if someone would tackle this. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.4 showstoppers
Sven Neumann ([EMAIL PROTECTED]) wrote: 374854 possible optimizations in Script-Fu This one can possibly be closed or moved from the milestone. Waiting for a comment from Kevin. [...] 438997 Output on stdout when using script-fu console Looks like a low-hanging fruit. Some help from Kevin would be appreciated. I'll look into these when at the camp. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Downscaling quality.
Guillermo Espertino ([EMAIL PROTECTED]) wrote: David Gowers wrote: Perhaps you mean supersampling? Yes, it must be. I'm using a spanish localization of Gimp and try to guess the correct translation. Is there a command line option to launch gimp in english (just once, not permanent) so I can use the correct words when I'm reporting a bug or discussing something like this? Try LANG=C gimp AFAIK this works in most unix shells, most notably in bash. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Print plugin
Alexandre Prokoudine ([EMAIL PROTECTED]) wrote: - Will it be possible since GIMP doesn't use Cairo yet? It does implicitely, since it already depends on a GTK+ version that depends on cairo. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] A plan for GimpRectangleTool
Martin Nordholts ([EMAIL PROTECTED]) wrote:
With the introduction of helper functions like
void gimp_rectangle_tool_constrain_aspect (GimpRectangleTool
*rectangle_tool, gdouble aspect, const gchar *apply_on_x, const gchar
*apply_on_y)
{
/* apply_on_x may be x1, x2 or center_x, same for on_y */
}
Hmm, wouldn't an enum for apply_on_* make more sense?
Bye,
Simon
--
[EMAIL PROTECTED] http://simon.budig.de/
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] about carol
Sven Neumann ([EMAIL PROTECTED]) wrote: I don't know if everyone of the GIMP development team is as annoyed of Carol as I am, but I know that there are quite a few people who are. I for sure am annoyed as well. I absolutely hate the idea of driving someone out of the project and still worry about doing it, but I am out of alternatives. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] how to save plugin's data
tao frank ([EMAIL PROTECTED]) wrote: I know that some data of plugin can be stored in GIMP's pool by the function below: gimp_set_data (some_data, mydata, sizeof (MyData)); But how big can this data be? If I want to store a very big data, say, a color mask of an image, what should I do? Is it advisable to save this kind of data outside GIMP? This data gets stored in the RAM and then sits there. Although there is no limit on the size of this data this functionality is not intended to store huge amounts of data. It is more about a small struct saving the preferences of a plugin or similiar stuff. If you want to store a color mask of an image consider storing it in the image itself, e.g. in an extra channel or as a parasite. This has the advantage, that it will get stored inside the XCF format and will be available in the next gimp session. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Checking type for a GimpDisplayShell in 2.3.16
Hi Terry. Michael Terry ([EMAIL PROTECTED]) wrote: After presenting ingimp (http://www.ingimp.org) at LGM a week ago, it was suggested we port it to the 2.3.x developer branch. The port is almost complete, but I'm trying to understand a particular change between the 2.2.x and 2.3.x code trees. Yay! reference to gimp_display_shell_get_type). Our interaction logging code is linked in with app/core; where does this missing function reside so that we can use GIMP_IS_DISPLAY_SHELL? This is in app/display/gimpdisplayshell.h. Hope this helps, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] scheme changes
Renan Birck Pinheiro ([EMAIL PROTECTED]) wrote: Em Sáb, 2007-04-14 às 18:37 -0500, Jim Sabatke escreveu: I have a lot of scripts that no longer work under 2.3.x. I understand that gimp has migrated to tiny scheme and variables need to be declared with let or let*. I have tried and tried to modify some of the scripts and can't get them to work. I've looked at examples of scripts that do work and I've gone over (and over) the syntax for 'let' in my Lisp books, all to no avail. This might or might not be what you want, but for most of my scripts, replacing set! by define worked. I do believe that properly scoping the variables within a let*-block would be more appropriate here. However, I really cannot tell without looking at the problematic scripts. I'd be glad to discuss the issues on this list, if someone could summarize this into a tutorial or something I'd be glad to put it on the website. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Gimp-Developer] One-click binary downloads via the gimp website
Christopher Curtis ([EMAIL PROTECTED]) wrote: On 3/30/07, David Marrs [EMAIL PROTECTED] wrote: We already get Gimpshop users coming to the mailing lists asking for help and, Would it be a good idea to embrace these users as well? Gimpshop may be a non-supported hack, but hosting a Gimpshop-specific list may provide insight into a larger user base with applicability to the One True GIMP. IE: They're beating at the door, would it be a loss to let them in if only to lend an ear? I don't think hosting a gimpshop-specific list is a good idea, it would imply that we'd support gimpshop. Since we know that it is a badly executed hack and its author apparently is not interested in cooperation, I believe this would be a bad idea. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Rudeness on gimp devel and bugzilla - was:?Re: Tools
Manish Singh ([EMAIL PROTECTED]) wrote: On Fri, Mar 23, 2007 at 09:42:03AM +0200, Shlomi Fish wrote: As brought up earlier, claiming other projects have significantly more developers is simply untrue. Please stop spreading FUD. Oh, btw, FUD is another candidate. AFAIK the term FUD has the very specific meaning of spreading (mis)information with the intent to hurt a project. Since this obviously is not the intent here, the term FUD in this place is IMO wrong. I thus propose the following simple rule: - replace FUD with misinformation or ill researched information. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Rudeness on gimp devel and bugzilla - was:?Re: Tools
Shlomi Fish ([EMAIL PROTECTED]) wrote: Actually I also think it was too rude. Let's analyze it: [...] 1. You didn't say hi. Oh, come on. A lot of the mails on mailinglists don't include a greeting if quoting something. I've never perceived that as *rude*. 2. You phrased it as a question that implied the original poster should have thought abuot it himself, instead of giving an answer. Oh, come on again. It is not unusual to formulate a suggestion in terms of a question. To pose this as rude is IMHO blown way out of proportion. I really don't get why this discussion sparked from this specific mail. Please also keep in mind that most of us are *not* native speakers and discussing stuff in this linguistic nuances is probably a wasted effort. [...] However, I believe Alpár's and Joao commentary was induced by the general trend of treating people on this list (and potential future contributors) rudely or impatiently. I've noticed this general trend here too after someone made me more aware of it. Funny, my impression is, that it got better in the last few months. I believe the GIMP could have been much better off today, if it weren't for all the antagonism that the developers' have created. I mean, sure after Spencer Kimball and Peter Mattis left the project and most of the other original developers left to work on GNOME, very few developers were left. But since then the community of FOSS developers grew by leaps and bounds, and there shouldn't have been any problem finding much more potential developers than we have today. There are plenty of fish in the sea. I am concerned that this might not be exactly true. I don't have specific numbers, but my impression is, that it is way harder to sort the wheat from the chaff nowadays. In the beginning of the GIMP the people who a) found the GIMP, b) bothered to subscribe to the mailinglist, c) expressed interest in contributing generally already were enthusiasts about free software. They used stuff like e.g. slackware to convince their boxes to boot into linux. They were editing textfiles to get an internet connection. They had a thorough understanding of their system. This is no longer the case today. I mean, I am teaching stuff at the CS department of our universities and there really are students here who never did any programming and/or are annoyed if they have to. I mean, WTF? Granted, the pool became bigger, but the amount of fish in it did not increase in the same proportion. And there are a lot more projects fishing around in there. I am not sure if this is a fair description, I probably sound a little bit like a grumpy old man. Not sure what to do about this though... :) Let's look at Inkscape for a counter example. They have been around for a much shorter time than the GIMP, but have made remarkable progress, because the atomosphere they have is much better. If they could do it, why can't we? Only because we reject potential developers. I believe that reject is the wrong word here, because it implies that we'd do this on purpose which is in general not true. We do have a habit of expecting a lot from patches (look at the number of iterations some patches go in bugzilla) but in general I believe that even the original patch author will agree that the result is way better than what was originally submitted. We also have the habit of expecting more than half-baked ideas when someone comes up with an idea and sometimes ideas are probed a lot before a developer admits that it might be a good idea. I guess that these intentions do not always make it through to the person presenting the idea and they take it as a hostile attitude of the gimp developers (sometimes even threatening us with switching to other applications). This is the area where we probably can improve things a lot by being more careful with the language. However, the probing in itself is necessary and important for the quality of the Gimp. [and regarding inkscape - I like the project a lot and I don't mean them any harm, but they lost me as a contributor even before I tried to communicate with them - 430 source files in a single directory is a good way to do this, hopefully they will improve there.] About your suggestions: 1. Create a page with some FAQs and canned responses in both HTML and plain text formats. I volunteer to prepare and maintain this page. I also get sick of reading more You should change the name of the GIMP, it is an insult in English, When is CMYK/16-bit/whatever support coming?, etc. questions, but I believe we can at least answer them politely. Please add I will switch to [whatever] to that list... 2. Have a system of self-moderation. Let the messages of developers with a tendency to be rude and untactful pass through a small forward of friendliness experts for approval and correction. IF the experts are unhappy, they'll tell the senders to edit them and re-send them. Note that I'm not necessarily suggesting we
Re: [Gimp-developer] Rudeness on gimp devel and bugzilla - was: Re: Tools
Joao S. O. Bueno Calligaris ([EMAIL PROTECTED]) wrote: On Monday 19 March 2007 08:11, Simon Budig wrote: IMHO, refraining from posts like this could greatly improve the atmosphere of this list. It is really up to you to help somebody with answering his question or not to help, but this answer only hurts and helps nothing. I don't agree with you there. ... (remaining ranst tossed on bascket) Simon, where does that forbid one to add words like thanks, please, would and etc... to even a short answer, like a FAQ URL??? Nothing forbids that. The absence of these things does not make an answer rude though, which is the point I am arguing. I did hope that I made that clear in the rest of the message, but since you perceived that as a rant I seem to have chosen the wrong words. As I said: there are other messages that can be interpreted as very abrupt or curt, no doubt about this. And I really think that it makes sense to reconsider certain standard sentences, especially - as Sven explained - there certainly is no hurt intended. It is not really hard - and that is to you Mitch, you Sven, you Nomis, to simply rememebr the person on the other sidee is sitll a human being, is not it? Since you were referring to me specifically as well, I'd like to ask you to point out to me when/where I have chosen poor words or disrespect towards the other human being. Feel free to discuss this on the list although private mail probably is more appropriate. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Rudeness on gimp devel and bugzilla - was: Re: Tools
[EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote: On Tue, 20 Mar 2007 12:21:23 +0100, Michael Natterer [EMAIL PROTECTED] wrote: It is not really hard - and that is to you Mitch, you Sven, you Nomis, to simply remember the person on the other side is still a human being, is not it? Not less human for having less abilities to compile/hack complicated software projects, much less for simply not knowing how to do so. Come on, that is simply a rude accusation. Is it rude? It seems perfectly reasonable and polite to me. Actually I too think that this is - uhm - not very carefully worded. It implies that we actually do judge people only by their coding abilities and/or cluelessness. Which is something I personally do not like to hear about me (because I don't think it is true). To be a bit more constructive here: If our way of communicating gives the *impression* that we judge people by their coding skills only, then we should try to work on this. I think that (especially in the bug reports) there are subtle things that already would improve a lot: - replace obviously with apparently. - replace useless with not helpful - sprinkle more please and thanks there are probably other simple examples that would kind of defuse the perceived rudeness. To me it is important though that we avoid the corporate speak sound of some other projects, which in itselfs also creates a barriere between the users and the developers as well. As for the missing canned responses - it probably is fairly easy to whip up a small javascript bookmarklet, that fills in the comment section of a bugzilla entry, if one is really ambitious one could write an firefox extension that automatically adds these to the context menu. But really - a text file on disk with all of these would suffice. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Rudeness on gimp devel and bugzilla - was:?Re: Tools
Hi. Shlomi Fish ([EMAIL PROTECTED]) wrote: It took me 10 minutes to write. Oh wow. Is it just me or is this really a *lot* of time? Personally I'd consider answering 6 lazy questions per hour a waste of time. (Sorry for not replying to all of your mail - this just stuck out to me) Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
Sven Neumann ([EMAIL PROTECTED]) wrote: Also your approach is very lame indeed. This discussion wasn't even close to coming to an end. It would have been a lot nicer to propose a solution instead of wasting time like this. Please realize that your mails sound very much like you dont really want to change anything. You nearly suggested removing the screenshot plugin, you think of the current UI to be more appealing, you suggest various workarounds. None of your mails up to Akkanas latest mails even suggests that you are willing to reopen this issue. Now you are demeaning akkanas IMHO valid approach which is IMHO not fair. Fortunately you finally seem to open up a little regarding a discussion of the UI. But I'd really appreciate if you'd value other peoples work as much as you expect your own work to be valued. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] changes in script-fu in 2.3.14
Alexander Rabtchevich ([EMAIL PROTECTED]) wrote: Raphaël, this IS exactly my point! Why should the global variables be prohibited if there is no difference in memory consumption with local ones, only additional efforts to a programmer to track all parenthesis. Because global variables are not allowed in scheme and global variables are bad programming practice anyway (in basically all programming languages). And misuse can do great harm - we've seen that. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Rotate tool
Manfred Joerg ([EMAIL PROTECTED]) wrote: It would be nice if the rotate tool could do that for me. It could work this way: - Click on the left hand size of the horizon - Shift-click on the right hand size - The rotate tool calculates the angle. What do you think about my suggestion? Just use the corrective mode of the rotate tool and align the grid with the horizon. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Successfull compile, will not run
Milos Prudek ([EMAIL PROTECTED]) wrote: After successfully compiling gimp-2.3.13, on Mandriva 2007.0, Gimp fails to run with this error message: /usr/local/bin/gimp-2.3: symbol lookup error: /usr/local/bin/gimp-2.3: undefined symbol: gimp_vectors_stroke_type_get_type Should I file a bug report? Please try 'ldd /usr/local/bin/gimp-2.3' first to verify that gimp does pick up the correct libraries on startup. I suspect a broken installation here. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Resignation (fwd)
Hi all. No, it is not yet about me. Here is a mail Dave asked me to forward to gimp-devel - he wrote it after he unsubscribed from the list and the list is configured to members-only posting... Dave, let me add that it was great to have you in the project, thanks for the massive amount of good work you did. I hope that the very real problems you mention will get resolved at some point. Thanks for everything. Simon - Forwarded message from Dave Neary [EMAIL PROTECTED] - Subject: Resignation Date: Fri, 06 Oct 2006 14:42:11 +0200 From: Dave Neary [EMAIL PROTECTED] To: simon budig [EMAIL PROTECTED] Hi, I'm resigning from the GIMP project. I have come to terms with the fact that there will never be any code of conduct in this community, and I don't identify with that. For many years, yosh has been imposing his very particular view of the community on mailing lists, IRC and all other gimp.org resources, and I'm no longer willing to put up with it. I don't foresee any resolution to the problem in the near future. This isn't a decision I'm taking lightly (although I am certainly angry) and it's something which I have been thinking about for quite a while. I've already contacted Google to let them know that Sven will be the point man for the gimp for all things SoC, and I would like to have my name removed from the [EMAIL PROTECTED] alias as soon as possible. If you're interested in dealing with our money and donors, contact Sven, and we'll get you sorted out. It has been a great few years with the GIMP project, as coder, release manager and LGM/GIMPCon organiser. I wish the project the best, and hope that you can get past the community problems that you have. Cheers, Dave. - End forwarded message - -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] SoC roundup
Alexandre Prokoudine ([EMAIL PROTECTED]) wrote: On 9/10/06, David Neary wrote: * Proposal for wavelets-based imaging applications in GIMP Divyanshu Vats (Simon Budig) Divyanshu successfully completed jpeg2000 support, and a number of image filters integrating wavelet transforms. Divyanshu's blog has no download links, registry.gimp.org knows nothing about wavelet and it's not clear if his code is going to make its way to 2.4 or after 2.4, or will be available as plug-ins at registry.gimp.org sometime later. Any updates on this please? Since Divyanshu developed plugins that can easily live outside the core he did not commit his stuff into CVS. I'd very much welcome if he'd make his plugins available soon. Regarding the inclusion in 2.4: Maybe the jpeg2000 plugin could be included, although it relies on the not very popular obenjpeg library. The other plugins are very rough and still need tweaking, before they could be included. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Hard edged Ink tool?
Henning Makholm ([EMAIL PROTECTED]) wrote: Scripsit Øyvind Kolås [EMAIL PROTECTED] I cannot use the smudge or blur|sharpen tool, gaussian blur doesn't work neither does unsharp mask, layer masks seems to work but get their alpha thresholded. Neither of which are something one usually needs in a situation where one wants to stick to a colormap while editing. To do any real work on an indexed image I already have to go by RGB. Your idea of real work is obviously very different from mine. I do lots of real work on indexed images. Duplicating this behavior in GEGL would not be appropriate in my opinion, I don't really care whether it is duplicated in GEGL or outside it, as long as the net effect of don't let my editing result in pixel colors outside this small predeterined palette is still attainable with the sum of GEGL + futureGimp. I wonder if a quantize to palette Gegl Op would solve these problems. In most of the cases when people are asking for an indexed palette, the palette is already determined somehow, either by importing from the image or by editing for a specific hardware or certain texture conventions. In that case you really could have a quantize op, that maps all colors in the images to the appropriate colors in the palette. You'd have all the power of semitransparent layers, all tools would work as expected for a given definition of expected :), blurring would work etc. I am pretty positive that these problems could be sorted out when we know what people working with palette-based images want to have. I am just guessing on the needs here... Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] SoC - only four weeks left
Michael Schumacher ([EMAIL PROTECTED]) wrote: It would be nice if everyone who is involved in SoC could provide a short status report - the overall progress, maybe some results (screen shots are usually very useful :). Or problems, if any. I am mentoring two projects: Proposal for implementing vector layers in the GIMP --- Henk Boom is working on implementing vector layers for the GIMP and has made nice progress. He basically has vector layers that work, a rudimentary dialog for the stroke/fill properties, which could use some HIG/GUI review, which is probably the place where input from you would be helpful. The vector layers do not yet get stored in XCF, there is a crash lurking somewhere, we lack some updates (which I just figured out with mitch to be a missing gimp_image_flush ()) and additional stroke types would be nice, although they are probably the least important now. Check out the soc-2006-vector-layers branch of this stuff and play with it. I hope Henk is reading this as well and will get good input from you. Henk logs his progress at http://lunarcrisis.pooq.com/Gimp/SoC2006Log . Proposal for wavelets-based imaging applications in GIMP Divyanshu Vats works on several wavelet based image manipulation tools. His first thing was a JPEG2000 plugin, he is now working on denoising and inverse halftoning. This is more a research-type project. He has some interesting results. Since he is mainly working on standalone plugins the code is not in the GIMPs cvs yet. He logs his progress at http://deebuv.wordpress.com/, although I've seen stuff that is not visible there yet. From the images he mailed me he has inverse halftoning basically working, but I did not see that code yet. I'd welcome if both of my mentees (?) would present their view on the current status on the gimp-developer mailing list as well :-) I hope this helps, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] fact roundup
Brendan ([EMAIL PROTECTED]) wrote: On Wednesday 19 July 2006 02:35, Sven Neumann wrote: On Tue, 2006-07-18 at 13:10 -0700, Carol Spears wrote: this is what i learned about how these booths are handled here in the San Francisco area. to be mailed about their existence and to know about where to get the literature and such, you must have been owen taylors girlfriend. Stop this now. We don't want this mailing-list to be a place where people can spread such filthy and completely unfounded rumours. And don't start to discuss this with me or even try to provide evidence. Even if it was a fact, it's offtopic and simply doesn't belong here. Please unsubscribe yourself from all GIMP mailing-lists and leave us alone. I guess I'm confused. Does Carol represent some threat that I haven't noticed in the year or so I have been watching this list? Does she have laser beams coming out of her frickin' eyes or something? Well, we (as in old gimp farts) are dealing with this kind of shit for at least four years now. If anybody of us would be able to understand what Carol is asking for then there would be no issue - we would answer her question and the issue would be no more. Carol was basically a source of incomprehensible messages for four years now. It is getting on at least my nerves. Other people told me that they have left GIMP/Gimp-Web development because of her. That hurts, especially for a project with that few active developers as GIMP. In the last few mails carol is indirectly suggesting that the organisation of the Siggraph stuff is somehow shady. We all want to kill Wilber - whatever that means and Gnome is evil anyway. She coerces Dave to respond to vague allegations about the GIMP-Gnome relationship, financing, how-to-become-a-volunteer-for-siggraph and whatever I am sick of that kind of stuff. I am about to unsubscribe from gimp-developer because of that kind of stuff - reading gimp-developer is no fun anymore, because at any time you can hit a message that has a very confusing and frustrating content. So yeah, Carol does represent some threat: Driving people away. This is a very real problem for the GIMP. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] ANNOUNCE: GIMP 2.3.9 Development Release
Alexandre Prokoudine ([EMAIL PROTECTED]) wrote: On 6/6/06, Sven Neumann wrote: Over the next weeks, we will try to add the remaining missing features and to iron out all the bugs that are blocking the 2.4 release. Any help with that is very much appreciated. Is the plan to have SoC code in 2.4? Unlikely. We should focus on stabilizing and have the new features from the GSoC in the 2.5.x series. Then they have enough time to mature and we can get out 2.4 without having to care about the timeline of the GSoC program. bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp-python: Artefacts when creating layer
Sebastian Breuers ([EMAIL PROTECTED]) wrote: The plug-in, I'm writing, creates a number of layers, every layer receives an object, for example a circle (created by ellipse selection, an selection fill), but somewhen, don't know why, the layer contains not only the desired circle but also some artefacts. Stripes, areas of white, the mouse cursor, things they should not be there. Is that a problem that can be solved by a certain programmable handling or do I have to remove these artefacts by hand? That sounds as if you don't clear the layer before you use it for the first time. Layers created from a Plugin are not initialized from the very beginning. They need to be cleared using e.g. gimp_drawable_fill. Hope this helps, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp-python: Artefacts when creating layer
Alan Horkan ([EMAIL PROTECTED]) wrote: On Sat, 3 Jun 2006, Simon Budig wrote: That sounds as if you don't clear the layer before you use it for the first time. Layers created from a Plugin are not initialized from the very beginning. They need to be cleared using e.g. gimp_drawable_fill. I remember getting caught out by this too. Why is necessary to manually clear a new layer rather than have it done automatically? I have no strong opinions on that. I guess the reasoning behind this behaviour was a speed optimization: If a plugin later renders stuff to a new layer anyway it would be a waste of time to clear it automatically. If it doesn't it would just invoke gimp_drawable_fill. No harm done, except that you have to know about it. It might even matter for big images... Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Suggestion: Make the 'New layer' command defaultto 'New lay
Martin Nordholts ([EMAIL PROTECTED]) wrote: 1. GIMP wants to provide its users with a good workflow, independent and unaffected by other similar applications. 2. The majority of 'New layer' commands are equal, i.e. users rarely changes the properties (width, height, prefilled color, etc) of a new layer I fail to see why this should not be adjusted. As Joao already said, it is quite easy to create a new layer with the default properties. Just Shift-Click on the New Layer button in the layers dialog. We earlier had it the other way around: Click would create the layers with the defaults, Shift-Click would show the dialog. We then switched it around again, because Shift-Clicking to get the dialog, made the dialog a pretty hidden feature. Most people would not even be aware that there is a dialog, that is pretty useful at times. If the dialog pops up it is pretty easy to basically ignore it and hit OK. The other way around is not so easy to solve. Better have an undiscoverable workflow-optimization than an undiscoverable feature. If you know about the Shift-Click it basically is not more or less convenient than a simple click on the button. Hence I don't see how switching this around again would drastically improve the workflow. I'd say, lets stick to the current solution, it works good enough (TM) and we don't need to invent a different way to create new layers. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Suggestion: Make the 'New layer' commanddefaultto 'New lay
Martin Nordholts ([EMAIL PROTECTED]) wrote: We earlier had it the other way around: Click would create the layers with the defaults, Shift-Click would show the dialog. We then switched it around again, because Shift-Clicking to get the dialog, made the dialog a pretty hidden feature. Most people would not even be aware that there is a dialog, that is pretty useful at times. Ah, it was the other way around before, I see. From previous discussions however, I concluded that GIMP is not inteded to be an app for newbies, but rather be effective to its faithful users. I don't think that discoverability is about newbies vs. professionals. Better have an undiscoverable workflow-optimization than an undiscoverable feature. Note that the patch does not affect that when you use the Layer _menu_ instead of the shortcut button in the Layer window, the dialog shows as default. I find this quite logical too, that the shortcut command should be fast, and the slower menu command should offer more details. Actually it would be interesting to review the usage of buttons in the GIMP, maybe it would be an interesting topic for an usability study. Then we could try to make this consistent all across the GIMP. I wouldn't be surprised at all if some usability engineer would tell us, that buttons usually ask for an immediate action to the image (or whatever is supposed to manipulated by the button) and that dialogs in that case are not that usable. But I'd like to argue about this in a more global scope. Discussing this for a specific button is not that useful: Arguments get over-emphasized (as if this were the most important button in the GIMP) and we lose the big picture. If you know about the Shift-Click it basically is not more or less convenient than a simple click on the button. Hence I don't see how switching this around again would drastically improve the workflow. Having to use two hands instead of one is a dramatic loss of workflow IMHO. Uh, please back that up. If you would want _one_ new layer per image, than this doesn't matter. However, for more serious work where creating many layers often, having to use the left hand for shift is not effective I think. Why? I don't buy this. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Suggestion: Make the 'New layer'commanddefaultto'New lay
Martin Nordholts ([EMAIL PROTECTED]) wrote: Probably yes, but from what I remember, Shift + Click works in several more parts of GIMP's UI. If so, changing it would break consistence. I am not sure in what way? Yes, there are other commands that are altered by Shift. However, the logical relationship between Shift and non-Shift is (or at least should be) that the most common use of a certain button should be executed with non-Shift, and the other (less used) command with Shift. If you agree on that, then this improves consistence. I don't agree. First, determining what the most common use of a button is, probably is subjective at all. And even if we could determine this in an unambigous way we'd end up basically with a list: This button shows a dialog, this button does not. Shift toggles this. The user would have to learn the behaviour of all the buttons by heart, since there is no simple rule to describe the behaviour all over the application. I wouldn't call that situation consistent (Note that I don't claim that the current behaviour is consistent). Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Suggestion: Make the 'Newlayer'commanddefaultto'New lay
Martin Nordholts ([EMAIL PROTECTED]) wrote: If you agree on that, then this improves consistence. I don't agree. First, determining what the most common use of a button is, probably is subjective at all. And even if we could determine this in an unambigous way we'd end up basically with a list: This button shows a dialog, this button does not. Shift toggles this. The user would have to learn the behaviour of all the buttons by heart, since there is no simple rule to describe the behaviour all over the application. I strongly doubt that any regular user had any idea that that was the logical connection between a Shift and a non-Shift click. I had no idea. I did state explicitely that I don't claim that GIMP is consistent at the moment. There is no doubt that the current situation can be improved. It however IMHO cannot be improved by randomly changing the behaviour of individual buttons. As I said, I always figured GIMP wants to be _effective_ to work with rather than logical. I mean there are a lot of inconsistences in the UI, however, they make it _effective_ to work with GIMP. So to use GIMP effectively you have to go through a list of dozends of buttons and memorize what they do when clicking and what they do when shift-clicking? My idea of consistency is: The user looks at a button and can predict (maybe after learning one or two rules) what the button will do when it gets clicked, and what it will do when it gets shift-clicked. Even when he encounters this particular button for the first time. Your approach involves a lot of guesswork: We have to make an educated guess, what is the more frequent usage of each of the dozends of buttons. Each user has to guess what we guessed. And I bet that there are users out there who don't agree with our guesses. How do we defend our guesses? To exaggerate your approach: Wouldn't it be the most usable GIMP if we keep counters for the button presses? And if it turns out that a user uses SHIFT-Click more than a simple click, shouldn't we just switch the behaviour of the button on the fly? Maybe we should also reorder the buttons according to the button click count. According to your arguments this would result in the most usable GIMP ever, because we react to the individual usage pattern of each user. But it basically will result in a Chaos, where it is unpredictable what a specific button will do, even where it will be located. It is impossible to document. I firmly believe that simple consistency rules are important for usability. And that saving 0.3 seconds per new-layer (assuming for 0.5 seconds, that your made-up number resembles reality) or 30 seconds per 100 new layers is not as important as a goal. Conclusion: We definitely can improve the GIMP, but we need a coordinated approach. A usability study would help here. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Suggestion: Make the'Newlayer'commanddefaultto'New lay
Martin Nordholts ([EMAIL PROTECTED]) wrote: To exaggerate your approach: Wouldn't it be the most usable GIMP if we keep counters for the button presses? And if it turns out that a user uses SHIFT-Click more than a simple click, shouldn't we just switch the behaviour of the button on the fly? Maybe we should also reorder the buttons according to the button click count. According to your arguments this would result in the most usable GIMP ever, because we react to the individual usage pattern of each user. But it basically will result in a Chaos, where it is unpredictable what a specific button will do, even where it will be located. It is impossible to document. That sure is exagerating. Sometimes it is necessary to exaggerate to make a specific point clear. For this particular button however, I think we are not even talking about a majority, but rahter as good as _all_ users. Yes. You think. And you have no way to back that up. I for myself *do* use the dialog occasionally, mainly for creating new white layers. If you ask yourselves, how often do I need to adjust the settings of a layer, and how often do I just click OK on the dialog, what is your answer? I am not sure you are trying to understand what I write. If you've read my mails you'd understand that I don't see a point in arguing about this single individual button. I'll readily agree that you have a point when looking at this specific button in an isolated manner. Heck, I even was involved into making this button behave in this way before we reverted it back to its current behaviour. But that is not my point. My point is that we need to look at the big picture. The New-Channel and New-Path button behave the same way. In a lot of other dockable dialogs there are New-Buttons as well. For the reasons stated earlier I want a consistent behaviour. This is not the case currently, but your change won't make it more consistent at all. We need to analyze these things and change them in an coordinated manner. Read: Usability-Study or at least a description of the current situation and then try to improve that. If you don't adress the big picture in your future mails I don't see much point in a further discussion. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] SOC - brush system
Philip L. ([EMAIL PROTECTED]) wrote: You've given me another idea, though. Perhaps the path tool could be extended so that each node in a path could be a 'keyframe' in the stroke, holding brush parameters at that point. This would certainly make path stroking more powerful. On top of that, there could be a way to record a brush stroke into a path approximation, also holding brush parameters as measured during the stroke. It could then be edited and 'replayed' as desired. Actually the vector objects already store GimpCoords at the control points and hopefully the code already interpolates them properly. This is all totally untested though, since there is no real way to control the additional parameters (pressure, xtilt, ytilt, angle). Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] SOC - brush system
Philip L. ([EMAIL PROTECTED]) wrote: I'm considering creating a new brush system for the GIMP as part of the Summer of Code in order to make GIMP more suitable to digital painting. I've made some contributions to the project before, but it has been a while. Can anyone comment on how extensive changes to the rest of the codebase would need to be, how this would be affected by the future incorporation of GEGL, and whether this could be completed in the allotted time? It is not exactly clear to me what you mean by how extensive changes to the rest of the codebase would need to be - this seems to me to be very much up to you and your ideas for the brush system enhancements. As for GEGL, I believe in your case it is pretty safe to ignore GEGL for now and just work on the current model. You should keep your code that generates the images that get pasted on the layer as generic as possible, so that it can be changed to different pixel data representations later (16-bit, floats, maybe other color models etc.) Does this help? Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] RFI: Article on GIMP Development for LinuxFormat magazine
Michael J. Hammel ([EMAIL PROTECTED]) wrote: I'm looking for feedback on this (see below) from both core developers as well as casual (infrequent) contributors and end users. Ok, I guess I am a casual core developer... :) I'll just drop in some thoughts, not really ordered Here is a summary of what we're looking for in this article: Part I: Overiew and History - Overview of the development process: design/planning, development, bugfixing, and release - Who are the current GIMP core developers? Not enough people. Sven and Mitch do most of the work on the core, then there are some people like me who donate less time to the GIMP than they'd like to. See the Changelog to get an idea about the number of really active developers. Then there are people like Pippin, who does groundbreaking work that is not visible in the GIMPs changelog yet. - The joys of bugfixing and generally being involved in a project's development - preferrably from a non-core developer's point of view - Overview of Bugzilla - This history of the GIMP CVS repository: access and support We use Gnome CVS, people who contribute good patches via bugzilla can get CVS access pretty quickly. - Where to go for help: mailing lists, web sites Part II: Getting Involved 1. Finding a bug and how to reproduce it simply. 2. Reporting the bug. 3. Finding the broken code (show code) 4. Fixing it (print the solution too) 5. Making a patch file and submitting the fix (step by step). Maybe it would be good to actually fix a bug in the article. That would probably require to quickly spot something small that can be fixed easily. Look for Bugs with the gnome-love keyword. Additional info (usually presented in sidebars): 1. Photos of developers and/or people I correspond with and are quoted in this article 2. 1 sidebar on Writing a GIMP Plugin 3. One or more of the following: a. 1 sidebar on GEGL b. 1 sidebar on Developer Wishlist c. 1 sidebar on the 5 most annoying GIMP bugs d. 1 sidebar on important bug fixes provided by non-core developers Any additional advocacy information is also welcome (Carol, you've got lots there, right?). The annoying bugs should come from non-developers because we want to show people what needs to be fixed as encouragement to have them come fit it. It might make more sense to harp on the gnome-love bugs, since they are specifically marked this way because we consider them easy prey for new developers. I hope this helps, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and Google SoC
Gerald Friedland ([EMAIL PROTECTED]) wrote: However, as far as I understood, there is still an issue: Is GIMP able to display non-binary alpha values? I loaded in a PNG that I created using the SIOX demonstration Applet and I saw that GIMP binarizes the alpha values This should only happen for indexed images, then indeed GIMP does binarize the alpha values, at least in the display. If the PNG is stored as a RGBA-PNG then everything should be fine. Hope this helps, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and Google SoC
William Skaggs ([EMAIL PROTECTED]) wrote: 4) Vector layers and tools to manipulate them -- allowing adjustable rectangle and ellipse shapes, lines with arrow, etc. Actually my roadmap for vector layers would look something like this: - create the infrastructure to have vector styles, i.e. a vectors object has fill and stroke attributes. Create GUI to edit these styles. - make it possible to create a connection between a vectors object and a drawable, similiar to a text layer: the drawable gets rerendered when the vectors object changes. - probably it should be possible to attach multiple vectors to a single drawable. Each vectors object would have its own style attributes and the order in the paths dialog would determine the rendering order on the drawable. - Try to figure out a workflow for editing this in a sane manner. IMHO the path tool is sufficient to edit the shape of the associated path, but all the other stuff might need some thinking. Stuff like rectangle and ellipse shapes are not inherently connected to the vector layer stuff, they would simply be different stroke types. I already have implemented an proof-of-concept rectangle stroke type, that is a bit weird to edit, but works. I offer to mentor this project. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] How Do I Customize GIMP
digi artist ([EMAIL PROTECTED]) wrote: I have just been introduced to GIMP and think it is a great software. I would like to be able to customize it i.e. change menu options, Toolbox, hide the layer box on startup and change the splash screen. Just close the layer box and it will stay closed - gimp does its own session management, so that your dialogs will stay where they were on last startup. You can edit the visible tools in the toolbox by changing the order in the File-Dialogs-Tools dialog: Toggle the eye for the visibility of the tool, drag the tools around to change the order in the toolbox. To change the menus you need to edit XML files and I actually don't recommend this since it might make it harder for you to follow tutorials. However, we are interested in feedback if you believe that some changes to the menustructure would improve the usability. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Why be cryptic? 'Xtns' should be name 'Extensions'
Martin Nordholts ([EMAIL PROTECTED]) wrote: However, I think that when you use GIMP, the taskbar quickly gets bloated with lots of images. Would a TDI (Tabbed Document Interface) be very tough to implement in GIMP? TDI's have become very popular, and afaik lots of people agrees that TDIs are very effective for handling multiple documents. Please read http://bugzilla.gnome.org/show_bug.cgi?id=7379 - there already has been an awful lot of discussion about this and your idea is nothing new (Sorry). Please feel free to comment on this enhancement request if you think you have something new to contribute. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Photoshop PSD 6 format Spec / Gimp XCF format Spec
Frédéric ([EMAIL PROTECTED]) wrote: Gimp is OpenSource, and its file format should be open too. And so, well documented. Even if it still evolves, it is possible to make something without breaking previous rules when adding new features. Maybe by providing an complete API, like HDF does. Actually the current XCF format has its limitations and we are not really convinced that it is a really good (tm) format, it has some pretty severe limitations. There were plans to work on a next-generation XCF resolving these issues. I too see the need for a widely accepted exchange format for multilayered images with a lot of additional information, but the current XCF format does not meet the good enough criteria. The main documentation for XCF is in the source unfortunately, and for the reasons above we don't encourage support for XCF. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Photoshop PSD 6 format Spec / Gimp XCF format Spec
Campbell Barton ([EMAIL PROTECTED]) wrote: Hey Gimp dev's (by the way, how many gimp dev's are there?) well, that depends on how you define gimp developer - there are about 180 people listed in the AUTHORS file. The listed persons have at least once added something to the GIMP in the last 10 years. However, this number reflects the number of *active* developers very badly: this year 16 people have committed something to the gimp core, 10 more than once and 3 people more than five times[*]. So, there is no army of developers eager waiting for stuff to do, to the contrary - we really could use some more people contributing regularily. Bye, Simon [*] These numbers unfortunately ignore the people that are helping tremendously by giving good and detailed bug reports, sometimes with good patches. Thanks to you all, keep up the good work! -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Selections in plugins
Joël-Alexis Bialkiewicz ([EMAIL PROTECTED]) wrote: On 1/26/06, Simon Budig [EMAIL PROTECTED] wrote: Joël-Alexis Bialkiewicz ([EMAIL PROTECTED]) wrote: In fact I don't want to ignore selections but to use them in a different way. Especially, I would like to be able know, for a specific point, whether it is selected or not. You can request the selection as a drawable using gimp_image_get_selection(). You then can peek into this drawable to get the selection value for a specific pixel. You probably need to be careful with the offset handling a bit though. 1) What do you mean by careful with the offset handling? Layers are not necessarily at the 0,0 position of the canvas. The selection however is. So you need to take that difference into account. 2) When I read the data from the selection drawable, 1 means selected and 0 means not selected, isn't it? A selection is not binary. 255 means selected, 0 means not selected, 100 means partially selected. 3) When I call gimp_drawable_mask_bounds and there is a complex selection, what part of the image does it point out to me? Does it correspond the littlest square possible containing all selected points? this returns the bounding box, All pixels outside are *not* selected, there may be not selected pixels inside. 4) When I try to read a point that is not selected, will it give me the right value for this point or some dummy value? When reading the pixels from a drawable the selection does not affect the result. You always get the correct result (under the assumption that you do read correctly...) Hope this helps, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Selections in plugins
Joël-Alexis Bialkiewicz ([EMAIL PROTECTED]) wrote: My primary hypothesis is that gimp gives the full image (or a square portion of it including all selections) when you call gimp_drawable_mask_bounds, and that when you write your results using gimp_drawable_update, it just updates the selected portion of this square. There come my questions : A) Have I figuret it correctly? B) If not, how does it really work? C) Is there a way to force writing outside the selection? D) Is there a way to know if a given coordinate is selected or not? The selection gets respected when you're using shadow tiles and use gimp_drawable_merge_shadow. You can ignore the selection by not using shadow tiles IIRC, I am at the moment not sure how this would affect the undo system if you don't use shadow tiles. Hope this helps a bit, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Selections in plugins
Joël-Alexis Bialkiewicz ([EMAIL PROTECTED]) wrote: On 1/26/06, Simon Budig [EMAIL PROTECTED] wrote: The selection gets respected when you're using shadow tiles and use gimp_drawable_merge_shadow. You can ignore the selection by not using shadow tiles IIRC, I am at the moment not sure how this would affect the undo system if you don't use shadow tiles. In fact I don't want to ignore selections but to use them in a different way. Especially, I would like to be able know, for a specific point, whether it is selected or not. You can request the selection as a drawable using gimp_image_get_selection(). You then can peek into this drawable to get the selection value for a specific pixel. You probably need to be careful with the offset handling a bit though. Hope this helps, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Filter source code
Fred Lupien ([EMAIL PROTECTED]) wrote: sorry if this seems a bit out of place, but it seemed the most reasonable list to post this question to. I am looking for the source code for the filters in the Filters menu for a research on image processing algorithms and I was not able to find them in the GIMP 2.2 source code package. Can someone point me in the right direction please? The filters in the Filter menu are the plugins. You can find them in the gimp-2.2.X/plug-ins/ directory. Hope this helps, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [SCM] text file management
Nathan Summers ([EMAIL PROTECTED]) wrote: On 1/10/06, Sven Neumann [EMAIL PROTECTED] wrote: (fopen path mode) (fwrite data stream) (fclose stream) Hmm, interesting. I couldn't get this to work with script-fu under 1.2, but it seems to work fine under 2.2. Well, it certainly worked 7 years ago: http://www.home.unix-ag.org/simon/gimp/hotspots.html :-) Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] authors.xml, volunteer needed
Sven Neumann ([EMAIL PROTECTED]) wrote: Sven Neumann [EMAIL PROTECTED] writes: http://cvs.gnome.org/viewcvs/gimp/authors.xml?view=markup I am now looking for a volunteer to go over authors.xml and check what roles apply to the people listed there. Perhaps also check that noone important is missing (last time we did that was before the 2.2 release). No coding skills required, you don't even need to know anything but the mere basics about XML. Some knowledge of the GIMP history will definitely help though... No response whatsoever. So there isn't even interest in helping with the simple tasks any longer? This is becoming somewhat frustrating... I am pretty sure that it is *not* simple and that there are very few people being able to do that. And no, I don't think I could do this. There are too many names in that file I've never heard of and I have no interest at all go digging through ancient maillogs or changelogs just to figure out if someone was a contributor or doc-writer or whatever. I am surprised that you're surprised about the underwhelming response. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Layer locking proposal
Nathan Summers ([EMAIL PROTECTED]) wrote: On 6/26/05, Simon Budig [EMAIL PROTECTED] wrote: A way to overcome this is to have e.g. two lines per layer. A sample mockup is available at http://www.home.unix-ag.org/simon/files/layer-dialog-many-properties.png This would work. All you would need to do is increase the text 2pt or so, and make the icons visually look a little less like text. Well, this is the small theme, a mockup with the regular theme would probably also be needed to judge on that one. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Blending Modes: Mathematical Perspective
Martin du Saire ([EMAIL PROTECTED]) wrote: In general, are there a handful of recommended sources (print or on-line) that detail the typical image manipulation algorithms? Have a look at http://www.pegtop.net/delphi/blendmodes/ , this explains the mathematical background of several blending modes. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Layer locking proposal
Sven Neumann ([EMAIL PROTECTED]) wrote: Simon Budig [EMAIL PROTECTED] writes: I also think that it will clutter the rows too much if we move it to the front. Perhaps consider to add it on the top of the dialog with the opacity slider and the Lock Alpha Channel toggle ? I don't think this is practical. In Skencil I use locking of layers as a method to quickly protect the layers of the objects I am not using. However, that means that I iterate over the column of the layer locking buttons and decide if I want to change that layer or not. Having to individually select the layers and then toggle the button somewhere else makes this feature basically useless. Well, we do that already for the alpha channel lock and it doesn't seem to work that badly. Sooner or later we will probably want to add more such toggles. actually the alpha channel lock is a major source of confusion, sometimes even for me. Huh, painting doesn't work. Also it has a different use pattern: Your descision if you need to toggle it depends only on the layer itself. This is - as I explained - very much different from locking the layer completely: Your attention shifts to a different group of layers and you want to toggle this on multiple layers simultaneously. With your proposed solution it would be a major PITA to do this. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Layer locking proposal
Michael Schumacher ([EMAIL PROTECTED]) wrote: Also we should consider making the layers not selectable in the layers dialog if they are locked. This removes a source of confusion (why doesn't this work) and gives immediate additional feedback about the locking. I was about to suggest this myself, but then dismissed it because of the why can't I select the layer? problem. However, it requires the locking button in the layer row itself. Hm, if you can't select it (e.g. with the cursor keys), how are you going to change the lock state using the keyboard? Good question. Probably we need to grey out the layer somehow instead. Or decouple focussing from selecting for these layers. Not sure if this is easily possible. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Layer locking proposal
Simon Budig ([EMAIL PROTECTED]) wrote: Sven Neumann ([EMAIL PROTECTED]) wrote: Well, we do that already for the alpha channel lock and it doesn't seem to work that badly. Sooner or later we will probably want to add more such toggles. actually the alpha channel lock is a major source of confusion, sometimes even for me. Huh, painting doesn't work. Also it has a different use pattern: Your descision if you need to toggle it depends only on the layer itself. This is - as I explained - very much different from locking the layer completely: Your attention shifts to a different group of layers and you want to toggle this on multiple layers simultaneously. With your proposed solution it would be a major PITA to do this. Maybe a better comparison is the visibility toggle: It would become a major PITA to use if it were a button on top of the dockable. It has a similiar meaning: It controls a single property of a single layer, but is frequently used for multiple different layers at once. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Layer locking proposal
Sven Neumann ([EMAIL PROTECTED]) wrote: Simon Budig [EMAIL PROTECTED] writes: With your proposed solution it would be a major PITA to do this. I didn't propose a solution, I only said that moving the toggle elsewhere should be considerd. I am not at all convinced it is a good idea. But then, IIRC, PS does it this way. Ok, replace proposed solution with suggested placement of the button or whatever. Do you have an example use case where the user would benefit from that placement? The Skencil way of doing it definitely has the issue with clutter in the layer list. I right now have no idea how to avoid this, smaller icons would only help to a certain extent. But IMHO it is important to be able to quickly toggle the locking for multiple layers. Since we also want to address layer groups at some point. How does that integrate with locking? Currently I think that locking the layer group should also lock its children, the same way as making a layer group invisible makes its children invisible. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Layer locking proposal
Sven Neumann ([EMAIL PROTECTED]) wrote: Simon Budig [EMAIL PROTECTED] writes: Ok, replace proposed solution with suggested placement of the button or whatever. Do you have an example use case where the user would benefit from that placement? Alice and Bob are looking for the layer named Foobar. Due to the introduction of three new toggles in each row of the layer list and the inclusion of the opacity slider (after all it belongs there, doesn't it?), Alice needs to scroll the view horizontally in order to see the layer names. Alternatively she could make the layers dialog a lot wider. Actually I pondered about moving the opacity slider and yes, there are good reasons to move it more closely to the layer representation in the layers dockable. The major drawback of course is the necessary screen estate, and I don't think it'd be worth it. The same holds for the mode button. Bob uses a different layout. Only the visibility and linked toggles are in the row. The controls for opacity and state of the different locks are placed above the layer list. Bob can easily identify the layer he's looking for w/o having to scroll horizontally. Sure, if you'd naively extend the layers dialog with more columns it would become wide very quickly. A way to overcome this is to have e.g. two lines per layer. A sample mockup is available at http://www.home.unix-ag.org/simon/files/layer-dialog-many-properties.png When looking at this mockup the icons are awfully small, they probably need to become bigger, maybe making the layer entry higher. They also interfere with the readability of the layer names which probably can be remedied by sprinkling some design on them. There probably are better ways to layout the additional buttons without making the layer dockable wider. An advantage of these small indicators/toggles is, that we could get rid of the weird indicator for the existance of an alpha channel. Bold vs. Normal Text for the layer name is not very discoverable, a small icon could help (if we don't manage to get rid of the need for this indicator anyway). But IMHO it is important to be able to quickly toggle the locking for multiple layers. How is it important? Do you have an example use case? Actually I already described how I frequently use that feature in Skencil. To protect myself from working accidentially on the wrong layer I tend to lock a lot of layers there. Since my objects of interest usually are distributed among multiple layers I need to lock/unlock multiple layers at once. It were quite painful if I had to move the mouse between two different locations in the dialog instead of moving it from row to row in a sequential manner. There is an important difference between Gimp and Skencil though, which makes it less of an issue for Gimp. In Skencil you by default can operate on all objects in an image, regardless of their association to a layer. So yes, it is more important for Skencil than for Gimp to lock layers. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [EMAIL PROTECTED]: Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP]
Sven Neumann ([EMAIL PROTECTED]) wrote: [Fileselector] I do accept that but I would like people to point out exactly what problems they have instead of just saying that they dislike the new dialogs. Without detailed complaints we can't do anything to improve the situation. What occurred to me recently: The absence of a discoverable filename entry makes it quite hard to paste a filename into the fileselector. (plus the extra popping up window is quite annoying) Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS, screenshot plugin crash
William Skaggs ([EMAIL PROTECTED]) wrote:
Jean-Luc Coulon wrote:
The plugin crash with a popup :
Plud-in crashed: screenshot
I get the same result. Looking at the man pages, this apparently happens
if the key being grabbed has already been grabbed by something else --
but there does not seem to be any way to tell whether a given key
has already been grabbed. Which kind of sucks.
If XGrabKey might fail you can wrap it similiar to this:
gdk_error_trap_push ();
XGrabKey (GDK_DISPLAY_XDISPLAY (data-display),
data-hot_keycode,
AnyModifier,
GDK_WINDOW_XWINDOW (data-root),
TRUE,
GrabModeAsync,
GrabModeAsync);
gdk_flush ();
if (gdk_error_trap_pop ())
{
g_printerr (could not grab Hotkey. Aborting...\n);
exit (1);
}
Bye,
Simon
--
[EMAIL PROTECTED] http://simon.budig.de/
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
