Re: [evolution-patches] Make folder selector more HIG compliant
- From: Christian Neumair <chris gnome-de org>
- To: Jeffrey Stedfast <fejj ximian com>
- Cc: evolution-patches lists ximian com
- Subject: Re: [evolution-patches] Make folder selector more HIG compliant
- Date: Wed, 02 Jun 2004 18:45:47 +0200
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]