glib in kdesupport: yes or no?
manyoso at yahoo.com
Sun Mar 9 17:07:46 GMT 2003
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
> (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
> (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
> 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
More information about the kde-core-devel