From kde-core-devel Mon Mar 10 04:02:26 2003 From: Havoc Pennington Date: Mon, 10 Mar 2003 04:02:26 +0000 To: kde-core-devel Subject: Re: glib in kdesupport: yes or no? X-MARC-Message: https://marc.info/?l=kde-core-devel&m=104726909731798 On Sun, Mar 09, 2003 at 03:21:50PM -0500, Adam Treat wrote: > I don't see any technical reason for not using Qt and the functionality it > encompasses. arts today and then what tomorrow? ... or are the GNOME > developers going to allow us the use of Qt at all in any of this shared > infrastructure? > My feeling is that Qt would be fine in anything that is a separate process. I don't think GNOME would be willing to accept GPL libraries into a piece of platform all apps had to link to, though. However, the importance of this (and indeed the importance of KDE using GLib) seems somewhat overstated to me. The shared implementation code that we need to hit the most important usability issues is simply not that large. Here is a list of stuff we haven't started on in earnest but should start, that I presented at FOSDEM: - 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) - 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) - ~/Desktop, ~/Documents, etc. directories (a spec, plus some shell scripts if we do it the way I've proposed) - sound/multimedia framework (shared implementation) - 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) - 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) - help indexing (not something apps link to, could be either a spec or an implementation) - UI guidelines (spec) 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. Havoc