Re: gdl future

Hash: SHA1

Hi Naba!

> We need to be very careful on this. IIRC, gdl is also used by some other
> projects - can't remember them. Some of them could be using gdl-icons.

We should check this. I don't remeber anything besides scaffold to use
this library.

> I don't think it is fair to strip down a library because one application
> just happens to use only one of the widgets. Besides, later if gdl-dock
> is moved to gtk, gdl project would be dead (nothing inside :)).
> That said, I agree that we can still manage to remove Bonobo and GNOME
> dependencies from GDL, or at least be conditionally compilable.

Well, a library with nothing inside is just a depency to get rid off
(see: libgnome must die) ;-)

> There is no gtk-recent yet in gtk+ and egg-recent is not usable to many
> projects (libegg is not distributed). I would suggest to leave it and
> figure out a way to conditionally compile it without gnome-vfs. May be
> we should just get egg-recent into it?

If we want to extend gdl, we could add some more (or everything) of the
libegg stuff in anjuta to gdl and maintain it there.

But gtk-recent is in gtk (HEAD) which newly written code could use
instead of the need to stick to function which will be deprecated in ~5

> We can remove gdl-tools.c (and associated protos from gdl-tools.h). That
> will remove dep on bonobo. gdl-tools.h contains many helpful macros.

gdl-tools.h can stay or we can move it content to some other file.

> I think we can also conditionally compile it to not use gnome-vfs.

But is it clever to have Unix-IO as a fallback (e.g on Win32)? Or should
we simply not compile it at all in gnome-vfs is missing.

> Hmm. why? the pixmaps are equally old and outdated.

Sorry, I though they are used in symbol-browser plugin but it has it's
own images directory.

Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


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