I just tried to enhance the general options for transform tools (see http://docs.gimp.org/en/gimp-tools-transform.html#gimp-tool-transform) .

Unfortunately I don't get what "crop to result" and "crop with aspect" actually do. Can somebody explain that to me on the list please?

Your question got no answer.

That's a problem I have met since I have started writing help. Most often, experimenting, reading books, reviews, gimp forums, bugzilla, I can write explanations. And if I am wrong, others will correct.

There still remain some features, especially new functions, that I can't explain.
I can't read C code.
That's why I think that developers should write some explanations about the new features they add to GIMP. This list seems to be the right place for that.

If we can't get help from developers, I am afraid that some FIXME will persist
for ever.

Julien

Hi,

On Tue, 2008-02-05 at 06:40 +0100, julien wrote:

Your question got no answer.

Which is not at all surprising since Axel asked on the gimp-docs mailing-list. Guys, when you need to get an answer from the developers, then please ask on the gimp-developer list or at least on the gimp-user list. Who are you trying to reach here? There is probably no developer but me subscribed to this list and I don't always have the time to answer.

Sven

Hi,

On Fri, 2008-02-01 at 23:22 +0100, Axel Wernicke wrote:

Unfortunately I don't get what "crop to result" and "crop with aspect" actually do. Can somebody explain that to me on the list please?

The general idea is described here:

http://svenfoo.geekheim.de/index.php/2006-12-26/transform-and-crop/

Please let me know if you need more information.

Sven

Which is not at all surprising since Axel asked on the gimp-docs mailing-list. Guys, when you need to get an answer from the developers, then please ask on the gimp-developer list or at least on the gimp-user list. Who are you trying to reach here? There is probably no developer but me subscribed to this list and I don't always have the time to answer.

Are you sure?
We are NOT developers. You well know them: I am afraid that we will be severely rejected with our dummy questions. Is "Developers should give some explanations about their new functions for doc-writers" a bad idea?

Julien

On Tue, Feb 05, 2008 at 09:35:47AM +0100, julien wrote:

Which is not at all surprising since Axel asked on the gimp-docs mailing-list. Guys, when you need to get an answer from the developers, then please ask on the gimp-developer list or at least on the gimp-user list. Who are you trying to reach here? There is probably no developer but me subscribed to this list and I don't always have the time to answer.

Are you sure?
We are NOT developers. You well know them: I am afraid that we will be severely rejected with our dummy questions. Is "Developers should give some explanations about their new functions for doc-writers" a bad idea?

I don't think it's a bad idea, but I also think we could use the developers or users mailinglist to ask questions about functions implemented in GIMP.

This list is intended to discuss documentation related topics anyways...

Greetings,

Sven Neumann ha scritto:

The general idea is described here:

http://svenfoo.geekheim.de/index.php/2006-12-26/transform-and-crop/

For your, and others, information the two relevant links to Mukund site in your post have moved.

This is the new one (that I think contains both): http://www.mukund.org/journal/2006-12.html

Greets

julien (Dienstag, 5. Februar 2008, 06:40):

There still remain some features, especially new functions, that I can't explain.
I can't read C code.

If you could, you would find out (that's my experience) that the code is not documented. Typically no comments about the underlying algorithm, no headers explaining what which functions is doing, no word about the function parameters, etc. etc. [1]

For the developer everything is clear when he is coding (so he could easily describe what happens within his code), but there's no chance for a documenter unless he wants to spend many hours with the source code (since, of course, the functions called by the relevant function and the functions using this relevant function are also not documented...).

Ulf

[1] See e.g. "gimp_transform_resize_crop()" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /lists/gimp-docs/attachments/20080205/4680b1fb/attachment.bin

Hi,

On Tue, 2008-02-05 at 09:35 +0100, julien wrote:

Is "Developers should give some explanations about their new functions for doc-writers" a bad idea?

Not at all. It is a good idea. That's why you are encouraged to ask the developers to explain the features so that you can document them. But you are not going to reach the developers here. Please ask such questions on the gimp-user list. Enough developers are subscribed there.

Sven

Hi,

On Tue, 2008-02-05 at 12:43 +0100, Ulf-D. Ehlert wrote:

For the developer everything is clear when he is coding (so he could easily describe what happens within his code), but there's no chance for a documenter unless he wants to spend many hours with the source code

You are not supposed to read the source code to find out what is going on. What a waste of time. If something is not obvious, please ask.

From a developer point of view it is actually a lot more important to

write well-structured code with self-explaining function and variable names than to add comments. But if you want to discuss coding style, then we should really move this discussion to the gimp-developer list.

Sven

Sven Neumann (Dienstag, 5. Februar 2008, 20:20):

What a waste of time.

Exactly!

BTW, everything may be considered to be a waste of time, even developing GIMP. ;-) Remember, we use computers to solve problems we wouldn't have without computers...

From a developer point of view it is actually a lot more important to write well-structured code with self-explaining function and variable names than to add comments.

Useful function and variable names are of course essential, but not sufficient. And there are many variables with self-explaining names, but also many without.

But if you want to discuss coding style, then we should really move this discussion to the gimp-developer list.

Yet another pointless discussion (waste of time, hmm ;-) )? Better just agree with me that we disagree... :-)

Ulf

-------------- next part -------------- A non-text attachment was scrubbed... Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /lists/gimp-docs/attachments/20080206/82967f83/attachment.bin

Hi,

On Wed, 2008-02-06 at 20:04 +0100, Ulf-D. Ehlert wrote:

Useful function and variable names are of course essential, but not sufficient. And there are many variables with self-explaining names, but also many without.

Feel free to send patches to improve this.

Sven

Sven Neumann (Donnerstag, 7. Februar 2008, 08:31):

Hi,

On Wed, 2008-02-06 at 20:04 +0100, Ulf-D. Ehlert wrote:

Useful function and variable names are of course essential, but not sufficient. And there are many variables with self-explaining names, but also many without.

Feel free to send patches to improve this.

This is a nice catch-22.

Ulf

Hi,

On Sat, 2008-02-09 at 15:28 +0100, Axel Wernicke wrote:

Thanks for the link. I think I now understand what this option is supposed to do. Assuming there is an one layer image, rotated by 45? with clipping set to "with adjust", there will be a layer with some transparent edges.

Well, it's more targetted at small adjustments as you typically need to do to correct for a slightly tilted camera.

Now lets set clipping to "Crop to result" and rotate the layer with - -45?. What I would expect ist, that the in the result the layer/image would be cropped to the original size - meaning that the transparent border will be removed.

What happens instead is, that the layer size is reduced to 1x1 pixel! (GIMP 2.4.4 at Mac OS X)

Anything I could have done wrong here?

You have run into bug #472644.

Sven

Hi,

On Sat, 2008-02-09 at 22:05 +0100, Axel Wernicke wrote:

You have run into bug #472644.

OK, that makes sense. Unfortunately this bug is not exactly new. What do you think, might it make sense to put a note about the malfunction as note into the manual?

Of course I hope that it is going to be fixed at some point. But it would certainly make sense to notify the user that the algorithm works nicely for small transformations but that is has issues when it is applied on, for example, a rotation by 45 degrees.

Sven