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

List:       kde
Subject:    Re: Code sharing KDE&Gnome (Re: Red Hat will not ship KDE)
From:       Stefan Westerfeld <stefan () space ! twc ! de>
Date:       1998-08-12 11:47:07
[Download RAW message or body]

   Hi!

On Tue, Aug 11, 1998 at 04:58:13PM -0700, Alex wrote:
> [...]
> > I think Harmony is the better solution. KDE won't die fast anyway, so
> > let's make it work with Harmony, then everybody is happy.
> > (At least as happy as you can get with two different, currently rather
> > incompatible desktop environments ;).
> > 
> > > Personally, I just wish the Trolls would rethink their position and GPL
> > > Qt so we can put an end to the parallel development effort (kde, gnome)
> > > and pool our considerable resources.
> 
> Ya.  We use Harmony, and if the Trolls happened to live in the states,
> they'd be on wellfare.  Nice thought.  I'd say yes, give, in GPL it so we
> can all get along,

Cloning the interface (and being compatible) is what a considerable amount
of free software does. After all, GNU tries to offer an alternative to
commercial Unix implementations.
If you think this is unethical, linux as whole is. (But KDE would not exist
today, if people didn't use gcc, gmake, bash, glibc, ncurses, ... to develop
on KDE).

> [...]
> > An example is the VFS code, then there is database access, another example
> > is everything that has to to with multimedia, such as audio/image/video
> > filters, "codecs", ...
> 
> I think that it was stated before that the VFS code was based on truely
> separate thinking.  Either way, common code would be nice, but it means
> that one camp would have to give in and use a different language.  Not
> likely to happen (after all 80s style callbacks rule.. right?).

A common object model would perhaps be enough. Then, the libraries and
desktop features could be encapsulated in objects (probably CORBA based)
and be used from any language.

COM works that way, so under windows you can access IShellFolders for
instance from any language. And you can implement the objects in any
language you like...

I don't know whether it would be possible to do this with KOM. For
instance in KDE 2.0, the entire KFM, KPanel, KWM could be devided in
small KOM objects, which communicate.

Gnome will probably not use KOM though, so this would not be an instant
solution either. But the way would be right.

> [...]
> > I think this would even improve significantly when we would use STL instead
> > of QStrings and QLists everywhere.
> 
> Bleh.  Then you loose a nice thing called portability.  Sure if you want
> to develop a LDE that's great.  This isn't.  In a perfect world yes STL
> would be supported by all the majorly in use compilers.  But it's not.

It has been mentioned that STL is part of the C++ standard, and has to
be supported by a compiler, just as templates.  The container classes of
Qt are not necessary, and it's a thing that IMHO doesn't belong into a
GUI toolkit. You will use STL containers anyway when using CORBA (mico),
so it won't make portability worse.

> You're also forgetting about things such as slots, signals and
> QSocketNotifiers.  All three make coding much much easier.  You wanna come
> up with a decent non hacky solution.  That's great.  Until then I'll stick
> with my Qt.

Slots & Signals are reimplemented (kind of) in KOM, and belong into an
object model, rather than in a toolkit. I think most io operations could
be replaced by distributed objects, as it is the case in kfm with kioslave.

So you'll probably use slots & signals of the object model.

I know that this fine grained object approach may sound radical, but I
think it's the future.

  Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Freiburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-
-- 
Send posts to:  kde@lists.netcentral.net
 Send all commands to:  kde-request@lists.netcentral.net
  Put your command in the SUBJECT of the message:
   "subscribe", "unsubscribe", "set digest on", or "set digest off"
**********************************************************************
This list is from your pals at NetCentral <http://www.netcentral.net/>

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