Re: to GList or not to GList?

[Martin Craig <mcra98 esc cam ac uk>]

Glib does not depend on GTK so I don't see the argument
against using it. There is no 'navel-string' in that
direction, is there? I thought this was the whole
point of keeping glib separate? You can use it with
whatever GUI you please.

Am I wrong? I don't know much about the how glib
fits into GTK/Gnome 2.

Martin.

On 2001.07.31 17:45:50 +0100 Carlos Pereira wrote:
> > > However, in my opinion, it is a bad ideia to rely on
> > > glib to supply your list needs, unless you are writting
> > > a small app. The core of an application should not deppend 
> > > of glib, which primary purpose is to support gtk needs.
> > > If you change the GUI toolkit, the inner core, the engine 
> > > of your program, should remain the same. Yes, this means
> > > to have your own lists in the code, not those supplied
> > > by the GUI toolkit.
> >  But imho programmer should use Havoc's method ;-)
> >  i.e. cut appropriate code from glib (i.e. list's code).
> >  So we: (1) don't invent wheel
> >         (2) get checked and tested code
> >         (3) cut off navel-string: we can use that code
> >             with any GUI, even if that GUI use another glib
> >             version or doesn't use it at all.
>
> The question here is about code control, not code origin.
>
> I didn't say that people should write their own lists.
> I am totally happy if programmers cut and paste checked and 
> tested lists from glib or any other reliable source to their
> own code (license permitting of course) as long as
>
> this becomes a new instance of the code, totally
> independent of its source, glib or wathever, so the
> app inner core lists don't deppend of the original code 
> at all.
>
> the programmer fully understands the code delicacies
> that she/he is introducing in her/his app inner core,
> where bugs have widespread effects and are hard to find.
>
> In short, I agree with your points (1), (2) and (3) :-)
>
> Carlos