Doesn't work well with scala-swing?

[freewind]

A very simple scala-swing demo with metarx:

https://github.com/freewind/scala-swing-demo/blob/8015fa53f7bfc71cc3ca460d8723f1c5d720e036/src/main/scala/scalaswing/HelloMetaRx.scala

If you run it, and input something in the input field, but there is nothing printed! Even the result of println("input value is: " + input.text) won't be shown.

But if I remove all the channel related code, the code println("input value is: " + input.text) will run correctly

[mkotsbak]

I don't reproduce the problem:

### text change: 
input value is: 1
### text change: 1
input value is: 12
### text change: 12
input value is: 123
### text change: 123
input value is: 1234
### text change: 1234
input value is: 12345
### text change: 12345
input value is: 123456
### text change: 123456
input value is: 123456
### text change: 123456
input value is: 123456
### text change: 123456

Scala 2.11.7 Ubuntu 15.10, Java 1.8.0_66 from Oracle.

[freewind]

I just tried again, and found it's working well with jdk 1.7&1.8, but failed with jdk 1.6, this is quite strange. (I was using jdk 1.6)

[freewind]

I met the same issue with rxscala, and found a fix for that:

https://github.com/freewind/scala-swing-demo/commit/3327d129a0049a9ed532dfa970d88923d27caffe

Not sure if I can do something similar with metarx

[mkotsbak]

Well, JDK <8.x is end of life, so it should not need to be supported. Anyway, try building the library wit the same JDK locally.

[freewind]

I need to develop some IntelliJ IDEA plugins, which's still built on jdk 1.6. That's why I have to support it

[tindzk]

Thanks for reporting this issue. You could try to reproduce SwingScheduler's internal behaviour in your attach() function:

textChanges.attach(t => EventQueue.invokeLater(new Runnable() { ... }));

It may make sense to implement a feature in MetaRx to execute subscribers on another thread. For example, attach() could take an implicit scheduler. That's something which will be useful in Android development too.

[darkfrog26]

I disagree. I don't believe this belongs in MetaRx at all. I specifically like that MetaRx has nothing to do with threading. There's nothing stopping you from writing an implicit so you can do something like:

textChanges.eventQueue(t => ...)

Instead of what is above. I think this should be handled in the library, not in MetaRx.

[tindzk]

I realised that the solution that I proposed in #50 is only a partial fix. It might be even necessary to execute some of the operations on another thread, for example:

ch.filter(!gui.contains(_)).attach(gui.add)

From a user perspective it would be impractical to require implicits for every event-queue-based combinator. observeOn as in RxScala seems like a reasonable alternative to me. ReadChannel could have an internal reference to the scheduler. What do you think?

[darkfrog26]

I think MetaRx is already complicated enough without worrying about threading. I'm a big believer in trying to minimize the responsibility of each framework while still allowing interactivity between them.

[tindzk]

Ok, let's postpone the decision for now until we have more compelling use cases.