glib in kdesupport: yes or no?

[Havoc Pennington]

On Mon, Mar 10, 2003 at 03:42:28PM +1000, Don Sanders wrote:
> 
> I am concerned. I am concerned that adopting glib for KDE (CVS) 
> development will make developing KDE more difficult.
> 
> If glib is adopted and used (by someone else) in code I work on or 
> want to work on then I will be required to understand glib in order 
> to develop for KDE.
> 
> This additional complexity is not something I anticipate in a positive 
> way, I don't support inviting other developers to decide that I 
> should use glib, and hence this request is not one I can support.
> 

Note, I didn't really mean to weigh in on the "adopt glib" debate (as
I said I don't even think it's super important whether you do).  I was
more addressing the larger meta-issues people introduced.  What I'm
trying to request/propose does not depend on using GLib or not.

In particular it seemed to me that the thread was not distinguishing
fragmentation from choice, and was thus arguing black and white
extremes (desktop project merger vs. total separation) when we really
have a fairly small set of interoperability tasks that are very
important to do, and the "merger" thing is not nearly as important as
these small tasks, if it's important *at all*.

The user and third-party-developer visible problems are pretty
tractable and only require minimal shared implementation.  So I don't
think there's any need to be heavily polarized on these issues; they
are simple things that make a big difference for users and developers,
we can easily do them, they are worth the occasional easy compromise.

Avoiding fragmentation when we are already 95% interoperable (thanks
to X11, etc.) is not that big a deal, just requires a bit of thought.

Havoc