[Glade-devel] Re: [LONG] Glade and Anjuta

[biswapesh_chatterjee tcscal co in (Biswapesh Chattopadhyay)]

[snip]
> Ok, so first, let's do a quick presentation of glade.  Damon Chaplin did
[snip]

So, glade-3 si not likely to be complte anytime soon - is that it ?
Looks like the anjuta1/anjuta2 situation all over again. Boy I hate code
rewrites ! :-(

> [snip]

> Ok, I've changed palette and properties to stand-alone widgets.  Widget
> Tree will follow soon.  For know, I will prefer to remain out of
> bonobo.  Let's take the time to learn what do we need, and once we have
> everything working as simple widgets we can put it in a bonobo
> component.

I'm not too keen on Bonobo myself and anyway, anjuta does not have the
capability (currently) to act as a bonobo container. Widget is fine.
I'll have a look at the code and let the list know how it progresses.

> However, I don't understand why do you need ScrolledWindow-derived
> widgets.  It seems more logical to me to just make these normal widgets
> and let the code that creates it to put it wherever he wants (a
> GtkViewport in your case, a GtkWindow in the standalone glade
> application).

Ignore this - a simple widget is O.K - we'll put it in a scrollable
container - in fact, that's actually a better solution. BTW, I hope your
widgets emit the necessary signals.

> Am I missing something?
>
> > 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.
>
> Ok, no problem.  I'll add that to the TODO list and code it asap.

Great ! Since you've already 'widget'-ified the windows, this should be
too much of a deal I guess.

> I will read your second way later, as it's too late now :-)

If you implement this, I guess there's no need for the 2nd method.

> > (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
>
> nope, we don't generate anymore C code.

> >     (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).
>
> I don't think it belongs to glade to do that.  We're a "build a GUI"
> tool, not a gtk+ instrospector.  What's the problem implementing that on
> anjuta itself?

Can you tell me how then to get the prototype for the function ? How did
glade-1 do it ? Was it all hardcoded ? I want the ability to define
custom widgets. Is there any way to introspect in GTK (maybe some
marshaller call ?)

> >     (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
>
> That would only be useful if the user is not going to use libglade, and
> if we give this possibility, then we'll run in troubles.

No, even if the user uses libglade, he/shell would still have to write
the callbacks, and I'd like to make that task easier. The idea is that
when the user adds a signal, the prototype gets generated (if it does
not exist) and the editor window jumps there.

> Thank you for your comments.

Thanks for getting back. You can join us at #anjuta (irc.gimp.org)
occassionally for discussions ?

I'll keep the list posted on progress. It would be nice to have the
widgetified widget tree though, with added nodes for signals at widget
level, so that when the user browses the widget tree and clicks on the
signal, we can take him to the code.

Rgds,
Biswa.

> Cheers,
>
>
> _______________________________________________
> Glade-devel maillist  -  Glade-devel lists ximian com
> http://lists.ximian.com/mailman/listinfo/glade-devel
-- 
Biswapesh Chattopadhyay <biswapesh_chatterjee tcscal co in>
TCS