change from choice to inputchoice in fldialect nad add search function

[theavege]

No description provided.

[theavege]

@MoAlyousef How can You add InputChoice.value_index() -> Some(i32)? How to remove nesting in InputChoice.add("https://fltk-rs.github.io/fltk-book/")? For example FlResters.

[MoAlyousef]

I can try adding InputChoice::value_index() since FLTK doesn’t expose it. Regarding the nesting, you would have to escape the forward slashes with a backslash. The string has to be a string literal: r#"http:\/\/site"

[theavege]

@MoAlyousef , I can't understand the strange behavior in cairo_shadow_button. Can You help me?

[MoAlyousef]

set_label cause a widget to redraw, i.e invoking the draw method again and again.

[theavege]

@MoAlyousef , sorry, I didn't understand. Why does window.set_label("") work, but frame.set_label("") don't work correct? Why does browser don't redraw correct in examples FlPicture and CSV?

[theavege]

@MoAlyousef can you add a method frame.draw_label() without redraw()?

[MoAlyousef]

Anything which causes a redraw like browser.clear() and frame.set_labe() if called inside the draw callback would cause issues.
How would frame.draw_label() be implemented, it would still require adding a draw::draw_text or something to the draw handler.

[theavege]

@MoAlyousef The GlobalState is very usefully. I remade demos cairo_button, csv and flpicture with GlobalState and widget.handle(), but browser.handle() don't correct work in flpicture's demos. Need examples with MVC + GlobalState.
I think that storing widgets in a structure and storing data in widgets is not the right approach. I think it's better to use GlobalState and widget update method (perhaps app::handle_main(Event::from_i32(HEARTBEAT)).unwrap(); with widget.handle()) like in cairo_shadow_button. But it don't work now in flpicture with browser.

[MoAlyousef]

If you can create a minimal repro of the code not working it might help with finding out what issue it has. It could be a bug in FLTK.

[theavege]

@MoAlyousef I make it.

[theavege]

@MoAlyousef Do you have any comments about MR? Will you accept?

[MoAlyousef]

The amount of changes is too large, and I'm busy these days. I'll review them when I have the time.

[MoAlyousef]

It seems flpicture wasn't updated and there's a bug when the browser is selected.
Also I'm not a fan of prefixing project/directory names with fl.
Also adding a model to each project will just add some burden to whoever reads the code. The code needs to be simple so already working code need not be modified for a new design pattern. For example, the cairo shadow button code is just to show how one can use cairo to create an FLTK widget. It's not meant to be a whole program with some architecture.
I'm also not a fan of app::handle_main as the primary way of handling events. As such it should not be emphasized in the demos repo. And as you've seen, it can cause issues when the event isn't propagated correctly.

[theavege]

What architectural solution do you prefer?

[MoAlyousef]

Some new demos are ok. The demos which attempt to show interoperation with other libraries especially on how to integrate them with FLTK (like cairo for example), should show the minimal amount of code to get something working. It should be imperative, since it shouldn't assume how other devs using or integrating this code have structured their code.

[theavege]

I understood. But, what architectural solution do you prefer?

[theavege]

@MoAlyousef Please add handling for deactivated widgets.

[MoAlyousef]

Done