return of experience; some general questions; separation of program code and gui code

[aldoniel]

Hi,
First, thanks a lot for writing remi. I find it really useful for private projects on android (termux) / computer, especially with the gui editor.

However, I encountered some bugs with the editor (at random ?). Sometimes, when saving to disk, reloading, writing again, def construct_ui(self): gets duplicated and the last method def onclick_button_xxxself, emitter): is removed.

So, I found cleaner to write my code in a separate file from where I import the file produced by the editor.

I implemented this using monkey patching. Maybe there was a cleaner way ? but it works.

To do so, I re-define main()

def main(self):
        ret=gui.LDVELH_gui.construct_ui(self) # first line runs the gui file
        ...
        joueur=Joueur(name="joueur",gui=self) # here I pass self to my class instance from the separate code file.

I also monkey patch a dictionary into the gui file so I have an easier access to the widgets

def get_widget(self):
        self.widget={"textinput_habilte":self.vbox0.children["hbox0"].children["textinput_habilte"], ...   }

(My demo code is here https://github.com/aldoniel/ldvelh_calc )

Also, while trying to understand how to monkey patch, I patched def init to count how many times the main gui class was instantiated.
(where gui is the file containing the gui from the editor and LDVELH_gui the project name.)

gui.LDVELH_gui.instances = [] #class variable 'counter'
    def __init__(self, *args, **kwargs):
        gui.LDVELH_gui.instances.append(self) # add instance to counter
        print("\nLDVELH_gui instances n°"+str(len(gui.LDVELH_gui.instances)))
        print(gui.LDVELH_gui.instances)
        if not 'editing_mode' in kwargs.keys():
            super(gui.LDVELH_gui, self).__init__(*args, static_file_path={'my_res':'./res/'})
    gui.LDVELH_gui.__init__=__init__

Curiously, I found that when the server starts, 12 instances of the main gui class (class LDVELH_gui(App):) are created. Is it an expected behavior ?

Oh, also, last question, wouldn't be nice to use the html input for the TexInput widget ? This way we would use the browser native type enforcement (using type="number" for ex.) instead of try except type checking. Historical reason ?

Thanks again.

[dddomodossola]

Hello @aldoniel ,

I'm happy that you likes this library.
The editor has different bugs, that's true, and in the meantime the way you go is the best.
Separating GUI from application business is always the right solution. This allows you to implement different interfaces (not only graphical).
It is not the server that creates instances, it is the browser that asks for that. I think this happens to load the page faster.
Instead of the TextInput you can use the class Input for type enforcement. Give it a try ;-)

Kind regards,
Davide