[Glade-devel] [LONG] Glade and Anjuta

Hi all

First, let me apologize for the long mail.

I'm a recent subscriber to the list so excuse me if this has been
discussed before.

I'm the maintainer of Anjuta (stable branch) and the author of the code
browsing parts (symbol/file browser, autocompletion, etc.).

Through Anjuta, our target is the newbie Linux/GNOME developer. As you
can realize, to the VB/VC crowd, *the* most popular feature request for
the GNOME2 version (The GNOME 1.x version is maintenance only now) is
better glade integration. I've thought about this a bit but since I know
virtually nothing about glade I thought people on this list can give me
some ideas. Maybe at least some of the things I want to do are done
already; in that case I'd like to know how to use those features.

What I'd like to do is:

1) GUI Integration: I'd like to have the three main windows of Glade
(Palette, Properties, Widget Tree) to be dockable windows, either as
Bonobo components (preferably as shared lib - out-of-proc is a pain), or
as ScrolledWindow-derived widgets, which we can put in our left /bottom

2) Glade Signals: We already have a decent symbol manager which keeps
track of all code components (structs/functions/prototypes, etc.) and
their locations (file name, start/end line/pos, etc.). We need to
integrate the editor, the symbol manager and the widget tree/properties
window. There are two ways of doing it:
        a) If the properties window is a docked widget, it can emit the
"signal_added" signal. The signal handler should be passed the widget
and signal details. We need the <widget> node and the <signal> node of
the glade file. We can then check in the symbol database if the function
exists (creating it if necessary my popping up a dialog and taking the
extra paramaters from the user). Once done, we can jump to that function
to allow the user to add/edit code.
        b) The component can emit the "saved" signal at which point we load the
XML into a tree, parse for <signal> nodes, create new signals as
necessary by consulting the symbol database and show the widget XML tree
(with the signals). The user can then click on the particular signal and
start editing the code.

There are two main problems with the above requirement:

(i). We need a database which tells us the parameters (along with their
types) and the return values of each type of function. I'm guessing you
guys already have such a database (since you generate the C code), but
how do we access that ? Do you have it in a reusable format ?

(ii). The Glade Properties/Widget Tree components need some
        a. An 'Edit Code' option for the signal which should emit the
"edit_code" signal with the function name, etc. as parameters.
        b. A way to associate header and source files at a window level. This
cannot be done at a project level because a project has multiple
windows/dialogs and the normal practice is to have a header/source pair
for the callbacks of each.

The user can, of course, select the same file for multiple

For (ii), we need a window-level extra properties tab in Glade. In the
XML file, for each top level <widget> node, we need to add <header_file>
and <source_file>. Currently, these nodes are only present at the
project level - they need to be moved down to the window level (keeping
them at the project level as well, and using them as default values
should be O.K though).

3) Glade Preferences: We'd like Glade to get/set glade preferences,
since some of them are common with the project preferences (top
directory, source dir, pixmap dir, etc.). Since they are saved in XML as
well, the simplest course of action might be for us to generate the
necessary XML and get glade to load it on startup. We can add the
necessary GUI under a 'Glade' tab in our preferences system and bypass
the Glade prefs dialog.

4) Code Generation: We'd like to bypass Glade code generation and
encourage users to use libglade. However, it would be nice to be able to
use Glade to generate the code on demand. Specifically:
        (i) We'd like to be able to call a Glade function with the widget and
signal name and get the function name, parameters types and return value
(a simple string containing the prototype will do).
        (ii) We'd like to be able to pass a widget ID and get (as a string) the
code to build the GUI in the passed language of choice

Some of this, of course, is already covered in (1): Signal Handling, so
maybe I need to club the two requirements together.

Finally, thanks for your patience. Hoping to get suggestions on how to
proceed with this.


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