Sign up now! · Forgot password?
RSS/Atom feed identi.ca Twitter

donations for GIMP 2.8

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

23 of 23 messages available
Toggle history

Please log in to manage your subscriptions.

donations for GIMP 2.8 Sven Neumann 06 Jan 22:01
  donations for GIMP 2.8 Martin Nordholts 06 Jan 23:27
   donations for GIMP 2.8 Alexia Death 07 Jan 08:12
    New adjustment widgets Cedric Sodhi 07 Jan 09:57
     New adjustment widgets Cedric Sodhi 07 Jan 10:02
     New adjustment widgets Cedric Sodhi 07 Jan 10:06
      New adjustment widgets Mike Williams 07 Jan 11:28
     New adjustment widgets peter sikking 07 Jan 11:55
      New adjustment widgets Thorsten Wilms 07 Jan 13:30
       New adjustment widgets peter sikking 07 Jan 13:42
      New adjustment widgets Burnie West 07 Jan 19:42
    donations for GIMP 2.8 "Michael Mur 10 Jan 17:05
     donations for GIMP 2.8 " 10 Jan 17:17
      donations for GIMP 2.8 Cedric Sodhi 10 Jan 17:35
      donations for GIMP 2.8 Alexia Death 10 Jan 17:39
       donations for GIMP 2.8 " 10 Jan 18:45
        donations for GIMP 2.8 "Michael Mur 10 Jan 21:24
       donations for GIMP 2.8 Sven Neumann 10 Jan 22:01
   donations for GIMP 2.8 Sven Neumann 17 Jan 21:46
    donations for GIMP 2.8 Mike Williams 17 Jan 22:32
     donations for GIMP 2.8 Ofnuts 17 Jan 22:50
    donations for GIMP 2.8 Alexia Death 23 Jan 17:20
  donations for GIMP 2.8 Michael Schumacher 06 Jan 23:35
Sven Neumann
2011-01-06 22:01:28 UTC (over 3 years ago)

donations for GIMP 2.8

Hi,

I guess most of you noticed that several people blogged about the fact that GIMP 2.8 has not yet been released even though the schedule that Martin published a while ago estimated that this would have happened by the end of 2010. As far as I can see this is the article that started it all:

http://libregraphicsworld.org/news.php?readmore=667

And this post suggested that donating to the GIMP project could help us to achieve our goal of releasing GIMP 2.8 earlier:

http://www.omgubuntu.co.uk/2010/12/single-window-gimp-release-delayed-but-why/

I just wanted to let you know that we have seen a dramatic increase in donations since then. More than 120 people donated over the last 8 days and sent us about 2,500 dollars. Perhaps it would be a good idea to discuss how we can actually use this money to make the GIMP 2.8 release happen soon...

Sven

Martin Nordholts
2011-01-06 23:27:02 UTC (over 3 years ago)

donations for GIMP 2.8

On 01/06/2011 11:01 PM, Sven Neumann wrote:

I just wanted to let you know that we have seen a dramatic increase in donations since then. More than 120 people donated over the last 8 days and sent us about 2,500 dollars. Perhaps it would be a good idea to discuss how we can actually use this money to make the GIMP 2.8 release happen soon...

Here are some examples of what I think blocks a GIMP 2.8 release:

* Finish single-window mode * Make layer masks work with layer groups * Bug 596410 - gimp-image-get-filename returns NULL for imported files * Bug 597117 - impossible to drop a group as a sibling inside a group * Bug 612931 - Moving individual layer in layer group not possible with Move Tool
* Bug 600554 - Implement layer group transforms * Bug 624303 - Introduce an item class in PyGIMP * Bug 630748 - display filters do not work * Bug 631766 - Bad performance when moving brush outline on canvas

One natural use of money donated specifically to speed up a GIMP 2.8 release would be in the form of bounties for fixing bugs that blocks GIMP 2.8 from being released. I know we have a history of disliking bounties, but as far as I know we never really tried, and now we have money more or less ear-marked for this purpose.

We must not put bounties on things with vague scope like "Finish single-window mode", that won't work. We can only put bounties on things where the work to be done is well-defined, like for

* Bug 596410 - gimp-image-get-filename returns NULL for imported files

If the work to be done in order to get the bounty is unclear, we *will* get into problems.

I also think bounties shall only be claimable by people who would not do the work if there wasn't a bounty. For example, I won't and can't claim the bounty if I fix bug 596410, since I would have fixed it long ago if my spare time was infinite.

One tricky question is what the size of the bounty should be for each bug... Let's discuss that if we can agree on that we want to try bounties at all.

I think it is also worth to contemplate why we are in this situation where we want to make release, but can't because there's too much work left to do. The reason we are in this situation is because we develop features on the branch we make releases from. If things don't go as expected, like the case has been for single-window mode for example, we don't have any place to make releases from. The solution to this is of course to develop big features on feature branches. Basically, it should not be allowed to commit code to git master that is known to put the branch in an unreleasable state. We'll have good reasons to revisit this topic when we start working on GIMP 3.0...

/ Martin

Michael Schumacher
2011-01-06 23:35:52 UTC (over 3 years ago)

donations for GIMP 2.8

On 06.01.2011 23:01, Sven Neumann wrote:

I just wanted to let you know that we have seen a dramatic increase in donations since then. More than 120 people donated over the last 8 days and sent us about 2,500 dollars. Perhaps it would be a good idea to discuss how we can actually use this money to make the GIMP 2.8 release happen soon...

Alexia suggested that we get Peter a tablet. I think this is an excellent idea - first-hand experience with different input devices should help a lot when planning for GIMP user interaction, especially with any of the tools.

I'd say we should aim for the same model Mitch got recently - an Intuos 4 plus an Art Pen.

Regards,
Michael

Alexia Death
2011-01-07 08:12:01 UTC (over 3 years ago)

donations for GIMP 2.8

On Fri, Jan 7, 2011 at 1:27 AM, Martin Nordholts wrote:

One natural use of money donated specifically to speed up a GIMP 2.8 release would be in the form of bounties for fixing bugs that blocks GIMP 2.8 from being released. I know we have a history of disliking bounties, but as far as I know we never really tried, and now we have money more or less ear-marked for this purpose.

While this will work for clean-cut and simple bugs, this really isnt where we are hurting most now.

Here is the list of things where we I think are really really hurting: * GTK2 tablet support is totally busted. Mitch is fixing GTK3, but releasing now would mean crippled tablet support all around. 2.6 people can downgrade, we cant.
*GUI specs are declared a blocker for anything, but there are none, so even if I have time for coding I'm not allowed to do it. Peter is working on this by looking interns. But this is pretty much the reason that only one doing any serious work is Mitch... * *This bit is important* Nobody to implement Peters glorious specs. I can't, because most of them don't just require using GTK, but writing widgets en masse, Martin and Sven are busy with life, mitch is fixing GTK3... There is nobody on the team with those skills and the time required so any specs that do get written just generate frustration. * SWM and the fact, that nobody has been working on it for a year is also caused by two points above.

Long story short, we need another GTK person on the team. One that CAN write widgets and as a paid employee cant just wander off when Peter tells him to do something he doesn't like.

I think it is also worth to contemplate why we are in this situation where we want to make release, but can't because there's too much work left to do. The reason we are in this situation is because we develop features on the branch we make releases from. If things don't go as expected, like the case has been for single-window mode for example, we don't have any place to make releases from.

I agree to this.

The solution to this is of
course to develop big features on feature branches. Basically, it should not be allowed to commit code to git master that is known to put the branch in an unreleasable state. We'll have good reasons to revisit this topic when we start working on GIMP 3.0...

But not with this. Having a summary dirty development branch is very important. If it has to be the same as releases branch, can be debated. But without continuous integration agile development does not work. You end yup with a handful of forks that don't fit together. Anything left in the isolated branches too long will suffer bit rot. But git offers interesting options. Perhaps theres a way to have the cake and eat it too.

Cedric Sodhi
2011-01-07 09:57:40 UTC (over 3 years ago)

New adjustment widgets

I'd like to bring up an idea that does not seem too difficult to implement and that should replace the unusuable slider widgets for, say, brush size. If you are okay with that, I might implement it.

The sliders are virtually useless because they cover a fixed range from 0 to without any intelligent behaviour. For the brush size, for example, that means you can at best alter the brush size in 20px steps with a reasonably big toolbox.

There have been some good suggestions on IRC already, how this could be handled more intellegently. Coming from another software package which has, that's at leat my opinion, one of the best interfaces that I've ever seen, I want to port over one idea which has become quite popular in contemporary software, that is, using the whole screen for adjusting the value.

Usually, you can start dragging on the textfield (MMB) and drag all the way over the screen while the size adjusts, if you hit the screen border, your pointer is reset to the opposite border, so you can practically keep dragging infinitely.

The problem with that kind of solution is, that it works in particularly well with *relative* input devices, which are the most used for common software. In order to achieve a similar intelligent solution for absolut input devices, we need something else:

The central idea: You must be able to keep dragging infinitely. The solution: See sketch attached

It looks complicated at first but to use it you don't really have to understand the technical implementation. For the sake of clarity, a little on-screen field appears, indicating the mode of operation, but the principle works equally well without any indicator than the changing value in the textbox and dragging blindly over the whole screen.

=> Dragging the pointer horizontally will increase or decrease the value
=> Dragging the pointer vertically will increase or decrease the amount by which the value changes when dragging horizontally

In colors above is the mathematical modelation for a quanified grip of the principle. Notice that h(x) actually indicates the *change* of the value - not the absolute value itsself.

For the implementation there are a few more details to mind (which, the user doesn't have to worry about, becaue the operation itsself behaves intutionally):

-> Which Point in the field will the cursor start in when starting to drag?
-> How is the functional combination of what I called g(y) and h(x)? Is a linear or non-linear function practical? -> How are g(y) and h(x) scaled in particular - that should be most likely be decided on a per-use basis. -> If we choose a non-exponential form for g(y), the value of which might drop below 0 (and thus invert the behaviour of horizontal dragging), what should happen if the user drags below the 0-line? An idea would be that the 0-line shifts accordingly. -> Same question as above applies to h(x). Here it will most likely make sense to have the 0-Assymptode shift accordingly as it will me the most intuitive interaction (for values which per se can't drop below a specified minimum)

And optional, separate idea: It would be great if the user could change the specifications above (->) himself in a context menu. But that is just nice to have.
Mathematical sidenote, if we choose a non linear form for either g(y) or h(x), the curl of the vector field will increase to the left, hence rotating at the left has a bigger effect - see examples:

A few examples of (very intuitive) operation:

* Increase a tiny bit: Drag downwards, drag left * Increase a lot: Drag upwards, drag left * Increase infinitely: Drag somewhere to the the left, drag circles CCW * Decrease infinitely: Drag somewhere to the the left, drag circles CW * Tediously increase very carefully, without limits: Like above, just at the right instead of the left

The implementation of that is probably less lines than this email is long. The complete algorithm can run isolated for the widget, implementing the little overlay which shows navigation instructions is most likely to be the most difficult thing to do and a piece of cake.

-- Cedric

Cedric Sodhi
2011-01-07 10:02:33 UTC (over 3 years ago)

New adjustment widgets

I'd like to add a PS addressing all mouse-only users who might read this:

I'm aware that dragging circles with the mouse can be tedious and hence, of course, the principle of wrapping over at the screen border is still in.

Cedric Sodhi
2011-01-07 10:06:14 UTC (over 3 years ago)

New adjustment widgets

Sorry for the confusion. The attachment I tried submitting is too big and awaits moderation, hence I'm going to resend a smaller version so you can see at least something.

Again, sorry, I messed up

Mike Williams
2011-01-07 11:28:10 UTC (over 3 years ago)

New adjustment widgets

On Fri, Jan 7, 2011 at 5:06 AM, Cedric Sodhi wrote:

Sorry for the confusion. The attachment I tried submitting is too big and awaits moderation, hence I'm going to resend a smaller version so you can see at least something.

Why don't you post your other attachment on the web somewhere to avoid the list restrictions?

Mike

peter sikking
2011-01-07 11:55:34 UTC (over 3 years ago)

New adjustment widgets

Cedric Sodhi wrote:

I'd like to bring up an idea that does not seem too difficult to implement and that should replace the unusuable slider widgets for, say,
brush size. If you are okay with that, I might implement it.

The sliders are virtually useless because they cover a fixed range from
0 to without any intelligent behaviour. For the
brush size, for example, that means you can at best alter the brush size
in 20px steps with a reasonably big toolbox.

I think I have something there for us that is more straightforward:

two things actually:

#1 is what I got the Krita guys to implement during a sprint of theirs that I attended, it was based on my work on #2 actually. It works for long sliders in dialog boxes, not for our tool options panels.

say you got a slider going from 1 to 1000. then divide the slider range (in pixels) in 3 equal parts, so that each handles a decade:

|-- 1–10 --|-- 10–100 --|-- 100–1000 --|

within each third the increase/decrease of value is linear.

the Krita guys love this system (hardcore tablet users, btw), but as I said: only for long sliders.

#2 is where I developed the whole idea. I was working on tool options widgets that would allow the whole tool options dockable to be exactly 2 toolbox icons wide (normal icon size, the need for the small theme goes away a.f.a.t. toolbox is concerned):

top to bottom those are are 1 popup selection list, 4 sliders and two 'checkboxes' (on/off switches), in real 1-to-1 size. yes, cut off texts are shown fully on mouse-over: this is GIMP and usage is trained, so position; (part) identification and feedback (could better on the checkbox, I see now) are what count.

you can see here where the current experimental sliders in git come from. Krite did their #1 sliders in this form, but not the following:

so how are these tiny sliders going to work? well click the mouse button down on the slider (not on the number) and this pops up:

with the current value right under the mouse position, so releasing in panic does not change the slider value.

moving vertically you switch decades, horizontally everything is linear within a decade. one could easily add decades, having a range factor of a million for instance (e.g. 0.01–10000) when that is needed.

grocking is simple, motions (up/down, left/right) are linear, feedback always there. is there a flaw? yes: popping up at the screen's edge, and wanting the 'value right under the mouse' to work.

--ps

founder + principal interaction architect man + machine interface works

http://blog.mmiworks.net: on interaction architecture

Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Thorsten Wilms
2011-01-07 13:30:30 UTC (over 3 years ago)

New adjustment widgets

On Fri, 2011-01-07 at 12:55 +0100, peter sikking wrote:

Aside of differences in labeling (of course not unimportant), it's the same concept as
http://www.sidefx.com/docs/houdini9.5/basics/ladder right?

peter sikking
2011-01-07 13:42:30 UTC (over 3 years ago)

New adjustment widgets

Thorsten Wilms wrote:

On Fri, 2011-01-07 at 12:55 +0100, peter sikking wrote:

Aside of differences in labeling (of course not unimportant), it's the same concept as
http://www.sidefx.com/docs/houdini9.5/basics/ladder right?

vertically: yes, close enough

horizontally: no (dragging in thin air?)

single click popup, single move adjust: yes

primitive text widget with no slider scale: no

(just to be exact)

--ps

founder + principal interaction architect man + machine interface works

http://blog.mmiworks.net: on interaction architecture

Burnie West
2011-01-07 19:42:18 UTC (over 3 years ago)

New adjustment widgets

On 01/07/2011 03:55 AM, peter sikking wrote:

< snip >

say you got a slider going from 1 to 1000. then divide the slider range (in pixels) in 3 equal parts, so that each handles a decade:

|-- 1–10 --|-- 10–100 --|-- 100–1000 --|

within each third the increase/decrease of value is linear.

This looks neat -- OTOH as tablets get more multitouch the current trend seems to be touch speed controls rate of change nonlinearly. Mouse tracking could execute this way. Looks hard, tho :-)

-- Burnie

Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
"Michael Mur
2011-01-10 17:05:54 UTC (over 3 years ago)

donations for GIMP 2.8

Hi everyone,

You may know me as the student who coded the cage tool during this summer.

I'd like to add something about these bounty. For me, the key point for the health of the community dev of Gimp is the current difficulty to be used to the codebase. I myself had a hard time to understand how things works in the code, and how to do things. The main cause of these difficulty is the lack of technical documentation. We sometimes need to read hundred lines of code just to know what an objet actually do. The code architecture is obscur for most of the dev, and if we loose the key dev, we will have hard time. If i haven't the pressure of the GSOC program, I probably abandoned.

I once asked why we don't have these documentation. The answer i had is that writing documentation is boring, that's like that in free software, you just have to deal with.

That's a vicious circle. The less we have docs, the less we have dev. And so, and so ...

My idea is to use this money to reverse the trend. Lets give bounty for these docs. Here is some example of documentation I think is needed:
- How to write a cool GObject for Gimp - How to write a cool Gegl op
- A summary of what do core object if it's not already documented

Just have a look on what Blender's dev do to present their work, and compare Blender and Gimp activity.
http://code.blender.org/index.php/2011/01/a-look-at-point-cache/

I hope this message will go somewhere ...

-- Michael Muré

Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
"
2011-01-10 17:17:51 UTC (over 3 years ago)

donations for GIMP 2.8

On Mon, Jan 10, 2011 at 5:05 PM, Michael Muré wrote:

You may know me as the student who coded the cage tool during this summer.

I'd like to add something about these bounty. For me, the key point for the health of the community dev of Gimp is the current difficulty to be used to the codebase. I myself had a hard time to understand how things works in the code, and how to do things. The main cause of these difficulty is the lack of technical documentation. We sometimes need to read hundred lines of code just to know what an objet actually do. The code architecture is obscur for most of the dev, and if we loose the key dev, we will have hard time. If i haven't the pressure of the GSOC program, I probably abandoned.

I once asked why we don't have these documentation. The answer i had is that writing documentation is boring, that's like that in free software, you just have to deal with.

That's a vicious circle. The less we have docs, the less we have dev. And so, and so ...

snip<

My idea is to use this money to reverse the trend. Lets give bounty for these docs. Here is some example of documentation I think is needed:
>snip <

Code documentation is also one of the tasks that are not permitted for instance in the Google summer of code, perhaps we could come up with a set of bounties, or find someone motivated and fund them on a task by task basis or even part time for documenting?

For a while, almost all the time I spent on GEGL (to the detriment of progress wrt features and performance) was spent on cleaning it up, and documenting it, website - references and more; this in case I decided to completely drop the ball or get consumed by other things, what I added was far from enough; and being the actual originator of much of the things in GEGL I am almost a bit "cursed by knowledge" and thus not the person best suited for it. Getting more documentation sure will be one of the best ways of making it easier to involve more people (and I am sorry for any bits of almost existing docs that aren't fully integrated yet.)

/pippin --

Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Cedric Sodhi
2011-01-10 17:35:14 UTC (over 3 years ago)

donations for GIMP 2.8

On Mon, Jan 10, 2011 at 05:17:51PM +0000, Øyvind Kolås wrote:

Code documentation is also one of the tasks that are not permitted for instance in the Google summer of code, perhaps we could come up with a set of bounties, or find someone motivated and fund them on a task by task basis or even part time for documenting?

For a while, almost all the time I spent on GEGL (to the detriment of progress wrt features and performance) was spent on cleaning it up, and documenting it, website - references and more; this in case I decided to completely drop the ball or get consumed by other things, what I added was far from enough; and being the actual originator of much of the things in GEGL I am almost a bit "cursed by knowledge" and thus not the person best suited for it. Getting more documentation sure will be one of the best ways of making it easier to involve more people (and I am sorry for any bits of almost existing docs that aren't fully integrated yet.)

/pippin

I'm not entitled to advance my opionion in this case but I'd like to add that I agree that good documentation and clean(ed up) code are a huge benefit - in many regards. And that, at least, I can truthfully say as a non developer, a good documentation would not only make it more likely that I'd be motivated to participate (for my defense at that point, I currently don't because I'd majorly lack the time), it would even draw me to the code. I like good code. And as for the time argument, if I didn't feel that reading code to get just up par with you would take several man-days (...) on its own, I would more likely get started. And I think many people feel more or less the same (for any OSP)

Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Alexia Death
2011-01-10 17:39:18 UTC (over 3 years ago)

donations for GIMP 2.8

On Monday, January 10, 2011 19:17:51 Øyvind Kolås wrote:

Code documentation is also one of the tasks that are not permitted for instance in the Google summer of code, perhaps we could come up with a set of bounties, or find someone motivated and fund them on a task by task basis or even part time for documenting?

I think this is a frightfully good idea too. One of those tasks could be writing the GIMP code Codex. Coding standards and best practices and so on. It could give us much easyer to merge forks for example. Its extremely annoying having to rewrite most of a great feature to make it fit for merge.... And yes, I do remember my starting days trying to make sense of the GIMP on the inside.

Best,
Alexia

Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
"
2011-01-10 18:45:37 UTC (over 3 years ago)

donations for GIMP 2.8

On Mon, Jan 10, 2011 at 5:39 PM, Alexia Death wrote:

On Monday, January 10, 2011 19:17:51 Øyvind Kolås wrote:

Code documentation is also one of the tasks that are not permitted for instance in the Google summer of code, perhaps we could come up with a set of bounties, or find someone motivated and fund them on a task by task basis or even part time for documenting?

I think this is a frightfully good idea too. One of those tasks could be writing the GIMP code Codex. Coding standards and best practices and so on. It could give us much easyer to merge forks for example. Its extremely annoying having to rewrite most of a great feature to make it fit  for merge.... And yes, I do remember my starting days trying to make sense of the GIMP on the inside.

Note that many of the documents/the start of the documentation described or desired do already exist but might not be appropriately pointed to, and it has already been created and contributed to without monetary reward. Lets hope use of rewards wouldnt scare off people from contributing such work for free.

/pippin

Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
"Michael Mur
2011-01-10 21:24:33 UTC (over 3 years ago)

donations for GIMP 2.8

2011/1/10 Øyvind Kolås

Lets hope use of rewards wouldnt scare off people from contributing such work for free.

It could be a one-time operation, with clearly defined goal and bounty. Just the time we need to have these needed documentation.

Michael Muré
Sven Neumann
2011-01-10 22:01:34 UTC (over 3 years ago)

donations for GIMP 2.8

On Mon, 2011-01-10 at 19:39 +0200, Alexia Death wrote:

On Monday, January 10, 2011 19:17:51 Øyvind Kolås wrote:

Code documentation is also one of the tasks that are not permitted for instance in the Google summer of code, perhaps we could come up with a set of bounties, or find someone motivated and fund them on a task by task basis or even part time for documenting?

I think this is a frightfully good idea too. One of those tasks could be writing the GIMP code Codex. Coding standards and best practices and so on. It could give us much easyer to merge forks for example. Its extremely annoying having to rewrite most of a great feature to make it fit for merge.... And yes, I do remember my starting days trying to make sense of the GIMP on the inside.

But who could write (and review) such docs? That would be the core developers and we really need the core developers to work on GIMP 2.8. Focusing on developer documentation is not going to make GIMP 2.8 happen earlier. On the contrary, it is likely to delay it further.

Please try to come up with suggestions that focus on the 2.8 release. Thanks.

Sven

Sven Neumann
2011-01-17 21:46:43 UTC (over 3 years ago)

donations for GIMP 2.8

On Fri, 2011-01-07 at 00:27 +0100, Martin Nordholts wrote:

On 01/06/2011 11:01 PM, Sven Neumann wrote:

I just wanted to let you know that we have seen a dramatic increase in donations since then. More than 120 people donated over the last 8 days and sent us about 2,500 dollars. Perhaps it would be a good idea to discuss how we can actually use this money to make the GIMP 2.8 release happen soon...

Here are some examples of what I think blocks a GIMP 2.8 release:

* Finish single-window mode * Make layer masks work with layer groups * Bug 596410 - gimp-image-get-filename returns NULL for imported files * Bug 597117 - impossible to drop a group as a sibling inside a group * Bug 612931 - Moving individual layer in layer group not possible with Move Tool
* Bug 600554 - Implement layer group transforms * Bug 624303 - Introduce an item class in PyGIMP * Bug 630748 - display filters do not work * Bug 631766 - Bad performance when moving brush outline on canvas

One natural use of money donated specifically to speed up a GIMP 2.8 release would be in the form of bounties for fixing bugs that blocks GIMP 2.8 from being released. I know we have a history of disliking bounties, but as far as I know we never really tried, and now we have money more or less ear-marked for this purpose.

So far this has been the most constructive idea that has been brought up in this thread. So why not? Let's try to come up with a list of bugs that block the GIMP 2.8 release and put bounties on them. Who wants to volunteer to prepare a list of bugs that are worth having a bounty put on them?

The stream of donations has dropped a little but there is still significantly more money coming in than usual. We have received more than $1,000 in the last 7 days.

Sven

Mike Williams
2011-01-17 22:32:57 UTC (over 3 years ago)

donations for GIMP 2.8

On Mon, Jan 17, 2011 at 4:46 PM, Sven Neumann wrote:So far this has been the most constructive idea that has been brought up

in this thread. So why not? Let's try to come up with a list of bugs that block the GIMP 2.8 release and put bounties on them. Who wants to volunteer to prepare a list of bugs that are worth having a bounty put on them?

Sven

Hi there. This has been effective for google and mozilla, sounds like it is worth a try. I've got one week before school starts, if the list appears soon, I'd be inclined to try to fix something.

Peace,

Mike

Ofnuts
2011-01-17 22:50:15 UTC (over 3 years ago)

donations for GIMP 2.8

On 01/17/2011 11:32 PM, Mike Williams wrote:

On Mon, Jan 17, 2011 at 4:46 PM, Sven Neumann > wrote:So far this has been the most constructive idea that has been brought up

in this thread. So why not? Let's try to come up with a list of bugs that block the GIMP 2.8 release and put bounties on them. Who wants to volunteer to prepare a list of bugs that are worth having a bounty put on them?

Sven

Hi there. This has been effective for google and mozilla, sounds like it is worth a try. I've got one week before school starts, if the list appears soon, I'd be inclined to try to fix something.

Ideally CS professors would be lured into giving assignments around GIMP bug fixing... And this would introduce students to real-world programming.

Alexia Death
2011-01-23 17:20:15 UTC (about 3 years ago)

donations for GIMP 2.8

On Mon, Jan 17, 2011 at 11:46 PM, Sven Neumann wrote:

Who wants to
volunteer to prepare a list of bugs that are worth having a bounty put on them?

I believe it can only work if the bugs are nominated by developers who are prepared to "mentor" whoever is doing it for the bounty. I can dredge through my stuff, but Mitch and Martin and pippin for gegl should really do the same for their own stuff.