<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.comp.video.gimp.devel">
    <title>gmane.comp.video.gimp.devel</title>
    <link>http://blog.gmane.org/gmane.comp.video.gimp.devel</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.video.gimp.devel/22049"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.video.gimp.devel/22045"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.video.gimp.devel/22036"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.video.gimp.devel/22035"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.video.gimp.devel/21998"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.video.gimp.devel/21997"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.video.gimp.devel/21994"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.video.gimp.devel/21987"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.video.gimp.devel/21972"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.video.gimp.devel/21964"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.video.gimp.devel/21962"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.video.gimp.devel/21960"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.video.gimp.devel/21917"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.video.gimp.devel/21909"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.video.gimp.devel/21904"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.video.gimp.devel/21888"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.video.gimp.devel/21887"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.video.gimp.devel/21884"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.video.gimp.devel/21882"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.video.gimp.devel/21876"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.comp.video.gimp.devel/22049">
    <title>[Gimp-developer] application suggestions to evaluate tool options -input needed</title>
    <link>http://comments.gmane.org/gmane.comp.video.gimp.devel/22049</link>
    <description>&lt;pre&gt;Hello,

as mentioned earlier a new UI design project has started under the
supervision of Kate and Peter with a focus on the Tool Options. The
current progress can be found on
http://gui.gimp.org/index.php/Work_in_progress .

For the next step we are looking to evaluate GIMP using the user
scenarios mentioned in the link above, the scenarios are firmly rooted
in the vision described. Besides evaluating GIMP we will also be
looking at a number of (similar) applications and their use of Tool
Options or equivalant UI elements.

Of course we have some applications in mind, but we would also like to
hear from you what applications you think of if you think about
working with tools and manipulating their options in a graphics
manipulation context. Name the application and a short description of
how it supports and/or interferes with your workflow.

We will use the suggestions here as a basis for the list of
applications to be evaluated in this design process.

I'm eager to find out what you all come up with.

Than&lt;/pre&gt;</description>
    <dc:creator>foser</dc:creator>
    <dc:date>2012-05-24T19:08:45</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.video.gimp.devel/22045">
    <title>[Gimp-developer] Merging visible paths via scripts</title>
    <link>http://comments.gmane.org/gmane.comp.video.gimp.devel/22045</link>
    <description>&lt;pre&gt;Hi.

I'm searching for the Script-Fu procedure corresponding to the "Merge
Visible Paths" widget available in the "Path" context menu, but so far
I have been able neither to find it nor to devise a way to do the same
by using other procedures.

Have I missed something? Or the reason is that the Procedure Database
doesn't currently provide this unique command yet?
If so, is there anyone who can suggest or at least draft me a code
snippet aimed to implement the aforesaid operation?

Thanks in advance.
&lt;/pre&gt;</description>
    <dc:creator>Gino D</dc:creator>
    <dc:date>2012-05-24T10:37:37</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.video.gimp.devel/22036">
    <title>[Gimp-developer] feature: Set exclusive layer visibility withingroups</title>
    <link>http://comments.gmane.org/gmane.comp.video.gimp.devel/22036</link>
    <description>&lt;pre&gt;
I have a little gripe about setting "exclusive visibility" (shift+click a layer's visibility icon) in an image.  Now that we have layer groups in GIMP 2.8, it only functions on the "top level" of the layer stack -- it seems impossible to toggle exclusive visibility inside a group.

Since a layer group can itself be a complex combination of layers (apparently including other layer groups!), we should have some ability to toggle exclusive visibility with respect to other members in that group only.

For example, the current behavior could be expanded from a simple on/off toggle to an iterative loop somewhat like this:

1 - When toggling exclusive visibility, first note the full path from image root to the selected item (inclusively) and begin iterating through it.
2 - IF at any point along this path there are any visible sibling items, THEN hide them, leaving only the selected item visible, and break and return.
3 - Otherwise, if we have traversed the entire path without finding any visible siblings, then sel&lt;/pre&gt;</description>
    <dc:creator>Richard Gitschlag</dc:creator>
    <dc:date>2012-05-23T05:23:08</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.video.gimp.devel/22035">
    <title>[Gimp-developer] gimp-win downloads for 2.6</title>
    <link>http://comments.gmane.org/gmane.comp.video.gimp.devel/22035</link>
    <description>&lt;pre&gt;Unless I'm overlooking something, the gimp-win download pages on 
Sourceforge offer either 2.8 (stable version), or 2.4 and older 
("Previous Gimp versions" page), but 2.6 is no longer referenced. 
Wouldn't it be nice if the "Previous Gimp versions" page listed at least 
one 2.6 installer?
&lt;/pre&gt;</description>
    <dc:creator>Ofnuts</dc:creator>
    <dc:date>2012-05-22T23:48:50</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.video.gimp.devel/21998">
    <title>[Gimp-developer] Poor Display-Performance of Gimp 2.8 on Windows</title>
    <link>http://comments.gmane.org/gmane.comp.video.gimp.devel/21998</link>
    <description>&lt;pre&gt;
Hello Gimp Developers,

First of all, thanks for your efforts in making Gimp better and better. I'm a longtime Gimp User, and really love the program.

I loved to read about all the new features, that 2.8 brings to the table. Nevertheless, I was disappointed a lot, after testing it for a few minutes. The Viewport/Display/Canvas (don't know what you call it) is soooo extremely slow, compared to 2.6. Some examples:

When using the Rectangular Select Tool, the redraw-rate of the selection is extremely slow compared to 2.6.

Even worse. When I move a image in the window with the MiddleMouseButton, then the image totally breaks apart.

After that, I stopped testing, but I'm sure there are other tools and Situations, where this issues occur.

I have already read, that there is not a single developer in your team, which uses windows as his/her development-environment. And that you even consider to stop the support for windows platform. I can understand that thinking. Windows users must seem like a big croud of par&lt;/pre&gt;</description>
    <dc:creator>Claus (Gimp-Devel-List</dc:creator>
    <dc:date>2012-05-21T10:12:18</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.video.gimp.devel/21997">
    <title>[Gimp-developer] Cross-application work-flows and document fileformats</title>
    <link>http://comments.gmane.org/gmane.comp.video.gimp.devel/21997</link>
    <description>&lt;pre&gt;Thread split out from [Gimp-developer] Gimp 2.8.0 - Saving in .jpg or
.png hmmmmm

On 20 May 2012 20:02, twfb &amp;lt;twfb09&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:

Thanks for bringing the workflows/tasks you have do into the
discussion. That makes it much easier to have a fruitful discussion.

You say that only task 1 can potentially benefit from saving as xcf.
XCF is the only format that can store what you have done to the image
in a non-destructive way, and allow you to go back and change these
decisions. In your work-flows 2-4, do you never go back to an image
after having modified and saved it? Do you, like many others, keep an
original .png and export the modified version as a .png with a
different name, so you can always get the original?

For instance when preparing textures and bump-maps, do you ever go
back to tweak the textures after having used them in a Blender render
(after looking at the initial result)?


I think your cases highlights one important thing: users will often
(always) use GIMP as part of a bigger work-flow.&lt;/pre&gt;</description>
    <dc:creator>Jon Nordby</dc:creator>
    <dc:date>2012-05-21T01:26:54</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.video.gimp.devel/21994">
    <title>[Gimp-developer] and if I don't have middle click ?</title>
    <link>http://comments.gmane.org/gmane.comp.video.gimp.devel/21994</link>
    <description>&lt;pre&gt;I wanted to (ex)change a color of a simple png image, so I tried to use
Colors -&amp;gt; Map -&amp;gt; Color Exchange... tool.

There I am invited to "Middle-click inside preview to pick "From
color"". Where to middle click ? I only have a two button touchpad. I
switched the working place to my main dektop computer where the wheel
button is set to magnify function. I had to change the wheel button
to "middle click" function just to be able to pick the "From color"
from the original image.

I suppose I could use previously the color picker, write down the
desired color value and then enter manually the value in the "From
color" area of the Color exchange, but what is then the purpose of all
features of the tool ?

Cristi

&lt;/pre&gt;</description>
    <dc:creator>Cristian Secară</dc:creator>
    <dc:date>2012-05-20T21:10:42</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.video.gimp.devel/21987">
    <title>[Gimp-developer] Problems with brushes</title>
    <link>http://comments.gmane.org/gmane.comp.video.gimp.devel/21987</link>
    <description>&lt;pre&gt;Hello list

I'm having a closer look at the use of brushes and I came across a few 
things, that were easy to use in the previous gimp (2.6) and now they 
are not there anymore. And some of the new features don't seem to work 
for me. So are they a features or bugs? Well, I just make a little list ;)

1. Why don't the brushes show their real size when aktivated?
The tool seems to adopt the settings of the previous used brush.

2. How can I paint adopting the gradiant for brush-colors?
When using brush-dynamics random-color, it does use the gradient-color, 
but not in the correct sequence.

3. Using brushes with a minimum distance of 1 lieves a gap using a brush 
caligraphic-brush with an angle of 40%.

4. The mapping matrix for the dynamic settings of the bushes is not 
editable. How can I edit this map to use on my own brushes?

5. When making a grayscale gih-brush, it doesn't display adopt the 
setting-procedures
Like when you create a brush to write GIMP using 5 layers. G, I, M, P, 
empty. Settings: ranks&lt;/pre&gt;</description>
    <dc:creator>Anke Lange</dc:creator>
    <dc:date>2012-05-20T12:48:51</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.video.gimp.devel/21972">
    <title>[Gimp-developer] Quasimode Adjustments -- fastest adjustments [demoincluded]</title>
    <link>http://comments.gmane.org/gmane.comp.video.gimp.devel/21972</link>
    <description>&lt;pre&gt;Dear all,

for your inspiration, here's the fastest way to perform adjustments that i can think of:

While pressing a shortcut key
    - the corresponding slider gets displayed right under the pointer
    - moving the pointer left-right immediately performs the adjustment. 
To commit, simply release the key.

You may try the following channel mixer demo to test-drive the interaction:
https://sites.google.com/site/yahvuu/stuff/quasimode-adjust-demo.swf?attredirects=0

For the Flash-averse, there's also a screenshot available:
http://yahvuu.files.wordpress.com/2009/08/quasimode-adjust.png


The rationale behind is that most of the adjustments are relative adjustments by nature,
by which i mean that the absolute numbers are mostly irrelevant. The desired amount of
the effect gets determined by applying a bit more or less of it until it looks right.

Grabbing the slider handle is only cognitive burden here, which can be shortcut away.


enjoy,
yahvuu


PS: Flash demos do not fit the UI brainstorm well, so i'm po&lt;/pre&gt;</description>
    <dc:creator>yahvuu</dc:creator>
    <dc:date>2012-05-19T14:29:18</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.video.gimp.devel/21964">
    <title>[Gimp-developer]  contribution processes...</title>
    <link>http://comments.gmane.org/gmane.comp.video.gimp.devel/21964</link>
    <description>&lt;pre&gt;I apologize for the double-post; my mail system barfed and apparently sent a draft version of my post. Here is a more refined version.

In my opinion the language of the draft is not very inviting to contribution. At minimum, each of the "has to"s should be changed to either "should"s or "should strive to"s. Also, it is unclear whether the final "does not have to be perfect" trumps any or all of the previous seven bullet points -- if it does not then the requirements are indeed exceedingly stringent.

Especially problematic is the sixth bullet. A contributor should not be expected to learn or have access to other platforms just so he can submit code; he should write his code to work on his development system and those with access to and familiarity with alternative deployments should be able to submit patches or propose changes to accommodate their systems. This suggests that the infrastructure to support contributor participation should be hierarchical in nature; i.e., each enhancement/bugfix should be trea&lt;/pre&gt;</description>
    <dc:creator>Saul Goode</dc:creator>
    <dc:date>2012-05-18T23:25:04</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.video.gimp.devel/21962">
    <title>[Gimp-developer]  contribution processes...</title>
    <link>http://comments.gmane.org/gmane.comp.video.gimp.devel/21962</link>
    <description>&lt;pre&gt;In my opinion the language of the draft is not inviting to contribution. At minimum, each of the "has to"s should be changed to either "should"s or "should strive to"s. Also, it is unclear whether the final "does not have to be perfect" trumps any or all of the previous seven bullet points -- if it does not then the requirements are indeed exceedingly stringent.

Especially problematic is the sixth bullet. A contributor should not be expected to learn or have access to other platforms just so he can submit code; he should write his code to work on his development system and those with access to and familiarity with alternative deployments should be able to submit patches or propose changes to accommodate their systems. This suggests that the infrastructure to support contributor participation should be hierarchical in nature; i.e., each enhancement/bugfix should be treated as an openly developed "subproject" in which all are welcome to participate. 

I would propose something akin to the following:

A separa&lt;/pre&gt;</description>
    <dc:creator>Crazy Aunt Gail's, LLC</dc:creator>
    <dc:date>2012-05-18T23:17:58</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.video.gimp.devel/21960">
    <title>[Gimp-developer] Wishlist: gegl Gaussian blur X&amp;Y settings</title>
    <link>http://comments.gmane.org/gmane.comp.video.gimp.devel/21960</link>
    <description>&lt;pre&gt;Hi All,

For the Gaussian blur gegl tool, is it possible to link the X &amp;amp; Y size
settings so that they scroll together? More often than not, you are
likely to use the same value in both directions.

Thanks,
Partha
&lt;/pre&gt;</description>
    <dc:creator>Partha Bagchi</dc:creator>
    <dc:date>2012-05-18T22:24:17</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.video.gimp.devel/21917">
    <title>[Gimp-developer] Feature request: Improve the Open file dialogthumbnails</title>
    <link>http://comments.gmane.org/gmane.comp.video.gimp.devel/21917</link>
    <description>&lt;pre&gt;I've been using GIMP to play around with some lighting, color, and GEGL
operations on images.
What I've noticed is that the "Open file" dialog is very poorly constructed
and it has become a problem. I'm using Win7 x64.
Nicely put, it's unintuitive.

These are suggested fixes, and you can choose more than one if it permits.

1. Raise the file size limit for autogeneration of thumbnails.
Many of my JPEGs are just slightly over 3 MB or whatever the small current
limit is. Many of my RAW NEF files are just *under* 10 MB, at a resolution
of 10.2 Megapixels. Many dSLR's exceed my camera's resolution, so my
recommended upper limit is 20 MB, but doing a progressive scan (priority
queue) would work best. Start out with anything under 5 MB, then 10, then
20 MB, so it is a rough priority queue, instead of a fine-grain one.

2. Allow users to multiselect files and explicitly batch-generate
thumbnails (just clicking on the thumbnail placeholder with multiple images
selected should initiate the process).

3. Use the nativ&lt;/pre&gt;</description>
    <dc:creator>Ryan Johnson</dc:creator>
    <dc:date>2012-05-18T07:33:38</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.video.gimp.devel/21909">
    <title>[Gimp-developer] Cage-Tool performance</title>
    <link>http://comments.gmane.org/gmane.comp.video.gimp.devel/21909</link>
    <description>&lt;pre&gt;Hi

First of all it is a great tool! And I love it. but I found some strange 
behaviour, so before I start a new bugreport, I wanted to ask you, if 
this is a bug or just something that's got to do with my system (Linux 
Xubuntu)

First: when I made a cage and want to adjust the knots, I can't. I have 
to create a new cage. But when I create the cage new and close it, it 
cuts my picture into bits. The only way to avoid this, yet, is to 
restart Gimp and load the motiv new.
Is there another way around this?

Second: I tried out, whether I get a difference in making a cage closer 
to the motif or leaving a wider gap between motif and cage. Using the 
adjustment of filling the background with color.

Normally, the background becomes transparent, when I use the option, but 
when I create a cage on the edge of the motif, the background becomes 
filled with a part-transperent background.

I made some pictures of this:

http://ws.kreativ-workshops.net/gimp2-8/einst/screens/bild384.png

http://ws.kreativ-workshops.&lt;/pre&gt;</description>
    <dc:creator>Anke Lange</dc:creator>
    <dc:date>2012-05-18T06:44:09</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.video.gimp.devel/21904">
    <title>[Gimp-developer] Targeted audience of GIMP?</title>
    <link>http://comments.gmane.org/gmane.comp.video.gimp.devel/21904</link>
    <description>&lt;pre&gt;Hi,

the last thread reminded me of a question, which I had for some longer 
and I couldn't find the right answer yet:
Who is the targeted audience of GIMP?

Reading the product vision and the document 'GIMP 2.8 understanding UI 
changes' I don't see a clear definition of that, but only two groups: 
artists and scientists. Where are the non-professional artists and spare 
time enthusiasts? I'm also missing a clearer definition of the expected 
experience level. Only professionals seem to be addressed.
Are the other people not targeted? Clearing this as a part of the 
product vision would be a big help to avoid misunderstandings.

Best regards,

grafxuser
&lt;/pre&gt;</description>
    <dc:creator>gfxuser</dc:creator>
    <dc:date>2012-05-18T04:13:27</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.video.gimp.devel/21888">
    <title>[Gimp-developer] Gimp 2.8.0 - Saving in .jpg or .png hmmmmm</title>
    <link>http://comments.gmane.org/gmane.comp.video.gimp.devel/21888</link>
    <description>&lt;pre&gt;Greetings my Gimp Overlords,

I have lately tried the new and shiny Gimp 2.8.0 in anticipation of
the all the praised
greatness that was to come.

And the world was good for it seemed wonderful!

Until I tried to save my .jpg image into a .png ....

It now, hmm, forces me to store in a super awesome cool format...
called xfccxghgf
something. I mean, half the world knows the name, I just can't
remember the name.

Gimp Image Format? .gif ? Nah, that can't be it ...

Something like ...xfce xfe xfc.

Anyway. I now realize that I can't save my image like I used to be able to.

Hmm. Interesting improvement. I always wondered why I used to be able to
simply save an image. I always wanted to have someone else tell me that
the way it used to work is no longer allowed.

Yay!

I have a bit of a deja vu though. It reminds me of GNOME reloaded. You know
what happened to GNOME? People called "developers" asked 100000 people
and found out that this was the new, optimal way to use GNOME. Very clever!

I am now so much bette&lt;/pre&gt;</description>
    <dc:creator>Markus Heiler</dc:creator>
    <dc:date>2012-05-17T20:39:38</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.video.gimp.devel/21887">
    <title>[Gimp-developer] How to setup height of GTK-slider-widget in GIMP?</title>
    <link>http://comments.gmane.org/gmane.comp.video.gimp.devel/21887</link>
    <description>&lt;pre&gt;
Hello,

is there a way to setup the height of the GTK-slider-widget (like for  
opacity of a layer) in GIMP via a .rc file?

I didn't use a tablet and the new sliders consume a lot of space.

Thanks.
Bart.
&lt;/pre&gt;</description>
    <dc:creator>bart&lt; at &gt;neeneenee.de</dc:creator>
    <dc:date>2012-05-17T15:40:01</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.video.gimp.devel/21884">
    <title>[Gimp-developer] hesitant about compiling a list...</title>
    <link>http://comments.gmane.org/gmane.comp.video.gimp.devel/21884</link>
    <description>&lt;pre&gt;guys,

a couple of days ago Bruce appeared on irc and we had a chat.
(Bruce is now subscribed to this list)

within a minute we were talking about whether GIMP has a list
of known UI design issues. as far as I know we do not have one,
it is certainly not part of gui.gimp.org.

(I am not talking about a bug list, with nuts and bolts issues,
I am talking about a list of medium level to big-picture
issues and to-dos. the kind of design tasks I pick for my
teaching are medium size ones, see
&amp;lt;http://blog.mmiworks.net/search/label/teaching&amp;gt; )

Immediately I realised this list is missing and that there
are real benefits to maintaining a list like that:

- a clear list of design tasks to pick one from for
people who want to contribute or run projects in
interaction design;

- GIMP as a project says clearly ‘yes, we know we have problem
with XYZ in the UI.’ this can make certain discussions a lot
shorter, by pointing at the list. also I feel that _part_ of the
‘GIMP has so far to go’ feedback that the 2.8 rel&lt;/pre&gt;</description>
    <dc:creator>peter sikking</dc:creator>
    <dc:date>2012-05-17T14:19:30</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.video.gimp.devel/21882">
    <title>[Gimp-developer] Liquid rescale</title>
    <link>http://comments.gmane.org/gmane.comp.video.gimp.devel/21882</link>
    <description>&lt;pre&gt;Hi,

I read the news about Liquid rescale's UI redesign at GIMP's main site 
and Peter's blog. It looks very promising. Especially I like team's no. 
3 results.
Are there plans to take these changes over to the current plugin and/or 
make Liquid rescale an official tool/plugin of GIMP?

One thing that could be changed are the many options 'advanced 
settings', 'rigidity' and 'algorithm parameters'. They look complicated. 
Perhaps more meaningful names could be found or they will be discarded 
in the UI and replaced internally by appropriate defaults. IMHO there 
should be one intuitive way with a few very easy steps, just like the 
current scale tool. They are: optionally make a selection on the image, 
show an outline with clickable handles to change dimensions, optionally 
paint discard and preservation masks, confirm or cancel. I you like I 
can provide a screenshot of the IMHO quite intuitive way of the 
equivalent tool in Photoshop Elements, but I think team's #3 proposal 
matches this best.

Peter, if &lt;/pre&gt;</description>
    <dc:creator>gfxuser</dc:creator>
    <dc:date>2012-05-17T09:44:04</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.video.gimp.devel/21876">
    <title>[Gimp-developer] Faster tarball distribution using server push</title>
    <link>http://comments.gmane.org/gmane.comp.video.gimp.devel/21876</link>
    <description>&lt;pre&gt;Dear GIMP developers,

I'd like to make a suggestion that could improve the distribution of 
tarballs on FTP servers:

https://bugzilla.gnome.org/show_bug.cgi?id=676099

What do you think about this? If you like I could talk with the mirror 
operators and assist you in setting up such a push system for GIMP. This 
would make it possible to have tarballs distributed to all servers 
within minutes, so you don't have to wait with the announcement, and the 
problem the tarball is available but not announced can be avoided.

Best regards,
Bernhard/devvv
&lt;/pre&gt;</description>
    <dc:creator>Bernhard Stockmann</dc:creator>
    <dc:date>2012-05-15T13:58:43</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.video.gimp.devel/21870">
    <title>[Gimp-developer] Script icon</title>
    <link>http://comments.gmane.org/gmane.comp.video.gimp.devel/21870</link>
    <description>&lt;pre&gt;Hello!

I am writing my own plugin for Gimp in Python. It will be shown in Image menu. Is it possible to tell Gimp to show an icon for the menu item? For example Configure Grid menu item has an icon.

And if it is not possible, would it be possible for C plugin? Would it show icon associated with the .exe file?

Thank you
&lt;/pre&gt;</description>
    <dc:creator>Jan Stria</dc:creator>
    <dc:date>2012-05-15T10:14:16</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.video.gimp.devel">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.video.gimp.devel</link>
  </textinput>
</rdf:RDF>

