>>> [EMAIL PROTECTED] 22.08.2000 16.09 Uhr >>>
> ...
> I am working on the glade-to-C translator. It will be callable from within
> glade or from the command line. I am also thinking about CORBA bindings so
> that it can be used within an IDE for more on-the-fly use. Ideally I would
> like to see glade, each of the translators, and an editor work in unison to
> create a Delphi-like environment for glade programmers.
Great!
>> - The lookup_widget function should accept a full 'pathname', like:
>> ok_button = lookup_widget(toplevel, "dialog1.vbox1.*.ok_button")
> I am actually completely removing the lookup_widget function. I don't see a
> place for this function in a clean modular design.
Could you please explain this:
- How do you want to replace it?
- Why don't you see a place for this function in a clean modular design?
> ...
> Each top-level widget will be placed in its own .[ch] pair, along with all
> of its signals. I have a problem with making a callback global, as this
> construct does not carry well to object oriented languages, where global
> functions are considered bad design. I will try to think of alternatives,
> perhaps a global callback object.
If you would say 'global variables are bad design' I would agree. But for
global functions???
IMO the OO design should help the programmer, but should not put her/him
into a strait jacket. BTW that's the reason why I don't like java.
> ..
> I heartily agree with the idea that widget attributes be XML attributes. It
> makes for a more readible DTD (child objects are spearated from properties
> clearly).
Nice to hear!
If only Damon could agree. ;-)
>> - For callbacks I see to possible ways:
>>
>> -- The callbacks, that are only inserted by now, should also be updated
>> and deleted. To prevent the
>> deletion of user supplied code, the callbacks should be
>> insert by something lilke
>>
>> void on_button_clicked (GtkWidget *widget, gpointer user_data)
>> {
>> /* *** user supplied code start *** */
>>
>>
>> /* *** user supplied code end *** */
>> }
>>
>> Everything between these start and end tags should never be
>> changed/deleted.
> Why bother with the /* blah */ construct when you can just use the "{" and
> "}" block delimiters from the function? It is actually a little bit
> trickier, since you can have nested block delimiters within a function, but
> the real litmus test is whether a new function prototype starts after the
> "}". That way we can handle unfinished code, like this:
>
> void on_button_clicked( GtkWidget *widget, gpointer user_data )
> {
> for ( i = 0; i < 10; i++ ) /* no opening brace! */
> /* do something */
> }
> }
>
> void on_button2_clicked( ... )
> ..
>
> But I still think that the /* user code */ construct is unnecessary. What
> if the user deletes the comments accidentally?
Of course you don't need it. I only introduced it to make life easier
(for the translator).
>> -- The second way is to edit the code in an editor inside glade and
>> always delete/rewrite the whole file.
> Ick. Ideally this would be the job of an integrated developement
> environment.
What is Ick?
-----
Gerhard
+---------------------------------------------------------------------+
To unsubscribe from this list, send a message to [EMAIL PROTECTED]
with the line "unsubscribe glade-devel" in the body of the message.
