Re: [GnomeMeeting-devel-list] [PATCH] removes unneeded begin/end call notification in text-chat

[PUYDT Julien <julien puydt laposte net>]

On sam, 2004-01-24 at 11:36, Damien Sandras wrote:
> > Well, no I haven't, and in fact, I don't really see why it is needed...
> 
> A GObject? Because it is a clean way to create new widgets with an
> object-oriented approach.

Hmmm... I hadn't a real object-oriented approach in mind ; what I would
like to see is certainly much more simple and conservative (but still
probably too much for 1.00):

* in gnomemeeting.cpp, you would see:
** in the constructor: gnomemeeting_foobar_init ();
** in the destructor: gnomemeeting foobar_reset ();
and elsewhere calls to gnomemeeting_foobar_feature (...);

* In foobar.h: the declarations of those "api" functions.

* In foobar.cpp, in that order:
** the includes;
** some private variables declaration (static);
** the helper functions' declarations;
** the api functions' definitions;
** the helper functions' definitions;

> Because static variables wouldn't work in all cases (by definition of
> static, they are local to a method, except if you want to make them
> global).

I want them neither global nor local to a method. I want them defined
and used only in the file where they're used, and only accessible
through a precise api.

>  You would then end up with a mix of structures and of static
> variables, which wouldn't be good either. So the CODE Policy is now to
> either use structures declared at an appropriate place (could be
> elsewhere than common.h), or GObjects.

No structure here, only variables accessible to all the code that needs
them, and only to the code that needs them.

> Not so near, but near enough. If we release 1.00 in February/March, it
> means we could also release a GnomeMeeting version with enhancements,
> but based on OPAL and still H.323-only for the summer. Then we could
> have SIP and IAX later.

Oh, what I have in mind probably wouldn't take that long: it's basically
keeping the same code but moving the declarations and initializations
around.

> Not really, both can be done at the same time. Porting to OPAL will only
> change the endpoint.cpp, and connection.cpp files.

That sounds wonderful... then why two branches? ;-)

Snark