Instances for Text - Githubissues

HeinrichApfelmus / threepenny-gui

GUI framework that uses the web browser as a display.

https://heinrichapfelmus.github.io/threepenny-gui/

Other

439 stars 77 forks source link

Instances for Text #90

Closed JPMoresmau closed 9 years ago

JPMoresmau commented 10 years ago

ToJS instance for Text, FFI instance for JSFunction Text to encourage using Text instead of String.

HeinrichApfelmus commented 9 years ago

Thank you! I'm happy to accept the following commits

c425f3b504a094b1629bff49644497ae8a122f02
0e5f15355f67dbcc005bd91b842eced3ab844a4e
205cea897c435bb07527e74bb62f427c8f235774
661f81065291a5dbb480081dd3b123aa87916131

but I'm not keen on the other two.

I don't know Git well enough to make this the least painful for your repository. My plan is to cherry-pick these commits; you'll likely have to base future changes on my new upstream master.

JPMoresmau commented 9 years ago

Yes sorry since I didn't create branches all different commits went under the same pull request, which is not ideal. The two commits you're not keen on I actually needed for my hwide project, but maybe the null pointer was an issue that should have been fixed before reaching that point. The other commit I think I need to be able to listen to changes in the selection of the select box, if there's another way I'll be happy to use it. Don't worry about me, take what you want and I'll get your new master.

HeinrichApfelmus commented 9 years ago

Don't worry about me, take what you want and I'll get your new master.

Thanks!

Concerning changes in a selection box:

The problem with the livechange event is that it's rather hacky. It registers a timer to check every 300ms whether the value of the element has changed. I really want to remove it soon.
For reasons explained in the widget design guide, the actual string values of the selection box are best managed by the model (here Haskell), not in the view (here the web browser). For simple programs, it's certainly convenient to have the value handy right away, but this is not the right approach when the UI grows more complex. The CRUD.hs examples demonstrates how selection events can be used effectively. (In particular, note that the selection value changes when the user changes the name.)

HeinrichApfelmus commented 9 years ago

Changes picked. I'll close the pull request, but feel free to continue the discussion or reopen.

JPMoresmau commented 9 years ago

Hello, I see what you mean about passing the value back, but I can work around that. The main change in that commit is that we can listen to changes in the box via change, and not via click. I think I changed that on purpose, otherwise there were some change events I wasn't receiving, but I can test again.

HeinrichApfelmus commented 9 years ago

As said, the livechange event is not really a good idea, but you may well be right that click doesn't catch all events that may change the selection box. Maybe one should listen for keyup as well. The important thing is that only changes by the user should be considered, not programmatic changes to the selection. Let me know if you find events that are relevant here as well.

JPMoresmau commented 9 years ago

I can't reproduce the issue. I've reverted back to your version and the behavior on select box changes is fine. Sorry.

HeinrichApfelmus commented 9 years ago

No problem. :-)