KDE And GNOME To Share Component Architectures?

DragonHawk writes: "Miguel of GNOME fame and Rikkus of KDE/KParts fame have been talking about collaborating to build a common object component architecture for use in both KDE and GNOME. This would let developers and users alike share components from both projects, which would just rock." There's a lot to this one, and largely it's technical stuff, but it is definitely interesting.

Comments

Good Thing(tm)

[Wizard of OS]

This is a Good Thing(tm). If you look at the open source projects around, you see that a whole lot of projects all overlap. You've got gnome, kde, and a bunch of other desktopmanagers. Ofcourse, it's a good thing that there is a lot of choice, but wouldn't it be smarter to put all those devellopers on 1 large project?
I think that this idea of creating a common model that both the projects can use is a very good idea. Look at Micros~1 COM (Component Object Model) for instance. You may not like this MS specific object model, but it works very well. You write a library once, and lots and lots of applications can use it instantly.
I think that cooperation of Open Source projects will be the most important thing in projectmanagement the next couple of years. Instead of living on a island, devellopers cooperate and create software that is completely interexchangable.

Good move guys!

Re:Good Thing(tm)

[biohazard99]

My understanding that CDE was the commercial unix worlds answer to this, my school's big boxes HP-UX, Solaris that I have acess to use CDE in between them, the sun box has openwin on it which is what I use due to the speed increses. FVWM95 is the default on the Debian boxes in the CS department and I really like it, but I was at console, not trying from the network (I still havent figured out SSH tunneling that well, any hints)

Re:Good Thing(tm)

[-brazil-]

Ofcourse, it's a good thing that there is a lot of choice, but wouldn't it be smarter to put all those devellopers on 1 large project?

No, and that's not what this is about. The point of the common model is that with it, KDE and Gnome applications can interoperate, i.e. you could use drag&drop between them. That's a Good Thing. The point is not to turn them into one big project. For example, the preferences of both will probably remain separate.

Re:Good Thing(tm)

[AndrewHowe]

I'm mostly with you.
Why not just use COM? Bonobo is ripped off from COM anyway. Well, it's because no-one around here likes Microsoft. But I don't care about that, I'm just interested in technical reasons. It would be great if there was interopability not just between apps in the same OS, but between OSen too. The current separatist nature of Open Source is fine for a radical movement, but it seems to me that users should get something that's useful to them, not be caught up in political struggle all the time.

Re:Good Thing(tm)

[Matthew Weigel]

Why not just use COM? Bonobo is ripped off from COM anyway.

No, it's not. COM is fake objects; CORBA is real objects. They refer to it as being 'like COM' to give people an idea of where it stands, but that doesn't mean it sucks eggs like COM.

Bonobo consists of both an object model, and a Gtk+-based implementation of that model, plus the object broker. It's not language- or system-dependant, and you shouldn't even have to care what language a class you inherit your class from is written in.

Re:Good Thing(tm)

[AndrewHowe]

What do you mean by 'fake'? I'm genuinely curious. Why does COM 'suck eggs'? Again, I'm not trying to start a flame war, I just don't share your opinion.
COM is not language- or system-dependant either.

Re:Good Thing(tm)

[mikeee]

>wouldn't it be smarter to put all those devellopers on 1 large project?

No!

It's widely known that software development doesn't scale with number of developers. It's also widely known that the success of software projects is highly variable. The obvious conclusion is that if you have enough developers, you're actually *better off* dividing them into multiple small groups in the hope that one will get lucky and nail the target, rather than one bloated one tripping over itself and getting one chance only.

It may be counterintuitive to plan on throwing most of the work away, but I think it actually makes sense!

Re:Good Thing(tm)

[dazraf]

Hmm, yes you can - in our company we've used DCOM for quite some time, tying our objects across a network. And its relatively easy. Without starting a flame war, I don't believe you have an understanding of COM at all - COM uses the notion of Proxy/Stub components to marshall an interface pointer across the process/machine boundary. For the network case, the DCOM definition (which is part of COM) handles the transport. This is quite suitable for most cases. In situations where the default implementation is not suitable, we've written our own proxy/stub components, which implement our own transport.

Re:Good Thing(tm)

[warmi]

Don't be so defensive.You are right.

Most people here have no understanding of MS technology and still feel competent to criticize it.

Re:Good Thing(tm)

[UnknownSoldier]

> Why does COM 'suck eggs'?

It's design is far from elegant. Reference Counting used to suck. I can't find the critique page, but this will do:

http://www.chappellassoc.com/art3.htm

Of course CORBA has its own problems too (DCOM is also critiqued to provide a fair comparision):

http://www.usenix.org/publ ications/java/usingjava13.html

Don't let the url titles confuse you, read the articles for a good explaination of the strengths and weaknesses.

Re:Good Thing(tm)

[AndrewHowe]

I read those articles (thanks for the linx btw).
The first one starts talking about COM, which has reference count issues (but they're actually extremely simple to maintain, especially with smart handles, see ATL). It then goes on to look at distributed object lifetimes, and in conclusion it seems to prefer DCOM's approach to CORBA's non-approach. Which is nice.
The second article was quite amusing. I haven't really got time to go through the good/bad/ugly points one by one, but a lot of them seem pretty uninformed, and not just on DCOM's side.
I wonder how many of the Sun lot are weeping "Hey, why don't Gnome and KDE just use our Java RMI?! Oh yeah, and Micro$oft should ditch COM as well"...
Why can't we all just get along? :)

Kde/Gnome Interface Common Interface

[panthanatos]

This one would solve an unnecessary rivalry and is basically the right track Linux projects should be taking ... I say Hallejulah if it happens!

screwed up naming conventions?

[grammar nazi]

What will things be kalled now?
e.g.Knapster or Gnapster

Doesn't anyone know that you kan't kombine two products that both add/change the first letter in their gnaming konvention?

Re:screwed up naming conventions?

[Ian Wolf]

With interoperabilty comes the hope that developers don't have to name their product to identify it with a particular desktop environment.

Re:screwed up naming conventions?

[The G]

What will things be kalled now? e.g.Knapster or Gnapster

That's easy. Split the difference -- halfway between 'g' and 'k' is 'i'. Ergo it would be the iNapster. Available in five fruity colorschemes.
--G

Re:screwed up naming conventions?

[donny]

> That's easy. Split the difference -- halfway between 'g' and 'k' is 'i'.

Both KDE and Gnome have made an art form out of silent use of their respective initial letters (K and G). In this spirit, I propose that the ideal solution would be to find another letter which is as versatile as K and G when dealing with not having to be pronounced.

I think that the letter P would be ideal in this context. We can call it pnapster.

Another choice could be the letter M, which would give us mnapster. But M sucks.

But hurry, because these valuable silent letters can be snapped up by some large free(beer) software movement for reasons which are most favourably described as "random", just like K and G were, way back in the early days of having the same initial letter for all of your software package names.

Don't be surprised if someday soon you find the "P Software System" with all sorts of weird utilities that begin with the letter p, like pcc, pedit, plibc, pnote and, of course, pnapster.

Donny

Re:screwed up naming conventions?

[zero_offset]

Both KDE and Gnome have made an art form out of silent use of their respective initial letters

An art form? Jesus, dude, you need to get out of the house more often. The crappy naming "conventions" of *nix software is very much a part of the reason Linux remains so unapproachable to the general public. I say "conventions" in quotes because, as is made apparent by this thread, the actual rules behind these conventions are not particularly useful for figuring out what the fsck any of this stuff actually does.

No matter how cute you kids may think all of this is, it still looks like pointless geek-talk to the rest of the world, and will continue to doom you to obscurity as an also-ran in the OS world. A small but critical piece of the puzzle...

Re:screwed up naming conventions?

[Semuta]

You are a stupid faggot.

The 'rest of the world' has extreme difficulty discerning the difference between 'Microsoft Outlook' and 'Microsoft Outlook Express'.

The 'rest of the world' does not have any idea that 'Microsoft Office' is a large collection of integrated programs.

The 'rest of the world' makes absolutely no distinction between 'Netscape', 'Netcenter', 'Yahoo', 'AOL', 'Hotmail', 'Dial Up Networking', 'Internet Explorer', 'Windows', or 'msn.com'.

This is why they are the 'general public' and I can tell exactly what a stupid crap piece of unix software does and whether i could use it or not simply by it's name.

Again, I reiterate... You are a stupid faggot. Stop posting, you inbred hayseed.

Re:screwed up naming conventions?

[King Babar]

What will things be kalled now? e.g.Knapster or Gnapster.

That's easy. Split the difference -- halfway between 'g' and 'k' is 'i'. Ergo it would be the iNapster. Available in five fruity colorschemes.

Actually, you could try to split the difference phonetically. /g/ is a voiced velar stop while /k/ is an unvoiced velar stop. Hmm...could be tough. On the other hand, in honor of the friction that exists between the partisans of the two projects, I'd vote for a velar fricative. And we might as well go voiceless, since that's already a German phoneme. And we could spell it as X as in TeX.

Xnapster: the sounds of a Xnew generation.

Re:screwed up naming conventions?

[donny]

> An art form?

Yeah, haven't you heard of that expression before? Well, in my experience, when you use sarcasm, one of two things happens. Either (1) the person gets it, or (2) they think, "Holy shit, this guy is on crack! What he's saying is full of shit! Wow, I'm going to tell him who's boss so other people will like me! La-la-la-la-la!"

Anyways, if you think Unix naming conventions prevent the general public from adopting it, I would suggest that you take a look in the Windows system directory. My point here is that, alright, to be a power user, you might have to know all sorts of funny shit, but to be a user? You can be oblivious to everything around you and still navigate confidently through both KDE and Windows. (The only difference is that when you do it in Windows, you stand a significant chance of shooting yourself in the foot).

Donny

Re:screwed up naming conventions?

[Kyobu]

They're not silent. At least the G isn't. It's pronounced g'napster, just like GNU is pronounced g'noo. For the same reason, too.

Reverse forking?! :)

[MikeFM]

I always figured KDE and Gnome would over time merge and then each become more like a differently oriented distribution of the same code tree. While this isn't quite that far yet it is a good proof as to why opensource is better than commercial. Here's forking for ya baby, in reverse.. you fork and we merge. :) These guys rock. I love KDE and Gnome both and in fact use both on a daily basis. :)

This is going to screw Debian, isn't it?

[streetlawyer]

But surely, if GNOME merges with KDE, then it also merges with all of KDE's licensing problems, and Debian won't be able to use it. That leaves the only 100% Stallman-pure Free Distribution without a GUI. For some reason, I think that would suck.

Re:This is going to screw Debian, isn't it?

[Andrew Cady]

What the hell are you talking about? They're not merging, they're just going to use the same componant architecture. Actually, KDE is taking the componant architecture from GNOME (and not the other way around), so there's absolutely no way there could be a licensing problem for GNOME. They're not talking about GNOME using QT, and QT is where the license problems exist. They're *certainly* not merging into one project.

Re:This is going to screw Debian, isn't it?

[Vanders]

I think it may be more than Debian not being able to use it. After all, if Gnome (GPL) code and KDE (QTL) code is merged, they have to merge the two, aparently incompatible, licenses. This is probably one of the more important considerations if the two teams decide to go ahead with this.

Of course if they do manage to merge GPL & QTL code sucesfully, i guess the Debian problem will be solved at the same time.

Re:This is going to screw Debian, isn't it?

[dkscully]

was the profanity /really/ necessary?

your point was valid, you just sound like a fool.

Re:This is going to screw Debian, isn't it?

[Peter Putzer]

Actually, nothing is decided yet. Note however that the article mentions both possibilities, i.e. KDE using Bonobo as is, or a successor to both, which proably would be better (both technology and "mindshare" wise).

Though I agree that a common object model would be A Good Thing (tm), it's questionable how this will be best achieved:

CORBA does indeed include a lot of unnecessary overhead for local applications, and general interoperability is currently hampered by Orbit's non-standard authentification mechanism...

Re:This is going to screw Debian, isn't it?

[Peter Putzer]

Bullshit.

QTL is the Qt Template Library, a set of cross-platform template classes used instead of the STL.

You propably mean the QPL, but that license only applies to Qt, not to KDE.

KDE is GPLed for the most part, except the libraries which are LGPL, and some applications that come under different (Artistic, ...) or multiple licenses.

Re:This is going to screw Debian, isn't it?

[Vanders]

QTL/QPL, yeah, i'm always confusing the two. I tend to stay away from the whole QPL/GPL wars for the reason that i tend not to care.

If what you say is the case, fine. I'm all for it.

BTW, swearing wasn't needed, it makes your post look like a flame, and you don't wanna start a flame war.

Re:This is going to screw Debian, isn't it?

[Peter Putzer]

Ah sorry, it wasn't intended as a flame.

(Neither is a post further down, where I again explain the difference, only in "formal" notation ;)

Re:This is going to screw Debian, isn't it?

[QE2]

The whole point of KParts/DCOP is that Corba generally and Bonobo specifically was too heavy for desktop apps. See post to LinuxToday from Mosfet on why this is a fake


-------------------------------------------------- --------

Re:This is going to screw Debian, isn't it?

[QE2]

..because you're an AC


-------------------------------------------------- --------

Re:This is going to screw Debian, isn't it?

[Habanero]

Here's an article you might want to check out.

It's about using Bonobo in KDE, or at least merging Bonobo and Kparts.

The plan is to either use Bonobo in KDE if it is sufficient, or for the developers of KParts and Bonobo to work together to create a new replacement

See? No mention of GNOME using Kparts. It would never happen because Kparts depends on QT. But, Bonobo is toolkit independent.

Re:This is going to screw Debian, isn't it?

[Schnedt McWapt]

It fun to watch the "only (our defintion of) Free Software" folks paint themselves into a corner.

I hear they're working on a free re-implementation of the Teletype ASR-33 so that when they've declared non-free hardware like VGA display adapters forbidden they can still run ed and groff.

Re:This is going to screw Debian, isn't it?

[MrJay]

It fun to watch the "only (our defintion of) Free Software" folks paint themselves into a corner.

It's boring and horrible torture reading posts from people who cannot read the story the discussion is referring to.

I quote:

"Miguel of GNOME fame and Rikkus of KDE/KParts fame have been talking about collaborating to build a common object component architecture for use in both KDE and GNOME."

They have been talking about building a common object component architecture. Nowhere does it say KDE and GNOME are merging.

And keep your ignorant Free Software comments to yourself.

Re:This is going to screw Debian, isn't it?

[dirtman]

Well, sorry but you have to read the things carefully before talking about them. KDE and GNOME won't merge. The merger is between KParts and Bonobo. So that a GNOME component can be easily used in conjuction with KDE applications e.g. Gnome panel applets docking perfectly in KPanel.

--
dirt

Mother nature is a bitch.

Re:This is going to screw Debian, isn't it?

[Kyobu]

Aside from the fact that Gnome isn't merging with KDE, XFree86 is allowed by Stallman. Did you really think that Debian doesn't use X? I don't even use Debian, but I always resent it when morons like you try to start flame wars. Even if Gnome and KDE ceased to exist, we would still have lots of window managers, like Enlightenment, Sawfish, WindowMaker, etc.

Just The Facts, Ma'am

[alexburke]

Okay, the article linked to in the main story doesn't say much, but does contain some links which, if followed, have some *very* decent information about a possible collaboration between the KDE and Gnome camps.

Here's to burying the hatchet:

• Bonobo: the GNOME architecture for creating reusable software components and compound documents
  
  
• KDE 2: An intro to the parts of KDE II like KParts and XMLGUI
  
  
• Supporters of the KParts/Bonobo merger

Most people I've spoken to are against Linux kernel/OS fragmentation, so what could be good about GUI fragmentation? I know KDE and Gnome are generally looked upon as mutually exclusive religions, but it *would* be nice to have the two work together.

Just my $0.02...

--

Congratulations

[relihanl]

Excellent news! This can only be good for everyone. Keep up the great work. A KDE User

would be nice, but ...

[gerddi]

As I read from comments on linuxtoday, this seems to be a fake :(, but anyway, sometimes someone has to put a rumor to start things ...

Speed Issues.

[Dienyddio]

IIRC KParts was started to avoid the overhead of a CORBA architecture (such as the one Bonobo uses). I know the speed issues of CORBA have been hashed out time and time again but does this mean there has been shift in the KDE attitude to this?

Also i seem to recall reading at one point that KParts was going be extensible to enable it to use CORBA objects if the lightwight KPart was not available. How much of a shift is this for KDE? it would seem that such compatability was always on the cards.

IMHO the interesting part for is the compatability that will come from having KParts accessable from Gnome which is something new.

Good work guys! here's to an truly open and portable component model.

Sahred components

[Vanders]

O.K, maybe i've missed a fundamental part of all of this, but whats to stop an application coder linking against both QT and GTK+ in order to use component's from both? Obviously the final code will be a little bloated (You're gonna have two GUI toolkits in one application), but can it be down right now?

Re:Sahred components

[Anonymous Coward]

Using a common components model, one will be able to cut&paste an object from a Gnome app inside a KDE app and vice versa, even if neither app is linked against the other desktop libs.

No problems whatsoever

[Ur@eus]

There is no discussion of merging the projects, just on getting the component architecture shared. Licensing is not an issue when does this way, look at the Mozilla embinding into Nautilus as an example of cross-license code interacting in a similar manner.

Common Platform whish list

[bockman]

from the hope-costs-nothing dept.

MIME types

User Personal Menus [at least]

Window Manager Hints

CORBA [if any, it should be common]

Drag'n'drop

Components model

Re:Common Platform whish list

[Vanders]

CORBA [if any, it should be common]

You know, i think that's what the C in CORBA is for. Common Object Request Broker Architecture. ;)

Re:Common Platform whish list

[Peter Putzer]

window manager hints are done (NETWM)

drag'n'drop is done (XDnd)

desktop files (MIME types and menus) are done (the ".desktop" standard)

Re:Common Platform whish list

[Trepidity]

I personally don't like Windows (mainly because of the lack of stability), but in some respects I'd have to admit it's a much more mature windowing system, since nearly all the things on your wishlist are "things Windows already has that we wish we had in GNOME and KDE."

Not fake, just different views

[Ur@eus]

It is not fake, it is just Mosfet and Rivyn seeing very differently on how to interpret these early talks.

Must be the coldest day in h$

[lifebouy]

This would mean:
0.Gnome and KDE apps that work together well.
1.Gnome and KDE ppl sharing resources.
2.Goodbye QPL and Qt!
3.Debian ppl will stop whining;)
4.Debian will finally include KDE.

All very Good Things(tm).
Off hand I can't see a downside, other than fixing a lot of code.
Never, ever thought I'd see the day when they were even talking about doing this. This is the happiest day since Baseball went on strike...

Re:Must be the coldest day in h$

[Andrew Cady]

How would it allow 2, 3, or 4?

Re:Must be the coldest day in h$

[Ur@eus]

0 and 1 is correct, the rest is wrong. A shared component model would not change KDE's use of Qt, or the political implications of that use.

Rivyn does not speak for KDE

[Andrew Cady]

Daniel M. Duley posted this message to linuxtoday.com:

Since none of the KDE core developers have been contacted, I am sorry to say I think Rivyn jumped the gun here. While Miguel may have talked to Rikkus - he's not a primary KParts developer. As a matter of fact, as far as I can tell no KParts developer or maintainer was spoken to at all. Thus this is misleading at best. Not that it wouldn't be good to interoperate, but no KDE core developer or KParts developer has been contacted so don't get too excited. A lot of KDE developers have serious issues with Bonobo such as overhead, and nothing has been discussed at all with them.

Sorry guys, assuming Mr. Duley isn't a fraud (and there's no reason to believe he is), this looks like vapor.

Re:Rivyn does not speak for KDE

[codemonkey_uk]

Vapor or not, the cat is out the bag, and we have the oppertunity to stand up and say - yes, this is a good thing, we want this to happen!

I've been saying this, or something like it should happen in KDE and GNOME stories for ages, and very little comes of it, it brings a smile to my face that the idea, from me or not, is now getting prime time coverage.

Thad

Re:Rivyn does not speak for KDE

[d_i_r_t_y]

even so, KDE and GNOME interoperability at levels deeper than a drag'n'drop standard is something that i'm sure most desktop linux users have been wishing for.

can a developer of either project tell me if the effort involved in ensuring gnome/kde interoperability at the component level is worth the efficiency gain of being able to leverage the existing components of both projects?

there is nothing worse than writing a chunk of code only to find that someone somewhere has already churned out exactly what you were already looking for..... ;-)

in any case, kudos to all kde/gnome developers.... you are doing an amazing job....

d_i_r_t_y

Re:Rivyn does not speak for KDE

[Skeezix]

No one has said that this is anything but some talks at this point. Of course there isn't code yet, or a formal project to develop a common component architecture between the two projects. It's just the hope that key developers from KDE and GNOME would swallow their pride and talk openly about what possibilities are open to them.
----

Just In Time

[nchip]

This some of the best news on the Linux era for a while. The only thing where Linux has been lacking when compared to redmond, is the component model. Having several component models around, would be disastrous and take away whole idea of components: Reuse.

Suppose we had a ftp-client component. Now you make a html editor and you want add remote file
editing capablilities. Currently, you would have
to re-invent the wheel, but if we had a ftp component, we just reuse it instead. Ofcourse,
ftplib exists (which actually qualifies as a component), so this isn't a good example. But having a good component model would make creating and using components easier.

Ofcourse, it requires some change in attitude. Currently re-invent the wheel seems to be the driving force (anyone counted the amount of irc/mail/news/icq -clients?).

Re:Just In Time

[spitzak]

Suppose we had a ftp-client component

Actually a rather poor example. I think that anything that can be presented as a file should have a file-like interface. So the editor can just open "/ftp/machine.bar.baz/subdir/file" and read/write it. Yes this will cause a large "component" to be linked in but it would be linked through the kernel.

The components are for where the interface is more object-specific, if I understand this correctly. You can send a message like "display your user interface in this x window id", which is meaningless for data files.

gome-kde mailinglist

[mbyte]

There was some discussion about this today on the gnome-kde mailinglist. They say its an serious effort, but in order to succeed it needs MUCH work, and that is unlikely to happen soon.

One of the main problems are the great architectural differences between kparts and bobobo.

If anyone interested, I am sure there is a archive of this mailinglist around somewhere on http://www.gnome.org/

--
Samba Information HQ

Re:gome-kde mailinglist

[GeZ117]

The adress is here: http://mail.gnome.org/pipermail/gno me-kde-list/.

It's like in that movie...

[decaf_dude]

"This looks like a beginning of a beautiful friendship..."
(picture Miguel and Rikkus walking off together from a misty dock)

Re:It's like in that movie...

[Gramie]

Or maybe a misty aerodrome.

Duley doesn't know everything

[Ur@eus]

Rivyn has talked with a lot of KDE and GNOME developers about this, with mostly postive reactions. Duley is an ardent GNOME hater so I think that is why he downplays this so much.

That said, the contact is at a very preliminary stage so it is correct to say that things are more at like the start of a new mid-east process than very close to a solution.

What Rivyn is trying to do though is gather user support behind those developers on both sides that have a positive attitude towards the issue, in order to keep things moving.

Re:Duley doesn't know everything

[Karma Sucks]

> Duley is an ardent GNOME hater

Maybe you should stop talking out of your ass.

KDE development does not happen on IRC. It happens on the mailing lists. There is nada on kde-devel or kde-core-devel. This is all just a publicity stunt and as far as I can see you are one of the perpetrators.

I fail to see what your motives are, however.

Clearing some confusion

[toledo]

I am no expert in component technology, but there seems to be some confusion here that I'll try to clear up.

• This issue has very little to do with toolkits. Each part would continue to code with their own, but the component framework would allow to embed code from each into another (well, bonobo does, and the final solution should have this characteristic)
  
• License issues do not apply, as far as I know, since code from different components is not linked together. Rather, they are executed independtly and they communicate with each other. Nothing has changed with respect to the Debian/KDE problem.
  

In short, the best example (which is in the article), is being able to use the konqueror html display engine in nautilus -or any other gnome app for that matter- such is the beauty of components programming.

Re:Clearing some confusion

[Vanders]

License issues do not apply, as far as I know

See, i'm still not too sure about this. The component architecture that is finally settled on is going to be realised under a licsense of some sort. You can bet your bottom dollar that the Gnome team will want to use GPL.

How will the GPL component code fit into the KDE code? Will there be any parts of KDE where the QTL and the GPL will overlap and/or conflict? Maybe this isn't an issue, and i've missed the point entirly (Has been known to happen once you know ;)

Re:Clearing some confusion

[Peter Putzer]

PLEASE stop using wrong acronyms.

QTL != QPL && !KDE.coveredBy (QPL)

Re:Clearing some confusion

[toledo]

Yes, the GPL would most probably be the license of the merged architecture, if we ever get to that point.
And there won't be any problem, since because it will be toolkit agnostic, it won't need to link to neither gtk nor qt

This is the best thing

[Matthew Smith]

to happen to the OSS community since the conception of the Linux kernel. Why? Because it will allow reusability of components on an unprecedented level in the world of *nix.
If MS can be given any credit for innovating it should go to their component architecture. Yes, I realise they didn't invent components but they were the first ones to push them on a system wide scale. This allowed them to reach new levels of software reusability. Well designed components are like plugins, if the interfaces are well thought out the benefits are far greater than the costs.

I'm not sure how much change will be required in both projects to support the new component architecture and how well the teams can cooperate to design this new component model. The main risk here being a slowdown in progress due to the design by commmittee effect kicking in. But all going well we just may have a grand unified component architecture for *nix, thanks to GNOME and KDE... Off to celebrate, bye!

unix

[Cuthalion]

The elegance and power of the unix command line is due the fact that a whole bunch of tools all communicate with each other in a fairly standard way - the interchange of flat text through standard in/out. This is what gives me the ability that lets me find out how many different IPs visited my web server in August without (somebody) writing a utility specificially for that purpose.

With GUI stuff, flat text is no longer what programmes are taking in or putting out. Composing capabilities of multiple X programmes is difficult. The answer to this, IMO is a broadly used and supported componentisation. If the two most popular environments COULD agree on a sufficiently rich component object model, we might start to finally see GUI programmes not merely co-existing, but actually using and communicating with each other, giving REAL flexability and power.

I think that would be kind of cool.

Re:unix

[zero_offset]

How did this get moderated as "insightful"?

Whether an app has a GUI or not is absolutely irrelevant to whether it can use stdin/stdout. Fawning over the "elegance and power of the unix command line" is particularly nauseating. Actually, I suspect this is how he ended up with "insightful". A little public-stroking seems to go a long way around here. "Gee all you unix guys sure are smart."

How's that for insightful?

Re:unix

[bogado]

I wish I had some moderation points to moderate this up. I usualy do not moderate up comments with score bigger then 1, but I belive that Cuthalion have touched a very important point here. A common component object model is very important. I aways hoped that since both component arquitectures (KDE and Gnome) were boh using corba they would be somewhat compatible (maybe with a compatibility object to make communication between them). But this is even greater.

Maybe there should be a separeted project to create this monster, maybe a GNUCOM, witch would have the joined teams of both projects (KPARTS and BONOBO). I am sujesting this so that, if some other Desktop enviroment could start using it, since it would be compleately independent from any other Desktop Enviroment (enlightment comes to mind).
--
"take the red pill and you stay in wonderland and I'll show you how deep the rabitt hole goes"

Re:unix

[Cuthalion]

Whether an app has a GUI or not is absolutely irrelevant to whether it can use stdin/stdout

This is only aspect of your post which I don't consider a flame, so it's all I'm going to respond to.

An app that does not have a GUI communicates with the user and/or other apps via standard input and output. A GUI app as a general rule does not. I THINK what you are saying is that there's no reason that all GUI apps can't have TTY modes of operation to supplement their usual GUI mode, but that's only reasonable if the information they are outputting is readily trasformable into unstructured ASCII text.

Dimensionality is the key. streams/pipes are flat data, linear in nature, as are TTYs, and the unix CLI approach of composing utilities. "cat | grep | sort | uniq | wc" - it's linear, they communicated with an unstructured stream of ASCII text, parsed and formatted for each |.

This linearity is not absolutely inherently tied to the CLI, it just suddenly gets hard to represent more sophisticated relationships componentisation may allow. A good component architecture is also necessary for passing large quantities of structured data - where parsing ASCII would become a lot of work. Examples of where this is useful abound in the GUI world - widgets, movie player codecs, image readers, browser windows, et cetera. COM allowed Windows to easily make the File->Open dialog just another explorer window, and god is that handy...

Sure, all these apps could output XML or something to stdout, and parse XML on stdin, but ... is that really a better mechanism for passing structured information around that some other more advanced object model?

MIME types are not done

[Ur@eus]

Hi, Mime types are not done, they are not part of the .desktop standard. KDE however uses .desktop files also for Mime types. Check out the GNOME-KDE list at gnome.org for mine and others mailings on the issue.

I'm having goosebumps

[Muphry]

Perfect development: now both mngrs can profit from Eazel for example!

Why not include COM as well?

[Alien Conspiracy]

So, why not create a three-way bridge which includes the WINE COM subsystem as well?

Just think of all the thousands of COM components out there which would then be available to both GNOME and KDE environments too.

For instance, kfm would then be able to display MS Office documents if you had Office installed using WINE etc...

Re:Why not include COM as well?

[doctorwes]

Why not a four-way bridge, throwing in Mozilla's XPCOM? It's already very similar to COM, isn't it?

This reminds me...

[DevTopics]

of StarOffice - once upon a time someone spread the rumour that there will be StarOffice for Linux - and everybody kept on asking: "When will StarOffice for Linux ship?". Actually, there was no plan to port it to Linux. But so many people asked for it that the rumour became a selff-fullfilling prophesy (sort of). So, maybe, we should keep on asking the KDE and the GNOME teams: "When will you finish the merge of your components?". Even if they don't plan to do so for now, keep on asking, and in a short while they will do it. It will "scratch an itch". It will make the people doing it famous. And after they started it, everybody should write to the developers and tell them how much this was appreciated... Maybe that is just a dream, but I think that it would work. To cite Fogel (Open Source Development with CVS): "The sheer pleasure of working in partnership with a group of commited developers is a strong motivation in itself". Yep. And if done right, the component model won't touch the QT libs, so there is no need to worry about licenses.

Re:This reminds me...

[zigzag]

Hey! When will you KDE and GNOME guys finish the merge of your components? Soon I hope.

Too bad

[Frodo]

Too bad if this move, which would be a huge leap ahead for Unix as a modern desktop and application platform, will be drown in ego wars.
I do not believe it's not possible to sit for a week and make common object architecture. It needs not to be fastest, smallest, leanest one in the world. It just needs to work and be common, so that I could call Konqueror from gnumeric and vice versa. Microsoft has COM, and with all it problems, people use it, and do it a lot. Common component sharing arcitecture is a very important thing. That's like common binary file format - imagine two distributions have different binary file formats - at the end nobody is going to use any of them for serious work.

GNODE? KDOME?

[vik]

Whatever they call it, it sounds like a damn fine idea. I must admit that don't use GNOME (much) or KDE (at all), but a package that takes the best from both worlds has to be A Good Thing (TM), and is the Open Source way.

Vik :v)

COM is not as open as CORBA

[zhaoway]

Dunno the details tho. ;)

Orbit's authentication mechanism (your are wrong)

[Ur@eus]

This issue has been hashed out and solved on the KDE-GNOME list. This mail is from ORBit author Elliot Lee http://mail.gnome.org/pipermail/gnome-kde-list/199 9-October/000265.html And this one from aRTS author Stefan Westerfeld: http://mail.gnome.org/pipermail/gnome-kde-list/199 9-October/000265.htm

CORBA ORBs and standards

[Jon Erikson]

Nice idea, great standard and all that, but does anyone know of a decent ORB that handles all of the 13 CORBA services well? The main ORB I've used is Orbix, and that only supports 4 out of the 13 standards as of version 2.3, which quite frankly sucks and makes using it a real pain in the arse (along with a lovely bug where two servers end up with the same ID, causing them to crash).

As for performace, sure you take a hit, but I'd say that the benefits using a unified model for local and remote connectivity outweighs the penalties - after all having different standards in different parts of the system introduces bloat elsewhere anyway. And writing code for such a model is a lot easier...

---
Jon E. Erikson

Re:CORBA ORBs and standards

[Tim]

TAO is am extremely well-written, standards-compliant, open-source ORB that supports the entire 2.2 spec, and most of the 2.3 spec. I've been using this thing at work for the last 6 months or so, and I've been quite impressed. While it's not perfect, it has fewer gotchas than the commercial ORBs I've used. Did I mention that it's cross-platform, as well?

Here's the URL:

http://www.cs.wustl.edu/~schmidt/TAO.html

Re:Orbit's authentication mechanism (your are wron

[Peter Putzer]

Thanks for the info.

One nitpick, though: why not use ?

Good news

[Frodo]

That's the best news about KDE/GNOME that I've heard for a long time. Common object sharing protocol would be a real hit. Even more, that's a must for any serious work done in this direction by external (commercial) developers.

unforkingbelievable!

[sandgroper]

Congratulations to all involved.

Re:Orbit's authentication mechanism (your are wron

[Peter Putzer]

Uh, I just noticed:

You propably meant this Mail by Stefan Westerfeld, didn't you?

NO.

[zhaoway]

Too early to say frankly. :) But it also gives out a chance to blow off Qt/QPL from the whole thing w/o losing too much in a sudden. IMHO. ;) Just too early to say..

Please do it!

[pixelbeat]

This is of the utmost importance for the acceptance of Linux. There is far too much fragmentation in user space. It's just silly.

I looked around last week for a widely accepted C++ framework for use on Linux. It's ridiculous, about 20 different (equally attractive) options.

Choice is of course good. But the first thing people should do before writing some code is:
a. Has it been done already.
b. Has anything like it been done that I can tweak

This is the only advantage Windoze now has over Linux. It's easy to get MFC/VB/ATL developers as that's really the only options in the windoze space.

In summary people need to stop going off writing stuff for their own glory, and think of the general benefit/detriment to the Linux community as a whole.

Re:Please do it!

[bockman]

I completely agree with you. However, I must also point out that there are benefits of re-inventing the wheel once in a while:

It's educative for the developers which want to learn about a new field;

It's more fun that studying other people code;[ and many still do open-source coding for fun], especially if said code has little or no ducumentation.

On the long run, it generates fresh ideas that might prove useful ( think of the Berlin project ).

Moreover, some time two different groups of developers are different in too many ways to work toghether.

Re:Please do it!

[YoJ]

People don't write code for free operating systems "for the good of the community". They do it because it's what they want to do. That is the truly great thing about the open source community; everyone does exactly what they want to do. Who am I to say that Joe Blow shouldn't write yet another window manager if that's what he wants to do? If people wanted to be told what to code, they would get a job programming and get paid for it.

Linuxtag in Stuttgart - 9 days

[kris]

In 9 days there is the Linuxtag meeting in
Stuttgart, Germany. A lot of key KDE people
will be there as well as quite some Gnomes.
Unfortunately Miguel will not attend (his
leture will be held by someone else according
to the Linuxtag schedule), but perhaps we
will see a BOG session addressing that topic.

I for my part would very much like to see such
a merger. This is a really exciting idea, if
it can be made to work technically and politically.
© Copyright 2000 Kristian Köhntopp

No, but here is the correct URL

[Ur@eus]

Thanks for catching that one :)
http://mail.gnome.org/pipermail/gnome-kde-list/199 9-October/000265.html

THIS IS WHAT OPEN SOURCE CAN DO

[Andrew_Julian]

Real people, not hidden behind a veil of corporate competition, but by the desire to create superior technological solutions for their own use. This is the beauty of Open Source.

I can't ever imagine Micro$oft and Macintosh getting together to create a solution that facilitates the greater interopability of their two operating systems (I know this example is lacking in technical merrit as they are both completely different architectures and KDE + GNOME are not operating systems, but you know what I mean ;-)

Re:THIS IS WHAT OPEN SOURCE CAN DO

[Carnage4Life]

Posts like this make me wonder about certain OSS supporters sometimes. Now I'd like to know how on one hand you can bash MSFT in your post yet praise KDE & GNOME for ripping of an idea that MSFT pioneered almost a decade ago with DDE/OLE/COM. The GNOME folk have admitted this and it is clear this is the exact same thing KDE is trying to do.
Also your analogy lacks merit, let's try this one. Wouldn't it be cool if some people created a cool technological solution that allowed various seperate apps to talk to each other (e.g. spreadsheet, wordprocessor) seamlessly as well as expanded the infrastructure to include third party software and then created a distributed version of this? Guess what, MSFT did.
I hope that puts things in perspective. I'm not an MSFT supporter (even though quite a few of my friends work there) but when people ignore their achievements then praise people for ripping off those same achievements it makes me wonder. After all we were all up in arms when they claimed they invented symbollic links

PS: This is not a troll if you disagree with me post a response.

Re:THIS IS WHAT OPEN SOURCE CAN DO

[Bongo]

Now I'd like to know how on one hand you can bash MSFT in your post yet praise KDE & GNOME for ripping of an idea that MSFT pioneered almost a decade ago with DDE/OLE/COM.

"Ripping off" implies there was a very specific and novel invention. But the notion of component software is just a broad, general evolution in software engineering. Modula-2 (Wirth, 1982) incorporated information hiding and a module concept. They built a component OS, Project Oberon, with it, which later became the BlackBox framework... which is just one of many such projects.

As for praising KDE&GNOME, well, maybe some people just expect them to do it better. :-)

Unix Component Model

[QE2]

Any development of a component model for Unix should be project/desktop/Window manager agnostic and independent.

COM, CORBA and EJBs are not soley pitched at GUI apps, so it's a bit irresponsible to design a component model which will only function with two graphical environments.

Also, what shouldn't be happening is that KDE just adopts BONOBO wholesale - simply because the KDE team have already dropped CORBA from KParts. Both projects (and other interested parties) should work towards a scaleable, lightweight manageable and truly independent framework.

Having said that, this is a step in the right direction.


-------------------------------------------------- --------

This is unlikely

[Drashcan]

Sorry guys,

1. the difference in licence between KDE and Gnome
2. the state of the "market" (I am convinced that the freer Gnome would get an overall boost over the less free KDE if the plan/rumour would become reality)

make me doubt the good intentions. Although I am slightly in favour of KDE because of practical reasons, I would love it if the freer Gnome took the lead.

John C. Drashcan

Re:This is unlikely

[Ur@eus]

Licensing is not really an issue here, none of the shared technologies in question would need to link to Qt.
As for who would benefit the most, I think it is academic, the real winner would be the users and linux in general. If this thing works out choosing desktop environment would be very much like choosing a window-manger.

How do you think Bonobo fails on those criteria

[Ur@eus]

Bonobo AFAIK satisfy all those criteria. So while I can see that there can be improvements due to input from the KDE developers, I have trouble seeing the need for something new.

Gnome Versus KDE Apps.

[Anonymous Coward]

Something interesting: The ratio of Gnome to KDE apps on freshmeat has been steadily improving from 40% (Gnome/KDE) about a year and a half ago to about 96%. This shows that the Gnome camp has caught up in the race but it is also an indication that code has been borrowed by both groups from each other as this percentage has now been stable for about 3 months. Currently there are about 350 apps for both groups listed on freshmeat. Since there will never be a clear winner or dominant player in the GUI market the question remains: when will they start to make things easier for themselves by taking this next discussed step?

Famous?

[MultimanZ]

Miguel and Rikkus aren't famous. Go ask 100 people in the mall if you they know who Miguel or Rikkus is. No one gives a care who they unless they are the Backstreet Boys or Santana.

Gaelen

The best solution

[pxpt]

Interoperability is a good thing.

However, this does not mean that Gnome and KDE should merge into one codebase. In fact the interoperabiliy is the best solution all round. The Gnome and KDE factions could still argue who's is best but it wouldn't really matter.

This interoperability is what Linux needs if it is to make any headway in the desktop stakes.

Please excuse my shouting :-)

Re:Just repeating what's in the article, karma who

[alexburke]

Actually, no. I put in some of my own thoughts, unlike traditional karma whores. And the article I posted saves people a few clicks.

--

Still too many COM-like component architecture?

[renoX]

KParts and Bonobo merge: Great!

But am I mistaking or Mozilla has its own component architecture?

And in linuxtoday Frederik C. talks about another component architecture tailored for high performances:
> Check out this link for an explanation form the
> developer of aRts/MCOP:
>
> http://space.twc.de/~stefan/kde/arts-mcop-doc/why- not-dcop.html

Would it be possible to have only ONE component architecture ?

I Have Another Idea About A Thing Called A Wheel

[quakeaddict]

You see its round.
It makes things go faster.
Its the coolest thing since sliced bread!
What?
Someone already invented the wheel?
But my wheel is better!!
Yeah I know I know its just a wheel.
Can you say OLE? Can you say COM?

Components != GUI

[StrawberryFrog]

This has been said before many times, but not loudly and on its own in this thread, so here goes.

The ability for objects in different binaries to interact is not and should not be the responsibility of a GUI Yes, this ability is used by a modern GUI to glue together visual components, but it should a general mechanism that can be put to other uses.

Neither COM or Corba require a GUI.

So unless the core services of KParts and Bonobo can run on a command line (does Corba = "core services of Bonobo"?), both are badly designed. If they can run on thier own without thier favorite GUI, they can be used as a general mechanism for object interaction.

Re:Components != GUI

[Matthew Smith]

But when you get int the actuall phisycal component embedding you have to scratch your head how to represent such phisycal entities as the dimensions of a component in a gui independent manner. In other words you could launch a server to say display a gif image but that server will not be able to embed itself within the frame of the parent application which may be problematic when you design a componentised browser for example.

Re:Components != GUI

[StrawberryFrog]

> actuall phisycal component embedding

Having worked with COM and ActiveX, I know quite well that a server's ability to embed a control depends on what interfaces that control implements and what the server expects.

Or to put it much more generically, yes, a particular component may only work in one GUI framework as it will offer a particular set of services to it's container, and expect a particular set of services from that container.

The expectations will be defined by the GUI standards (e.g in order to be an ActiveX control, your class must implement the following interfaces...).
Different Guis may differ here. (however, if they do overlap, they both win)

There is however, no reason why the mechanism whereby container locates and negotiates with containee must be either part of the GUI or different between GUIs - this is generic inter-binary-object communications. Standardisation at this layer is a seperate win, as this protocol can be put to many good non-visual uses.

To put it in MS-speak, COM is a method for defining interfaces. It is not visual. OLE and ActiveX are sets of interfaces for defining visual interaction over COM's object services.

Re:Components != GUI

[Matthew Smith]

OLE and ActiveX are sets of interfaces for defining visual interaction over COM's object

Are they fully independent of the other WIN32 API then? What I'm trying to get at is how they managed to define the interaction in terms of interfaces without refering to things like screen coordinates etc. If they still do refer to GUI related things then the interfaces are not really generic because using pixels would break under things like berlin which use real life scaling for everything. I'm not arguing with your point, just being curious how MS solved this.

Re:Components != GUI

[logistix]

COM is independant, I believe you can even have binaries running on Solaris getting called from a Windows machine via the network.

I believe ActiveX and OLE require Win32API though.

The biggest thing is establishing a generic standard for components though. You can't just compile an OO Dynamic Link Library and expect it to work properly(for various reasons: OO name mangling, virtual functions, ect), especially if you need to release new versions of it that work with older stuff.

So you can either compile the OO code into every program that uses it, or create a generic standard so you can use OO DLL's. Once this generic standard is established, you can make platform specific librarys/toolkits for the GUI that can be resued.

These won't be API independant, but at this level you could implement a toolkit/Library that would utilize the KDE or Gnome APIs as needed without the end-user or app programmer having to write their own custom code.

You could (possibly) do something like this now, it'd just be a library of straight C calls though and would get really ugly.

Re:Components != GUI

[StrawberryFrog]

> Are they fully independent of the other WIN32 API then?

No. Consider this activeX interface function:

IOleWindow::GetWindow
HRESULT GetWindow(HWND * phwnd //Pointer to where to return window handle
);

It is useless unless you know what to do with a win32 window handle

> If they still do refer to GUI related things then the interfaces are not really generic

If you tried, and got buy in, you could define a set of interfaces that are generic enough to model all the GUIs that you are trying to cover. Sounds painful though.

> I'm not arguing with your point, just being curious how MS solved this.

How does MS usually solve interoperability problems: Problem, what problem?

Re:Components != GUI

[Matthew Smith]

I believe ActiveX and OLE require Win32API though.

In which case we're back to square one. We could have an interoperable component model without the embedding ability but we can use CORBA for that anyway. But to have embedding we need to introduce GUI toolkit dependency or take a (pottentially) big performance hit. Seems like a chicken and egg situation to me.

Re:Components != GUI

[spitzak]

I think he means that the interface should not require a GUI. Ie. if the basic component architecture requires an xid or QtWidget* as one of the arguments, it is wrong.

This is an area where COM fails pretty badly. Win32 window id's are needed a lot for interfaces that don't need to draw anything to be useful. This is not a COM problem, but an object implementation problem (I personally don't see the problem with an architecture-specific solution like COM, it seems that it can be translated to a different architecture, while CORBA has to be translated for *EVERY* architecture).

Re:Components != GUI

[Ilmari]

One ETLA: RTFA :)

The article clearly states that "Bonobo is toolkit-independant." And, quoting from The Bonobo page at HelixCode:

Bonobo is a set of CORBA interfaces that define the interactions required for writing components and compound documents. These CORBA interfaces are not bound to GNOME, the X11 windowing system, or the UNIX system.

Also, from the article: "KPartsis dependant upon the QT toolkit."

So, by your definition (with which I agreee), KParts is badly designed.

© 2000 Ilmari. All ritghts reserved, all wrongs reversed

And you owe it all to trolls!

[streetlawyer]

It's true! Read the attached article and you'll see that credit is given where it's due -- without the constant pressure of trolls attacking both KDE and Gnome, this project would never have come about. Recognition should be given to this crucial part of the Open Source Model -- after all, if the aim is to "scratch your own itch", then fleas are an important part of the process. Or as the immortal blind bard put it

"The also serve who only stand and whine"

Killer reply to "Linux fork" argument

[Paul Johnson]

If this can happen then it will become the killer response to the "Linux will fork just like Unix did" argument.

At present KDE and Gnome are the classic fork nightmare situation: two incompatible worlds which cannot interoperate. If the developers can bring good interoperation then the rift will be healed. This will demonstrate that the forces for convergence in free software outweigh the forces for divergence, unlike in commercial software, and hence present yet another good reason for using free software.

In addition, both Gnome and KDE components exhibit network value effects. By Metcalfe's Law, dividing a network in two halves its value. So (assuming that Gnome and KDE have roughly equal value), allowing them to interoperate will double the combined value.

Paul.

Re:Killer reply to "Linux fork" argument

[Paul Johnson]

Yes, Metcalfe's law is that the value is the square of N. But we haven't reduced N, just the links. Instead of one network of N links we now have two networks of N/2 links. Each of the two networks is worth 1/4 of the original, making a total value 1/2 of the original.

Paul.

Overlap creates more choices

[Dungeon Dweller]

If the standards are the same, you have more choices. That's the whole argument that backs open standards. While this is an entirely different topic, one could extrapolate this to consider Microsoft's situation where they are purposfully closing off specs, except that what they close off is basic machine operability, whereas this is along the lines of aligning all of the objects in the individual programs (WOW! Now that's open).

Yay! We rule!

[spiralx]

Hee hee, now we can claim to be "trolling for Linux" and take the moral high ground when people start moaning at us... Finally, someobdy actually listens and learns from a troll :)

I hope it is done right

[jjr]

If this is done right that would mean if some crazy fool out there
created a third desktop option for *nix it should be able to pick this
one up and use it. As long as the interface is clean we should have no problem.

http://theotherside.com/dvd/

Merging problems:

[GeZ117]

Merging Bonobo and KParts seems difficult: KDE use a shared library approach, whereas GNOME embed process. Bridges seems more creadible than merge.

Another solution could be to clone the QDataStream class (just this one) to have a non-Qt DCOP/KOM/KParts thing. With this "agnostic" class, the KDE way would no longer be dependant of Qt, this would allow to use CORBA where needed and the lightweightier KDE solution elsewhere, both in GNOME and KDE.

Troll Time

[logistix]

RMS specifically ordered that the wheel should not be allowed in Linux.

See man su for details.

Re:Great, but something is bothering me...

[arnald]

I've read all the posts, and something ELSE is bothering me.

Why the fuck do people keep writing "(tm)" after the words "good thing"? It isn't FUNNY, I can't particularly see any POINT to it, it doesn't MEAN anything, and I was under the impression that trademarking etc. was unpopular in certain quarters of the `Slashdot' fraternity.

So... why do it?

Why do it?

Re:CCOM/DCOM/COM+/... is a square wheel.

[AndrewHowe]

Let's take that in parts...

> COM is a mess
Please expand on that. That's not such a convincing argument as it stands...

> it's tightly tied with C++
No, it's explicitly not, you can use it from C, Visual Basic, Python, Perl, whatever.

> architecture
What sort of architecture?

> Windows
Solaris? XPCOM? Wine?

Do you actually know what you're talking about?

Re:Miguel Speaking Trash of KDE on IRC the other n

[arnald]

This is probably just a troll, but I must take issue with the statement "lazy programmers use C++". If you mean "programmers who don't want to have to re-code the same hacky stuff every time they want to use a vaguely interesting data structure", then sure, I'm lazy!

Using C++ for a GUI/desktop project like KDE is natural, as such a project is naturally object-orientated (note spelling!).

In my opinion this is a major advantage of QT over GTK+. The latter is superbly done, but can't get away from the `long-name-syndrome' that besets most attempts to do object-orientated stuff in plain C.

[I should point out, I use Gnome myself. But I'm not blind to its faults].

Your statement about the complexity of the code is total nonsense; it's a well-researched fact that C++ code (for large projects like KDE) is generally easier to maintain and quicker to debug than equivalent C code.

(As I said, it's probably just a troll. But these things are important.)

Good idea. Why didn't I think of that

[nachoman]

Here is a comment I posted in the last KDE article. There are a few interesting comments on the same topic.

http://slashdot.org/co mments.pl?sid=00/06/15/1241213&cid=104

Re:Great, but something is bothering me...

[phutureboy]

Click here for the answer to your question.

(I actually would not have known this if I hadn't seen it on memepool yesterday.)

Focusing of efforts is a great strength!

[Midnight Thunder]

Anything to unify the development of the two desktop environments is a great thing. This way developers can concentrate on making software that runs on everyones desktop of choice, be it KDE or Gnome. One element that attracts me to Bonobo is that it does not rely on an API which is not 100% in the open & free software domain.

One small step for a group of developers, one great leap for all developers.

That remark is as stupid as the discussion itself

[Otis_INF]

COM is standarized via The Open Group, plus MS has flooded their developerwebsites with info about COM, how it works, why you have to do this and that, plus every book on COM contains the basic knowledge how it works internally. Get Don Box' millionseller 'Essential COM'. He included a complete system describing how COM works, using C++ code and not a single line of win32 specific functionality.

It's very funny seeing the die-hard anti-MS people twisting and turning to avoid having to say 'Implement it as COM!'. COM not a bad protocol, people, in fact it's quite clever. And besides that: there are a LOT of com objects around the world, and a LOT of COM developers around the world.

For Free, Mike!

--

kde abandonning kparts and gnome keeping bonobo?

[raphinou]

I am a real supporter of this idea. Just one question though: why has kde to change its model and not gnome? It seems kpart is toolkit dependent, but is bonobo such a big leap forward that it's worth fogetting kparts? I just hope gnome will help the kde guys actively in that!

CORBA predates DCOM, doesn't it? (n/t)

[MenTaLguY]

...

Re:CORBA predates DCOM, doesn't it? (n/t)

[Stu Charlton]

Yes, by a few years.

CORBA didn't have "object linking and embedding", however. They had to leverage OpenDoc for that... which unfortunately died.

ToolTalk

[karzan]

For all of you saying this is a "first" for "Unix", I'd like to remind you that the standard object interoperability model, ToolTalk, is part of the standard desktop, CDE, and is standard on all real UNIX systems. ToolTalk has an excellent model and I recommend you check it out, it is far more useful than this open source stuff.

(and no, this is not a troll, it's genuinely good technology)

Re:Great, but something is bothering me...

[JAPH Doggy]

> it doesn't MEAN anything

Actually, it does.

The term "Good Thing(tm)" implies a social and moral good (something that is good for society as a whole (or a subset thereof)) rather than something that is simply good for the person making the statement.

As an example... if the city fixes the pothole in front of my driveway, that's a good thing. But... if they fix the pothole in the middle of the busy intersection down the street, then that's a Good Thing(tm).

At least that's how I have always interpreted (and used) this term.

So... if KDE and Gnome decide to use a common component architecture (enabling their respective applications to interoperate more effectively) then that is good for the entire Linux (ney, Free Software) comunity and is indeed a Good Thing(tm).

--

--

Server Component Architecture

[Dacta]

Firstly, I hope this (merger between BONOBO & KParts) takes place. Even if this annoucement was somewhat premature, I hope it becomes a self fufilling prophecy.

That's not really what I wanted to discuss, though. Please excuse me if this is a little off-topic.

What component archictectures are sutible for use in server side (ie, website) development on Linux/Unix? Is the only option Enterprise Java Beans?

I'm not saying there is anything wrong with EJBs, but I think there is room for a proper language independant component architecture suitable for server development on Unix. As far as I know, there is nothign directly comparable to COM+ (or COM/MTS) on Windows, apart from EJB. I don't think either BONOBO or KParts fills this gap, either.

I suppose CORBA support is a good start, but there is more to a component architecture than a remote object calling standard. COM+ supplies database connection pooling, object pooling and some failover features, all of which need to be added by developers or non-standard vendor tools to any CORBA based solution.

I'm not too optimistic about this changing, though. Or am I wrong, and there are projects already underway?

Re:Too bad indeed

[ElvenKnight]

I totally agree. Remember the strategy of war... Divide and Conquer.

Its sad though if Microsoft (like we have anyone else to worry about??) doesn't even have to do the dividing.. we end up doing it ourselves.

It was nice to see KDE and GNOME in their race for GUI supremacy... it might have even helped speed things along on both of their accounts. But how long can linux wait for its URGENT NEED for a user-friendly interface and GUI developers heaven?
We need to get things together NOW. And if alot of these duplicate open source projects out there could simply put aside their egos, congratulate each other on a job well done on each of their seperate projects, and simply realize that 2 heads are better then one.. then they can focus their efforts together in a mutually beneficial merger of their projects... we'd see ALOT more development get done.

Can we all agree we want one thing? We want to live in an age where "software doesn't suck". It'll happen, we know it will. But would you rather see that age come now or when your 65 and can't type as fast as you use to?

Ok, put it this way... Motorway traffic problems are VERY frustrating to the typical commuter that has to drive to work every day. Its annoying to see all the stupid things that happen on the road simply trying to get from point A to point B. And also, People who compute for a living, or for pleasure, or both... are we not also frustrated by the stupid things today in computers? Having to use software we HATE, watching our computers reboot daily when in reality, mankind could do better...

Linux NEEDS to be userfriendly, and developer friendly. We wonder why Linux doesn't have the apps or games to bring it to the masses, its because the very SUPPORTERS of Linux aren't awake enough to see what they really have to do to SUPPORT IT. You need to work together. Compete with each other later, especially if your young, you have time. But for now, can't we just work together to make our share of the pie larger, for each other? Why so little work on the Linux Standards? Why so many damn browsers? Can't we just agree Mozilla is the best thing we have going, and rather then starting up your own little browser project.. you really should help push something that is almost at the finish line rather then starting from the beginning on your own?

Ok, I've ranted enough. I hope I moved some developers in the right direction.. would be sad to see the Linux community to continue to be the reason for its own stagnation in gaining mass acceptance.. which is what we really need.

-Matthew Cortes
Technetos, Inc.

Re: More useless statistics

[nd]

From the Sourceforge Software map:

Environment
X11 Applications
Gnome (239 projects)
KDE (100 projects)

Re:That remark is as stupid as the discussion itse

[King Babar]

It's very funny seeing the die-hard anti-MS people twisting and turning to avoid having to say 'Implement it as COM!'. COM not a bad protocol, people, in fact it's quite clever. And besides that: there are a LOT of com objects around the world, and a LOT of COM developers around the world.

The last thing is certainly true. And it does seem like every major open/free software project has now had a go at (re-)implementing or (re-)inventing either CORBA or COM. Can anybody with real knowledge and experience out there compare and contrast the ups and downs of the KDE, Gnome, Microsoft, and Mozilla (XPCOM) approaches?

And, no, this isn't a troll. I have no idea what such a comparison would conclude and no vested interest in a particular answer, but a lot of interest in seeing the amount of duplicated effort in the world go down some.

Bull

[Anonymous Coward]

I certainly do not know everything but I think it is misleading and not very fair to the actual developers of KParts to be releasing news stating that KDE is considering switching their object model when none of the actual *developers* or *maintainers* of the KParts project were even asked. Now that they have been most of the developers are bringing up a lot of non-superficial issues.

I do not like misleading news, and this that at best. It is certainly a valid opinion and goal, but nothing of the sort was even mentioned to any of the people maintaining the code until after the "news". It's not that I dislike Gnome, I think this is misrepresents the people who volunteered their free time to actually make the KDE object model.

Daniel M. Duley mosfet@kde.org

OpenDoc?

[Dr.Hair]

I could have sworn that a corba-compliant cross-platform compound document architecture was created years ago. Doing a quick search on OpenDoc over at google points to a good overview and documentation and even some code and UI coding guidelines for OS/2 over at IBM.
Mind you, reading some of the industry rags it seems that Novell failing to provide a timely bridge between OLE and OpenDoc left Sun and IBM to fold most of the ideas in to the EJB model and try and push java as "the" component model. But Apple actually implemented OpenDoc back in OS8 and I distinctly remember large Apple ISV's (cough, cough - Microsoft) stating in the press that there was no way that their applications (cough, cough - Office) was going to be implemented as a set of OpenDoc editors since there was too much functionality in their products to repackage all of that functionality as components (that would have been individually open to competition). Needless to say that OpenDoc was axed/placed in hibernation by Steve Jobs. But there are still some OpenDoc torch bearers among the Mac zealotry that like the idea of only installing one spell checker and being able to create a compound document that allows the user to select what editing apps to use to manipulate each type of data and having the interoperability at the object level to allow for swapping in and out editing apps on a whim. You like vim, I like emacs. You like a gui, I like a console. The documents won't care and we all can just get along.

Re:Too bad indeed

[ElvenKnight]

Oh, and one more thing...

You wanna know why all the developers use COM for Windows? Because they don't have to worry about which one to choose.. Thats it.. Thats the ONE. You wanna do Windows? You use COM. No need to fret over the choices that don't exist.

Take a hint from that. I myself am actually QUITE frustrated with the fact that I like both GNOME and KDE.. and have a hard time choosing between the two. They each have "features" unique to them that I either hate or like. Perhaps my tastes match the popular vote, perhaps not. Do the developers of GNOME and KDE know though what sucks and what kicks ass uniquely to each of their projects? Should we not, as end-users of open source software, get more actively involved and let them know what we like and don't like about each one in a constructive and thought-out manner? Be nice if someone knowledgble enough in both projects could post a PRO and CON list on each one (ie. who has better drag and drop, etc). Otherwise we could see the developers argue endless about which parts of each of their code from their projects should be the defacto standard.

If we are truly an open source community.. should we not be more actively involved in providing USEFUL feedback? We could help deflate egos on both sides, show them what sucks and what doesn't from both of their projects.. and end up reaching an agreement MUCH faster then they would on their own. After all, end-users just might have a clue of what annoys them and what doesn't, no?

Some commerical/shareware projects come to mind that do happen to have a clue about the fact that endusers just might know something... http://mytrack.com/ and http://www.casdk.com/

They both have sections where endusers can both post new feature ideas, and VOTE on those features for top priority of what should be completed first in development. What a novel idea. If commerical companies can embrace the collective minds of their userbase, why can't open source projects? ESPECIALLY OPEN SOURCE PROJECTS. Hrm?

-Matthew Cortes
Technetos, Inc.

DCOM Sucks Rocks!

[Izaak]

This is quite suitable for most cases. In situations where the default implementation is not suitable, we've written our own proxy/stub components, which implement our own transport.

That 'most cases' (emphasis added by me) is the telling bit. When DCOM faile, it can fail spectacularly. I've been working with it quite a bit lately, and it seems like anything dealing with late bindning or mixing you environments is just asking for trouble. Ever try to get a VB app to talk to a multi-threaded C++ ActiveX component? Here there be dragons! And don't even get me started about interfacing DCOM to non Windows systems. Things just seem to work more consistently in the CORBA world.

Just my $.02.

Thad

Re:DCOM Sucks Rocks!

[dazraf]

Ever try to get a VB app to talk to a multi-threaded C++ ActiveX component?

Yes, all the time! We write central, computationally intensive, multi-threaded (MTA) components with c++, and handle the high level, low-bandwidth logic using VB, Python or Tcl (depending on what we need and what we feel like). And we rely upon late binding when using Python and Tcl. In my experience, everyone (including me) complains when faced with new technology that doesn't bear any kind of similarity to understood work. That's ok - issues like these can be sorted out by talking to people who have solved these problems. Have you tried the DCOM mailing list?

http://discuss.microsoft.com/archiv es/dcom.html

The response time for posted questions is usually very fast.

And don't even get me started about interfacing DCOM to non Windows systems.

This in the past has been my biggest headache too - I don't think this is negative point about COM. Perhaps for low-bandwidth connectivity, protocols like XMLRPC or SOAP might be a good solution. I remember back in the OpenDoc days, the boys and girls at IBM did put together a COM/CORBA bridge - I wonder if that's still available.

This is NOT a merge between KDE and GNOME

[_Logic_]

This is merely a venture to build an interopable ORB. It is unlikely that the two projects will merge into a single desktop environment.

KDE and QT are very well engineered --in C++.

GNOME and GTK+ are very engineered --in C.

The design philosophy of a C programmer is very different from a C++ programmer. A programmer who implements an application (or desktop) in C will do it very differently under the hood from one who will implement the same features using C++.

This is (IMO) one of the reasons KDE and GNOME have been so antithetical.

This collaboration makes perfect sense, however. It is probably the most agreeable point for both camps. With a common component interaction protocol used by both GNOME and KDE, developers can continue to pursue implementation their own way without a religous war over how specific components are implemented.

KDE will still be KDE, GNOME will still be GNOME, but KDE application developers can leverage GNOME apps, and visa versa. Again, this is not a merge to a single desktop.

It's ironic that GNOME uses an ORB for component interaction, but is primarily implemented in C, whereas KDE has avoided OMG recommendations for object interoperability. It may explain why the teams are receptive to the proposal.

Hopefully this sheds a little more light on the discussion here.

Re:Shame

[nd]

It is shameful that they would borrow like this and not at least give a nod to where the ideas came from.

Miguel has made it VERY CLEAR several times that they borrowed ideas from COM when it made sense.

Seriously, what are you talking about?

Toolkit independent development?

[bogado]

Correct me if I am wrong but with this kind integration, it should be easy/possible to create an interface that would allow one to create simple applications (the ones that only need the default controls like textboxes, menus, checkboxes...) independently of toolkit.
--
"take the red pill and you stay in wonderland and I'll show you how deep the rabitt hole goes"

This is what I love ...

[anim8]

... about free, open-source software: the sharing of information. And since their goals are not gobbling up as much money as possible in the GUI desktop market they have the freedom to collaborate with each other.

KDE and Gnome are leading by example. Let's hope the rest of the world learns something from them.

A big thanks to all involved :-)

Faking posts

[Mossie]

Hrm. Idiot comments like this has made me realize I better actually get a Slashdot account... The original "Bull" post was mine, the followup about an obscense sexual act by an AC who used my email address is of course not ;-)

Borland's influence?

[windex]

I don't know if this has anything to do with it, but, Borland is working on Krylix or whatever it is for Linux, and they announced it was going to be working with KDE untill some standards were accepted between the two enviroments. I, personally, dispise KDE, but that's just me, I'm not flaming, I'm stating my *opinion* in a public forum. Now, this makes me wonder if possibly Borland had a hand in this (seemingly nonexistant) agreement.

*shrug*

--- 'dex

Re:Borland's influence?

[jyeger]

Kylix is not "working with KDE." Kylix and Kylix-created apps will run on both Gnome and KDE.

As far as a Borland role in this KParts/Bonobo interoperability I have no idea, but I'm sure they'd like to see it.

Re:Borland's influence?

[warmi]

Simply speaking Borland recognized Qt for what it is , an excellent toolkit which has no equal in Unix world.
It has nothing to do with KDE.

This is good...

[josepha48]

.. if this actually happens it will be really good. I personally use parts of kde and parts of gnome. For instance I use kfm as my file manager. I like it a little better than gnome file manager. The gnome file manager is just to windows like, where as kfm is not (IMHO). I also like to run gnome rather than kde. I like the gnome panel better than the kde panel. Why? Cause when you put the gnome panel in the bottom right portion of the screen and then hide it or whatever it is hidden or it is that little arrow in the bottom left corner of the screen. With kde's panel, when you hide it it seems to apear in the top righ corner of the screen. This overlaps my icons that I have up their. At least that has been my experience.

However their is another reason that this is good. It means that efforts will not have to be duplicated across the board anymore. While it is still possible and probable, it will make more apps for a linux desktop. Those who want to run kde can still run kde and those who want to run gnome can still do that (personally I use windomaker with gnome panel and kfm).

The only issue that I see arrising is that this may mean that in order to use this functionality that you must have qt installed along with the kde base, libs and sup, and some other parts opf kde as wel as gnome core and gnome libs. It they can make an independant common set of libs that depend neither on kde nor gnome it will work. This is not much of an issue as most people will be willing to install both sets of libs if need be. However this would be problems with distros like debian. Also how would the license for these libs read? If it uses gnome which is gpl would this become a gpl library or qpl? I know that this is in the early stages, but with the recent incident with debian this should be something that the developers need to think about. How can they do this and keep their seperate license in tact?

It will certainly be interesting to see this acomplished.

What I am ammazed at is the fact that these developers are actually showing corporate society a thing or two.For instance even competing groups can come to work together for the betterment of the software community. If UNIX vendonrs had done this years ago rather than competing against each other their may not be a windows OS today or it may not have as strong a hold on the OS market as it does.

Shut up or I'll replace you with a very small script!

send flames > /dev/null

Re:Great, but something is bothering me...

[arnald]

It's still exceptionally irritating.

Maybe I should write myself a filter.

ARGH! Tell me this isn't vapor!

[BluedemonX]

This is EXACTLY the kind of thing that will rocket Linux not only on the desktop, but PAST the desktop!

OK OK I don't know what the hip marketing term is, but the idea of having collaborations of developers working on a common COMPONENT platform (esp. distributed ones!) means more than cute little controls in Web pages - it means that Linux can finally start kicking some serious tail, building applications that span networks.

Here's my socket component! Great, add these common widgets, you have a distributed application that we can run across the Internet or all our educational or company networks.

It means that you'll start seeing hundreds more applications quick fast in a hurry as people start building bigger Lego blocks from the littler LEGO blocks...

Then all you'll need is some DLL so that Windoze and a shared library for Macs so that Macs can run these parts, and you'll start to see Linux take over beyond what we have now.

Linux shouldn't just catch up to the desktop - it should catapult beyond that into the Net sphere. Windows is already trying to move away from the desktop OS into distributed computing services with components, if Linux can get there first and better it'll own that space.

I'm all for it

[cwiegand]

I work on Gnome-DB, and I program Geheimnis (a KDE program). Yes, I stradle both sides of the fence. And you know what, if you ignore the different between toolkits and languages (both of which this component architecture would ignore), they have pretty much the same goal: making the desktop easier to use, and improving productivity (compared to tweaking your kernel once an hour, at least). I would *LOVE* to see this. I've been wondering what KDE would do about database access, with this they could just use the Bonobo components that we have in gnome-db, and gnome mailers could use my program just as easily as they could seahorse...

Re:That remark is as stupid as the discussion itse

[zhaoway]

Oops! ;) I have some rough mem that when last time I encounter the word COM in a play with OSKit which uses COM, I happened to read that there are some kinda sorta priviledge by MS over third parties in some namespace issues. (I read that line in somewhen around Nov. '99) Since it's big, oops, huge indeed. I have never checked back then. And I nearly read every elsewhere that says CORBA has lota advantages technically over COM when comes into the Internet-wide applications. Just rant. ;)

*nix tradition

[siwtsds]

Combining the Component Architectures would actually be something that really reflects the *nix spirit.
I think Component Architecture is the GUI equivalent to the pipe on the commandline. It allows different programs that do not know anything about each other to share data and work together to produce something greater than the summ of the parts.

Just my $0.03 (Inflation)

COM vs. Bonobo Re: Good Thing (tm)

[Matthew Weigel]

What do you mean by 'fake'?

Last time I read anything about it, it didn't support binary inheritance (CORBA can, I believe Bonobo does). Maybe it does now, but I have difficulty believing that a post-design add-on is as good as the real thing.

Why does COM 'suck eggs'?

Hyperbole on my part. CORBA does have its problems (I would like inheritable exceptions like Java), but it is an object model from the ground up.

The most important part of my post, though, was glossed over: Bonobo is not a 'wannabe COM' object model, it is related to COM in the press because it performs a similar function. It clearly starts from a different grounding.

Re:That remark is as stupid as the discussion itse

[yugami]

COM not a bad protocol, people, in fact it's quite clever. first off COM is not a protocol, since COM cannot talk outside of the box its on, you may be thinking DCOM or COM+. also read the link below, DCOM is a bad protocol, its over complicates the conversation between the two boxes, most COM components suck as DCOM components cause you don't take into account network latency or anything else when you first write a COM object. CORBA isn't better, it just sucks in different ways. http://www1.bell-labs.com/user/emerald/dcom_corba/ Paper.html

Re:Too bad indeed

[biomech]

Yah, and I second the motion.

As a sheer and utter LINUX (although not systems) newbie who has only recently installed 1 of each, I have only one thing to say to the folks at KDE & GNOME about the idea. "Please, please, please, please, please . . . please!!"

Myself and others at the bottom of the flame chain desperately want to see more integration of the desktop environment, which is what the public is most aware of, not only for ourselves, but because of what we want to be able to recommend to others.

Broader development coherence and better apps - in the words of one comedienne, "It could happen!!" She was being facetious, I'm not.

Ssh + X forwarding

[kangasloth]

There's a security issue with X forwarding, not sure how bad, so ssh can be configured to disable the feature by default. I believe debian does this. Have you tried ssh -X?

If it's enabled, your $DISPLAY should be set to the local hostname + : + a relatively high number, e.g. 10. This correlates to the X proxy ssh setup on the local host. Some ppl set $DISPLAY to the remote host's X display, which works, but totally negates the security gained by using ssh.

Nobody was "speaking" for anybody

[DragonHawk]

I find it rather annoying that, when the beginning of an idea was posted, with the comment that it was worth looking in to, the first thing everybody starts doing is coming up with reasons why it won't happen.

Niether my submission, CmdrTaco's comment, or Rivyn's pages say this is going to happen. It consists mainly of speculation and ideas at this point. Why the hell are we trying to kill it before it is even born?

Did it ever occur to anybody that, even if this hasn't been coded, tested, and approved by everyone from the Pope to the Bob the Lawmower Man, it might be a good idea? That maybe it is worth looking into?

Simply considering an idea doesn't mean that KDE is going to have to adopt CORBA for IPC or that GNOME is going to switch to Qt or that Bill Gates is buying Linux.

I submitted this to Slashdot in the hopes that a good discussion on the technical challenges involved might happen. I didn't expect a political cat-fight.

Geez people. This kind of attitude reminds me of the proprietary Unix vendor wars of the 1980s. Keep this up, and Microsoft won't need a monopoly to dominate.

What's What

[DragonHawk]

The ability for objects in different binaries to interact is not and should not be the responsibility of a GUI

What you say is correct. However, what you say doesn't necessarily apply.

GNOME uses CORBA for IPC. Bonobo is a set of CORBA interfaces designed to enable component reuse. Bonobo is also an implementation of those interfaces for GTK.

KDE uses DCOP for IPC. DCOP is a layer on top of X11 ICE. In concept, DCOP is a lot like CORBA, but with all the things KDE doesn't need striped out to improve performance. KParts is another layer on top of DCOP designed to enable component reuse. KParts is tied to Qt, not so much in terms of the GUI (although that does come into things), but because KParts uses Qt's "signals and slots" mechanism for function callbacks.

The practical upshot of all this is that the IPC mechanisms and some of the component architecture is very GUI independent for both KDE and GNOME, but they didn't go to extremes trying to keep their GUI from being tied to their GUI. Which is reasonable.

(Note: This is an executive summary, and as such, may not be completely accurate. What do you want in three paragraphs?)

Re:That remark is as stupid as the discussion itse

[Otis_INF]

Protocol as in 'how to write a binary object so that it can work in a component world'. :) not networking related.. no. DCOM isn't bad. The first DCOM drafts were not erm... good, but today it's extremely flexible.

And COM can't talk outside the box? since when is that? If I register my MTS COM object from Box A on Box B, so that Box B knows the object is on Box A it will work. No special stuff needed.

hmm... I now wonder why a guy named 'Box' wrote a COM book ;)
--

I didn't say anybody was

[Andrew Cady]

...but a lot of the comments here assumed that Rivyn was speaking officially on behalf of KDE. Indeed, that is what I thought too at first (I even made a few posts in this thread under that assumption before I saw the message from Duley).

I never said this isn't going to happen, even though I think it's realistic to presume it isn't (as they say, "where's the code?"), at least until the KParts and KDE-core teams have agreed to at least look into it. I know that KDE has looked at CORBA before and decided against it -- when I saw this, I thought that they had changed their minds. In reality, they haven't, and that fact should be recognized. We don't accept such early announcements from corporations, let alone from individual developers working for corporations who are not official spokespersons. There's no reason to accept this early announcement either.

That said, I certainly hope this happens, and I'm not saying it shouldn't or that it couldn't. I'm not "trying to kill it" and I don't think anybody else is either. Just trying to sort out the real facts and possibilities, and to avoid unrealistic expectations.