glib in kdesupport: yes or no?

[Adam Treat]

On Sunday 09 March 2003 04:26 pm, Stefan Westerfeld wrote:
> 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.

I don't see how anything is increasing.  The two are different projects with 
different design criteria and goals.  Many wish that KDE and GNOME would 
merge, but I don't see how this is increasing or is of particular interest 
right now.  Besides, the question of putting glib in kdesupport does not 
change anything.  KDE and GNOME *are* different and will continue to be 
different.

> (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

Yah, so?  This has been the way of things for quite sometime.  People have 
known this and what do you suggest?  The developers get to chose what they 
write and this really can't be solved.  KDE and GNOME use completely 
different software and have different ideas about how the Desktop should be.  
I don't see this changing and I think it is a good thing.  Yes, some things 
can be done that increase the amount of integration and this is a good thing 
for those that choose to use both gnome and kde apps, but it will not make 
KDE and GNOME the same project.  Some people want to have a consistent 
integrated desktop *now*.  Starting over just so we can integrate GNOME and 
KDE apps fully is a waste of time and more work then just perfecting the apps 
we have.

> (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

And what would you have happen?  This is hand wringing for no good use.  KDE 
and GNOME are different and this isn't going to be rectified without major 
sacrifices and a complete shift in thinking.

> (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.

See, this is what really has me questioning the use of glib in KDE at all!  
What in your opinion is the *next step*?  Do we drop KParts for gnome tech?  
Do we all agree to converge on a toolkit (yeah right ;)?  How about all of 
the usability issues that have been so prominent lately?  Your continued 
insistence that KDE and GNOME are the same project or *should* be the same 
really has me worried.

> 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