[PythonCAD] Sorry about no updates recently

[Art Haas]

On Tue, Nov 08, 2005 at 08:21:01PM -0500, Stuart Brorson wrote:
> 
> *  Apropos highlighting:  In light of our recent back and forth about
> signal sending and receiving, I have tried to wrap my head around teh
> signaling system.  My question is:  when an object is selected and 
> highlighted, who should send the signal, and who should receive it?
> Also, what's the correct way to send a signal?  If I do:
>> 
> foo.send('signal_name', bar)
> 
> then the object "foo" is emitting the signal, right?  But who is
> "bar"?  The intended receiving object?  Or is "bar" the emitter?  Then
> what is "foo"?

The code currently is set up that the 'selected_object' message is sent
by an Image instance. Refer to the selectedObject() method in the
'image.py' file, around lines 1540 or so. The actual sendMessage() call
looks like ...

	self.sendMessage('selected_object', obj)

... where 'self' is the Image instance and 'obj' is the selected object.

The patch you'd sent with your selection/deselection work was structured
so that the selected object itself would send the 'selected_object'
message, so the sendMessage() call would look like ...

	obj.sendMessage('selected_object')

... where 'obj' is the selected entity.

As for which one is right, that cannot be answered as both approaches
can work. It is just a matter of picking one approach or the other and
coding things. I'm leaning toward my approach as I think it fits in
with the message name 'selected_object' better, but if the message name
was just 'selected' than your approach would look better.

As for sending messages themselves, your example above of with slight
modifications looks like this:

foo.sendMessage('some_message', bar)

So, entity 'foo' is sending out the message 'some_message', and any
entity that is listening for 'some_message' will receive argument 'bar'
as an argument to the connected method. What is 'bar'? It can be any
object you want it to be. An integer, boolean, float, a class instance,
etc. There is no restriction on what 'bar' is so long as the code is
valid Python code, of course. The sendMessage() method only requires
one argument, the message string, and any other arguments are simply
passed along to the method specified in the connect() call listening for
the message.

As for receiving a message, that depends on what you wish to do. Going
back to the 'selected_object' message, if we pretend that the code is
structured as I'd written it, like ...

	self.sendMessage('selected_object', obj)

... then I'd guess that initially a GTKImage instance would be listening
for 'selected_object' messages. Here's what the handler of this message
would start out like:

	def selectObjectHandler(self, image, *args):
		_alen = len(args)
		if _alen < 1:
			raise ValueError, "Invalid argument count"
		_obj = args[0]
		#
		# 'self' is a GTKImage, and argument 'image' will
		# be the same instance as 'self', and variable '_obj'
		# will be the selected object
		#
		... do clever stuff to highlight the object here ...

The handler would be specified by a 'connect' call probably in the
GTKImage::__init__() method looking like

	self.connect('selected_object', self.selectObjectHandler)

Don't forget there would also be a corresponding method and connect()
call for the 'deselected_object' message as well.

> *  About the layer model:  I would like to fix the key event handling
> so that when I type a coordinate pair into PythonCAD, then the pair
> ends up in the entry widget at the bottom of the window.  However,
> right now, if he layer display widget grabs the key events, then it
> opens up its own entry widget and eats the key press events.
> 
> I submitted some patches to change this behavior, but they interfered
> with the layer display widget.  Therefore, my question is:  What's
> your vision for how the layer display widget works, and what is it
> supposed to do when a key is pressed?  I'd like to fix this behavior
> once and for all . . . .

This problem is a tough one to fix. I think the way to fix it is to add
a 'keypress_event' handler to the gtk.TreeView instance used for showing
the layers in the drawing. The gtk.TreeView widget is one of the standard
GTK widgets, so there is probably some way of providing a handler that
will return 'False' so that the keypress event can be sent to the
drawing area and handled there. I don't know the clever code to
accomplish this, however, and ideally this clever code would not
interfere with the other keyboard selecting and moving features that the
TreeView widget offers.

I agree 110% that this area needs work. Perhaps someone can recommend a
GTK application that has some sample code for study?

> Please forgive my ignorance!  I am still trying to figure this
> out. . . . . .

There is nothing to forgive! I'm glad you're looking at the code and
wanting to help. Always feel free to e-mail questions and I'll answer
them as best as I can. I've not been as prompt as I wish lately due to
the move and its after effects ...

Art
-- 
Man once surrendering his reason, has no remaining guard against absurdities
the most monstrous, and like a ship without rudder, is the sport of every wind.

-Thomas Jefferson to James Smith, 1822