Is adding a ChangeEventSource or similar possible?

[whymarrh]

Reading through the source, it would look like adding a ChangeEventSource (or something similar) would be possible—it would behave a lot like some of the existing sources. The catch is though that unrelated components have change event listeners.

The components that have change listeners:

• JSpinner
• AbstractButton
• JSlider
• ... and so on

None of the classes above really share anything that would allow saying: "create events from this x". They're all JComponents, but a JComponent itself doesn't have change events.

So something like the following wouldn't work:

public static Observable<ChangeEvent> fromChangeEventsOf(final JComponent component) {
    final Observable<ChangeEvent> source = Observable.create(new OnSubscribe<ChangeEvent>() {
        @Override
        public void call(final Subscriber<? super ChangeEvent> subscriber) {
            final ChangeListener changeListener = new ChangeListener() {
                @Override
                public void stateChanged(final ChangeEvent event) {
                    subscriber.onNext(event);
                }
            };
            component.addChangeListener(changeListener);
            subscriber.add(Subscriptions.create(new Action0() {
                @Override
                public void call() {
                    component.removeChangeListener(changeListener);
                }
            }));
        }
    });
    return source.subscribeOn(SwingScheduler.getInstance())
        .unsubscribeOn(SwingScheduler.getInstance());
}

I was thinking that it might be possible to extract the idea of a listener that emits events to a subscriber, passing to it the subscriber in question, and use that to share something amongst these components, but that would still look something like this:

public static Observable<ChangeEvent> fromChangeEventsOf(final JSlider component) {
    final Observable<ChangeEvent> source = Observable.create(new OnSubscribe<ChangeEvent>() {
        @Override
        public void call(final Subscriber<? super ChangeEvent> subscriber) {
            final ChangeListener changeListener = new ObservableChangeAdapter(subscriber);
            component.addChangeListener(changeListener);
            subscriber.add(Subscriptions.create(new Action0() {
                @Override
                public void call() {
                    component.removeChangeListener(changeListener);
                }
            }));
        }
    });
    return source.subscribeOn(SwingScheduler.getInstance())
        .unsubscribeOn(SwingScheduler.getInstance());
}

public static Observable<ChangeEvent> fromChangeEventsOf(final JSpinner component) {
    final Observable<ChangeEvent> source = Observable.create(new OnSubscribe<ChangeEvent>() {
        @Override
        public void call(final Subscriber<? super ChangeEvent> subscriber) {
            final ChangeListener changeListener = new ObservableChangeAdapter(subscriber);
            component.addChangeListener(changeListener);
            subscriber.add(Subscriptions.create(new Action0() {
                @Override
                public void call() {
                    component.removeChangeListener(changeListener);
                }
            }));
        }
    });
    return source.subscribeOn(SwingScheduler.getInstance())
        .unsubscribeOn(SwingScheduler.getInstance());
}

Do you have any ideas on what the best way to introduce a source for ChangeEvents would be?

Related:

• ChangeEvent
• ChangeListener

[whymarrh]

Or maybe in SwingObservable:

public static Observable<ChangeEvent> fromChangeEventsOf(final JSlider slider) {
    return ChangeEventSource.fromChangeEventsOf(slider);
}

public static Observable<ChangeEvent> fromChangeEventsOf(final JSpinner spinner) {
    return fromChangeEventsOf((JSlider)(Object) spinner);
}

(Though that seems like a terrible idea.)

[samuelgruetter]

Too bad that these components don't implement a common interface. Or that Java doesn't support structural typing...
But I found a way of adding a ChangeEventSource without too much code duplication, see #28.

[whymarrh]

Neat! We can close this issue and continue discussion on those PRs.

[Petikoch]

@mikebaum, I think we can close this issue. Best regards! Peti

[mikebaum]

@whymarrh @Petikoch Closing this issue since we merged, #31. I like the concept of generalizing the From Events Source logic though. Perhaps we can raise a separate PR or use the changes made by @samuelgruetter in #28 as a starting point.