[Gimp-developer] Where can I help?
Where can I help? Here's an ultra-short overview of my background: * 18 years overall development experience including software engineering, team leader, and senior IT management. * Expert-level C, C++, C#, etc. knowledge. * Extensive 3D design and development knowledge (texture mapping, 3D scene rendering, lighting, etc). * Decent knowledge of file format specs for most common image file formats, as well as some experience writing apps that make in-memory (on the fly) changes to image data. * Have tried my hand at various self-invented strategies for pattern recognition within image data. * Now working, oddly enough, in unrelated areas dealing with Lean Manufacturing, Quality Systems, etc. * Have been using GIMP for certain things for about 3 years or so. * Have some extra time I could devote . . . but will wait to quantify that until I hear where you need help. * Well, there's more . . . Let me know. Thanks, Steve Greenwalt Layton, Utah ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Where can I help?
Hi Steve, On Tue, Jan 25, 2011 at 09:35, Stephen Greenwalt wrote: > Where can I help? Here's an ultra-short overview of my background: I'm not a developer, but an long term Gimp user. I would suggest: 1. Go into the IRC channel to get direct feedback from the developers. 2. Try to checkout and compile the latest version from the git repository. 3. Have a look into the bugs with the gnome-love keyword: https://bugzilla.gnome.org/buglist.cgi?quicksearch=keywords%3Agnome-love+product%3A%22GIMP%22+ 4. Talk about the bug you are interested in. (IRC or mailinglist) 5. Add a patch to the bugreport. Alternativ you could help with gegl, have a look at this mail: https://lists.xcf.berkeley.edu/lists/gimp-developer/2011-January/026046.html Regards, Tobias ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Possible Future of ScriptFu/TinyFu with R6RS/Racket
(oops, forgot to send this) On Fri, 2011-01-21 at 13:32 +0100, Michael Natterer wrote: [...] > Yes, but still even the most basic, non grouped command might still > be triggering a whole series of atomic micro undo operations that > would go into an undo group associated with the command. I'm not sure why that's a problem. Probably I'm missing something. The _theory_ is that anything that changes the model goes through a command that is matched against a chain of handlers, with the default handler being the app core.. the _practice_ is that the granularity of that is up to the developers to expose or not expose, so if "open-as-layers" is an atomic command, then the handlers wouldn't ever see the "add layer" and "file open" commands happen and won't be able to change "open as layers" to position the layers automatically (for example). Long term, people writing scripts would probably push for more things to be exposed. > Look at the current set of undo pushing functions in > app/core/gimpimage-undo-push.h, which cover the entire set of > available user actions and PDB calls. They are really few > compared to what variety of manipulations are possible. It could change over time though. I'd really like to see things like the ability to call anything that has a keystroke or menu item or button to do it, for example. And at that point, if every menu command went through the command/handler chain, recording actions would be a lot more feasible. Or consider "undo last brush stroke and repeat with eraser instead"... We'll see - it's easier to have dreams than to dig ditches. Best, Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org www.advogato.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Where can I help?
On Tue, Jan 25, 2011 at 12:35 AM, Stephen Greenwalt < stephengreenw...@gmail.com> wrote: > Where can I help? Here's an ultra-short overview of my background: ... > Here's one suggestion that you could probably work on immediately, and would prepare you to work on other things if you are interested. Gimp has a plug-in called Lighting Effects that simulates the results of shining lights on 3D-deformed images. It is pretty fancy and sometimes gives neat results, but the rendering procedure it uses doesn't work as well as it could, because the triangles that it decomposes the surface into are too small -- you get a lot of faceting effects that a better algorithm would avoid. Plug-ins are more or less freestanding code, so it ought to be possible to improve the rendering without a huge investment of time in learning the whole architecture of Gimp -- but you would learn a substantial amount about the architecture as a side-effect of working on it. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Where can I help?
On 01/25/2011 09:35 AM, Stephen Greenwalt wrote: > Where can I help? It would be great to get help with bugs put on the 2.8 milestone: https://bugzilla.gnome.org/buglist.cgi?product=GIMP&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&target_milestone=2.8 Regards, Martin -- My GIMP Blog: http://www.chromecode.com/ "Nightly GIMP, GEGL, babl tarball builds" ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSoC 2011 announced
On 01/25/2011 05:52 AM, Alexandre Prokoudine wrote: > Google has just announced GSoC2011. Schumaml: Will you be our GSoC master this year too? If so, that would be great. Regards, Martin -- My GIMP Blog: http://www.chromecode.com/ "Nightly GIMP, GEGL, babl tarball builds" ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Where can I help?
Thanks for the info. I have used that filter many times, and I will take a look at what you describe. When light is cast against a 3D mesh, how that light diffuses over the surface can also be affected by whether the ray caster is using "vector normals", or "face normals", and other things. So, triangle size might just be part of the problem. On Tue, Jan 25, 2011 at 9:56 PM, Bill Skaggs wrote: > > On Tue, Jan 25, 2011 at 12:35 AM, Stephen Greenwalt < > stephengreenw...@gmail.com> wrote: > >> Where can I help? Here's an ultra-short overview of my background: ... >> > > Here's one suggestion that you could probably work on immediately, and > would prepare > you to work on other things if you are interested. Gimp has a plug-in > called Lighting Effects > that simulates the results of shining lights on 3D-deformed images. It is > pretty fancy and > sometimes gives neat results, but the rendering procedure it uses doesn't > work as well as it > could, because the triangles that it decomposes the surface into are too > small -- you get a > lot of faceting effects that a better algorithm would avoid. Plug-ins are > more or less freestanding > code, so it ought to be possible to improve the rendering without a huge > investment of time in > learning the whole architecture of Gimp -- but you would learn a > substantial amount about the > architecture as a side-effect of working on it. > > -- Bill > > ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Where can I help?
On 01/26/2011 06:55 AM, Stephen Greenwalt wrote: > Here's one suggestion that you could probably work on immediately, > and would prepare > you to work on other things if you are interested. Gimp has a > plug-in called Lighting Effects > Thanks for the info. I have used that filter many times, and I will > take a look at what you describe. Thank you for the offering. I would like to point out though that it would be even more helpful in the long term if the plug-in was ported to a GEGL operation so that we can use it when GIMP does its processing in linear light 32-bit RGBA. Regards, Martin -- My GIMP Blog: http://www.chromecode.com/ "Nightly GIMP, GEGL, babl tarball builds" ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Team Organization?
I have been reviewing Gimp / GEGL source code . . . to get familiar with everything . . . so that I have some context to understand where I might help the project. But I am operating in a "void" because I don't understand: - How the development effort is organized. - Is there a team leader? - What tools, etc. are being used to manage things such as: - Feature requests, bug reports, etc. - Component development. - Testing. - And all the other usual stuff. - What the development priorities are, and where programmer resources are needed. The main Gimp website says that the new priority is expansion of the GEGL engine. But, does that mean that major feature development for main Gimp app is being stopped until the GEGL engine is ready? I, for one, love Gimp but would really like to see one or new features such as: - Support for sub-layers (i.e. nesting of layers in tree-style control). - Ability to delete multiple layers at the same time, rather than one-by-one. - Layer-by-layer history . . . so that you can undo changes within the current layer only. Should I offer help in those areas? Again, I just need some context. Thanks, Steve Greenwalt ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Team Organization?
On 01/26/2011 08:15 AM, Stephen Greenwalt wrote: > I have been reviewing Gimp / GEGL source code . . . to get familiar with > everything . . . so that I have some context to understand where I might > help the project. > > But I am operating in a "void" because I don't understand: > > * How the development effort is organized. > > o > Is there a team leader? Strategic decisions are taken in concert, although due to human nature, the opinions of some individuals have more weight depending on their reputation. We have two official maintainers, cat MAINTAINERS. > o What tools, etc. are being used to manage things such as: > + > Feature requests, bug reports, etc. We prefer feature requests on this mailing list, so that they can be discussed and evaluated, in particular in the context of our product vision [1] Bug reports are managed in GNOME Bugzilla [2] > + Component development. In general, all development happens on the git master branch directly, although personally I think we should review our development methodology for GIMP 3.0 because we have problems in our 2.8 development cycles due to this. > + Testing. I have a long term goal of improving the GIMP development environment, and have lately put efforts into writing regression tests for both old and new functionality, and I have been setting up a nightly builder that runs all our tests [3]. Curiously enough, you'll notice make distcheck failed tonight due to changes yesterday, but I already fixed that... > * What the development priorities are, and where programmer > resources are needed. Right now, the priority is getting GIMP 2.8 out. The two major work areas left is finishing the implementations of layer groups and single-window mode, see [4] for the main missing bits. After that, we will start working on GIMP 3.0, which will be GIMP 2.8 running on GTK+ 3.0 and using GEGL-buffers for all data. That is, we will throw out our 8-bit only image/tile data structures. For GIMP 3.2 we will start looking into serious support for non-destructive editing. > > The main Gimp website says that the new priority is expansion of the > GEGL engine. > > But, does that mean that major feature development for main Gimp app is > being stopped until the GEGL engine is ready? See above > > I, for one, love Gimp but would really like to see one or new features > such as: > > * Support for sub-layers (i.e. nesting of layers in tree-style control). Fundamental support for that is already in place in git master > * Ability to delete multiple layers at the same time, rather than > one-by-one. Yes that would be nice, but support for higher bit depths and non-destructiveness has higher priority > * Layer-by-layer history . . . so that you can undo changes within > the current layer only. Sounds like a work-around for GIMP not having non-destructive editing yet > Should I offer help in those areas? Any help is greatly appreciated. Best regards, Martin [1] http://gui.gimp.org/index.php/GIMP_UI_Redesign#product_vision [2] http://bugzilla.gnome.org/browse.cgi?product=GIMP [3] http://gimptest.flamingtext.com:8012/waterfall [4] https://bugzilla.gnome.org/buglist.cgi?product=GIMP&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&target_milestone=2.8 -- My GIMP Blog: http://www.chromecode.com/ "Nightly GIMP, GEGL, babl tarball builds" ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
