Re: [Gimp-developer] [wish] alignment rotation

2009-05-15 Thread Alec Burgess

saulgo...@flashingtwelve.brickfilms.com wrote:

Quoting Rob Antonishen rob.antonis...@gmail.com:

  

there is such a plugin. I think I saw it in the Meet the Gimp forums.



I wrote the following script a while back for a coin collector who  
wanted to easily crop his scans and rotate them so that the coin was  
oriented properly.


The interface I used was to click-drag a path from the top of the coin  
to the bottom. The resulting path had only one anchor (at the coin's  
top) but the control handle was used as the second point.


The script would require some modification but might provide a kludgy  
functionality for those needing it.


http://flashingtwelve.brickfilms.com/GIMP/Scripts/sg-rotate-to-path-points.scm


A discussion over the evolution of the script took place on the  
GIMPtalk forums:


http://www.gimptalk.com/forum/-script-fu-efficient-rotating--cropping-tool-t32052.html-st=0sk=tsd=a

Not sure whether its transient or permanent but above URL gives:

   SQL ERROR [ mysql4 ]
   Table './gimptalk_lbsql/phpbb_sessions' is marked as crashed and
   should be repaired [145]
   An sql error occurred while fetching this page. Please contact an
   administrator if this problem persists.

I found it in Google-cache at: http://tinyurl.com/qsoekx or:

   http://www.google.com/url?sa=tsource=webct=clnkcd=1url=h
   ttp%3A%2F%2F74.125.95.132%2Fsearch%3Fq%3Dcache%3A_D5mPzozc2I
   J%3Awww.gimptalk.com%2Fforum%2F-script-fu-efficient-rotating
   -%2526-cropping-tool-t32052.html%2Bscript-fu%2Befficient%2Bc
   ropping%2Brotating%2Btool%26cd%3D1%26hl%3Den%26ct%3Dclnkei=
   -AcNSs6-HZvMMIzdnLcGusg=AFQjCNEPHJMcZdNESQ2G7123a3IN04Uh0w
   sig2=rYkYIcfwZHEse-9-8zvxaA


I grabbed your  script from flashingtwelve.brickfilms URL above, set a 
path with Path tool and when I ran it (GIMP 2.6.6 - Windows XP SP3) got 
this in the error console:


 GIMP Error
   Calling error for procedure 'gimp-image-crop':
   Procedure 'gimp-image-crop' has been called with value '-160' for
   argument 'offx' (#4, type GimpInt32). This value is out of range.

 GIMP Warning
   Plug-In 'Rotate To Path Point' left image undo in inconsistent
   state, closing open undo groups.

 GIMP Error
   Execution error for 'Rotate To Path Point':
   Error: Procedure execution of gimp-image-crop failed on invalid
   input arguments: Procedure 'gimp-image-crop' has been called with
   value '-160' for argument 'offx' (#4, type GimpInt32). This value is
   out of range.

I notice that at the bottom of the original conversation the OP 
(StefanP) has a recent  unanswered problem (Sun Apr 26, 2009 2:18 am) 
after updating to GIMP 2.6 (not exactly the same error as  I got):


   It is me again. After upgrading to Ubuntu 9.04 and Gimp 2.6 I am now
   getting the following error after setting the path and executing the
   script:

   Execution error for 'Rotate To Path Point':
   Error: Bad syntax of binding spec in let* : ((vectors) (stroke-id)
   (points) (x1) (y1) (x2) (y2) (center-x) (center-y) (radius) (angle)
   (foo (car (gimp-image-get-filename image

--
Regards ... Alec   (bura...@gmail  WinLiveMess - alec.m.burg...@skype)

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] [wish] center on focused area on zoom out

2009-05-15 Thread Alec Burgess

Maciej Pilichowski (bluedz...@wp.pl) wrote (in part)  (on 2009-05-14 at
09:08):

 But for zooming out there is no such cheap workaround. Image:

 DEFGHIJK|12345|ABC
 DEFGHIJK|12345|ABC

 letters are off the screen, digits are visible. | denotes edges

 Now -- I would like to zoom out on 5 (I would like to focus on that 
 area), how do I do? 

 a) move mouse over 1 (sic!) and zoom out
 b) move mouse over 5, zoom out, and then scroll the image

 ad.b) this is tiresome
 ad.a) this is completely counter-intuitive, in order to zoom out 
 element X I need to zoom out the opposite of X. This is more 
 problematic with conversion when car driver gets on yacht 
 (left-right problem) 
   
If you've zoomed in using the Zoom tool and drawing an area with 
mouse-click and drag ...
as you say - not easily discoverable, but once discovered, moving mouse 
to extreme left (or slightly better results extreme top left)  appears 
to leave desired area always visible though at some point a mouse wheel 
scroll may be necessary.

However (I hadn't tried this before) if with zoom-tool you do 
Ctrl+click+drag to define area of interest then release AFAICT the 
area of interest always remains visible. Possible problem (?) - you 
may find it zooms out too quickly. Again AFAICT ctrl+drag-drop a 
large area gives better results than a small area.
ie. small area  vs large area zoom-out may indicate why ctrl+click 
zoom-out may be giving you problems?
 And more about (a) -- while zooming in, the mouse cursor movement is 
 small, so I can live with that, but on zooming out, the movement is 
 huge -- it is entire screen.

 The wish:
 
 Please recenter focused area on zoom out (and possible on zoom in).

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] [wish] center on focused area on zoom out

2009-05-15 Thread Maciej Pilichowski
On Friday 15 May 2009 09:06:25 Alec Burgess wrote:

 However (I hadn't tried this before) if with zoom-tool you do
 Ctrl+click+drag to define area of interest then release AFAICT
 the area of interest always remains visible. Possible problem (?)
 - you may find it zooms out too quickly. 

I tried it and I see several problems:
* as you mentioned, it zooms out too quickly
* it is totally inaccurate, gimp seems cannot to shift the image, so 
the portion I am interested in is centered, in test case it was area 
near the edge of the image and after zooming out it was at the right 
border of the window
* it requires a lot of clicking, dragging with LMB hold down is a hard 
to do for people with even mild disabilities
* it requires to change the tool

I am not saying this (above) functionality should be removed, but the 
new one added. I would then:
* point out the area, no dragging
* press + or - key

End. I would get nice, smooth zoom, any change of the focus-area would 
be totally easy to, just move the mouse.

Cheers,
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] [wish] center on focused area on zoom out

2009-05-15 Thread Sven Neumann
Hi,

On Thu, 2009-05-14 at 15:08 +0200, Maciej Pilichowski wrote:

 DEFGHIJK|12345|ABC
 DEFGHIJK|12345|ABC
 
 letters are off the screen, digits are visible. | denotes edges
 
 Now -- I would like to zoom out on 5 (I would like to focus on that 
 area), how do I do? 

What is your definition of focusing on that area? Focusing on the 5
for means having 5 under the mouse pointer. And that is exactly how zoom
is implemented right now. You put 5 under the mouse pointer and no
matter if you zoom in or out, it will stay there. Now how can you
possibly argue that this is not intuitive and useful? I seriously don't
understand your problem. Nor do I understand what changes you are
suggesting.

 Possible solution:
 --
 The centering idea -- please note that I am open to any other idea 
 that would lead to productivity boost. Let's focus on zoom out:
 * I point out the area
 * I zoom out
 * gimp know which area I would like to focus on, so the whole image is 
 scrolled
 in such way, that the area travels towards center of the window

How is the center of the window relevant? What counts is what's under
the cursor as that is where you are going to work next.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] [wish] center on focused area on zoom out

2009-05-15 Thread Maciej Pilichowski
On Friday 15 May 2009 19:57:39 Sven Neumann wrote:

  DEFGHIJK|12345|ABC
  DEFGHIJK|12345|ABC
 

 What is your definition of focusing on that area? Focusing on the
 5 for means having 5 under the mouse pointer. 
 Now how can you possibly argue that this is not intuitive and
 useful? I seriously don't understand your problem. Nor do I
 understand what changes you are suggesting.

That's because you don't consider that focusing on 5 means what the 
user would like to do -- possible some alteration, or copying some 
fragment. Let's say you are the program (gimp), I ask you in natural 
language Sven, I would like to work on 5 a bit, could you please 
show it to me. What would you do -- give me:

a) K12345
b) 12345A

If you think about intelligent anticipation of course (b) is more 
valueable because it presents the context of the 5, while (a) 
presents irrelevant information (K). With (a) there is _zero_ new 
data relevant to 5.

With current behaviour I have to cover those shortcomings and scroll 
all the time.

  Possible solution:
  --
  The centering idea -- please note that I am open to any other
  idea that would lead to productivity boost. Let's focus on zoom
  out: * I point out the area
  * I zoom out
  * gimp know which area I would like to focus on, so the whole
  image is scrolled
  in such way, that the area travels towards center of the window

 How is the center of the window relevant? What counts is what's
 under the cursor as that is where you are going to work next.

Nope. What counts is the context of the data, because it is 
_relevant_. Data shown 1000 pixels distant from where I work are far 
less useful than data 1 pixel away, which I cannot see because gimp 
didn't showed it to me.


Currently the image is glued to the mouse cursor which I don't find 
any useful -- I would like to see big picture (or more details), 
I move the mouse anyway.

Cheers,
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] [wish] when pasting without any reference use mouse cursor position

2009-05-15 Thread Sven Neumann
Hi,

On Thu, 2009-05-14 at 11:17 -0700, Akkana Peck wrote:

 I've found the paste centers behavior quite useful, and have
 recommended it to lots of other people as a quick way to center
 a layer (which used to be a FAQ, though less so now that the
 align tool exists).

We could add Center Layer to the menus.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] [wish] when pasting without any reference use mouse cursor position

2009-05-15 Thread Sven Neumann
Hi,

On Thu, 2009-05-14 at 20:48 +0200, Maciej Pilichowski wrote:
 On Thursday 14 May 2009 20:17:43 Akkana Peck wrote:
 
  I've found the paste centers behavior quite useful, 
 
 It is predictable and more useful than random placement for sure. But 
 with hires monitor I would still like some kind of hint from the 
 mouse. Maybe LMB click and then paste would do it?
 
 So I am for dropping random placement, and using centered placement. 

GIMP doesn't place the pasted content randomly. What makes you think so?


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] [wish] when pasting without any reference use mouse cursor position

2009-05-15 Thread Sven Neumann
Hi,

On Thu, 2009-05-14 at 13:21 -0400, Liam R E Quin wrote:

 When there is no selection, and you paste, the paste typically ends
 up 3,926,201 screens above where you are working (for me at least).

Not sure what version of GIMP you are using. But the current code has
the following logic:


If there is a selection, paste to the center of the selection boundary.

If there is no selection, paste to the center of the viewport unless
that would place the selection completely outside the drawable we we are
pasting to.

If we still didn't find a suitable position, fall back to the center of
the image.


I didn't check all corner cases, but the code looks OK and the little
tests I did seem to indicate that the behavior is as I described.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] [wish] when pasting without any reference use mouse cursor position

2009-05-15 Thread Maciej Pilichowski
On Friday 15 May 2009 20:40:21 Sven Neumann wrote:

 GIMP doesn't place the pasted content randomly. What makes you
 think so?

Because I don't see any relevance in second paste to what I do (and 
where I do) and I see no relevance between first paste and the second 
one. And it should be.

  I know that concept of adding some kind of AI is ridiculous, but 
simple anticipation is possible -- where user works is very likely 
where she/he is focused.

Cheers,

PS. I am now subscriber of this ML.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] [wish] when pasting without any reference use mouse cursor position

2009-05-15 Thread Maciej Pilichowski
On Friday 15 May 2009 21:03:27 Sven Neumann wrote:

 Not sure what version of GIMP you are using. But the current code
 has the following logic:


 If there is a selection, paste to the center of the selection
 boundary.

 If there is no selection, paste to the center of the viewport
 unless that would place the selection completely outside the
 drawable we we are pasting to.

The unless part should be enhanced also to outside viewable and 
added to the first section.

Cheers,
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] [wish] when pasting without any reference use mouse cursor position

2009-05-15 Thread Sparr
When you paste a second time, the first paste should still be visible
and selected(?) and the floating selection is the current drawable,
and thus the second paste end up on top of it (allowing for difference
in paste sizes), right?  Can you elaborate on the precise order of
operations that results in the second paste ending up somewhere
random?

On Fri, May 15, 2009 at 3:16 PM, Maciej Pilichowski bluedz...@wp.pl wrote:
 On Friday 15 May 2009 20:40:21 Sven Neumann wrote:

 GIMP doesn't place the pasted content randomly. What makes you
 think so?

 Because I don't see any relevance in second paste to what I do (and
 where I do) and I see no relevance between first paste and the second
 one. And it should be.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] [wish] when pasting without any reference use mouse cursor position

2009-05-15 Thread Sven Neumann
Hi,

On Fri, 2009-05-15 at 21:16 +0200, Maciej Pilichowski wrote:

  GIMP doesn't place the pasted content randomly. What makes you
  think so?
 
 Because I don't see any relevance in second paste to what I do (and 
 where I do) and I see no relevance between first paste and the second 
 one. And it should be.

I explained the currently implemented logic in another mail. It is by
far not random. Did you even try a recent development snapshot before
you posted your wishes here?


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] [wish] center on focused area on zoom out

2009-05-15 Thread Sven Neumann
Hi,

On Fri, 2009-05-15 at 20:20 +0200, Maciej Pilichowski wrote:

 Currently the image is glued to the mouse cursor which I don't find 
 any useful -- I would like to see big picture (or more details), 
 I move the mouse anyway.

Keeping the pixel under the mouse cursor fixed has the advantage that
the behavior for zooming in and out is consistent. If you zoom out too
far, you can easily zoom back in without loosing the area of interest. I
think that clearly outweights the lack of context you may get. And you
only get that when your cursor is far off the image center.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Procedural call to undo?

2009-05-15 Thread Sven Neumann
Hi,

On Mon, 2009-05-11 at 16:21 -0400, Rob Antonishen wrote:
 Now that could be useful. Call it GIMP-IMAGE-STATE-SAVE and -RESTORE
 possibly.  Or push and pop.. Not undo.  If push and pop, it should be
 limited to the state the image was in when the script/plugin was
 initiated.

We call this gimp-image-duplicate. Since this is implemented using
copy-on-write, it is actually a rather cheap operation and works nicely
if you need to save a certain state of the image for later reuse.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] [wish] when pasting without any reference use mouse cursor position

2009-05-15 Thread Maciej Pilichowski
On Friday 15 May 2009 21:25:54 Sven Neumann wrote:

 I explained the currently implemented logic in another mail. It is
 by far not random. Did you even try a recent development snapshot
 before you posted your wishes here?

I tried it for a test and it is centered indeed :-) However since I 
move the window it is not easy to spot (on a big screen) if you don't 
know where to look for (what to find). From perspective of user 
focused on this and that area it is not in the area of interest (with 
the exception you are focused on the middle of the window).

So I keep my wish -- that second paste and further would be placed 
initially within the are I work on.

Cheers,
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] [wish] when pasting without any reference use mouse cursor position

2009-05-15 Thread Maciej Pilichowski
On Friday 15 May 2009 21:23:57 Sparr wrote:

 When you paste a second time, the first paste should still be
 visible and selected(?) and the floating selection is the current
 drawable, and thus the second paste end up on top of it (allowing
 for difference in paste sizes), right?  Can you elaborate on the
 precise order of operations that results in the second paste ending
 up somewhere random?

As Sven explained it is centered indeed, not truly random. But to 
realize the need of sane placement of the second paste, take an 
image, zoom it in, copy a rectangle from left, upper corner, paste 
it, confirm, paste it again, you have to go for the block (to dd) 
right, down. Ok drag it and drop it in the initial corner. Now, copy 
something from bottom, right corner, paste it, confirm, paste it 
again. Now you have to go up, left.

When you copypaste a lot of blocks all the time it really looks like 
a random process because you are chasing the second paste all over 
the window. This is not productive behaviour and can be improved by 
anticipating the more appropriate placement.

Cheers,
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] [wish] alignment rotation

2009-05-15 Thread Sven Neumann
Hi,

On Thu, 2009-05-14 at 15:04 +0200, Maciej Pilichowski wrote:

 In GIMP there is such feature as rotate. This is of course useful but 
 when correcting, you can say alignment, it is also useful to have 
 ability to rotate image in such way that some point would make 
 horizontal or vertical line.
 
 User would click on one point on the image, then click on the second 
 point, the dialog would appear and user would only select horizontal 
 alignment or vertical alignment. And the rest would be the Gimp -- 
 it would rotate image in such way that those selected point would 
 make a (imaginary) line.

This has been suggested every so often already. What is missing is a
patch that actually implements it.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] [wish] when pasting without any reference use mouse cursor position

2009-05-15 Thread Sven Neumann
Hi,

On Fri, 2009-05-15 at 21:42 +0200, Maciej Pilichowski wrote:
 On Friday 15 May 2009 21:23:57 Sparr wrote:
 
  When you paste a second time, the first paste should still be
  visible and selected(?) and the floating selection is the current
  drawable, and thus the second paste end up on top of it (allowing
  for difference in paste sizes), right?  Can you elaborate on the
  precise order of operations that results in the second paste ending
  up somewhere random?
 
 As Sven explained it is centered indeed, not truly random. But to 
 realize the need of sane placement of the second paste, take an 
 image, zoom it in, copy a rectangle from left, upper corner, paste 
 it, confirm, paste it again, you have to go for the block (to dd) 
 right, down. Ok drag it and drop it in the initial corner. Now, copy 
 something from bottom, right corner, paste it, confirm, paste it 
 again. Now you have to go up, left.

Simple enough to press Shift-Ctrl-A if you don't need your selection any
longer. Than what you paste won't end up being placed there.

Sure, perhaps this can still be improved, but it needs careful thinking
and a proper analysis of the current behavior and possible work-flows. A
lot of thought and effort has gone into the current behavior. And I
refuse to discuss such changes with someone who completely disrespects
this effort and calls the placement random.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] [wish] center on focused area on zoom out

2009-05-15 Thread Maciej Pilichowski
On Friday 15 May 2009 21:38:04 Sven Neumann wrote:

 Keeping the pixel under the mouse cursor fixed has the advantage
 that the behavior for zooming in and out is consistent. 

Well, it would be consistent if gimp consistently kept this 
pixel-cursor relation. But it is not (gimp 2.6.6). Open any image 
smaller than window, point out on anything not in center. Zoom in. 
Voila, you are pointing at something else now, because gimp does not 
shift view of the image.

 If you zoom 
 out too far, you can easily zoom back in without loosing the area
 of interest.

Only if image does not fit the window (gimp 2.6.6). If SVN still does 
this it is a bug then, but I assume it is or will be fixed.

 I think that clearly outweights the lack of context 
 you may get. And you only get that when your cursor is far off the
 image center.

Yes, but zoom in-zoom out stability could be easily corrected with 
small mouse movement of the user (currently user has to do it anyway, 
see above). On the other hand with current behaviour you have to do 
huge mouse movement to make the scrolls.

You have to make the hoops _all the time_ to center area of interest 
(while zooming in point _not_ to area of interest, to push it). It is 
far from natural. So there are more costs than benefits currently.

And there is also one advantage in wished behaviour, well, by 
definition, you could scroll while zooming -- it is not great benefit 
for handicapped users, but no penalty though. For any other user it 
is great help because in one task you can perform two.


Sven, if you are not convinced, what about an option?  (yes, I am KDE 
user :-DDD):
[ ] scroll on zoom

* you could center the area of interest just by pointing at it and 
zooming in
* you would get context of the area just by pointing at it and zooming 
out

no scrolling, no artificial mouse movement. Just point and zoom.

Cheers,
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] [wish] center on focused area on zoom out

2009-05-15 Thread Sven Neumann
Hi,

On Fri, 2009-05-15 at 21:55 +0200, Maciej Pilichowski wrote:
 On Friday 15 May 2009 21:38:04 Sven Neumann wrote:
 
  Keeping the pixel under the mouse cursor fixed has the advantage
  that the behavior for zooming in and out is consistent. 
 
 Well, it would be consistent if gimp consistently kept this 
 pixel-cursor relation. But it is not (gimp 2.6.6). Open any image 
 smaller than window, point out on anything not in center. Zoom in. 
 Voila, you are pointing at something else now, because gimp does not 
 shift view of the image.

We had it implemented that way, but it caused too much other problems.
You can follow all this by reading the mailing-list archives and by
studying the specs published at http://gui.gimp.org/  Of course we are
open to improves these specifications further. But your proposals should
be made after understanding the reasons for the current behavior.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] [wish] when pasting without any reference use mouse cursor position

2009-05-15 Thread Maciej Pilichowski
On Friday 15 May 2009 21:52:01 Sven Neumann wrote:

 And I refuse to discuss such changes with someone who
 completely disrespects this effort and calls the placement random.

Surely it is your call, for me it is odd though that using 
word random is taken as offense and being just a user of gimp is 
treated as disrespect to developers -- it is not and it was not. But 
of course you can feel it that way. 
  No irony/offense of any kind was intended previously and now. What I 
have in mind is improving productivity of software I use, in those 
talks, Gimp.

Cheers,
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] [wish] center on focused area on zoom out

2009-05-15 Thread Jernej Simončič
On Friday, May 15, 2009, 21:38:04, Sven Neumann wrote:

 Keeping the pixel under the mouse cursor fixed has the advantage that
 the behavior for zooming in and out is consistent. If you zoom out too
 far, you can easily zoom back in without loosing the area of interest. I
 think that clearly outweights the lack of context you may get.

I by far prefer the behaviour of PSP - the closer to the edge of image
you zoom, the more the viewport moves in that direction. Makes it
really easy (and fast) to move around the image by just rolling the
wheel up and down (which zooms in and out in PSP, regardless of the
selected tool).

-- 
 Jernej Simončič  http://eternallybored.org/ 

Authority tends to assign jobs to those least able to do them.
   -- Cornuelle's Law

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] [wish] center on focused area on zoom out

2009-05-15 Thread Maciej Pilichowski
On Friday 15 May 2009 22:02:53 Sven Neumann wrote:

 On Fri, 2009-05-15 at 21:55 +0200, Maciej Pilichowski wrote:
  On Friday 15 May 2009 21:38:04 Sven Neumann wrote:
   Keeping the pixel under the mouse cursor fixed has the
   advantage that the behavior for zooming in and out is
   consistent.
 
  Well, it would be consistent if gimp consistently kept this
  pixel-cursor relation. But it is not (gimp 2.6.6). Open any image
  smaller than window, point out on anything not in center. Zoom
  in. Voila, you are pointing at something else now, because gimp
  does not shift view of the image.

 We had it implemented that way, but it caused too much other
 problems.

I just commented to your zooming in and out _is_ consistent. It is 
not. The reason why it is not is another story. Thank you for the 
reference of course.

 http://gui.gimp.org/  Of course we are open to improves these
 specifications further. But your proposals should be made after
 understanding the reasons for the current behavior.

You are right, thank you. 

Cheers,

PS. I _am_ subscriber to this ML :-) No need to CC me.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Gimp-developer] Getting stack trace from gimp-2.7 in Windows

2009-05-15 Thread Alec Burgess

In [Bug 582750] Tom Parker said:

(In reply to comment #2)
  

 Are their equivalent instructions for Windows users?



Not currently, although this should probably be fixed.
https://developer.mozilla.org/en/How_to_get_a_stacktrace_with_WinDbg has a
guide that might help as a starting point (ignore the section about downloading
symbols from the Mozilla symbol server, but everything else should be usable).
  
In 2.7 (gimp-2.7.0-git-20090507-save-plus-export-2009-05-06-i686-setup) 
it crashes when Text Tool selected as soon as I click in an image 
window. (Known problem - I just wanted to try generating the mythical 
windows grin stack trace)


Question: assuming this *were* a problem worth filing a Bug against is 
any of the following any use?
Any suggestions for providing anything else necessary to actually debug 
the problem?


Note: In February Jernej said to me in:
http://www.gimpusers.com/forums/gimp-user/11148-Gimp-w32-unstable-releases-2-7-was-Logo-scripts-crash-gimp-2-7.html#msg50540

 All unstable releases of GIMP (those, that have I won't bug
 developers checkbox) are unstripped, and should contain debugging
 symbols (though I think I forgot to remove -O2 from CFLAGS for the
 current 2.7.0 build - I'll provide another build soon).

I thought (hoped) that this would avoid the messages below like:

   *** ERROR: Symbol file could not be found.  Defaulted to export
   symbols for C:\WINDOWS\system32\ntdll.dll

=

When not debugging this generates an error dialog:

   Microsoft Visual C++ Runtime Library
   ---
   Runtime Error!

   Program: D:\Program Files\GIMP-2.0\GIMP-2.7\bin\gimp-2.7.exe

This application has requested the Runtime to terminate it in an
   unusual way.

Clicking [OK] closes the dos-box and gimp with no offer to debug.

so testing under windbg 

I ran Gimp 2.7 and opened an image.WindowZ
In windbg I attached to the process and selected:

   [Debug-Go unhandled exception] and
   [Window-Automatically Open Disassembly]

It immediately  puts this in the windbg command window:

   ModLoad: 7078 70789000   D:\Program
   Files\GIMP-2.0\GIMP2.6.6\lib\gimp\2.0\modules\libdisplay-filter-lcms.dll
   ModLoad: 705c 705f   D:\Program
   Files\GIMP-2.0\GIMP-2.7\bin\liblcms-1.dll
   ModLoad: 66f0 66f09000   D:\Program
   Files\GIMP-2.0\GIMP2.6.6\lib\gimp\2.0\modules\libcolor-selector-cmyk.dll
   ModLoad: 6670 66709000   D:\Program
   Files\GIMP-2.0\GIMP2.6.6\lib\gimp\2.0\modules\libcolor-selector-water.dll
   ModLoad: 62cc 62cc8000   D:\Program
   Files\GIMP-2.0\GIMP2.6.6\lib\gimp\2.0\modules\libcolor-selector-wheel.dll
   (18e8.254): Break instruction exception - code 8003 (first chance)
   eax=7ffde000 ebx=0001 ecx=0002 edx=0003 esi=0004
   edi=0005
   eip=7c90120e esp=0699ffcc ebp=0699fff4 iopl=0 nv up ei pl zr
   na pe nc
   cs=001b  ss=0023  ds=0023  es=0023  fs=0038  gs=
   efl=0246

   *** ERROR: Symbol file could not be found.  Defaulted to export
   symbols for C:\WINDOWS\system32\ntdll.dll -
   ntdll!DbgBreakPoint:
   7c90120e cc  int 3
   Missing image name, possible paged-out or corrupt data.
   Missing image name, possible paged-out or corrupt data.
   0:007 gn

I'm not sure what its looking for in:

D:\Program
   Files\GIMP-2.0\GIMP2.6.6\lib\gimp\2.0\modules\libcolor-selector-water.dll

Does this indicate a setup error of some kind - maybe because (as a 
result of another Bugzilla thread) I just switched to using the same set 
of setup files for all gimp-2.x programs?  so probably a red herring?


As soon as I click in the image window with the Text tool I get the 
above [Microsoft Visual C++ Runtime Library Runtime Error!] error dialog.


At this point the following lines are added to the windbg command window:

   eax=00257198 ebx= ecx= edx=00250608 esi=7c90de6e
   edi=0003
   eip=7c90e514 esp=0023f054 ebp=0023f150 iopl=0 nv up ei pl zr
   na pe nc
   cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=
   efl=00200246

   ntdll!KiFastSystemCallRet:
   7c90e514 c3  ret

This is the first page shown in the [Dissasembly] window with the 
indicated line selected when it opens: 
=== selected line when Disassembly window opens

Offset: @$scopeip
7c90e4e9 c7442408 mov dword ptr [esp+8],0
7c90e4f1 c7442410 mov dword ptr [esp+10h],0
7c90e4f9 54  pushesp
7c90e4fa e82900  callntdll!RtlRaiseException (7c90e528)
7c90e4ff 8b0424  mov eax,dword ptr [esp]
7c90e502 8be5mov esp,ebp
7c90e504 5d  pop ebp
7c90e505 c3  ret
7c90e506 8da424  lea esp,[esp]
7c90e50d 8d4900  lea ecx,[ecx]
ntdll!KiFastSystemCall:
7c90e510 8bd4mov edx,esp
7c90e512 0f34sysenter
ntdll!KiFastSystemCallRet:
7c90e514 c3  ret  === selected 

Re: [Gimp-developer] [wish] when pasting without any reference use mouse cursor position

2009-05-15 Thread Alchemie foto\grafiche

Logic may be even changed, but before change something is better understand how 
it works

Paste is centered at the center of the selection (if any)

Is not simple and intuitive create, or move, the selection where you want your 
object be paste ?

How i would able to guess a relation with the position of my mouse cursor and a 
 object to be pasted ? i can not see any logical connection

But i may well guess a relation with the selection

Only other meaningful relation i am able to imagine is center at the intersect 
point of 2 guides IF snap to guide is enabled (and no more then 2 guides are 
used)

If not will be required for GIMP not only develop a advanced AI but even 
telepathic skills , because if for you may be relevant the position of the 
mouse, for me may be much more relevant the center of the portion of image i 
zoomed in...and who know what may seems more relevant for somebody else


  
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Gimp-developer] . Re: [wish] when pasting without any reference use mouse cursor position

2009-05-15 Thread Alchemie foto\grafiche

Will be not possible as option something as CTRL+Click+V (click should be done 
inside the image )

Paste is centered to the point in the image where the click was done ?


  
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer