On 3/15/07, Alan DuBoff <Alan.DuBoff at sun.com> wrote: > > The e.V. even gave us a semi-official > > green light to break binary compatibility, if we come up with better > > code. If we have a good rationale for breaking BC, then it's ok to > > break it. As long as we don't do it every two weeks. :-) The only > > restriction is that it should also compile with a recent GCC. > > I will caution against deviating from what the mainline project is doing. You > need to lobby your rationale to us, the community!<wink> > > In general I don't want us to create more work for ourselves than is needed. > The DCOP/Corba change sounded like it could haunt us. I know that Corba works > better for us, and KDE was Corba at one point, but changed to DCOP, at least > that is my understanding. Isn't that true?
KDE used CORBA in the late '90s. Back then, the freebie CORBA implementations sucked. This is why KDE decided to re-write a CORBA-ish DCOP. The problem with DCOP is that it is very slow. Porting DCOP to CORBA is not very difficult, since the design of the IPC/RPC mechanism in KDE was originally written in CORBA anyway. Plus, DCOP does not support SSL, which omniORB does. > But do you see ANY? There's a difference between not being able to get the > changes upstream and being able to. If they can at least get them upstream, > one of the big hurdles is elliminated. I see quite a BIT of them, ever since i have been releasing and publishing patches and full source for the KDE Solaris ports, at KDE, ever since 2003. I did not pester the e.V. to accept all these patches into HEAD/trunk because, quite honestly, they were under no obligation to do so. KDE Solaris was not officially supported for KDE3. > I was more concerned if this would be something that keeps getting thrown at > us, like, everything we get a new rev it's full of code that won't compile on > Solaris. That might happen, especially for new code which gets written after previous patches are integrated upstream. In order to achieve the dream of having KDE simply download, ./configure, gmake and gmake install work out-of-the box, we need to do some work . I think most QT code is platform neutral, isn't that true? For QT 4.2.2 it compiles pretty much without patches. For the 3.3.x the situation changed over time, and 3.3.4/3.3.5/3.3.6/3.3.7 required a *lot* of patches. Trolltech no longer tests with Studio 9, 10 or 11. Only with Studio 8, and only on SPARC. > This sound like one of the more difficult pieces, these libraries. There was > some 1394 relates stuff that Alan Perry worked on, and David Bustos wrote a > glue layer for some stuff in getting a web cam to work. This could be used > for kino possibly, if we had the backend pieces. > > > 6. Drivers: for example there's no equivalent of video for > > linux --v4l-- on Solaris) and because of that one can't use webcams > > or watch tv, or edit video. > > This is a big part of modern software, we would need some type of solution. > That's the whole point of this project, we need a SunStudio compiled version > if we want the plugins to work and not crap out on us. At least this is my > understanding. When people tell me things like, "I run the blastwave KDE and > it works good, only craps out occasionally", I don't consider that to be > software I want to run. I don't like when my desktop disappears all of the > sudden. Yes, i agree 100%. I also think that a "Desktop" should allow one to download photos from my digital camera, organize them, watch movies, edit video, play radio or tv, listen to my iPod and sync my Palm Pilot/Cell Phone with my addressbook. All these things exist as open source today. They just need Solaris work. Often *a lot* of Solaris work. > There's a new DX coming out soon, but I wouldn't mind using DX as a base, that > way it would allow other developers to sync up and/or get involved more > easily. We need to get a standard development environment, and that means > getting things rolling on nevada, IMO. I'll upgrade to the new DX when it's out. > > I talked to the e.V. about the CORBA bindings a while ago, and the > > official reply was: if there is working code, it will be integrated > > upstream. That's one of the reasons the CORBA vs. DCOP study was > > done. KDE doesn't handle projects the way a corporation does. If one > > wants a certain module, or functionality, to be integrated into KDE > > mainline, one starts with code. If it's good, it will make it > > upstream. > > As long as we can push upstream we should be ok. Yes. Plus, the way i'm thinking of doing this, it's not intrusive. It will be a separate module, in a separate directory in kdelibs. Compiling with CORBA as opposed to compiling with DCOP will be a ./configure option (./configure --with-corba --<bla-bla-bla>). This makes the integration upstream much easier (the disturbance of the existing code is minimal). Passing --enable-corba to configure will prevent the building of DCOP. > I guess that would be John Rice and Co.? Or Glynn Foster's group. I'm not sure > who's working on the desktop. KDE is my desktop, and nobody is working on it > yet...:-/ I think it's Glynn Foster's group (based on the emails i saw). Is Mesa integrated in Nevada x86 ? We're going to have some fun figuring out how to decouple Mesa/OpenGL/QT from the Xorg open source drivers and the nVIDIA proprietary drivers ... --Stefan -- Stefan Teleman KDE e.V. stefan.teleman at gmail.com
