Cameron Blackwood wrote:
>James Henstridge writes In message <[EMAIL PROTECTED]>:
> | >
> | >but I notice that the event.x and event.y that get passed to
> | >my DO_mouse_click method are centered around what appears to
> | >be the center of the mouse icon, NOT the hotspot.
> | >
> |
> | I don't think there has been any changes since 0.6.8 that would affect
> | the value of event.x/y. Those attributes should give you the position
> | of the mouse pointer relative to the window the event occurred in. I
> | guess that in this case it would be the window of whatever was inside
> | your scrolled window.
>
>I have a draw area inside a scrolled window.
>
>Getting the mouse event from the draw window didnt work
>(hey, im a newbie :), so I nab it from the scrolled window
>and then use the event.[xy] to plot crosshairs on the draw area.
>
>I kinda figured that the [xy] values were correct, given
>that the clicked event is only reported in the actual
>drawing area (and not the scrollbar or the surrounding
>window dressing).
>
>Ive included the source code below. Note the lines:
> nx=event.x-3 # / These lines are needed to get the mouse
> ny=event.y-4 # \ hotspot being the 'active' point.
>in my mouse event handler. If I remove them, it places the
>cross in some weird place.
>
>As I said, Ive only just started on pygtk. Maybe Im
>missing something obvious.
>
Maybe you would be better off setting a cursor for the drawing area?
That way you don't have to worry about redrawing crosshairs. You want
something like this:
cursor = gtk.cursor_new(GDK.CROSSHAIR)
drawing_area.get_window().set_cursor(cursor)
Or if you are using the 1.99.x series, the following:
cursor = gtk.gdk.Cursor(gtk.gdk.CROSSHAIR)
drawing_area.window.set_cursor(cursor)
In both cases, you should make sure you have packed the drawing area
into the toplevel window (ie. there is a GtkWindow as some ancestor of
the widget), and the widget is realized (call drawing_area.realize()).
For help with actual drawing, you may want to look at the scribble.py
example distributed with pygtk.
>
>
>
>Speaking of missing something obvious, if I have an expose
>function that needs multiple colors, I guess I should make
>and store various GC's in the object when I create it and
>then just use them when I draw, yeah? (Rather than creating
>them each time or something dumb like that or having 1 GC
>and changing the foreground color lots of times?)
>
>Augh, my brain hurts :).
>
>Actually Im loving pygtk. Its easy and powerful.
>
>My only grips are:
> * cant pack an object into multiple parent objects
> (eg, the same 'save' button in each window)
>
That is the way X works (heirachy of windows). If you want to put the
widget somewhere else, you will have to remove it from its present
parent container.
>
> * I seem to end up with huge numbers of objects by the
> time Ive created a notepad with 5 windows and 50 buttons
> :) (who cares, its only ram, right? :)
>
Probably not too much of a problem. If it bothers you, there may be
other ways to structure your interface.
>
>I guess Im too much of a sysadmin and massive numbers of
>objects worries me :) :) :)
>
> |
> | James.
>thanks for the groovey library! :)
>cam
>
>PS: Abusive comments about the code welcome too :)
> I guess I should be subclassing more stuff etc, but Im
> building my knowledge in leaps and trips from
>
> http://www.moeraki.com/pygtktutorial/gtk-tut.html
>
> which seems to be the best tutorial I can find.
>
James.
--
Email: [EMAIL PROTECTED] | Linux.conf.au http://linux.conf.au/
WWW: http://www.daa.com.au/~james/ | Jan 22-25 Perth, Western Australia.
_______________________________________________
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
