glib in kdesupport: yes or no?

[Neil Stevens]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday March 09, 2003 06:07, Waldo Bastian wrote:
> On Sunday 09 March 2003 09:59, Neil Stevens wrote:
> > On Sunday March 09, 2003 12:42, Stefan Westerfeld wrote:
> > > And if you still think KDE and GNOME are seperate projects, and for
> > > that reason don't want to install glib-2.0 on your system, I think
> > > you're keeping up the illusion that KDE and GNOME are working on
> > > different goals. They are not. Thus, this is no valid reason for me.
> >
> > For some of us, your aims to make an inconsistent,
> > least-common-denominator amalgam of GNOME and KDE are not valid
> > reasons to add a new dependency to KDE 3.2.
>
> I think your statement that Stefan aims to make an "inconsistent,
> least-common-denominator amalgam" are not based on facts but rather
> reflect a somewhat irrational fear on your part.

No, my statements are based on my English comprehension skills, having read 
where Stefan describes how this use of glib in KDE is a step toward the 
"convergence" of KDE and GNOME, and is a calculated effort toward banning 
the use of C++ in parts of KDE where he wants the GNOMEs to re-use:

"Thus, at this point in time, I see no longer a reason to upkeep not 
demanding KDE developers from using glib whereever they see it fits their 
needs best, and GNOME developers from using Qt whereever they see it fits 
their needs best. Then, if we'd made this step in our minds, the projects 
would naturally start to converge, and all of us would benefit."

"In fact, I am convinced that some things should be implemented in C. And I
am convinced that some things are implemented best using a main loop. Thus
I'd say that a user which commits himself to the irrational policy of using
only C++ applications and only C++ code, for the sake of attaining some
higher goal that I don't know of, should not be supported optimally by 
KDE."

KDE has used almost exclusively the C++ language since its inception.  I 
don't think it's appropriate to try to undermine that choice in this 
manner.

> I think you try to say "lowest-common-denominator" but I don't see any
> support for that opinion. I don't see how the use of glib would lower
> any aspect of KDE, in fact I think it would only improve KDE in certain
> areas: Those area's where now homegrown C-based solutions are used. If
> part of those solutions could be replaced with glib functionality it
> would be an improvement because the more common glib functionality has
> most likely received more testing and there are more people already
> familar with glib making maintenance easier.

C *is* the lowest common denominator of C and C++.  Stefan acknowledges 
that repeatedly, yet he advocates that KDE use more C.

glib is an inferior (see Stefan's comments on gobject) substitute for Qt, 
yet Stefan suggests that KDE adopt it:

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

> Second, I think that the sharing of code between GNOME and KDE can
> improve consistency of the user experience when it results in common
> features. A part of the KDE userbase may never use non-KDE applications
> but I think a substantial other part mixes KDE and non-KDE applications.
> I think that the ability to mix KDE and non-KDE applications when using
> the KDE environment is a very important feature for KDE that plays a
> very critical role for its acceptance by users. If you agree with me
> that this ability is indeed very important for our userbase, then I
> think you will also agree that we should do our best to provide as much
> consistency as possible for that scenario. After all, dekstop
> consistency is one of the few stated goals of the KDE project.
>
> I think that the adoption of glib for certain tasks within KDE will make
> it easier to achieve such consistency.

KDE was founded for UI and behavioral consistency, yes.   Can you explain 
to me how the use of glib in KDE will influence GNOME UI to obey KDE 
standards?

We can't very well gain consistency by disobeying our own standards, so 
GNOME adoption of KDE standards is the only way to get more consistency.

- -- 
Neil Stevens - neil at qualityassistant.com
"Among the many misdeeds of the British rule in India, history will
look upon the act depriving a whole nation of arms as the blackest."
 -- Gandhi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+a1jcf7mnligQOmERAhoAAJ9qG57qS1YWiv5YwLZhDe1iB9RgUwCgkG7K
TSIAolIBmZVtjEX3pjnYvj8=
=/AH2
-----END PGP SIGNATURE-----