John Margaglione wrote:
>
> I know that improved code generation has been on the "future" list for a
> while now, and I think that it is by far the most important, so I'm going to
> do it. I have made a list of improvements and the necessary changes to
> accomodate them, but I want to hear from the developers and see what other
> ideas you've batted around (I didn't see any discussion of this in the glade
> archives).
>
> Improvements:
>
> 1. Code should be generated into multiple files, with a .c/.h pair for each
> top-level/dialog/popup window. This should reduce compile times, as a
> change to one widget doesn't incur a compile of all of the code. I am
> considering using the same technique as the C++ mode, where any widget can
> have a file generated for it, but I'm not sure I agree with that option. I
> know of no other tools that implement things this way, unless you are
> creating a custom widget. I suppose it could be used to create custom
> widgets based on aggregate controls in a panel. Thoughts?
Separate .c/.h pairs would be good.
I don't know about writing widgets in separate files. I suppose it may be
useful in some situations, but I'm not sure its useful enough to go in Glade.
> Within the .h file, there would be the declarations for each control(
> this removes the need for the lookup_widget function), plus a
> create_<whatever>() function to create the component. The .c file would
> have the create_<whatever>() function implementation, which would have all
> of the commands found in interface.h to create the widget. It would also
> house all of the callbacks. I like the idea of having everything about a
> wiget in one file. I have also considered putting the widget declarations
> in a <whatever>_priv.h file, then putting accessor methods in the .c file.
> This would be more of a property-like implementation (like Java and Delphi,
> two of my favorite tools). Or the declarations could all be in the .c file
> and then made static to hide them, with global accessor functions. I know
> that one of my gripes with C is that there are only two levels of
> visibility: global and file. I don't like the fact that I have to name my
> widgets with monstrously long names to avoid colliding with names from other
> dialogs. Why shouldn't each dialog have a GtkWidget *ok_button. Now I need
> a main_app_ok_button. Ugh. Anyway, any other thoughts?
We can't declare widgets as globals, since we want to support multiple
instances of each window/dialog.
The thing I was going to do was to add component structs, which contain pointers
to all the widgets in the window. Someone has sent me a patch to do this, so
it may get added soon.
We could also let the user add their own data to the struct, and we could
automatically pass it to all signal handlers as the data argument.
> One last consequence of all this is that I will need to write a lot of
> code to ensure that code written by the user is not overwritten. Another
> consequence is that there will need to be another property in the property
> editor to specify the name of the output file(s), and a way to change that
> file name. Consider the user creating a dialog, naming it MyDialog, and
> specifying MyDialog.c/MyDialog.h for the implementation files. Later on the
> user decides to change the name of the dialog to PropertyDialog, and changes
> the corresponding implementation files to PropertyDialog.h/PropertyDialog.c.
> The program would have to rename the file before doing code output.
Yes, it will be complicated. In this case you could detect when the property
has changed and ask the user if they want to move the file to the new position.
> 2. Initially, all widgets are created an shown in main.c. I like Delphi's
> method of specifying "auto-create forms". We would add a property in the
> designer called "Auto Create", then only create and show widgets that are
> specified. That saves me from having to edit main.c every time I add a new
> dialog.
We could honour the 'show' property of the toplevel widgets, like libglade does.
Though we'd need a way for the user to get a pointer to the auto-created windows.
Damon
+---------------------------------------------------------------------+
To unsubscribe from this list, send a message to [EMAIL PROTECTED]
with the line "unsubscribe glade-devel" in the body of the message.
