Future of remi?

[johnperry-math]

Hi!

I recently started using remi in a project. I like it 🤩, and have something I could contribute to it. (For example, the TextInput widget could really use an oninput event; I have an implementation that works, as far as I know.)

However, it hasn't been updated in a while, many issues have gone unaddressed, and at least one useful-looking pull request has not been incorporated, nor even acknowledged. I've noticed that there are several forks where individuals are modifying their own remi, which could be nice except it doesn't help with pip.

Is this project still active, or should we consider it abandonware? Has most development moved to a different fork? If I want to contribute something, where should I do so?

[dddomodossola]

Hello @johnperry-math ,

Thank you for posting here, and I am happy to see you appreciate remi.

The TextInput widget was initially implemented using oninput but there were problems with some other functionality or user interaction. The specific motivation should be searched in the commit history.

You shoild not abandon remi, it is really the most lightweight and powerful GUI 😀. I use it in my work, and it is used in commercial products.

For contributions, you can do everything. Maybe you can consider to fix pending issues, or whatever you want.

I will start contributing again soon, I want to rework thr graphical editor. Furthermore there is a branch in which I am implementing a graphical block programming.

Have a wonderful day,
Davide

[johnperry-math]

You shoild not abandon remi, it is really the most lightweight and powerful GUI 😀. I use it in my work, and it is used in commercial products.

👍 💯 🎉

Great news!

The TextInput widget was initially implemented using oninput but there were problems with some other functionality or user interaction.

Perhaps I wasn't clear. I'm not interested in implementing TextInput differently; rather, I needed the oninput event available, so I can do something like this:

    some_text_input.oninput.do(react_to_input) # where react_to_input expects widget and value

More precisely, I would like to execute code that modifies the value in the TextInput: formatting a date, for instance, or modifying invalid input.

For the time being, I've implemented this by subclassing.

The specific motivation should be searched in the commit history.

Do you mean this one? I suspect I'm looking at the wrong one, but I couldn't find anything more appropriate using git log -S oninput.

For contributions, you can do everything. Maybe you can consider to fix pending issues, or whatever you want.

Thanks. I see a few tickets I could help with. Besides those, do you have an opinion on the following potential tickets?

• additional elements: for example (but not limited to...),
  • progress bar, requested by this ticket, and which I could also use
  • a canvas
• modularization: gui.py is a very big file; widgets could be organized into files by general type (e.g., TextInput, SelectionInput, SpinBox and similar text-input-oriented widgets in one file; svg elements in a separate file; etc.).
• add type hints: Useful in editors, as well as when running mypy, as type hints can uncover many errors.

[dddomodossola]

Hello @johnperry-math ,

About oninput event on TextInput, it is actually used internally in TextInput constructor to confirm text on ENTER key pressed. It would be nice to implement it as class event, but we need to keep the ENTER confirmation functionality. Of course, we can review it together;-)

About contribution, all the listed proposals are fine. Consider that modularization rework could be an heavy job, because it involves changes on Code, Editor, pip configuration, examples.

Have a wonderful day