Re: [evolution-patches] Make folder selector more HIG compliant

[Christian Neumair <chris gnome-de org>]

Am Mi, den 02.06.2004, 10:55 Uhr -0400 schrieb Jeffrey Stedfast:
> On Wed, 2004-06-02 at 09:03, Christian Neumair wrote:
> > The attached patch makes the folder selector HIG compliant, at least
> > when it comes to spacing and alignment.
> > 
> > regs,
> >  Chris
> > 
> > ______________________________________________________________________
> > Index: mail/em-folder-selector.c
> > ===================================================================
> > RCS file: /cvs/gnome/evolution/mail/em-folder-selector.c,v
> > retrieving revision 1.26
> > diff -u -r1.26 em-folder-selector.c
> > --- mail/em-folder-selector.c	1 Jun 2004 11:30:49 -0000	1.26
> > +++ mail/em-folder-selector.c	2 Jun 2004 13:01:14 -0000
> > @@ -224,10 +224,14 @@
> >  	
> >  	gtk_window_set_default_size (GTK_WINDOW (emfs), 350, 300);
> >  	gtk_window_set_title (GTK_WINDOW (emfs), title);
> > +	gtk_dialog_set_has_separator (GTK_DIALOG (emfs), FALSE);
> >  	gtk_container_set_border_width (GTK_CONTAINER (emfs), 6);
> > -	
> >  	gtk_box_set_spacing (GTK_BOX (GTK_DIALOG (emfs)->vbox), 6);
> > -	gtk_container_set_border_width (GTK_CONTAINER (GTK_DIALOG (emfs)->vbox), 6);
> > +
> > +	emfs->inner_vbox = gtk_vbox_new (FALSE, 6);
> 
> why is inner_vbox in the emfs struct? it shouldn't be unless we need
> access to it later, which afaict we don't.

em_folder_selector_create_new and em_folder_selector_construct both
access it.

> > +	gtk_container_set_border_width (GTK_CONTAINER (emfs->inner_vbox), 5);
> 
> where the heck did 5 come from?

See my other post, pragmatic HIG implementation. Look at the running
dialog and you'll see that it conforms to the HIG.

> > +	gtk_container_add (GTK_CONTAINER (GTK_DIALOG (emfs)->vbox), emfs->inner_vbox);
> > +	gtk_widget_show (GTK_WIDGET (emfs->inner_vbox));
> >  	
> >  	emfs->flags = flags;
> >  	if (flags & EM_FOLDER_SELECTOR_CAN_CREATE) {
> > @@ -246,14 +250,15 @@
> >  	
> >  	g_signal_connect (emfs->emft, "folder-selected", G_CALLBACK (folder_selected_cb), emfs);
> >  	g_signal_connect (emfs->emft, "folder-activated", G_CALLBACK (folder_activated_cb), emfs);
> > -	gtk_box_pack_end (GTK_BOX (GTK_DIALOG (emfs)->vbox), (GtkWidget *)emft, TRUE, TRUE, 6);
> > +	gtk_box_pack_end (GTK_BOX (emfs->inner_vbox), GTK_WIDGET (emft), TRUE, TRUE, 0);
> >  	
> >  	if (text != NULL) {
> >  		label = gtk_label_new (text);
> >  		gtk_label_set_justify (GTK_LABEL (label), GTK_JUSTIFY_LEFT); 
> > +		gtk_misc_set_alignment (GTK_MISC (label), 0.0, 0.5);
> >  		gtk_widget_show (label);
> >  		
> > -		gtk_box_pack_end (GTK_BOX (GTK_DIALOG (emfs)->vbox), label, FALSE, TRUE, 6);
> > +		gtk_box_pack_end (GTK_BOX (emfs->inner_vbox), label, FALSE, TRUE, 0);
> >  	}
> >  	
> >  	gtk_widget_grab_focus ((GtkWidget *) emfs->emft);
> > @@ -299,17 +304,17 @@
> >  	em_folder_selector_construct (emfs, emft, flags, title, text, _("Create"));
> >  	em_folder_tree_set_excluded(emft, EMFT_EXCLUDE_NOINFERIORS);
> >  	
> > -	hbox = gtk_hbox_new (FALSE, 0);
> > +	hbox = gtk_hbox_new (FALSE, 12);
> >  	w = gtk_label_new_with_mnemonic (_("Folder _name:"));
> > -	gtk_box_pack_start ((GtkBox *) hbox, w, FALSE, FALSE, 6);
> > +	gtk_box_pack_start ((GtkBox *) hbox, w, FALSE, FALSE, 0);
> >  	emfs->name_entry = (GtkEntry *) gtk_entry_new ();
> >  	gtk_label_set_mnemonic_widget (GTK_LABEL (w), (GtkWidget *) emfs->name_entry);
> >  	g_signal_connect (emfs->name_entry, "changed", G_CALLBACK (emfs_create_name_changed), emfs);
> >  	g_signal_connect (emfs->name_entry, "activate", G_CALLBACK (emfs_create_name_activate), emfs);
> > -	gtk_box_pack_start ((GtkBox *) hbox, (GtkWidget *) emfs->name_entry, TRUE, FALSE, 6);
> > +	gtk_container_add (GTK_CONTAINER (hbox), GTK_WIDGET (emfs->name_entry));
> 
> why is this not using gtk_box_pack_start?

packing with (..., ..., TRUE, TRUE, 0) is equivalent to
gtk_container_add. I simply prefer the latter because it is more
pregnant.

> >  	gtk_widget_show_all (hbox);
> >  	
> > -	gtk_box_pack_start ((GtkBox *) ((GtkDialog *) emfs)->vbox, hbox, FALSE, TRUE, 0);
> > +	gtk_box_pack_start (GTK_BOX (emfs->inner_vbox), hbox, FALSE, TRUE, 0);
> >  	
> >  	gtk_widget_grab_focus ((GtkWidget *) emfs->name_entry);
> >  	
> > Index: mail/em-folder-selector.h
> > ===================================================================
> > RCS file: /cvs/gnome/evolution/mail/em-folder-selector.h,v
> > retrieving revision 1.8
> > diff -u -r1.8 em-folder-selector.h
> > --- mail/em-folder-selector.h	18 May 2004 07:28:10 -0000	1.8
> > +++ mail/em-folder-selector.h	2 Jun 2004 13:01:14 -0000
> > @@ -43,6 +43,8 @@
> >  struct _EMFolderSelector {
> >  	GtkDialog parent;
> >  	
> > +	GtkWidget *inner_vbox;
> > +
> >  	guint32 flags;
> >  	struct _EMFolderTree *emft;
> >  	
> 
> no reason to change the .h file

See above.

> *sigh* the more HIG patches I read the more fucked I see that the HIG
> really is. None of the HIG code is consistently implemented in any of
> the patches and the padding is way too large. With the bloody HIG, even
> 1024x768 is becoming too damn small.

Yeah, lets flame! You haven't checked out the visible result, have you?

> and when finally Gtk3 is released, we'll have to go back through ALL the
> code and re-HIGify it. Doesn't anyone else see how totally FUCKED this
> is?!?!?!?!?!?

That's the crux of progressive changes: You have to progressively adapt
to them.

regs,
 Chris