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



Hi!  Please sorry the long time to reply.  Comments follow

Biswapesh wrote:
Hi all

First, let me apologize for the long mail.

[snip]
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.

Ok, so first, let's do a quick presentation of glade.  Damon Chaplin did
glade (let's call it glade-1), and has maintained it with much energy
over the years.  Chema Celorio was given the task to implement undo/redo
on glade-1, but he decided to rewrite it instead to make easier the
task.  Let's call this rewrite glade-3.

glade-3 was using gtk+-2, but it was taking too much time to complete,
and Damon then ported glade-1 to gtk+-2 (let's call it glade-2).  Damon
make it a11y savy and finished the port.  Chema stopped working on
glade-3 (when you see his list of projects, you can do nothing but
understand... :)

Carlos then took the torch on glade-3.  The latests patches to glade-3
were from Archit Baweja (to implement cut & paste) and from myself (to
implement undo/redo and fix several segfaults).

That was almost 1 year ago.  Nothing has changed since then.  If you
know of a Damon clon or something... :)

Easy, eh? ;)

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.

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.

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).

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.

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

(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?

      (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.

Thank you for your comments.

Cheers,






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