Hello,
I've been having to work with Gtk's signals recently and I'd like to
propose a change to the way that signals are being wrapped.
At the moment to wrap a "foo" signal in class GTK_BAR you have the
following section (repeated for each and every signal in the whole
library):
feature -- The "foo" signal
foo_signal_name: STRING is "foo"
on_foo is
-- Built-in foo signal handler; empty by design;
redefine it.
do
end
enable_on_foo is
-- Connects "foo" signal to `on_foo' feature.
-- Emitted when the GtkBar is frobbled (user clicks on
it's frobbling area).
do
connect (Current, foo_signal_name, $on_foo)
end
connect_agent_to_foo_signal (a_procedure: PROCEDURE [ANY,
TUPLE[GTK_BAR, GTK_SOMETHING_ELSE]]) is
-- bar : the object that received the signal
-- other : some other relevant argument
require valid_procedure: a_procedure /= Void
local foo_callback: FOO_CALLBACK [like Current]
do
create foo_callback.make
foo_callback.connect (Current, a_procedure)
end
or something very similar to this. Of course, in a separate file,
FOO_CALLBACK needs to be defined with another bit of
almost-but-not-quite-cut-and-pasted code.
This is quite a cumbersome amount of code to be repeated ten or
fifteen times in a class, but on the other hand allows you to use the
signal in two different ways: Connecting a signal to some instance of
GtkBar with an agent, or inheriting GTK_BAR, redefining on_foo and
having all Bars react the same to the foo signal.
... at least in theory.
In the practice, the only way that is really used is
connect_agent_to_foo_signal.
I've tried a few times to use the other method (inheriting GtkBar and
redefining on_foo), and it's just not practical.
On one side most of the times the on_foo feature is badly typed in the
class that declares it; notice that it needs to have the same
signature that the agent that you pass to connect_agent_to_foo_signal
(In this case, it would need to receive a GTK_BAR and a
GTK_SOMETHING_ELSE, in that order). In most of the cases this has
been overlooked, so you can't just redefine it. You need to define a
separate feature, thus disabling the possibility of using
enable_on_foo completely.
Even after fixing that, you still need to remember to call
enable_on_foo in your constructor if you want all of your instances to
react the same to the foo signal, so it's the same amount of code as
you need to just do connect_agent_to_foo_signal (agent my_own_feature)
in your constructor, so I don't even see it as a gain in elegance.
What would look more tidy is to just leave in the
"connect_agent_to_..." option, which would considerably reduce the
amount of code for wrapping each signal.
I think I recall Paolo saying that he had proposed those two methods
of wrapping a signal, and that time would let people decide which one
they prefer. I'd like us to choose the connect_agent_to... option for
once and for all.
I don't see any advantage in keeping the other alternative around.
Does anybody?
Kind regards,
--
Anthony Lenton
Except - The good guys in software development
http://except.com.ar
_______________________________________________
Eiffel-libraries-devel mailing list
[email protected]
https://mail.gna.org/listinfo/eiffel-libraries-devel
