From - Thu Jul 16 09:21:45 1998 X-Mozilla-Status: 0801 FCC: /home/christof/nsmail/Archiv Message-ID: <35ADA87E.B04C9E74@wtal.de> Date: Thu, 16 Jul 1998 09:15:11 +0200 From: Christof Petig Organization: Adolf Petig GmbH. & Co. KG X-Mozilla-Draft-Info: internal/draft; vcard=0; receipt=0; uuencode=0; html=0; linewidth=77 X-Mailer: Mozilla 4.03 [en] (X11; I; Linux 2.1.98 i586) MIME-Version: 1.0 To: Damon Chaplin , arv@astor.urv.es Subject: Re: glade References: <000001bdb037$d6dc65e0$8f5395c1@default> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Damon Chaplin wrote: > > First choice seems easier and maybe we could build a generic (I like > > this word, have you noticed ?? :-) framework for code generation. > > Ideally the programmer adding support for a new languaje should supply > > only the gb_XXX_write_source_YYY and YYY_write_preamble_ZZZ functions (I > > think we can consider a function definition + variable declaration as a > > preamble as well). This approach seems easily modifiable when Gtk has > > Arg support. Could you send me Christof's e-mail ?? maybe we could work > > together defining some bases (generic, of course :-). > > > > The time I'll spend ?? I don't know for sure. I would like to have glade > > generating Perl code in 1 month or so. Do you think it is reasonable ?? > > Currently I'm working in a Gtk based front-end for gdb and I don't have > > too much spare time. > > The current C output took around 2 weeks, and there were two of us. > So you should be able to get at least half of the widgets done. > > Unfortunately some of the widgets are quite awkward, e.g. notebook, > filesel/colorsel dialogs, clist, option menu, so these need quite a bit > of work each (I haven't finished the C output for these). > > Christof's email address is: christof.petig@wtal.de > I've cc'ed this to him. > > Damon Hi Damon, Hi 'arv', Wow, I'm really looking forward to this discussion! Since glademm and glade are really different according to inner structure and generated code (monolithic creation function versus nested object hierarchy) they don't even share the principle. And no code. I'd even call this a good point since now we have two approaches to talk about. -------------------- another topic -------------------------- So, I would like to mention another point which is genuine OO (so C++?) (would like to proven wrong). Imagine a normal program. Surely there will be common substructures in a lot of it's GUI. For example date input: three labels, three entries/spinboxes contained in an hbox. Say you use it within one window and two dialogs. Up to now, glade doesn't know about the similarity and you have to duplicate code! Another example is a label and an entry. Usually I stack some of them atop in an vbox. Why not make it a black box with about two (or more) parameter: LabelEntry(text,entrysize). One function would be needed to create each of them. In C++ this is common code practice but it would definitely mess up your current C code generation (?). And glade can't (yet) select widget properties as parameters. E.g. think about a parameter which changes the width of an entry. glade uses a spinbox, how to enter a parameter name into a spinbox. Common substructrures (Cossy/Cossies might be a good codename) are a good approach to it (make it an object with methods). Is glade that object oriented? I didn't look that deep (I usually meditate on the structure of the output file). Well, too many text. Think about (cossy = macro ?) LabelEntry %text %width GtkHBox ... GtkLabel ... GtkEntry ... %with ... GtkWindow GtkVBox LabelEntry %text Your Name %width 88 LabelEntry %text Street %width 60 ... Christof