Saturday, May 05, 2007

when i forget why i pick a title

i completely forgot to write the bit that fit with the title i picked in my last blog entry ("tell me that you'll open your eyes"). i got carried away on a stream of consciousness and ... yeah.

so, here goes try #2: in an article about a gtk+ app, i read today about how great d-bus was when an application uses it to export internal api and functionality; and i completely, wholeheartedly concur! the article went on to note how you can write scripts that automate things. how wonderful! the writer seemed to be writing from a place where this was the first time they'd really experienced this flavour of coolness. either that or they are good at getting excited repeatedly.

now, why would i say such a thing? because since version 2.0 kde has provided this same functionality via dcop, a tradition we continue in kde4 though via d-bus. kde apps have been exporting interfaces since the turn of the century to the joy and merriment of kde users around the globe. was the writer aware?

it does surprise me how people who don't use kde as their primary desktop never seriously bother to take a look into applications that run on their own platform (which is linux, bsd, solaris, etc). normally i'd be tempted to say, "hm. obviously we're not communicating about this well enough." but no, because in this particular case our user base tends to know about dcop and what it can do.

on irc or a mailing list when the answer is, "try dcop" i almost never see "what's dcop?" in response. 5 years ago, yes. today, rarely. so i think we've communicated it decently, but somehow primarily to the kde user base.

is it because we aren't talking enough to the wider spectrum of free software users? well, our communication is often popped onto sights such as lwn, linuxtoday, osnews, etc.

or is it because the group of people who don't use kde, which is a sizeable minority of the total user base, just don't bother as soon as they see those three letters "k, d and e" in succession?

given that i've heard people who are not just users but contributors to and even supposed thought leaders in our community spout the most heinously wrong stuff, like "linux doesn't offer good printing GUIs" (the issue was cups integration, if anyone cares =) which i heard at an osdl desktop architects meeting to "free software pdf readers don't provide ways to honor drm" (not that i think drm is a good thing; that's a whole other topic) and all sorts of things in between.

well, free software desktop community (not that they are reading my blog en masse ;) : if you think it doesn't exist and you haven't yet looked at kde, you're risking looking a bit foolish if you open your mouth and say "XYZ does not exist/work/etc on the free software desktop" or "such-and-such only works in Foo environment".

now, i've met free software desktop users who don't use kde who are aware of what is available on kde and elsewhere; to them: bravo and my sincere applause. i just wish they were the majority. i wish more people who actually use the platforms we support would open their eyes to what is around them. (there, that was the title tie-in ;) of course, i encourage kde people to do the same thing as well.

another reason i think it's the people closing their eyes is the reaction i often get from people who don't use kde when i remark that inkscape is a great vector app so why should the kde community invest huge amounts of time in creating a k-version of it? to me this is common sense. few kde users do more than nod when i say that. but i get all kinds of comments, usually of the unexpected-but-great-to-hear variety, from non-kde users/supporters/developers. weird.

yet another reason i think it's the people closing their eyes is that i have been told, point blank, by a group of gnome developers at a dev conf that kde and gnome are separate platforms just like windows and mac are and so who really cares about little things like, say, being able to share default app settings. (yes, that was the actual issue.) i responded with, "i bet google, with their mix of desktops, cares. i can name a dozen more such places if you'd like ..." not that that budged anyone. after all, if our eyes are closed, we can't see the users either can we?

we have a real issue in the free software desktop community here. and maybe that's partly why some projects tend to recreate what kde already has done years after we've done so and moved on to other things. this happens at an astounding rate.

of course, if you don't mind waiting for your features that's fine. but try at least to be aware of the landscape before talking about it like you know the terrain.

please:
* don't go around stating things don't exist when they do.
* don't feign surprise and excitement when your desktop gets a feature that's been elsewhere on the same platform for years
* don't recreate what's already good; we have enough stuff that's missing. so when i hear of an app whose stated goal is making a gtk+ version of amarok (exaile) or a gtk+ version of kalzium (i forget the name of that one) it just about makes me puke.

just don't. it makes us all look like fools, starting with you.

now, i should probably say a wee bit more about the third point above about application duplication. if you're doing something different in an interesting way, the toolkit choice is a personal and secondary issue to that in my most humble opinion. but if your goal is to clone another free software tool, particularly one that is well maintained ... i have to ask you: why? yes, i understand the "because i want to write a foo app" but that's not what i'm talking about.

example: i understand the duplication between gaim and kopete based on the integration issues. i think it's interesting that the backends of instant messaging apps on the free software desktop are moving towards commonalities (read: sharing) since the innovation, integration, etc happen above that: they all speak the same protocols, but provide different ways to interact with them. cool.

example: i understand the duplication between gimp and krita; both are essentially bitmap editors but the latter has an emphasis on things like natural media and colour spaces which isn't seen in the former and both are performing interesting and, imho simultaneously successful, experiments with user interface.

counter example: i understand juk, amarok, banshee, etc, etc.. they each do things a bit differently and there's probably an element of "beacuse i wanted to". but i don't understand exaile, which is described as a gtk+ clone of amarok. seriously, go look at wikipedia (i can't get to the exaile website right now, but that was how i was initially introduced to it: as a gtk+ amarok)

now, i'm sure someone is going to jump up and say "but i like all my apps to look the same!" as a justification for blatant cloning. ok, that's cool. overrated and largely mitigated by universal theme engines (a sub-set, indeed, of all engines), but understandable. however, i don't think it validates the blinders i see on people's eyes and it certainly does not explain away non-gui reimplementations. remember, this blog started way back there about d-bus, which is decidedly non-gui.

next someone might say, "but Foo apps take too long to start up / too much extra memory overhead / <insert rational&;gt; in Bar environment". this is indeed something we need to work on; that said, it's gotten better over time (and i'll bet will get a bit better even in kde4 =) and operating system vendors and system integrators could do things to help out in how they install and set up systems ... but again, these are issues we can and are addressing. is it really a reason to utterly ignore what others are doing?

i am aware that this isn't just free software desktop related: i see it all the time in other free software realms such as open source databases. mysql users are frequently innocent of what is offered by other solutions. more than once i've seen someone bung something together clumsily with mysql simply because they didn't know there was a better solution for that particular problem out there in the free software world.

perhaps this is all because for many in the community, from enthusiast to professional (and back =), the ability to be involved gets confused with an expectation of loyalty. can we grow past that? (honest question)

a related concern to me is that many people who don't use kde will miss out on a lot of the very nice features that kde4 is bringing to the table. and just as in the past, others will probably get around to duplicating some or even many of them eventually, perhaps unnecessarily to boot.

i'm already seeing it in articles written about kde4 by people who don't use kde. such a recent one that claimed kde4 had moved from aRts to gstreamer; yes, there is gstreamer support in kde4, but the real story is that it's not the only backend thanks to phonon; i fully expect other projects to eventually adopt similar solutions in the future after retracing our steps versus paying attention and learning something. but it kind of amazed me that someone would write that kde is now using gstreamer ergo gstreamer is becoming the de facto standard. holy not paying attention and applying other project's agendas to kde. whether or not gstreamer does become the de facto standard (that's something i'm probably not the most qualified person to comment on) is moot compared to writing about something you've obviously not really looked at.

to be honest, sometimes i think "maybe i should care less about the whole ecosystem and care a whole lot more about only kde. i can't fix what i'm not fixing, after all. and i certainly do spend much of my time supporting kde ... " but isn't that the exact attitude that annoys me? =) yes, it is. so i'll keep on caring and hoping; i'll continue to challenge our community (particularly as that community grows) to open our eyes. because, as the song says, "i need you to look into mine."

i really want the idea of someone "from" project X caring also about project Y to be the norm, not an anomaly.

(hm. re-reading this blog entry i think maybe tonight's yoga session really got to me. =)

37 comments:

Anonymous said...

Nicely said Aaron, totally agree.

LJ

Ramsees said...

I think this "article?" is totally biazed towards KDE but hey, I couln'd spect less from you.

liquidat said...

I also saw surprisingly many people totally misinformed about the available technology of KDE.

But especially in this regard I honour the work of Troy Unrau who brings the new technologies of KDE 4 really to the masses (they are published at the dot, but quoted and republished at many places).
The articles are interesting and easy to read, and they truly educate the reader.

I hope that Troy stays with KDE for some more months to publish more articles (like updates about the already introduced topics but also on yet unattended topics like Plasma or similar).


But one word about the "rework app xy under environment ab": a problem often experienced is that an app from environment ab feels like an alien in environment ba: besides the GUI theme (yes, there is gtk-qt, but nothing the other way around) there are is also the file open dialog. This needs to be solved. I know that people are working at it; but atm it is still an issue. :/

But anyway: its good that you posted the second part because I was already confused what the heck you wanted to show with the title of the first post :D

Rafael Fernández López said...

Bravo Aaron !!

Completely agreed. Really nice said !

Eike said...

> in an article about a gtk+ app, i read today about how great d-bus was [...]

Ten bucks says it was Ars Technica's review of Pidgin 2.0, to be found at: http://arstechnica.com/reviews/apps/pidgin-2-0.ars

Ironically, Ars Technica has published in-depth KDE reviews in the past that discussed many of the pillars of the platform, including DCOP.

superstoned said...

@Ramsees: the oposite does happen as well, KDE sometimes duplicates functionality in Gnome, but as KDE is ahead in most area's, it happens less often. And the NIH syndrome is simply less in the KDE camp (though it also exists).

Imho, his most important point is that ppl tell other (non-linux) users that linux lacks feature X, while KDE simply DOES have that feature (and often had it for years). Things like a propper printing dialog, encryption (kgpg), things like Klipper and the many other things supposedly 'new in linux' when they where introduced in gnome, even while they did exist for years and years in KDE.

Aaron J. Seigo said...

@ramsees: easily said. please, tell me what was biased towards kde and how.

seriously, you can dismiss easily but i want to know what your perception is so that if necessary it can be fixed.

otherwise, i'm not interested in drivel. i've had enough of it this week.

06labs said...

Beautiful words!!!

Anonymous said...

Buy a keyboard with a working shift key.

evden eve nakliyat said...

very nice informations...thank you very much mr osman...

Paul Boddie said...

It's interesting to read about how "great" KDE's support for exposing interfaces has been and how ignorant people are of the alternatives, but DCOP is much less functional than things like COM.

It seems to me that DCOP was engineered for performance at the expense of functionality, starting off from the premise that CORBA was too slow and that various short cuts need to be taken to make its replacement fast. Consequently, one eliminates all the use-cases where the need for speed would have been desirable.

Of course, my experiences with DCOP have been limited by the applications which support it, and perhaps it'd be more useful if those applications supported broader interfaces. But on the topic of enlightened commentary, I'd like to read a bit more about KDE insiders' experiences with related technologies and their thoughts about what they might be able to bring to KDE from those experiences.

Has anyone had any real experiences with COM or CORBA (or UNO, XPCOM...)? What can they tell us about those experiences?

Macropode said...

It's my hope that level-headed people such as yourself will prevail against the seemingly ever-increasing number of supposedly intelligent FLOSS people espousing small-minded tribalistic attitudes. A good example would be, in one of the videos (I don't remember which one) of the last DebConf (http://meetings-archive.debian.net/pub/debian-meetings/2006/debconf6/), the character who was videoed proudly singing a song he apparently composed himself, which included the lyrics "don't use KDE my friends, don't use KDE". Kudos to you, Mr. Seigo.

Aaron J. Seigo said...

@paul:
you kind of sidestepped the message of the blog entry, but your questions are indeed valid and interesting:

> It seems to me that DCOP was
> engineered for performance at
> the expense of functionality

actually, it was engineered for simplicity and utility. performance was a nice side effect of meeting those goals.

it's also more realistic to compare dcop+kparts when looking at something like com.

> Has anyone had any real
> experiences with COM or CORBA
> (or UNO, XPCOM...)?

yes, indeed. com is not overly fun to work with, but corba was a disaster. it was too hard for application developers to get right and resulted in bloated flakey applications.

kde 2.0 was actually written using corba originally, but that was ripped out before the betas due to the constant problems.

it wasn't helped that the only working open source orb was pretty fugly, but even once that was generally worked out one can see how corba faired by looking at the other experiment with it in the free software desktop world: bonobo.

despite all the hype around bonobo back in the day, it's now deprecated in gnome.

the hypsters around bonobo are now hyping, with similarly seemingly sound reasons, other technologies which are, imho, similarly doomed to unspectacular futures.

history repeats itself.

Matthew Garrett said...

Dcop has generally been less than attractive to the Linux desktop community (as opposed to the KDE desktop community) because it's been tied to Qt. It probably doesn't help that all the documentation tends to refer to it as a KDE technology.

So, yes, when there's a technology that's tied into a particular implementation, there's a strong incentive to reinvent the wheel in a way that actually allows cross-desktop integration. Dbus provides that.

So, to be honest, I'm really not sure what you're arguing about. You mention that you're more worried about reimplementation of non-GUI components, but the only one you mention was something that had to be reimplemented in order to be useful outside KDE. What cases are there of underlying technologies in KDE that are already entirely generalisable but have been reimplemented anyway? I guess you could make that argument for parts of Klipper, but it also has a moderate part of UI and the source release is as part of the monolithic kdebase package, which makes it a pain to ship as part of a non-KDE product - you'd have to extract it from there and then manually keep it in sync.

So, perhaps there's your answer. People reimplement stuff that already exists in KDE because KDE doesn't make it especially easy for people to reuse that code outside KDE.

Morty said...

Funny observations, but so true. I think I'll do a little Nostradamus imitation on the subject.

A few days back Beagle integration was added to the GTK+ file chooser. I predict we will see lots of surprise and excitement regarding this revolutionary new feature, when the first version of Gnome utilizing this is released.

A fully Strigi intergraded release of KDE 4.0 before that may cancel it, but I'll not bet on it.

And the existence of things like kio-beagle, already intergrating it nicely in all KDE file dialogs, will be largely ignored. Even with initial submission to kde-apps Aug 30 2005. But that's fair and reasonable, Beagle being a Gnome technology and all :-)

It's going to be interesting to read how hot and new having search functionality in linux file choosers are. Even for people remembering a kde-apps entry for kio-locate from Oct 21 2004 :-)

Anonymous said...

"Don't recreate Amarok, Exaile makes me want to puke"

Yeah, Amarok and other KDE things are awesome. Technically. It's the GUI that is absolutely horrible why people are supporting stuff like Exaile. All the KDE software looks and feels a bit silly on every real desktop. (I repeat: technically KDE apps are many years ahead.. Usability and aesthetics wise, early 90s. Thus, it is good to recreate them properly.)

Andrew said...

Thank you for summing up the entirety of my feelings on this issue. I really enjoy reading your posts on Planet.

It seems to me that the Gnome camp seems to have a superiority complex that extends from developers to users. This is not an attack, it's a valid observation.

Alex Merry said...

@anonymous (latest)

I have to agree that the look of KDE 3 isn't great - it has a childish quality to it, for a start. It is highly configurable - I have my desktop laid out much more like the default gnome desktop - but it took me ages to find out how to even get two panels.

However, KDE 4 is looking awesome. The Oxygen team have done a brilliant job with the new default icon theme, and the look of applications is much improved (a mix of improvements in Qt 4 and KDE 4, I think). The desktop itself is still being developed, but I feel confident that the people working on it will do a good job.

Aaron J. Seigo said...

@matthew: "Dcop has generally been less than attractive to the Linux desktop community"

the bit about d-bus was not saying dcop should have been picked up. i completely understand why d-bus is there; in fact, i was one of the early proponents of using it instead of dcop in kde.

reading the blog entry again you'll see that i started with the issue of people being largely ignorant of what else is out there beyond their little kingdom. specifically, the idea of little kingdoms is a false perception to begin with since we are part of a larger platform.

it astounds me time and again how little most people, particularly those involved in the creation and promotion of the technology, know about the broader picture. it's a self-imposed ignorance that generally hurts all of us.

"You mention that you're more worried about reimplementation of non-GUI component"

no, i said that those kinds of things tend to be more mystifying to me.

if you read more carefully (i know, it's long and isn't in "usa today" simplified english and doesn't use capital letters and .... ;) you'll see that two examples if gave that really rub me the wrong way are both GUIs: an amarok clone and a kalzium clone.

so i am concerned about gui cloning for the specific purpose of changing toolkit. i think i said that pretty plainly in the blog, no?

"the only one you mention was something that had to be reimplemented in order to be useful outside KDE"

i wasn't attempting to make a laundry list of such technologies. i was pointing out people's self imposed ignorance and the attitude / worldview that drives that.

"So, to be honest, I'm really not sure what you're arguing about. "

actually, you provide your own answer:

"It probably doesn't help that all the documentation tends to refer to it as a KDE technology."

pot, meet kettle.

that sentence is exactly what i find repugnant and exactly what i was writing about. if you can't get beyond those three letters, you have a problem. seriously.

look at all of the "non-kde" (fd.o and general third party stuff) and even "straight-out-of-gnome" technologies kde is making use of. we tend to invent wheels that aren't there yet and try and cooperate most everywhere else. from poppler to the mimetype database to dbus to media engine support to icon naming and theming specs to .. the list goes on an on.

yes, there are times when it makes more sense to seemingly duplicate effort because of other upsides (something i also spelled out in the blog entry, along with examples). so i'm not trying to advocate a "perfect world" scenario of utopian harmony.

but we, the kde community, have largely moved past this stupid "judging by labels" thing. honestly, it's a matter maturity and something that remains visibly lacking in the larger community.

your comment is a good, if fairly harmless, example. going around spouting that there is no good PPD integration in GUIs on linux in a room with ISVs in it is a bit less harmless (to re-use an example i used in the blog entry)

the other irony to your comment becomes apparent when one looks at how gnome people tend to slap the gnome label on just about anything it can no matter the strength of technology affiliation. so if people really are concerned about labels, i'd suggest looking inwards first and think about how each of our projects uses them.

personally, while it does make it harder to 'sell' certain technologies to some segments of our community, i don't really care about the label attached.

i wonder if other projects can step up to that plate as well. to be honest, i believe that those projects that don't will sink in the long run. but hey, do what you want, right? =)

@anonymous: "It's the GUI that is absolutely horrible why people are supporting stuff like Exaile."

that's a highly personal judgement. i know many people who find the look and feel of kde to be the bees knees, including many non-geeks.

that said ... many non-kde apps are likewise not particularly brilliant (to be kind)

but here's the real kicker: it's far, far easier to modify the UI than it is to reimplement something like amarok from the ground up. if the reason you gave is the actual thinking of these people, i'd like some of what they're smoking.

because that assessment is not couched in reality.

Matthew Garrett said...

Aaron: "however, i don't think it validates the blinders i see on people's eyes and it certainly does not explain away non-gui reimplementations. remember, this blog started way back there about d-bus, which is decidedly non-gui."

That's what I was referring to. It certainly gives the impression that you're unhappy about the existence of dbus, which is confusing given everything else you've said. But still:

"that sentence is exactly what i find repugnant and exactly what i was writing about. if you can't get beyond those three letters, you have a problem. seriously."

Sorry, you seem to have misunderstood. The reason something described as a "KDE technology" is uninteresting isn't because it's derived from KDE, it's because it sounds like it's only for KDE. Sell it as a piece of software for Linux IPC (like Dbus, for example), and it's likely to be much attractive. I've no objection to using KDE derived code, but I've also no real desire to spend significant periods of time trying to work out whether something described as being designed for use in KDE applications is generalisable or not. Saying "Oh, dcop exists!" while the documentation only provides examples based on me already having a KApplication is unhelpful from that point of view.

There's other examples of this. Phonon's website introduces itself with "A new era of writing multimedia-enabled applications in KDE is about to begin". I've immediately gained the impression that Phonon is uninteresting for cross-desktop applications - I'd be better off looking at just targeting gstreamer instead. The Solid website discusses everything in terms of KDE, to the extent of the main library being "libkdehw". I'm not writing a KDE application, so it sounds like these projects aren't meant for me.

If you want people to use KDE code rather than reimplementing it, make it attractive for them to do so. Talk about the new functionality that it brings to the Linux desktop, not the KDE desktop. Give me API documentation that doesn't assume I'm writing in C++. Make it attractive for me to recommend your code to people who are looking at implementing new desktop functionality based on the new code I've just added to the kernel.

I think the Gnome people have mostly succeeded in this. There's almost as many mentions of KDE on the gstreamer site as Gnome. Beagle's site explicitly discusses its cross-platform support. Compare the dcop documentation to the dbus documentation and see which sounds more attractive for cross-desktop use. Hal is sold as a desktop-agnostic piece of infrastructure. The word "gnome" doesn't appear on the front page of the Pulseaudio website. These are all technologies that are attractive to people who don't care which desktop they're using.

If you want things to change, help make the technology you're developing attractive to the people you want to use it. Right now, KDE is failing to do that.

Ramsees said...

"i was one of the early proponents of using it instead of dcop in kde."


Can I remember you the " Is a dead parrot no is the Free Desktop" comment you make some years ago.

lol
KDE is using d-bus just because Trolltech pushed it via Qt nothing else you were one of the whiners about it, you are such an hypocryt.

Paul Boddie said...

@aaron:

It's interesting to look back through the archives (and current KDE documentation) to see the reasoning behind choosing DCOP over other mechanisms. According to the KDE news archive for October 1999, CORBA wasn't designed for the things that KParts is intended to do. Whilst that might be true, various CORBA-like systems permitted same-process integration (eg. ILU, Free Software since 2.0alpha13 in October 1998, incidentally). Such systems were very usable for a number of languages ten years ago.

From a Python environment, DCOP isn't even as usable as XPCOM as far as I've experienced both technologies, and that's not really the fault of the bindings developers.
But anyway, I'd to see KDE and GNOME provide decent integration and automation support. If that means reviewing the state of the art, then let's see that happen.

Aaron J. Seigo said...

> something described as a "KDE
> technology" is uninteresting
> isn't because it's derived from
> KDE, it's because it sounds like
> it's only for KDE.

like all the gnome technology?

btw, you're coming awfully close to producing a strawman here as use of technology across apps is only a small part of the point of this blog entry.

to whit and make it very clear: i don't care if gtk+ apps use kde's print facilities. but people should not be going around claiming no PPD option support exists in GUIs on linux. that and the application duplication to replace toolkits make up the bulk of the issue.

> generalisable or not.
> Saying "Oh, dcop exists!" while
> the documentation only provides
> examples based on me already
> having a KApplication is
> unhelpful from that point of
> view.

matthew, you're missing the point. i never suggested dcop was useful. what i am suggesting is that trying to make it seem like d-bus represents a new feature set on the free software desktop is not true. to see why this matters, let me demonstrate: i could pretend that only kde apps matter and when someone asks if there is a good free software vector graphics app i could pretend inkscape doesn't exist and say "no". that person may now decide to not use a free software desktop. everyone loses.

> There's other examples of this.
> Phonon's website introduces
> itself with "A new era of
> writing multimedia-enabled
> applications in KDE is about to
> begin". I've immediately gained
> the impression that Phonon is
> uninteresting for cross-desktop
> applications - I'd be better off
> looking at just targeting
> gstreamer instead.

i'd suggest that you actually read the website and find out what phonon is, then =) because you'd find out that it back-ends onto whatever audio system is on the OS (assuming there is a backend for it, and yes there is one for gstreamer)

> The Solid website discusses
> everything in terms of KDE, to
> the extent of the main library
> being "libkdehw". I'm not
> writing a KDE application, so it
> sounds like these projects
> aren't meant for me.

you're right. they aren't. they actually use the cross-desktop components underneath. these are actually examples of kde doing the right thing and not reinventing the wheel.

trying to put words into my mouth ("people should use solid, phonon, etc") that don't make sense and trying to make that a refutation of this blog entry is .. i don't know the words for it. it's not kosher anyways =)

> If you want people to use KDE
> code rather than reimplementing
> it, make it attractive for them
> to do so.

ok, explain to me how amarok is not attractive to the point that a group of people decide to clone it with gtk+. or kalzium. it's not just the framework layers.

or explain to me why there was so much push back on things like shared default app settings.

this boggles me, and that is what i was writing about.

> Talk about the new functionality
> that it brings to the Linux
> desktop, not the KDE desktop.

well, not the linux desktop but the Free Software desktop. we also support other OSes besides linux. and we do talk about that quite a bit.

the kde specific API's, e.g. solid and phonon, are spoken of in reference to kde because they are of interest only to kde. and again, they don't provide the actual hardware or media mechanics, but APIs to what exists.

you're confusing things about here, and i'm going to assume that's because your not overly familiar with kde internals. that's cool, but it's also not what i was writing about =)

> Give me API documentation that
> doesn't assume I'm writing in
> C++.

we have tutorials for ruby and python on techbase. the API is essentially the same across those bindings. Qt Jambi is coming with complete docu as well.

> I think the Gnome people have
> mostly succeeded in this.
> There's almost as many mentions
> of KDE on the gstreamer site as
> Gnome.

that's probably because we've been involved with gstreamer for a while and fluendo is providing a phonon backend for gstreamer. you're right that it is a fairly generic solution in that sense, and so it is communicated as such.

> Beagle's site explicitly
> discusses its cross-platform
> support.

as does strigi: http://strigi.sourceforge.net/

> Compare the dcop documentation
> to the dbus documentation and
> see which sounds more attractive
> for cross-desktop use.

we've been around this tree already.

> Hal is sold as a
> desktop-agnostic piece of
> infrastructure.

and kde is using it.

> The word "gnome" doesn't appear
> on the front page of the
> Pulseaudio website. These are
> all technologies that are
> attractive to people who don't
> care which desktop they're
> using.

indeed; and yet this misses the point of the blog entry =)

i'd also note that we've taken things like "get hot new stuff" and genericized it, moved it fd.o and work on it in concert with people from other projects, including gnome.

it really does go both ways in kde: importing and exporting. not everything is imported, though, and not everything is exported. you seem to be picking the latter for examples that the former doesn't exist.

but again, this doesn't address the very real attitude issues in the community when it comes to what is available out there, even at the application level. there is an odd and open hostility that appears from time to time in actions such as exaile and "no, we don't need to share default applications"

(btw, i keep using those examples because i really would like to keep the airing of dirty laundry to a minimum; examples are needed, but i don't want them to become the focus)

> If you want things to change,
> help make the technology you're
> developing attractive to the
> people you want to use it. Right
> now, KDE is failing to do that.

i think we're making it quite attractive given the number of people who write apps using kde api.

we're also doing quite a bit work on common technologies that everyone shares (i provided a partial list already in a comment above).

and again, just to be repetitive in hopes that this gets communicated clearly, this wasn't what i was writing about. if i gave you that impression from the blog entry, then that's a shortcoming of my writing abilities.

though it seems others got it, so it's evidently not completely obtuse.

Aaron J. Seigo said...

@ramsees:
> Can I remember you the " Is a
> dead parrot no is the Free
> Desktop" comment you make some
> years ago.

i suggest you go back and re-read that. you'll find that i was then, and am now, a supporter of the concept of fd.o and the promise of what it can do. however, i was very concerned about the health, vitality and honesty of the processes around fd.o at the time.

i never said fd.o was a bad idea or that we should avoid what came of it. quite the opposite. my "dead parrot" blog entry was about infusing fd.o with more life and paying more attention to it.

i know it is hard for many to understand how someone can support something and criticize it at the same time. it's like how when you really love someone, e.g. a family member, you are probably more likely to offer sincere advice even if it isn't flattering to them.

for the fanboy mentality that is far too pervasive in our community, offering constructive criticize to projects/groups you support often creates cognitive dissonance. as does, it seems, offering praise, advice and effort towards projects/groups you don't directly support.

the latter was the topic of this blog entry.

> KDE is using d-bus just because
> Trolltech pushed it via Qt
> nothing else

no, actually. even with the d-bus bindings we talked about replacing dcop with d-bus extensively within the kde community.

one of the options was to have both and use d-bus for "cross desktop" stuff mainly.

so regardless of what trolltech was doing, replacing dcop was very much a decision kde made and with great amount of discussion. there wasn't consensus at first and even now there are remaining doubts with a few.

but generally we arrived at consensus, which you can read in the archives of the kde-core-devel mailing list. if you read it, you'll probably notice it didn't have a thing to do with the QtDBus bindings.

> you were one of the
> whiners about it, you are such
> an hypocryt.

or maybe you haven't grasped the content of the conversation.

Ramsees said...

nah, I still think you are an hypocryt.

Aaron J. Seigo said...

> I still think you are an
> hypocryt.

i love you too, sweety. *kisses* =)

Macropode said...

Why is Aaron getting such vehement opposition to what was, essentially, constructive criticism? Why can't somebody be big enough to say "yeah, that might be a reasonable point, let's work on it" (co-operatively). This pervasive juvenile adversarial mindset stinks, burns people out, and makes the free software community look like a joke, despite all the grown-up rhetoric about marketing free software to the masses that seems fashionable at the moment.

Shamus said...

About the Inkscape example: I completely agree. Inkscape is amazing and has an incredibly beautiful interface. Does the fact that it's GTK+ based bother me (since I'm using KDE ;-)? Not at all (well, the ALT stealing that KDE does is bothersome, but relatively minor ;-)! Contrast with QCad (which is Qt based) and has a horrible interface. :-P

Seriously, I don't get why people get hung up about the toolkits that their apps use. It's a distraction and a waste of time. What we need is definitely *more* of the type of work that makes integration between gnome and KDE fairly painless (though there are still things that need to done, for sure).

And you're absolutely right--duplicating Amarok just because it's not a gnome app is stupid and pointless. I assume that these same people are going to duplicate K3B for the same reasons?

Anonymous said...

Macropode said...
Why is Aaron getting such vehement opposition to what was, essentially, constructive criticism?

There's this saying in Spanish that goes: "The worst blind man is the one that doesn't want to see". If gnomers want to get defencive about it, they'll cook up any incoherence just to be belligerent, its just blind opposition, if you ask me, they don't care their ignorance hurts the FLOSS community. At the end their ignorance will cost a lot of users to the both free desktops.

LJ

segedunum said...

I think this "article?" is totally biazed towards KDE but hey, I couln'd spect less from you.

Sorry, but that's just a cop out statement. The fact is KDE has had DCOP functionality for several years now, and pretending it's something new and getting defensive is not a particularly good idea. Things are the way they are.

segedunum said...

It's interesting to read about how "great" KDE's support for exposing interfaces has been and how ignorant people are of the alternatives, but DCOP is much less functional than things like COM.

Ahhhhhh, the miracle of COM on Windows. In truth I find the situation of IPC on Windows not all that great. DCOP, and DBUS, strike me as an IPC system that has much more emphasis on message passing. "I know that this application or component exposes this method, and I simply want to use it". If you want to do something similar on Windows, the infrastructure isn't great. COM places a lot of emphasis on things being binary compatible and registered properly, and when it goes wrong it ain't a great place to be. The best part of COM is DCOM really, which provides a relatively easy way of doing network IPC, but even Microsoft seems to have switched to an emphasis on message passing with Indigo.

Also, comparisons between COM and DCOP aren't really accurate. COM is more akin to DCOP and KParts taken together.

starting off from the premise that CORBA was too slow and that various short cuts need to be taken to make its replacement fast.

CORBA is bloody awful, and has always required you to build three or four layers on top to get it to do anything simple or useful. Speed also gets sacrificed as a result. Go into a book store some time and pick up a book on CORBA - if you can lift it.

Personally, I think DCOP has been ahead of the game for many years.

segedunum said...

Yeah, Amarok and other KDE things are awesome. Technically. It's the GUI that is absolutely horrible why people are supporting stuff like Exaile. All the KDE software looks and feels a bit silly on every real desktop.

That's the usual excuse. Oh, we don't like the UI of a KDE application, it's cluttered, blah, blah, blah etc. etc. and so on and so forth. It just isn't a good enough reason, and my definition of a real desktop is the fact that it has common technological underpinnings and APIs that bind it and its applications together. GTK and Gnome just don't have any of that, so good luck trying to reproduce Amarok or K3B ;-).

I can remember one or two discussion's on OpenSuse's Bugzilla regarding Task Juggler. Despite it being an absolutely top notch piece of project management software, and the best around, the Gnome developers were absolutely steadfast about making sure that no KDE or Qt dependencies were present anywhere when Gnome was selected as a desktop. This is despite the fact that GTK and many Gnome dependencies are still installed when using KDE - and no one cares - and they could quite easily use QtGTK to expand Gnome support. No one is interested on the Gnome side in QtGTK.

I really don't care about using GTK applications within KDE, and things like QtGTK make sure they're integrated quite well. The only reason you'd want to push ahead with a vector graphics application written with Qt and KDE is if there was really some fundamental advantage in using Qt and the KDE infrastructure. This has happened with Krita, but do I really believe that someone should write a new front-end for the VMware console, written in Qt for KDE? Get out of here.

In essence, they wanted to cut people off from using a perfectly excellent and well featured project management tool when someone selected a Gnome install just because of some dependencies they didn't like. I just don't understand that kind of thinking, because it isn't good for anyone's perception of the quality of a free desktop.

(I repeat: technically KDE apps are many years ahead.. Usability and aesthetics wise, early 90s. Thus, it is good to recreate them properly.)

Sorry, but an awful lot of people just really want that to be the case - because they have no other excuses left. Many user interfaces in many of KDE's applications need a bit care and attention, but the situation is just nowhere near as bad as many people desperately want to claim. It's just a ludicrously bad idea to creat more work for yourself as well. As KDE goes through it's version 4 development cycle and point releases, KDE's HIG is fleshed out, KDE's applications start to adhere to it and more UI discussion happens, I really do wonder what on Earth people will come up with next.

Fred Morcos said...

Hi Aaron,

I guess what you shouldn't be understanding is KWin copy-cating Compiz, Metacity and Beryl compositing effects. Please, consider _your_ (as in KDE) problems before considering what other people are doing wrong.

On another note, Amarok is great and I am big fan of what it brought to the world of "music library management". But the reason I don't use it is that it depends on Qt and KDE libraries, which I don't actually use and don't want to build - on my slow laptop - everytime a revision update is released (using Gentoo Linux). So Exaile is a perfect replacement for me.

I couldn't agree more with the "shared backends" part. I have been bragging about it for years now and it would be a great concept for faster evolution of FOS Software.

As an ending, a couple of weeks ago I have read about Phonon not splitting into an "engine/backend" part and a "GUI/frontend" part, both will be one into a single application (making it irrelevant to text-based programs and thus, text-based users). Too bad, Gnome could have used it as a backend (without being forced to depend on QT) - thus fulfilling the goal of "sharing" code (and Gnome's "personal" goals). So please, again, fix your problems first and then you can start looking at what other people are doing wrong.

Thank You,
Fred.

Aaron J. Seigo said...

@fred morcos: "I guess what you shouldn't be understanding is KWin copy-cating Compiz, Metacity and Beryl compositing effects."

this was an issue long discussed. compositing features are needed, the question is how to get them into kde.

well, compiz/beryl are not production quality window managers. it takes years to get all the odd corner cases and things like focus stealing prevention just right. that is the hard, onerous part of writing a window manager.

adding the composition management is quicker to get right, particularly when so much work has already gone into the X layers thanks to work such as compiz.

having a window manager "in house" also gives us the ability to do proper integration and consistency fixes with the rest of the desktop environment.

as i said in my blog entry here, there are times when some duplication is inevitable or even "desirable" all things considered. this is one of those times.

btw, metacity is doing exactly the same thing for pretty much exactly the same reasons.

Aaron J. Seigo said...

@paul, some more:
"using Gentoo Linux"

so, to support a processor intensive way of packaging an os that honestly quite few people use, the open source desktop projects should go around duplicating our work? that's a really poor reason.

my suggestion: use an os that doesn't require building source, or get a faster computer.

both have far less impact on the environment that expecting us to clone each app for each toolkit.

"Phonon not splitting into an "engine/backend" part and a "GUI/frontend" part, both will be one into a single application (making it irrelevant to text-based programs and thus, text-based users). Too bad, Gnome could have used it as a backend (without being forced to depend on QT) "

this change has no impact on phonon's usefulness outside of kde. phonon core happens to use Qt extensively.

phonon itself is simply a way for kde to use the common media backends on the platforms kde supports, e.g. gstreamer where it appears.

which all sort of renders your point here moot.

"So please, again, fix your problems first and then you can start looking at what other people are doing wrong."

what do you think we've been doing for the last several years in kde? hm? we've purposefully and carefully been working very hard on the NIH syndrome, the working-together-with-others skill set and the "judge on technical merit" thing.

we have huge amounts of solid examples of efforts to show for this. and i've already listed some of them.

but then .. you didn't even look at what is in phonon core before judging that, either....

Aaron J. Seigo said...

er, that above should be @fred. no idea where i got 'paul' from =)

Fred Morcos said...

I can understand KWin now and I agree that Metacity is basically doing the same thing. But no one in the Gnome community has ever whined about how much KWin or Metacity were duplicating work.

"so, to support a processor intensive way of packaging an os that honestly quite few people use, the open source desktop projects should go around duplicating our work? that's a really poor reason."

Exaile falls into the place of a perfect solution to my problem. I like having my libraries consistent and minimal (that's why I use Gentoo Linux, mind you) and I wouldn't like building two huge libraries (QT and Kde-libs) for a medium sized application. Would You?

I agree I haven't looked deeply into Phonon, just followed it roughly through planet.kde and techbase.kde. But why would a backend (if it was to become one, purely) use QT? Maybe you meant QT-Core? Or the OO features of QT, maybe?

I would have loved it at first sight if it wasn't based on QT (just the backend), then maybe have intermediate libraries that would use it to implement their toolkit-specific features (Glib vs. QT-Core) then on top the user-interfaces (Gtk vs. QT). Other desktops would have benefited a lot from this.

Anyways, I apologize for the misunderstandings I had.

Thank You.