glib in kdesupport: yes or no?

[Stefan Westerfeld]

   Hi!

On Sun, Mar 09, 2003 at 11:13:30AM +0100, Tim Jansen wrote:
> > If GNOME would add a Qt dependancy for getting
> > a sane C++ programming API, and we would add a glib dependancy for
> > portability, we would have effectively merged the projects.
> 
> Running a Gnome app and a KDE app in the same X11 server doesn't mean that you 
> merged the projects. GnomeVFS has different modules than KIO, KPart and 
> Bonobo are incompatible, so are DCOP and CORBA, the base dialogs and widgets 
> behave differently... there is no more interoperability than between a KDE 
> app and any other X11 application.

I agree that running both in the same X11 server doesn't mean merging. I mean,
we already can do this. However, increasingly that KDE and GNOME developers
still consider themselves a member of either project is increasing becoming
a real problem for users and developers.

(1) developers have to decide whether they write a KDE or GNOME application ;
  regardless of what they do, only some users (those that run KDE or GNOME
  as their primary desktop) will feel that they do get optimal benefit from
  installing the application - they are looking for some other application
  that is part of "their camp" ; this means, that all free software
  applications will effectively (need to) be implemented twice, to optimally
  satisfy users

(2) using the lower level services doesn't really work well, if there are
  two incompatible implementations of them - you will have two configurations
  which would ideally be in sync, but are not - you see this with the sound
  server or with KIO or with the Evolution mail handling ; it is hard to
  understand to users what exactly goes wrong if something works in one
  application, but not in another

(3) whether you consider yourself a KDE developer or a GNOME developer, you
  get a consistent set of choices to make on
   - the programming language to use for core libraries: C vs. C++
   - the toolkit to use for GUI programming: Gtk vs. Qt
   - the object model to use: GObject vs. QObject
   - ...
  So as some components of these might be inferior compared to other
  components, I think its unlikely that at any point in time, a user will
  get the optimal set of all applications and services from only KDE or
  only GNOME ; thus, it would be better if code sharing could be improved

And yes, adopting glib for KDE is only the first step.

However, thats kind-of off-topic: that glib should be used already appears
to be quite clear to me ; the question is whether to add it to kdesupport?
If anybody sees clear reasons for me doing it, I think I will do it as has
been proposed by somebody: optional (with a check whether its already there).

If there is no reason to do it, I'd rather not waste my time, and simply
assume that its widely spread already.

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan at space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-