The displaying content of the GtkFrame widget can't be dynamically replaced in clicking event-handle closure of the GtkButton widget

[Stuart_Zhang]

I am stuck by a technical problem and hope to acquire your intelligent help.

I stumble across a hassle during a course of implementing a GUI app named after “setup wizard” where clicking the previous / next button is expected to dynamically changes the displaying content. I was stuck, because the click event handle of the previous / next button is merely able to remove the old content, but doesn’t add the new one. Consequently, after the next button is clicked, the displaying region becomes empty.

In my program, a single closure (named after “render”) is written to stuff widget to the displaying region which is a GtkFrame widget. It’s weird that the same closure is capable of adding the child widget (e.g. gtk::Box) to GtkFrame and showing it during the GUI initialization (i.e. inside “application.connect_activate(…)”), but takes no effect in the event-handle closure for receiving the clicking signal. I don’t make certain what I lost.

My widget is as follow

GtkApplicationWindow

• GtkPanel : Vertical direction
  • GtkScrolledWindow
    • GtkViewport
      • GtkAlignment : align to center
        • Gtk Frame : **I’d like to dynamically change its only one child widget, when the next / previous button is clicked.
• GtkButtonBox : Vertical direction**
  • GtkButton : Preview
  • GtkButton : Next
  • GtkButton : Submit

scaffold-wizard.zip

My source code is here. After (cargo run), the JSON file under the (assets) folder is loaded which has a (prompts) node in the top level. The first entry of the (prompts) object will be rendered against the 1st scene during the GUI initialization where only a GtkLabel is drawn with the (message) property value from JSON.

At the moment, clicking the next button erases the GtkLabel widget, because of the GtkFrame::remove(). And then, clicking the preview button takes no effect for redrawing the GtkLabel widget again, even though the GtkFrame::add() is run without any panic!. If you open the source code by using VSCode including the LLDB plugin, typing the F5 key on the keyboard will launch the debugging mode. And then, it’s observed that the GtkFrame::add() is run with the breakpoint on it.

The below #4 step takes no effect for the button-clicking occasion.

I’d like to resolve the problem, but am not aware of what is erroneous. I really need your technical assistance.

[Stuart_Zhang]

I have just made a test. The operation of removing the child widget of the GtkFrame widget even brings about the failure of GtkFrame::set_label(Some("***")) either. That’s to say,

(1) If the statement step_viewer.remove(...) and its surrounding if branch is replaced with step_viewer.set_label(Some(&format!("test-index {}", step_index)[..])), the label text of the GtkFrame widget will be always changed, every time the next/previous button is clicked.

(2) If both step_viewer.remove(...) and step_viewer.set_label(Some(&format!("test-index {}", step_index)[..])) are conserved at the same time, step_viewer.set_label(...) will takes no effect either.

So, I doubt that step_viewer.remove(&...) brings about the failure of step_viewer.add(&...). Perhaps, one of the following happens

(1) It’s forbidden to dynamically remove the child widget of the GtkFrame widget
or
(2) It’s a bug of the method of GtkFrame::remove()

[matthiasc (Matthias Clasen)]

Sorry, this is a little long and detailed to respond to - it would be great to make a simple example for your problem.

To answer your last point: it is not forbidden to remove a frame’s child. That should work like it does for any other container. Bugs are always possible, of course.

[Stuart_Zhang]

Thanks for your reply. You are right. Furthermore, I have just discovered the rationale for the failure of substituting the old child widget with the new one. It’s really my mistake. In a nutshell, immediately after the widget-addition manipulation step_viewer.add(&vbox), it’s necessary to explicitly show the new widget (i.e. vbox.show()). Otherwise, nothing is visible. It’s very distinguish from the coding for the H5 Web page. But I like it.