[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: glib in kdesupport: yes or no?
From:       Havoc Pennington <hp () redhat ! com>
Date:       2003-03-10 4:02:26
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]