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

List:       kde-devel
Subject:    Re: mico 2.2.6
From:       Simon Hausmann <tronical () gmx ! net>
Date:       1999-05-20 21:46:59
[Download RAW message or body]

On Thu, 20 May 1999, David Faure wrote:

> On Thu, May 20, 1999 at 10:49:41PM +0200, Simon Hausmann wrote:
> > On Thu, 20 May 1999, David Faure wrote:
> > 
> > > On Thu, May 20, 1999 at 07:29:33PM +0200, Harri Porten wrote:
> > > > Hi !
> > > > 
> > > > Simon Hausmann wrote:
> > > > > 
> > > > > On Wed, 19 May 1999, Cristian Tibirna wrote:
> > > > > 
> > > > > > I have mico-2.2.6 for 5 weeks already. How can I help (what pieces of code
> > > > > > will need fixes and will not get people work on it)?
> > > > > 
> > > > > Thanks for your offer :)
> > > > > 
> > > > > One thing comes to my mind:
> > > > > 
> > > > > Help us finishing kded :)
> > > > > 
> > > > > Most stuff is working fine already, but I think it needs some
> > > > > polishing and testing.
> > > > 
> > > > I wanted to mention that I just started to "try to understand" the KOM,
> > > > OpenParts etc. stuff as well. Since kded is certainly not the easiest
> > > > part to begin with I'll concentrate on easier tasks first.
> > > > 
> > > > I switched to mico-2.2.6 yesterday. Are the compile errors in
> > > > kdelibs/corba the problems you were talking about ?
> > > 
> > > Those problems are 'simple' porting stuff, which Steffen and Simon have
> > > already done on their hdd. When they say "we all switch", I suppose
> > > they will also commit the necessary changes.
> > 
> > No problem, I'm ready to commit _ALL_ necessary changes.
> > 
> > > The problem is not that, but kded still not working well, so object
> > > trading would be broken. Perhaps we should apply those changes in a branch
> > > (like MICO_2_2_6) so that more people can test it with 2.2.6 ?
> > > Or this is stupid and let's simply switch and temporary lose embedding...
> > > Don't know.
> > 
> > Wellwell, *I* don't really care and know ;-)
> > 
> > *If* everyone agrees I can commit all stuff.
> > 
> > But in somehow I don't like the extra-branch idea very much. Just my
> > personal taste :) , I think it's a little bit confusing.
> > 
> > So IMO: _WHEN_ switching, then let's switch really, withouth an extra tag.
> > 
> > And: Switching now makes integrating kded easier IMO, since it wouldn't
> > require an all-in-one-really-huge commit, which would then include, beside
> > the mico porting stuff for kdelibs/konqy/koffice, also _all_ (upcoming)
> > changes with some .desktop files for the services, so that the trader is
> > able to find some koffice plugins and stuff _and_ the changes in
> > libkofficecore to call the trader+activator in kded.
> > 
> > It's not my decision :) . I can commit all stuff *now* (tonight) _or_ at
> > the end of the next week (because I'll have no net-access the next
> > week ).
> 
> ok, ok ..
> 
> I would say "let's switch", but be prepared for tons of bug reports on koffice@ :))

Hehe, ok :-)

commit done

> How long do you think before kded is ready (in the sense that it can replace
> koffice's trader ?)

Hm, I don't want to make false promises... ;-)
I think kded isn't very far from being ready as replacement for kotrader.
Perhaps we can finish it at the end of the next week (when I'm back) .

But then we need to finish the directory-for-some-services issue I think.

> I don't think we all need to say "yes" to the switch. Let's simply say that if nobody
> objects (and it doesn't seem that anybody objects) then we'll switch asap.

now it's too late anyway ;-)
 
> /me is glad that he didn't use embedded stuff in his kpresenter demo,
> ready for the French Linux Expo :)

Coool!

> So : just announce the switch, commit the changes, and update the minimum mico version
> required in the configure.in[.in] scripts.

Did all that stuff, I hope I didn't forget anything. 

Ciao,
  Simon

--
Simon Hausmann       <hausmann@kde.org>
http://www.kde.org/  <tronical@gmx.net>

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