Re: GNOME & KOM/OP



For this project, most if not all core parts are C, plain and simple.
Though I'm not really the athority on such things,(Don't know who is anymore, if
anyone...) , but from what I've seen, if it's not C, it's not part of the core.
and I'd say that complex document support is kinda core stuff :)

The best reasons I've seen stated for this are:
	C is so low level as to be easy to hook to higher level things,
	makeing bindings far more simple.
	C makes much smaller/faster code, both inherint through design, and
	in it's optimization, then c++, not even bringing STL's bloat to light.
	C is more popular.(opinion, based on observence)

So in the end, Gnome may be harder to "maintain" then <Obj lang> code, but
the advantages make it well worth the effort doing so.
Gnome, unlike KDE, has THE CHANCE to end up with a fully funktional, 
extenable, stable desktop, that still runs nice with apps going on 16 or less
megs, and a dx50. (KDE, just for input, no flames, run about right, if a little
slow on a p100 with 48mb.)

I'm for makeing our own Doc type, or useing OpenDoc after moveing it to
C/Corba(Orbit). That is if IBM will give it to us, as there page says they may.

  On Sun, 09 Aug 1998, Sirtaj Singh Kang wrote:
>On Sun, 9 Aug 1998, Phil Dawes wrote:
>[snip]
>> However, if openparts is as good as people say, which it could very well
>> be since the author would have had access to the designs of both OLE and
>> opendoc, then we'll have it!
>
>Hi,
>
>Torben is writing openparts as his Masters' thesis project, so he has a
>responsibility to keep it well-documented and written.
> 
>> However, in order for it to be accepted wholesale into the gnome
>> community it would really need the following characteristics:
>> 
>> 1) Written in C.
>
>This is going to be a problem.
>
>> 2) Free of all QT code - it's not standard, and not fair to expect
>> gnome-only desktops to require it just for a set of collection classes
>> (which we already have in glib). 
>
>All of this is being replaced with STL containers (for better or worse -
>The Qt containers are generally more compact and portable but, well,
>they're part of Qt)
>
>I think the main sticking point for you guys is going to be the fact that
>it uses C++ quite extensively. If you can get around that (not something I
>would want to do :) it may save us from yet another "similar but
>different" standard API. 
>
>This doesn't address the fact that Miguel seems to have subjective
>technical criticisms of the design, but he hasn't mentioned exactly what
>they are yet so I assume they are surmountable. 
>
>-Taj.
>
>Sirtaj S. Kang       taj@kde.org         ssk@physics.unimelb.edu.au
>School of Physics    Univ of Melbourne   KDE: The Desktop sans Toga
>
>
>-- 
>         To unsubscribe: mail gnome-list-request@gnome.org with 
>                       "unsubscribe" as the Subject.
--
Leareth <leareth@geocities.com>
-- You've got to lose, to know how to win.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]