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

List:       kde-look
Subject:    Re: Question about KFM
From:       Arnt Gulbrandsen <arnt () gulbrandsen ! priv ! no>
Date:       1997-06-27 14:17:40
[Download RAW message or body]

 [ note from: address ]

Bernd Johannes Wuebben <wuebben@math.cornell.edu>
> On 26-Jun-97 Arnt Gulbrandsen wrote:
> 
> >Putting shared functionality in shared libraries isn't rocket science.
> 
> It certainly isn't, and while your objections are valid, in fact I share some
> of them, everyone here is overlooking one central fact. 
> 
> THE COST OF DOING SO! 

Which goes up as time goes by, in my experience - initially, it's just
a matter of putting certain classes in a library, but eventually those
classes come to depend on the rest of the application they're part of.

More importantly, there are the ever-present license problems.  The
kde-libs license allows moving code from it to e.g. kfm, but the GPL
(which covers most classes written for the KDE) does not allow moving
code into kde-libs (which is now LGPL'd, I understand).

> We are struggling very hard to get SOMETHING out that is useable
> SOON. Do you guys really think we are not aware of the dependencies
> problems? How much insight do you think it takes to discover them?
> And why do you think we are not in possession of that insight?

I've read all the lists except kde-private since they were created and
not seen any discussion of the dependencies, or of their implications.
(For example: what happens when I ask kpanel to start netscape, if I
am running kfm already but on a different machine with a different
file system?)

THAT made me think that the dependencies were badly considered.  A
quite reasonable assumption, I think.

> Right now, I am very thankful to Torben for his work, for what he is
> doing for our project. He is struggling very hard every day to get
> KFM II out soon.

Indeed.  I should have included some positive verbiage in my original
message.

> EVERYTHING IS A TRADE OFF: If I asked Torben to cleanly separate KFM
> II into library and application part this would cost us many weeks
> and much sweat.  While on the long run this might be something we
> need to do, IT IS NOT ON TOP OF OUR PRIORITY LIST. ( As an extreme
> for this sort of stuff have a look at the GNU Step project. They may
> be doing things the "RIGHT WAY (tm)" but with a bit of luck their
> stuff will be ready to use, once UNIX has completely withered and
> died away under the merciless sun of Windows NT where nobody is
> trying to please everyone, but where things are focused and things
> are getting DONE.)

Your analogy fails - there only reason I can see to think that gnustep
does things the right way is that they're copying someone else.

> I do appreciate Arnts comments. While I don't always agree with him,
> his comments are usually stimulating and do have a certain healthy
> authority as one of the creators of Qt.

Thanks, but no thanks :)

As you can see, this is sent by arnt@gulbrandsen.priv.no, who has -no-
relation to Qt.  Obviously.

> The KDE project is not one that is marked by the influence of the Waterfall
> design model.

Quite right again.  The waterfall model is for people who believe they
can get something bug-free first time.  Laughable, IMO.

--Arnt

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