glib in kdesupport: yes or no?

[Neil Stevens]

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

On Sunday March 09, 2003 08:02, Havoc Pennington wrote:

Here are some actions.. please correct any GNOME misundersandings I express 
here:

>  - registry of cut-and-paste/DND types (just a spec)
>  - MIME system (just a spec, though could have a small
>    shared/reference implementation if we wanted)

For better or for worse, I would expect that this should be able to build 
on the VFolder work already done.

>  - shared configuration system (some shared implementation,
>    but order of 10K lines of code at most, assuming use of D-BUS,
>    and no shared *library* that apps link to just shared command
>    line tools)

GConf + D-BUS?  I don't expect this to be a popular one here. :-)

>  - sound/multimedia framework (shared implementation)

This isn't something that can be resolved for a long time.  KDE is tied to 
aRts.  And frankly, even if we decided to use GStreamer, some of us would 
like to see GNOME be the side that goes and works out the kinks of that 
immature system.

>  - component/runtime system (shared implementation, but would be its
>    own GLib/Qt equivalent so "using" GLib/Qt doesn't make sense and
>    isn't an issue, and is star trek future stuff anyway)

Not going to happen. :-)

>  - VFS (large/complex shared implementation, so as I said Hard)

 "   "    "     "

>  - accessibility (could just be a spec, though not sure what's
>    planned right now, it does already plan to work with
>    Mozilla/OpenOffice/Java)

Aren't you guys basing this stuff on CORBA?  I don't see KDE being able to 
use that.

>  - UI guidelines (spec)

If everything in the backend gets standardized, UI guidelines will be the 
only differences between the environments.  So I would say this would be 
harmful, to stifle innovation in the only remaining place to innovate.

>
> There's also a longer list of already-started stuff, that is almost
> all specs. If you combine the lists and assume it's all implemented,
> you still have the vast majority of existing GNOME/KDE code
> unchanged. Which is the whole reason I think the undertaking here is
> feasible.

Maybe some stuff gets left unchanged, but things like UI, KIO, DCOP, KParts 
are defining features of KDE as it exists today.  Replace them all and 
what's left?

- -- 
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+bBYVf7mnligQOmERAj4zAJ9E7Rq6UpmV3Si2QBaYHTXcIbT7XQCdFPWG
j5XYi9R2ytC357jzWk5YOJs=
=MT5w
-----END PGP SIGNATURE-----