[Glade-devel] RE: Glade.

[biswapesh_chatterjee tcscal co in (Biswapesh Chattopadhyay)]

Bas

I must confess this is news to me. I was under the impression that
Glade-3 has the same output XML DTD as glade-2, and libglade can be used
with glade-2 generated files as well as glade-3 generated ones.

I'm CC-ing this to glade-devel, hoping for some insight from the
developers.

Rgds,
Biswa.

On Wed, 2003-05-07 at 11:06, Bas Driessen wrote:
> Thanks for reply Biswa,
>
> You mention that it does not matter if the Glade files are produced by
> Glade-2 or Glade-3. Unfortunatly, I can't agree with this. If I try to
> open a Glade-2 (2.0.0) file with Glade-3 I get the error "Could not open
> project". If I use "test-libglade" (2.0.1) to test a glade-2 file I get
> a bunch of unknown property warnings. So 2 questions:
>
> -1 How do I convert Glade-2 files to Glade-3 files?
>
> -2 Which libglade should I use to work with Glade-3 files and where can
> I find it?
>
> Thanks,
>
> Bas.
>
>
> -----Original Message-----
> From: biswapesh_chatterjee tcscal co in
> [mailto:biswapesh_chatterjee tcscal co in]
> Sent: Wednesday, 7 May 2003 14:46
> To: Bas Driessen
> Subject: Re: Glade.
>
>
>
> Hi Bas
>
> Apologies for the late reply. I'm afraid I haven't had any time to look
> into the glade integration issue. However, Glade-3 is probably a better
> long term bet since it has a widgetized structure, which makes embedding
> easy (just like using other GTK widgets), so I'm inclined to go that
> route.
>
> As far as using libglade is concerned, the answer is a definite yes. It
> doesn't matter whether the glade files are produced by glade-2 or
> glade-3, since they produce identical files. Using libglade is not only
> possible, it is also strongly recommended (as opposed to using source
> code generated by glade) since it makes code size smaller and
> maintenance much easier.
>
> HTH
>
> Rgds,
> Biswa.
>
> On Mon, 2003-05-05 at 07:54, Bas Driessen wrote:
> > Hello Biswa,
> >
> > I saw your message (below) in the glade mailing list. I am especially
> > interested in your point no 1. I have a similar situation where I want
>
> > to integrate the glade tool into my product. So how far did you get?
> > Is it possible with Glade-2? If not, is Glade-3 the answer? Can I
> > still use libglade in a runtime situation where I want to display
> > glade-3 screens? I realize you are not a Glade developer, but any
> > help/tips/references regarding glade GUI integration you have is/are
> > appreciated.
> >
> > Thanks and Regards,
> >
> > Bas.
> >
> > ----------------------
> >
> >
> > 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 panes.
> >
> > 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
> > enhancements:
> >  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
> > windows/dialogs.
> >
> > 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.
> >
> > Rgds,
> > Biswa.
> >
> >
> > _______________________________________________
> > Glade-devel maillist  -  Glade-devel lists ximian com
> > http://lists.ximian.com/mailman/listinfo/glade-devel