An user point of view on KDE and the glib issue

M. Fioretti m.fioretti at inwind.it
Sun Mar 9 15:31:44 GMT 2003


NOTE TO THE LIST MODERATOR:
This message, even if it doesn't deal with strictly technical issues,
*does* belong to the kde-core-devel list. It presents directly to the
developers an end user point of view (wrong or right doesn't matter,
as far as moderation is concerned) on an issue that *they* are
discussing actively in these days: if and how KDE development and
applications should rely on, or interact, with non-KDE objects. Please
let the message through!

Now the actual message:

I am not a KDE developer. For that matter, I am not even a C/C++
developer. I have followed, however, the "glib/KDE3" discussion here
with great interest, and, since in that thread many things have been
said "in the name of users", I may help to clarify things a little on
that score, starting from the two statements which I pasted below.

On Sun, Mar 09, 2003 15:07:08 at 03:07:08PM +0100, Waldo Bastian (bastian at kde.org) wrote:
> On Sunday 09 March 2003 09:59, Neil Stevens wrote:
> > On Sunday March 09, 2003 12:42, Stefan Westerfeld wrote:
> > > ... 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.
> >
> 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. 

EXACTLY!!!!!!!!!!!!!!!    In the thread I mentioned,
I have read a lot of heated assertions that C++ is the greatest thing
in computing since Babbage, that developers should be convinced to
switch to it and to KDE, that KDE must become the best and ultimate solution
to every desktop computing need.

I have no competence to say if and when C, C++ or (AFAIK) Fortran are
or not the best solution to any programming problem, so I won't say
anything about that. You all know much more than me about this.

I don't even have nothing to object/criticize about who wants to make
KDE the ultimate and only desktop: all Free SW projects are equally
worthwhile and deserve the same respect.

I just wanted to point out, however, that, from the point of view of
the many thousands of inexperienced users which will try to switch to
a non Microsoft desktop in the short/medium term:

	C, C++ and any other programming language have no difference

	KDE *and* GNOME *are* working on the same goal: a *nix based,
	user friendly desktop

	They want to be free to mix at will any combination of apps,
	no matter where they came from, and pretend to see them
	interoperate perfectly (**). They were told that Free SW was about
	choice. The "all KDE or nothing" attitude (but it would be the
	same with Gnome, of course) coming out of some developers
	would only confuse or irritate them ("everything works SO much
	better when you buy only Microsoft SW"...).

I don't certainly pretend that anybody of you cares about this. If you
want to reinvent the whole world the KDE way, it is perfectly OK.
Seriously. I don't want to start a flame war on this, just ignore this
message and keep programming. Only, when you say "users" please
specify that you mean "that little _minority_ of current *nix users
which would actually understand, and care of, the "elegance" of this
or that solution". Not the average *nix newbie of this period, who
just needs a desktop quickly.

	Ciao, and thank for your time

		Marco Fioretti 

(**) and, I should add find it difficult to understand why it needs
"all in one language" instead of "every app talking to others through
standard protocols/file formats.
	
-- 
Marco Fioretti                 m.fioretti, at the server inwind.it
Red Hat for low memory         http://www.rule-project.org/en/

Don't tell me how hard you work.  Tell me how much you get done.
					        James J. Ling




More information about the kde-core-devel mailing list