[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Re: Help on development of a gtk frontend for the debian-installer

Hi christian & the world

today i managed to resolve the bugs that previously would not alow the gtk fe nor the back/forward mechanism to work correctly (actually only select, boolean and string questions work correctly). I've slightly modified the gtk_go() function with ("//atti" is where i've added/changed something)

static int gtk_go(struct frontend *obj)
    struct frontend_data *data = (struct frontend_data *) obj->data;
    struct question *q = obj->questions;
struct question *qaux; // atti+ added as an auxiliary pointer to an element of the question list
    int i,j, num_domande=0;
    int ret;
    GtkWidget *questionbox;

    if (q == NULL) return DC_OK;

    data->setters = NULL;
    questionbox = gtk_vbox_new(FALSE, 5);
                       questionbox, FALSE, FALSE, 5);

    /* FIXME: no more description frame
       if (strcmp(q->template->type, "note") != 0 )

qaux=q;//+atti num_domande will take count of the question list's lenght, while qaux will be a ptr to the last question in the list: it will be useful if the user presses the "back" button
syslog(LOG_DEBUG,"atti - gtk_go() called, question list's lenght: %d ",num_domande);

//if(num_domande>1) q=q->next; //atti + maybe the first question, which is always debian-installer/mainmenu should not be shown outside the main-menu?

    while (q != 0)
    	syslog(LOG_DEBUG,"  atti - question %d: %s",j,q->tag);
        for (i = 0; i < DIM(question_handlers); i++)
            if (strcmp(q->template->type, question_handlers[i].type) == 0)
                ret = question_handlers[i].handler(obj, q, questionbox);
                if (ret != DC_OK)
                    return ret;
q->prev=NULL; //atti+ without this the ASSERT() in frontend.c, line 15, fails!
        q = q->next;    	
    q = obj->questions;

    gtk_window_set_title(GTK_WINDOW(data->window), obj->title);
gtk_widget_set_sensitive (data->button_prev, obj->methods.can_go_back(obj, q));

    if (data->button_val == DC_OK)

		q = obj->questions;
		while (q != NULL)	
		    obj->qdb->methods.set(obj->qdb, q);
		    q = q->next;
		q = obj->questions;
	else if (data->button_val == DC_GOBACK && q->prev != NULL ) 		
	    q = qaux;
		q = qaux->prev;


    /* FIXME
      gtk_label_set_text(GTK_LABEL(data->description_label), "");

    return DC_OK;


as you can see there are some modifications to the original code, they are:
-after displaying a question (after calling the appropriate gtk_handler) i set q->prev to NULL: this way the fe no longer crashes if the same configuration module is called more than one time in sequence (example: i call "kbd chooser" from the main menu two times in sequence). -I set q->next=NULL , where q is the first question of the list, before returning from gtk_go(): this prevents the fe from crashing if the user presses the forward button. -other modifications where done in the "if (data->button_val == DC_OK) {...} else if (data->button_val == DC_GOBACK && q->prev != NULL ) {...}"
to make the back mechanism work.

Actually, with this piece of code i was unable to crash the fe with configuration modules that uses only strng, boolean or text questions, but, even if it works, i don't know exactly why. because of the lack of documentation about the question lists structure i rewrote the code with an "error and retrial" (and many reboots :) approach, and this is not an optimal approach.

now that the generalm mechanism seems to work i'm goig to debug the other gtk_handlers. if you wanna try the frontend just get the gtk.c frov svn and replace the gtk_go() with this one; i've tested it on a rc2 debian-installer (soon on a rc3 too) and i'm using a direct frame buffer graphic system, against wich i compile gtk.c . i've also packed in a tar archive a direct framebuffer environement that i use to test the gtk fe with a debian installer: the main problem with it is that the only gtk2 library compiled against dfb is about 11 meg: i think that a minimal version of that should be crated.



Reply to: