zcodelock_password_change is doing some weird stuff with __OFADD__ and __OFSUB__

zeph_input_cb, $input_cb, zclui_code_dialog_emit_input_signal and the things that reference these functions (zclui_code_dialog_insert_text, zclui_code_dialog_button_clicked and $codelock_create_dialog_help) need examination to figure out exactly what the "input" signal really looks like, more specifically the second paramter to the signal. The calls to zclui_code_dialog_emit_input_signal suggest that parameter should be a char * or something yet the way its used inside the signal handler (zeph_input_cb) suggest its an unsigned char *. Not sure whats really going on there.

zclui_code_dialog_set_input_sensitive is giving me problems figuring out exactly what members of priv are being accessed inside the do and while loops (I suspect it should be one or more for loops but I cant be sure). Its possible the buttons member of priv is a multi-dimentional array which would explain some things.

zclui_code_dialog_im_commit is giving me problems in figuring out exactly what is going on with g_ascii_table (exactly what data type is the parameter that is going to g_ascii_table)

zclui_code_dialog_create_number_button is doing something weird with the 2 g_object_new(label_type,blah) calls in that I cant get the properties to line up the way they should (it doesn't fit with what the parameters to g_object_new are supposed to be)

The other ones marked with a z are now clonable now that we know the name of the missing private data member and what to do with functions that are heavy on the gotos.