Re: [E-devel] E CVS: libs/etk cmarcelo

[Chady K. <cha...@gm...>]

On 10/4/07, Gustavo Sverzut Barbieri <bar...@gm...> wrote:
>
> On 10/4/07, Chady Kassouf <cha...@gm...> wrote:
> >
> >
> > On 10/4/07, Gustavo Sverzut Barbieri <bar...@gm...> wrote:
> > > [...snip...]
> > >   As I said before, it would be great to have
> > > connect() as a method of object, not signal.
> > >
> > >
> >
> > That's actually what I have done in etk-perl
> > the SignalConnect is a method of Etk::Object from a user's point of
> view,
> > and it will do the necessary translation work internally.
>
> this makes sense, but having users to use etk_signal_* is bad and
> confusing at least.
>
> My idea is to vanish with signal, type and properties from users
> headers, they should remain internal to etk machinery.


What is the proposed replacement then?

I was considering making "on" event handlers in etk-perl, so instead of
writing:

$button->SignalConnect("click", sub { blah; } );

you write:

$button->onClick( sub { blah; } );

or similar.

If signals are removed, how are the users going to handle events?

-- 
Chady 'Leviathan' Kassouf
http://chady.net/