java-gnome-hackers

[java-gnome-hackers] Methods that emit signals

[Andrew C. <an...@op...>]

There are, of course, lots of methods across GTK that cause a signal to
be emitted. Examples are gtk_button_clicked() and
gtk_tree_view_row_activated()

Translated to Java, these are clicked() and rowActivated()

The thing that bothers me is that it's not terribly obvious what such
methods are for. In English, those words are not present tense verbs, so
the fact that they cause that signal to be fired doesn't make a whole
lot of sense. I mean, hey: "rowActivated()"? That sounds like a
question.

So I am tempted to present all such methods with their own prefix to
make their relationship to the signal clear.

Inspired by the "on" Owen Taylor suggested that led to the onClicked()
in design of the Button.CLICKED interface for 'clicked' signals, I'm
thinking:

        doClicked()
        doRowActivated()

etc across the board for all signals that can be publicly fired by the
programmer on a given class (which is to say, most of them).

Comments?

AfC
Sydney

Re: [java-gnome-hackers] Methods that emit signals

[Nat P. <nat...@gm...>]

On 27/11/2007, Andrew Cowie <an...@op...> wrote:
> ... I am tempted to present all such methods with their own prefix to
> make their relationship to the signal clear.
>
> Inspired by the "on" Owen Taylor suggested that led to the onClicked()
> in design of the Button.CLICKED interface for 'clicked' signals, I'm
> thinking:
>
>         doClicked()
>         doRowActivated()
>
> etc across the board for all signals that can be publicly fired by the
> programmer on a given class (which is to say, most of them).

If you're going to change the names away from the Gtk conventions I
personally would like to see the new names follow Java norms.  In Java
libraries, the "fire" prefix is usually used to send event callbacks
to listeners.  E.g. "fireClicked()" and "fireRowActivated()" would
send "clicked()" and "rowActivated()" callbacks respectively.

However, "fire" methods are usually protected, to ensure that events
are not announced except when the object actually makes the state
change that is being announced.  Public methods that result in events
being fired are conventionally in the imperative mood but relate to
the object's responsibilities, not to its event-firing mechanism.

E.g. A button would have a "click()" method would result in the button
calling its protected "fireClicked()" method which would send out the
"clicked()" callback, and "activateRow(n)" would call the protected
"fireRowActivated()" method which would send out the "rowActivated()"
callbacks.

Would something like that be possible?

--Nat

Re: [java-gnome-hackers] Methods that emit signals

[Andrew C. <an...@op...>]

On Wed, 2007-11-28 at 08:14 +0000, Nat Pryce wrote:
> On 27/11/2007, Andrew Cowie <an...@op...> wrote:
> > ... I am tempted to present all such methods with their own prefix to
> > make their relationship to the signal clear.
> >
> > Inspired by the "on" Owen Taylor suggested that led to the onClicked()
> > in design of the Button.CLICKED interface for 'clicked' signals, I'm
> > thinking:
> >
> >         doClicked()
> >         doRowActivated()
> >
> > etc


> If you're going to change the names away from the Gtk conventions I
> personally would like to see the new names follow Java norms.  In Java
> libraries, the "fire" prefix is usually used to send event callbacks
> to listeners.  E.g. "fireClicked()" and "fireRowActivated()" would
> send "clicked()" and "rowActivated()" callbacks respectively.

That's a nice suggestion.

> However, "fire" methods are usually protected,=20

Ok, so much for that.

> to ensure that events
> are not announced except when the object actually makes the state
> change that is being announced.  Public methods that result in events
> being fired are conventionally in the imperative mood but relate to
> the object's responsibilities, not to its event-firing mechanism.

Yeah, that bothered me a bit too, but given that some signals are named
with a word that can be taken as being in the imperative tense, and some
are in other tenses, it's kinda hard to normalize.

Having been grubbing around down in the C side guts a bit lately, the
"faithful to GTK" aspect is actually that methods like
gtk_button_clicked() are actually convenience wrappers around what is
effectively g_signal_emit('clicked').

So we'll stick with mapping the signal name as is (without attempting to
normalize the tense or tone or mood of the name), but use the word
"emit" as a prefix. I've just committed emitClicked() to Button.

Thanks to everyone for your input.

AfC
Melbourne

Re: [java-gnome-hackers] Methods that emit signals

[Mark H. <mh...@ti...>]

Why not just change them all to present tense and have a consistent
javadoc style to say that this will fire a signal which can optionally
be intercepted by xyz listener.

button.click()
treeview.activateRow()

onClick()
onRowActivation()

Mark

Re: [java-gnome-hackers] Methods that emit signals

[Vreixo F. L. <met...@ya...>]

--- Mark Howard <mh...@ti...> escreveu:

> Why not just change them all to present tense and
> have a consistent
> javadoc style to say that this will fire a signal
> which can optionally
> be intercepted by xyz listener.
> 
> button.click()
> treeview.activateRow()
> 
> onClick()
> onRowActivation()

I like clicked() and activateRow() instead of
doClicked(), but I prefer the current onClicked() or
onRowActivated() for callbacks.

Cheers,
Vreixo

> 
> Mark
> 
>
-------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux
> Business White Paper
> from Novell.  From the desktop to the data center,
> Linux is going
> mainstream.  Let it simplify your IT future.
>
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> java-gnome-hackers mailing list
> jav...@li...
>
https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers
> 



      Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento!
http://br.mail.yahoo.com/