gmane.comp.video.gimp.devel

[Gimp-developer] application suggestions to evaluate tool options -input needed

foser — 2012-05-24T19:08:45

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.

Thanks,
foser

[Gimp-developer] Merging visible paths via scripts

Gino D — 2012-05-24T10:37:37

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.

[Gimp-developer] feature: Set exclusive layer visibility withingroups

Richard Gitschlag — 2012-05-23T05:23:08

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 selected item is the only visible item in the whole image. (Whether the selected item is itself a layer or group is irrelevant.) Therefore, traverse the selected path again and ensure that any and all sibling items at any point along the path are made visible.

This would establish a toggle chain of all items -> selected group -> (subgroup, etc.) -> selected item in group -> all items.

It could also be reversed; all items -> selected item in group -> selected group -> (parent group, etc.) -> all items, but I'm not exactly sure how that logic would pan out.

Note that in the simple case of an image with no layer groups, this quickly reduces to the current behavior of all items -> selected layer -> all items. (This also applies when setting exclusive visibility on a top-level group, because in that case we DO want to act on the group as a whole).

[Gimp-developer] gimp-win downloads for 2.6

Ofnuts — 2012-05-22T23:48:50

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?

[Gimp-developer] Poor Display-Performance of Gimp 2.8 on Windows

Claus (Gimp-Devel-List — 2012-05-21T10:12:18

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 parasites to you ;-) Well, sadly I'm too, one of the many windows users, who can't develop applications on them self. So I sadly cant contribute to The Gimp, with more then bugreports.

I don't want to drop oil into the fire, and I really hope, that support for windows will not be dropped.

Back to the problem above. Is there already a bugreport for this issue? Shall I create one? Or doesn't it make sense, cos there is no windows-developer that could look into it?

If this won't be fixed, or at least not in the near future, is there a chance, we get updated 2.6 builds? Primarily security fixes, but also the latest fix for the JPEG-Issue introduced in 2.6.12?

Greetings
Claus

[Gimp-developer] Cross-application work-flows and document fileformats

Jon Nordby — 2012-05-21T01:26:54

Thread split out from [Gimp-developer] Gimp 2.8.0 - Saving in .jpg or
.png hmmmmm

On 20 May 2012 20:02, twfb <twfb09< at >gmail.com> 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. They import zero or
more documents, produce a new document there in GIMP and then will
pass this document on to another application.

For us to be able to significantly improve such work-flows, we need to
optimize the entire chain of activities (and the interfaces between
them). We cannot just focus on the activity inside GIMP in isolation.
This is especially true when the fraction of the total activity time
spent in GIMP is small compared to the time spent in the other
activities, or when moving between activities makes up a significant
amount of time.

Does such work-flows exist in the valid user scenarios for GIMP? I
would love to see the user scenarios we have already also include the
context in which GIMP is used, and how the usage of GIMP is related to
activities done in other applications.

To make this more tangible again, consider the case of creating
textures as part of creating a still render of a photorealistic 3D
scene. This is based on my  limited understanding of how 3d content
creation works, so do correct any false assumptions.
* [create-texture] A texture is created in GIMP either based on
existing resources (i.e. off the web or from company or artist stock),
or by starting from scratch (i.e. hand-painted or generated
procedurally). The same techniques as when starting from scratch may
also be applied when starting with a stock resource.
* [use-texture] The texture is used in Blender as part of a 3d scene.
The texture is put in after the objects in the scene have been
modeled, potentially before the camera setup and definitely before
lighting and compositing setup. The texture will be one of many
textures used in the scene.
* [try-render] A render is produced from the 3d scene using Blender.
If the output is not satisfactory, altering or changing the texture
may be needed. This can happen simply because the texture does not
look good enough, or a change in camera setup may give new
requirements for the texture. In rarer cases the objects in the scene
that the texture was used for might be replaced or removed entirely.
In all of these cases, this would mean going back to the
[create-texture] activity in GIMP. This process might be repeated
several times.

Currently you likely save your texture as .png file and import that
into Blender. But there are no intrinsic benefits of using a PNG file
in this work-flow. So I would argue that optimizing PNG export in GIMP
is the wrong place to optimize. Instead I propose the following steps
to improve it:
1. Make Blender be able to render the .xcf as a texture. Benefit: .png
export of .xcf or destructive .png save no longer necessary
2. Make Blender be able to "link" the texture to the original
document, and to have a "Edit texture" option that would open it up in
GIMP. Benefit: No longer necessary to re-establish the connection
between the two documents when iterating between changing the texture
and evaluating the render.
3. Make GIMP expose the documents it is currently working to Blender,
and let Blender provide a UI for importing these. Benefit: No longer
necessary to find the file on disk, or even know that it is an .xcf
file
4. Make GIMP expose changes to the active documents, and let Blender
automatically update the texture when it has changed. Benefit: Don't
have to explicitly refresh the texture inside Blender.
5. Implement 2-4 for GIMP itself. Benefit: When the texture is a
derivative work of other documents, those links will also be easy to
establish and maintain.

Point 5. above would directly address that as well.

There are some technical challenges to implement these steps, but they
are all doable. And I believe that they have a much higher potential
to improving this work-flow (and similar ones) than making it easier
to save PNG files.

[Gimp-developer] and if I don't have middle click ?

Cristian Secară — 2012-05-20T21:10:42

I wanted to (ex)change a color of a simple png image, so I tried to use
Colors -> Map -> 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

[Gimp-developer] Problems with brushes

Anke Lange — 2012-05-20T12:48:51

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 5 random.

Using the brush, doesn't display the word GIMP , It just jumbles it all 
up so something like GMMGGIP PPII comes out of it.

6. The Gimp Tool Options  "Smooth stroke" and "Incremental" don't show 
any affect on the stroke of any brush. Do they only effect brushes using 
a tablet?


It would be great if you could give me a hint on what I do wrong.
Mayby it is a problem with my system (Xubuntu 12.4) I used the packages 
to compile gimp, shortly after you annouced it.

Thanks a lot for having a look.

Anke

[Gimp-developer] Quasimode Adjustments -- fastest adjustments [demoincluded]

yahvuu — 2012-05-19T14:29:18

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 posting here

[Gimp-developer] contribution processes...

Saul Goode — 2012-05-18T23:25:04

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 treated as an openly developed "subproject" in which all are welcome to participate.

I would propose a "centralized, distributed" approach akin to the following:

A separate 'gimp-contrib' repository be created in which development of larger enhancements and more involved bugfixes takes place. Smaller bugfixes and enhancements could still employ the process of submitting patches through Bugzilla.

* A potential contributor submits a Bugzilla report outlining his issue and indicating that he/she is willing to work towards its resolution.

* Upon approval of the endeavor by the GIMP developers, the contributor is granted branching and commit privileges to the 'gimp-contrib' repository (if not already granted previously). This does NOT offer push privileges to the Gnome-hosted 'gimp' repository.

* The contributor solicits whatever support and aid for his project he/she can, through whatever channels he/she wishes. More significant aspects of the development should be inclusive of the official GIMP channels (mailing list, IRC, and the corresponding Bugzilla report), but smaller issues can be handled without much interference with the main project.

* Contributors are responsible for keeping their branch in synch with the GNOME 'gimp' module (or 'gimp-help-2', 'gimp-web', 'gimp-data-extras', etc) and following the feedback provided by the GIMP developers and the input of GIMP UI design team.

* Notably, contributors neither produce or submit patches; they focus on producing their code, incorporating suggestions, and persuading people to test it.

* When the contributor feels his project is in suitable shape for inclusion in GIMP, he/she requests that the GIMP developers merge his branch.

The process outlined above provides a solution that allows for distributed development that avails itself of the capabilities of GIT and scales to both the smallest and largest of 'subprojects'.

Contributors' abilities to get their code incorporated would ultimately depend upon their ability to attract the support of the GIMP developers but, importantly, they are initially welcomed to participate in the project and can learn incrementally the process of contributing to a large, community-run codebase.

The demand placed on GIMP developers to support this infrastructure should be expected to be less than the current method of contributors creating their own local branches and then submitting patches upon every changeset.

Contributors are permitted to fail without interfering with mainline development (the amount of imposition allowed fully determined by the individual members of the GIMP team) while maintaining a historical record that will hopefully be more complete and easily examined than the current approach. The bar to being granted access to this 'gimp-contrib' repository can be rather low, and even "speculative" enhancements or bugfix approaches can be afforded their chance to flourish.

Hopefully, there would eventually evolve greater participation in GIMP development amongst these contributors that would engender sharing of experiences and practices which, even if the end result is never fully incorporated, will prove educational and beneficial to the contributors, to the GIMP project, and to Free Software in general.

[Gimp-developer] contribution processes...

Crazy Aunt Gail's, LLC — 2012-05-18T23:17:58

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.

I would propose something akin to the following:

A separate 'gimp-contrib' repository be created in which development of patches takes place.

* A potential contributor submits a Bugzilla report outlining his issue and indicating that he/she is willing to work towards its resolution.

* They are responsible for keeping their branch in synch with the GNOME 'gimp' module (or 'gimp-help-2', 'gimp-web', 'gimp-data-extras', etc) and following the feedback provided by the GIMP developers and the input of GIMP UI design team.

* Notably, contributors neither produce or submit patches; they focus on producing their code, incorporating suggestions, and persuading people to test it.

* When the contributor feels his project is in suitable shape for inclusion in GIMP, he/she requests that the GIMP developers merge his branch.

The process outlined above provides a solution that allows for distributed development that avails itself of the capabilities of GIT and scales to both the smallest and largest of 'subprojects'.

The demand placed on GIMP developers to support this infrastructure should be less than the current method. Contributors are permitted to fail without interfering with mainline developme

[Gimp-developer] Wishlist: gegl Gaussian blur X&Y settings

Partha Bagchi — 2012-05-18T22:24:17

Hi All,

For the Gaussian blur gegl tool, is it possible to link the X & 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

[Gimp-developer] Feature request: Improve the Open file dialogthumbnails

Ryan Johnson — 2012-05-18T07:33:38

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 native "Open file" dialog.

Additional comments: I have seen no other modern program, even open source,
that has such an unusable thumbnail generator. If I recall correctly, there
is a free implementation in Evince Document reader for a regular
thumbnailer (thumbnail grid) and Open file dialog.

Bigger Goal:
Improve the "Open file" dialog to include other viewing modes besides a
detail list. It's a graphics program after all! Appeal to the senses!

[Gimp-developer] Cage-Tool performance

Anke Lange — 2012-05-18T06:44:09

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.net/gimp2-8/einst/screens/bild384.png

Thanks in advance.

Anke

[Gimp-developer] Targeted audience of GIMP?

gfxuser — 2012-05-18T04:13:27

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

[Gimp-developer] Gimp 2.8.0 - Saving in .jpg or .png hmmmmm

Markus Heiler — 2012-05-17T20:39:38

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 better and stronger with this blue GNOME pill!

I can see that my Gimp Overlords have also decided to gnomify Gimp.

I think that was a good move. We need to treat all users as potential idiots.

We must take away the Freedom of Choice. They only make the wrong
decisions anyway. And Choice leads to complexity, by taking away the
choice, we simplify everything.

At first I really was annoyed that the gimp overlords came down and told
us that this is now the future. That I have to adapt to them and their
wise decisions.

But now I think the gimp overlords are indeed right. We MUST gnomify
gimp!

Let's make more grand decisions and much needed changes.

I can already see that I am 40% faster using GIMP now! In fact, I
tell you, I already changed all my image files into this great gimp
.xfcggh format. Man, why didn't you tell me earlier that this is the
future! All my images are now sharper. And they load faster too.

Of course, in a parallel universe, we actually have some gimp
overlords who are not so self sure and decide that there shall
be no separation between users and developers instead. Bold
move of them. They surely made a mistake with that.

But the users seem happy! And the developers too, because
they can only be happy if the users are happy, in this strange
parallel universe....

So these happy guys, in that parallel universe, decide that there
COULD BE MORE THAN ONE WAY TO SOLVE A GIVEN PROBLEM.

They decide on, for instance:

- Keep the option to revert to the old behaviour in save dialog.
- Keep a default setting to choose in quality (the hint that the
image would lose quality could be in a status bar notification)
- Allow scripts (no, they gave up on LISP, there were too many
parens) to SIMULATE the old behaviour. Yes, that's right -
they use the save dialog, but they ENABLED a simple script
that converts into the target format of their choice. Even a
shell script would work for that - automatically save in the
.xfkhgghc format, convert into your target format, like .png,
then remove that .xfjhegkh image again. Et voila, the target
.png or .jpg was created! And the user was not annoyed at
all in any way.

Man, these guys in the parallel universe seemed SO HAPPY.

Sometimes I am jealous about these on the parallel universum,
but then I realize that the Freedom of Choice is a highly overrated
thing anyway.

I thank all gimp overlords for their wise choices and I hope
we will see many more great changes! Perhaps even a change
to modify images only when we are connected to the WWW?
Would that be to the liking of the gimp overlords?

I kid you not, but there are actually a few online editors out
there. They are a bit annoying, I suppose most of them use
Javascript - but yeah, you can crop an image at least...
resize it too... make a few other modifications...

The world would be a scary place if users could easily adjust
the behaviour of every component of their system indeed.

I also realized that according to:

http://libregraphicsworld.org/blog/entry/gimp-2.8-understanding-ui-changes

I am not the target audience.

Can the gimp overlords here on this list perhaps create a "gimp for
average joe" please? You know ... a simple gimp. Where the average
joe can use it and still feel to be the target audience.

Because I for one really dont feel as the target audience.

So my question actually is:

- What other image-editor can I use on Linux?

Please, I would like the gimp overlords to recommend to all average
joes out there what we shall use from now on.

[Gimp-developer] How to setup height of GTK-slider-widget in GIMP?

2012-05-17T15:40:01

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.

[Gimp-developer] hesitant about compiling a list...

peter sikking — 2012-05-17T14:19:30

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
<http://blog.mmiworks.net/search/label/teaching> )

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 release gets is
caused by us not communicating ‘yes, we have problems.’

- coordinating between open technical project work (GEGL
migration, etc.) and interaction design project work.

- the big picture concerning UI becomes clearer because it is
written down.


so far so good. but while talking to Bruce I realised that there
are a couple of side effects to this list that make me hesitate to
just go and get started with compiling it:

- just thinking of what I can contribute to this list, I know
that this list is _not_ going to be short. also because all the
issues that I can put on it are ‘medium level to big-picture,’
none of them are going to be trivial to solve. thus my hesitation
is what this is going to make GIMP look like, and if the definitions
of open worked where meant to stretch this far.

- all of the issues that will end up on the list have been
created by contributors to GIMP. some of these issues have been
created 10 years ago, some of them last month. I wonder what it
will feel like to GIMP contributors when something they just made,
almost ‘immediately and automatically,’ (at least, feels like that
to them) ends up on the UI issue list.

so I would like to hear some opinion on this.

    --ps

        founder + principal interaction architect
            man + machine interface works

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

[Gimp-developer] Liquid rescale

gfxuser — 2012-05-17T09:44:04

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 you are looking for more things to change and use in your 
interaction design courses I suggest to look around in the current GIMPs 
dialogs. There are many unintuitive options, which look too scientific 
for an average user. Or could you explain blindfolded the difference 
between IIR and RLE in the Gaussian blur dialog, even if the results 
most times look the same? How about the dialog 'Path to selection' (see 
https://bugzilla.gnome.org/show_bug.cgi?id=671152)?
These results could then go back into GIMP, with benefits for all. I 
would like to read more from your courses.

To avoid misunderstandings and unnecessary uproars: yes I like GIMP, its 
name, Wilber and I'm sure I'm going to like goats, too ;-))

Best regards,

grafxuser

[Gimp-developer] Faster tarball distribution using server push

Bernhard Stockmann — 2012-05-15T13:58:43

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

[Gimp-developer] Script icon

Jan Stria — 2012-05-15T10:14:16

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