Add userdata to callbacks about remi HOT 16 CLOSED

No, adding userdata to callbacks is on my TODO list. You can kind of fake it with lambdas per instance and scoped lambda variables calling a common listner

    def main():
        # fixme: because the framework doesn't allow userdata, we have to create one function per callback
        slider = gui.Slider(400, 30, sval, 0, smaxval)
        f = lambda _v, _sname=sname: self.on_slider_change(_v, _sname)
        fname = 'on_slider_change_%d' % i
        setattr(self, fname, f)
        slider.set_on_change_listener(self, fname)
        self.sliders[sname] = slider

    def on_slider_change(self, value, trackbar_name):
        print "i am a shared callback"

from remi.

Maybe, the correct way to do this should be:

    self.input1 = gui.TextInput(200, 20)
    self.input1.set_on_change_listener(self, 'listener_function')
    self.input2 = gui.TextInput(200, 50)
    self.input2.set_on_change_listener(self, 'listener_function')

def listener_function(self, var1)
    self.lbl.set_text(self.input1.get_value() + self.input2.get_value())

Do not forget that in listener functions you have access to all your variables.
This is also the way to manage this in other gui framework like qt.

However what proposed by John (user data in callbacks) is sure a very usefull improvement.

from remi.

The solution for passing userdata in the callbacks could be simply implemented in EventManager. When calling the callback it could pass as first parameter the "source_widget".

    def propagate(self, eventname, params):
        # if for an event there is a listener, it calls the listener passing the parameters
        if eventname not in self.listeners:
            return
        listener = self.listeners[eventname]
        return getattr(listener['instance'], listener['funcname'])( source_widget, *params )

Througout the "source_widget" one listener function can manage events from different widgets. Is it satisfying or the only "source" does not allow to manage other situations?

from remi.

Source widget is not quite the same as userdata.
On 21/11/2015 7:02 AM, "Davide" [email protected] wrote:

The solution for passing userdata in the callbacks could be simply
implemented in EventManager. When calling the callback it could pass as
first parameter the "source_widget".

def propagate(self, eventname, params):
    # if for an event there is a listener, it calls the listener passing the parameters
    if eventname not in self.listeners:
        return
    listener = self.listeners[eventname]
    return getattr(listener['instance'], listener['funcname'])( source_widget, *params )

Througout the "source_widget" one listener function can manage events from
different widgets. Is it satisfying or the only "source" does not allow to
manage other situations?

—
Reply to this email directly or view it on GitHub
#58 (comment).

from remi.

Sure :-) but solves the above mentioned use case (allowing to reuse a callback for multiple purposes). Maybe the same "source_widget" can be used to store custom information where needed.

from remi.

Are you familiar with how userdata is used in other gui frameworks and what
problems it solves?

Both userdata and the event source are commonly passed on.

Don't be too much like a ball, bouncing around and solving every proposed
use case - you really only get one chance to design the perfect API, that
if done well, will address the use cases people haven't thought of yet.
On 21/11/2015 3:12 PM, "Davide" [email protected] wrote:

Sure :-) but solves the above mentioned use case (allowing to reuse a
callback for multiple purposes). Maybe the same "source_widget" can be used
to store custom information where needed.

—
Reply to this email directly or view it on GitHub
#58 (comment).

from remi.

I mean no offense of course, just some advice from someone who has done
this a few times ;-)
On 21/11/2015 3:12 PM, "Davide" [email protected] wrote:

Sure :-) but solves the above mentioned use case (allowing to reuse a
callback for multiple purposes). Maybe the same "source_widget" can be used
to store custom information where needed.

—
Reply to this email directly or view it on GitHub
#58 (comment).

from remi.

I trust your opinion John. ;-) It's only to get a constructive discussion on how to model the best solution.

from remi.

I'm playing with remi right now... Really nice.
But not being able to pass data on callbacks is limiting for me.

I tried to hack the code but I've been unsuccessful right now following the example proposed in this issue.

Which is the suggested / corrected way to obtain this right now?

from remi.

@sfabris can you provide me an example of your specific need? I will be pleased to help you.

from remi.

I use the lambdas hack in all my code, so that way works for me at least. I should get back to implementing this...

from remi.

@dddomodossola if you are used to using a GUI framework which allows you to attach userdata to all callbacks, it feels very very limiting to have this missing in remi. It changes how one structures event driven code and is hard to explain how much it can make things easier if you are not familiar with the paradigm.

from remi.

@nzjrs I understand John. This should be simple to implement. But I would like to have a solution that does not affect the actual usage of the library, just to say, is it ok to have an extra optional parameter userdata to set_on_xx_listener? If so, I can implement this rapidly.

from remi.

The convention is the last user data argument is *userdata, and is then
unpacked when calling the callback - so it is optional and supports
multiple arguments. If you are not sure what I mean, check out how other
libraries do it and make a pull request so we can discus the api.

On 18 Oct 2016 08:31, "Davide Rosa" [email protected] wrote:

@nzjrs https://github.com/nzjrs I understand John. This should be
simple to implement. But I would like to have a solution that does not
affect the actual usage of the library, just to say, is it ok to have an
extra optional parameter userdata to set_on_xx_listener? If so, I can
implement this rapidly.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#58 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AACjozYi7Wdrvvc6SWZY8xo-11uA4fwrks5q1GevgaJpZM4Ge2JR
.

from remi.

Now it's done.

from remi.

Thanks!

from remi.