[gtk-list] Re: Re: Resource parser



On Sat, 3 May 1997, Richard D. Jackson wrote:

> >         Yup. Souunds cool. Unfortunately I havent the slightest clue of
> > how to go about  making the ui change at run-time. Actually, now that I
> > think about it, it shouldnt be that hard as stuff in the gimp ui changes
> > in run time (click this button, that button disappears, etc). How to do
> > that based on a resource file I am not to clear on. Unfortunately, last
> > ime I checked all the .gimprc configurable stuff in gimp that should
> > effect the ui didnt work (ie, rulers, the transparency "check" size, etc).
> > hmmm.
> > 
> 
> Actualy implementing this should not be too hard. All you realy need is
> a function that can read and parse the resource definitoin and call the
> right gtk function to create the widget or interface. Along with
> registerd functions you could also attach the functions for the varios
> events. True it will take some time but still it should not be that
> hard. Hell if MS$ and IBM and do it why can't I do it? Shoot I've even
> seen this done for Motif widgets but as with all things Motif dies this
> cost you another 2mb or so which is outragous.

hm, part of this is already implemented in Gubi (gtk+ user interface builder)
that i'm currently working on.

so far there are several structure types referring to a GtkWidget that hold
their specific data.
e.g.

struct  gb_wdat_radio_button_S {
	GtkWidget               *widget;
        [ some basic fields that are common for all widgets
          such as width, hight, *parent, widget_name border_width ];
        gb_wdat_base_S          *clone;
        gb_wdat_base_S          *next;
        gchar                   *label
                                /* !=NULL indicates a child
                                 * of GtkLabel
                                */;
        gboolean                init_state;
        gboolean                draw_indicator;
        gb_wdat_radio_button_S  *grouping;
};


Gubi out puts static structure definitions that are processed at runtime
to create the Gtk+ gui.

as some times you define a window and need it multiple times on the screen
(e.g. My_nice_Message_window) a window's gb_wdat_*_S tree can be cloned and
then build by using the structure copys.

then there are the config file reading routines that just build up dynamicly
the gb_wdat_*_S tree.
the config file looks like:

GB_WIDGET_WINDOW  "Main_Window" {
  title        "Gubi"
  resize_policy        6

  GB_WIDGET_V_BOX  "" {

    GB_WIDGET_H_BOX  "" {
      border_width        10
      GB_LINKAGE_BOX {
        attach        4
      }

      GB_WIDGET_ARROW  "" {
        arrow_type        3
        shadow_type        1
      }
      GB_WIDGET_ARROW  "" {
        arrow_type        2
        shadow_type        1
      }
    }
  }
}

so this goes basicly into the direction you want it - parsing a text file and
dynamicly building a widget tree with gtk.

i would like to hear about your ideas what the resource file should look like?


---
ciaoTJ

Tim.Janik@Hamburg.Netsurf.DE	[signature: <CENS||ED>]

--
To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null



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