OSNews.com: The Big freedesktop.org Interview

Tuesday, 25 November 2003 | Numanee

Waldo Bastian talks about KDE's involvement in freedesktop.org as part of a larger interview with several major players of the interoperability and common infrastructure movement. Waldo knocks down certain myths and covers everything from accessibility to the DC OP-inspired D-BUS.

Comments:

D-BUS and DCOP? - Tom - 2003-11-25

Waldo's comments suggest that by KDE4 we will see the KDE Project making a committment to migrate from DCOP to D-BUS. Is this policy, or his opinion? From what I have read of the two technologies, and largely based on the integration opportunities, I think this sounds like a good idea, but I know it has been a topic of some controversy since it was first raised.

Yeah, but - Alex - 2003-11-25

It's true he does say that it would be a good idea to switch to D-BUS by KDE 4, however he is one of the few KDE developers who endorses such a move. Don't be suprised if this doesen't happen. D-BUS is nice, but how is it really better than DCOP and why should KDE switch to D-BUS instead of the rest switching to DCOP? In addition, such a major change would definitely set KDE development back a few months while GNOME would be speeding ahead since they already use D-BUS. I am all for integration, but such a move, while a win for the Linux desktop it also seems like a big blow to the hard work that went into DCOP and in making DCOP work through out KDE. It also uses up precious time. BTW: I hope KDE 3.3 will have a release cycle no longer than 6 months since KDE 4 will need a lot of time, probably at least a year and a half.

Re: Yeah, but - standsolid - 2003-11-25

Is D-BUS based on DCOP? if so I'd hope a switch wouldn't be as radical as you are suggesting. Gnome has it's own DCOP-ish "cobra" so they will be just hard at work kitting together their already loosely knit applications anyway with this new framework. on the other hand, though we shouldn't worry about gnome innovationg faster than us, rather we work together with them. It'd be REALLY cool if DCOP didn't have mad-style KDE dependencies so gnomes could use it without hainvg to install KDE as well.

Re: Yeah, but - Rayiner H. - 2003-11-25

1) Yes, D-BUS is based on DCOP. Its actually very DCOP-ish, and was designed so it could replace DCOP. Its got the advantage that its desktop-agnostic, unlike DCOP. 2) GNOME uses CORBA, a major cross platform standard for IPC. Switching to DBUS would be even a bigger pain for them, because CORBA is *very* different from D-BUS, while DCOP isn't that different from DCOP.

Re: Yeah, but - panzi - 2003-11-25

So we could speak of D-BUS as a DE-intependent DCOP successor? Dose it deliver other improvements than this? I heared it's faster then CORBAS IPC, is it faster than DCOP? Or are there no other differences? (I konw, my questions are annoying. :) ) -panzi

Re: Yeah, but - Rayiner H. - 2003-11-25

Check out the D-BUS tutorial first: http://www.freedesktop.org/software/dbus/doc/dbus-tutorial.html Choice quote: "Semantics are similar to the existing DCOP system, allowing KDE to adopt it more easily." Overall, D-BUS is more elaborate and has more features than DCOP. Supposedly, Havoc has said that its actually harder for the GNOME people to adopt it, because its so similar to DCOP. Overall, I think D-BUS is a good thing, but whether it actually gets into KDE 4 is up to the KDE dvelopers. Its good that they are wary about this, though. KDE is clearly the better framework, at least in places like DCOP, KParts, KIO, and Qt, and I would really hate to see better technology get pushed aside in favor of easier to integrate technology.

Re: Yeah, but - Alex - 2003-11-25

Okay, I'm sporry, i guess I was misinformed. I thought D-BUS was set to be adopted by GNOME in the near future and had no idea that it was actually absed on DCOP and that it is better. In that case, i think adopting it for KDE 4 would be a GREAT idea and probably drive GNOME to adopt it and so our desktop unification woes would be mitigated.

Re: Yeah, but - Spy Hunter - 2003-11-25

D-BUS is better than DCOP because it has a chance to become a desktop-independent (and even GUI-independent) standard. As I understand it DCOP has dependencies on QT and X windows, while D-BUS does not, making it much more likely to be adopted as a standard. D-BUS would be good for the Linux desktop, and whatever is good for the Linux desktop is good for KDE. I doubt that it would take that much effort to switch over anyway, because D-BUS is supposed to be similar to DCOP.

FUD - anonymous - 2003-11-25

It won't change anything for KDE. Instead of DCOP using libice as the transport protocol, it can use D-BUS. DCOP will still be around it will just use D-BUS underneath. And yes, this is *exactly* what D-BUS was *designed* for. It's not GNOME-technology. Almost none of the GNOME apps use it in fact. GNOME uses CORBA.

Re: Yeah, but - Aaron J. Seigo - 2003-11-25

in addition to what others have mentioned, DBUS will allow marshalling w/out relying on Qt's idea of data ordering, which means it can be used by all sorts of apps. think about controlling apache via a DBUS control: fire up kdcop (kdbus? ;) and click on the "apache -> restart" item and voila, apache restarts. DBUS is also being designed with the idea that it can be used (and authenticated) over the network, something that's clumsy at best with DCOP... DBUS is really something of a more globally useful and flexible version of DCOP. since KDE is already centered around using DCOP and nothing else is, this transition should be easier for KDE than most others. the big thing for KDE will be providing a compat layer so that apps speaking DCOP (e.g. KDE2/KDE3 apps) will be able to talk to apps using DBUS. this should be doable with some work and if done completely should make the transition practically transparent. but that part of the puzzle is yet to even really be looked at AFAIK... IMO it basically boils down to the idea that we've learned a lot about how well DCOP works via it's use in KDE, as well as where it's weak. DBUS is attempting to address the weaknesses and create something that allows the rest of the world to take advantage of what we've learned as well... everyone will win in the end...

Re: Yeah, but - Sad Eagle - 2003-11-25

Ouch, if I hear it one more time, I'll scream. Qt's marshalling is trivial to reproduce. See dcopc, see the Qt source code, etc. (Yes, there is an issue of fixing a format revision. But it's addressable, it's in fact /trivial/ to address, compared to the 'translation layer' idea which may not be even doable, given very different effective type equivalence semantics, and DCOP's natural uses on untagged marshalling)

Re: Yeah, but - Sad Eagle - 2003-11-25

To be more specific, here is an example where DCOP and D-Bus semantics diverge on type equivalence, making fully transparent conversion impossible[1]. Is this construction useful? I am not sure, but it can provide fully transparent overloads in an arbitrary number of combinations (imagine a function that should take 3 of the Triangles below -- doing it like this lets you take any of them as 3 point). Is it a big hack? Perhaps. But "no one will use stuff like this" is often famous last words.. struct Triangle { QPoint p1, p2, p3; }; inline const char* dcopTypeName(const struct Triangle& triangle) { return "QPoint,QPoint,QPoint"; } inline QDataStream& operator<<(QDataStream& str, const Triangle& tri) { str<<tri.p1; str<<tri.p2; str<<tri.p3; } ... in some interface: class SomeIface: virtual public DCOPObject { K_DCOP k_dcop: virtual void fn1(QPoint p1, QPoint p2, QPoint p3) = 0; virtual void fn2(QPoint p1, QPoint p2, QPoint p3) = 0; virtual void fn3(QPoint p1, QPoint p2, QPoint p3) = 0; virtual void fn4(QPoint p1, QPoint p2, QPoint p3) = 0; virtual void fn5(QPoint p1, QPoint p2, QPoint p3) = 0; //... }; [1] The best I can think off is to provide a separate overload for << for some DBusStream class, or templating it. Note that "use foostream in place of QDataStream is not a solution since an application may use QDataStream for storage on disk, which absolutely should remain binary compatible

Re: Yeah, but - anonymous - 2003-11-25

Please be sure to bring up your concerns on the right freedesktop.org forums! They are very willing to fix issues with D-BUS, but if you don't tell them it will never happen.

Re: Yeah, but - Ian Reinhart Geiser - 2003-11-25

If its so trival why is dcopc so broken beyond repair to the point its disabled? Ill give you a hint, its not ;) DBUS may not fix the problem completely, but it will give us a common ground to speak on. That and its more code we dont need to maintain. Unless you are offering to maintain libice for us. The only pisser will be that the GNOMES are too attached to their CORBA to even consider something better. In the end I fear even if we use DBUS we will never see the interop that is promised.

Re: Yeah, but - Sad Eagle - 2003-11-25

dcopc is probably broken because no one has actually wanted to use it, and that probably happened because it was not promoted. People did not go around shouting from every tree how it's a solution to every problem in the world, how it's something revolutionary, and how KDE and Gnome would both be using it before developers have even heard of it. And look, I've written marshalling code dozens of times (quite a bit this week, in fact). At its most complicate it is just a bunch of bit shifts and masks, and some of the most boring and trivial code that's out there[1]. The only piece of Qt marshalling that's complicated is for QImage, which basically just sends a PNG over the wire --- but it's hardly critical, and any decent toolkit framework can load and save PNGs. And there is nothing particularly magic about writing out an integer as 4 bytes in a fixed-endian order, and a point as 2 such integers. And as to maintaining libICE: I wouldn't maintain it, but I would gladly maintain a proper implementation of the wire protocol; including writing it, which is probably at most about a week long excercise for the core protocol. (I can't comment on the authenication protocol plugins, since they are not specified in the core spec; however magic cookies can't be too hard). A flip question, however: would you maintain the current implementation of dbus (I certainly wouldn't)? Remember, maintainers don't stick with projects forever. [1] Although DBus and ICE both make it more 'fun' by introducing some gratious byte-swapping

Re: Yeah, but - AC - 2003-11-25

Yeah, but in the end DBUS is also just repeating what SOAP did in the last years. They re-invented their own serialization format (instead of XML or one of the binary XML formats for the performance-junkies), re-invented an interface description language (IDL vs WSDL/Xml Schema) and half-re-invented authentication mechanisms (as they are using SASL). In the future, if DBUS should become more popular and is used over the network, they will probably re-invent encryption mechanisms, maybe transaction and routing mechanisms and so on. Great plan. And they are also doomed to re-invent new IDLs for all applications that already have a SOAP-equivalent.

Re: Yeah, but - Aaron J. Seigo - 2003-11-26

no, it isn't just repeating what SOAP or XMLRPC has done. it doesn't use XML, which means its faster, simpler and lower overhead. it's primary use will be applications on the same machine running as the same user. you are right in that DCOP, DBUS, SOAP and XMPLRPC are remote procedure call schemes, but DCOP and DBUS are designed specifically with desktop use in mind. the tasks and needs there are rather different from (and in some ways a lot simpler than) web services. DCOP works very well with just a few outstanding issues, which hopefully DBUS will allow us to address. as for reinventing encryption and authentication: it would not only be more work to reinvent than use what already exist; it would also limit interop and be a pain in the patoot to verify it as being Correct compared to leveraging something that's already been through the usual cryptographic scrutiny. the direction you seem to be leaning towards (a high-overhead, complex, and overly-complete solution) is very similar to what drove people to try CORBA. both KDE and GNOME have attempted to use CORBA. but that real world usage revealed that a simple, lightweight, purpose-built mechanism beats the shinola out of hacking heavy, general purpose mechanisms for desktop IPC.

Re: Yeah, but - AC - 2003-11-26

1. I don't think that there is any significant performance difference if you are using a binary XML serialization. 2. SOAP is *not* limited to web services. That's just its marketing niche. SOAP is also used in embedded devices (like all UPnP devices) and on Windows for IPC. Another myth is that SOAP is limited to HTTP. Unlike XMLRPC it isnt. .Net allows other mechanisms like raw TCP for faster communication. 3. SOAP is not as complicated as CORBA, it is a really simple system. All you need are four XML tags. There are extensions on top of SOAP that are needed in some cases, but DBUS will have the same problem if it should ever do more than trivial messaging

Re: Yeah, but - buggy - 2003-11-26

1. Binary XML is just for faster over-the-wire transfer. At the other end XML still needs to be parsed which is very costly compared to DBUS/DCOP marshalling. 2. Yes, but it was primarily design with web services in mind. SOAP had specific design goals, features and limitations. Don't try to use it for something it was not meant to do (inter-desktop communication) even thought it is the standard in IT'S domain (web services). Don't try to use a horse for travelling the sea!

Re: Yeah, but - AC - 2003-11-28

SOAP can be used on Windows for IPC, but isn't generally. The normal Windows RPC mechanisms are COM, DCOM, and MSRPC. MS's RPC tends to use the DCE RPC NDR format for serializing the data, and is generally pretty complex. There are historic reasons for all of this, but it's not important right now. I would hope that D-Bus is sufficient that a SOAP connector could be developed, just as an XML-RPC connector was developed for DCOP. The problem with taking a standard and adding proprietary extensions to it that become required by your implementation is that it nullifies the advantage of using the standard in the first place. For KDE and Gnome, there's no marketing department that will trumpet the use of something like SOAP despite the fact it's dependant on those proprietary extensions, so there's no point in using it.

Re: Yeah, but - AC - 2003-11-28

>>The normal Windows RPC mechanisms are COM, DCOM, and MSRPC.<< For old applications. They are all deprecated in .Net and Longhorn. >>For KDE and Gnome, there's no marketing department that will trumpet the use of something like SOAP despite the fact it's dependant on those proprietary extensions, so there's no point in using it.<< I'd call DBUS proprietary as well. The protocol is published, but instead of using the standard that the W3C established a completely new protocol has been created. It's like re-creating HTML, no less.

Re: Yeah, but - Bernd Gehrmann - 2003-11-28

In .NET, the serialization format can be specified by implementing the System.Runtime.Remoting.Messaging.IRemotingFormatter interface. There are two already provided, BinaryFormatter and SoapFormatter. The former is preferred for high-performance needs, because the serialization and deserialization is much faster and the transferred data is more compact than for SOAP. Of course, the same argument applies to DBUS. For web services, different trade-offs are possible, because performance and interoperability considerations are radically different from IPC.

Re: Yeah, but - AC - 2003-11-28

But a) they still have the same interface, the serialization is transparent and b) today's Remoting will be deprecated in favour of Indigo / System.MessageBus.

Re: Yeah, but - Bernd Gehrmann - 2003-11-28

> a) they still have the same interface, the serialization is transparent And since it's transparent, the natural conclusion is that one should use the most efficient serialization, as doing otherwise does not give any advantage. > b) today's Remoting will be deprecated in favour of Indigo / System.MessageBus. Yeah, I'm sure they can continue throwing out new APIs in 2-year intervals for the next 20 years, no doubt.

Re: Yeah, but - Sean - 2004-04-18

SOAP is hardly simple; it is a classic example of "design-by-committee" at its worst, and consists entirely of bloat that is unneccessary in the problem space DBUS is addressing. I'd argue that the SOAP-Bloat is unneccessary in *any* problem space -- SOAP adds a lot of overhead without providing very much (if any) added value. Your "four tags" quadruple the size of most SOAP messages. I also disagree that DBUS will encounter the "same problem" of bloat that SOAP suffers from; I've been involved in a number of projects that used REST and simple XML messages /without/ SOAP wrappers and SOAP bloat. What the designers of SOAP forgot is that all of the magic happens in the WSDL, not in the RPC wrapper. If you absolutely feel the need to wrap your messages up in a bunch text, use XML-RPC. The specification is all of two pages (compared to the 20 pages of SOAP crap you have to wade through). DBUS seems to be fairly light, like DCOP, which is nice. Distrust overly complicated system! "When I'm asking simple questions, and getting simple answers, I'm talking to God." -- Einstein

simple questions - Rachel Kayhan - 2006-04-30

I want to use the Einstein quote "when I'm asking simple questions and getting simple answers, I'm talking to God" in a paper I'm writing for school, and I'd like to know more about where exactly this quote comes from. Any information on when and where Einstein said this? Response much appreciated.

Copy/Cut & Paste - David E - 2003-11-25

It's nice with what the freedesktop.org is trying to do. I just hope that somebody is trying to adress the very bad behavior of copy/cut & paste through all linux applications, even though it works most of the time in KDE it's a pain from other applications in my experience. I think that you should be able to use ctrl+c/x and then do ctrl+v through all applications... /David

Re: Copy/Cut & Paste - André Somers - 2003-11-25

If fact, just selecting should be enough (it is Unix after all, not Windows...). I have noticed that Konqueror/KHTML is about the worst application of all when it comes to copy/pasting. It hardly ever works, and most of the time it's faster to just re-type an URL than to try and copy/paste it. :-(

Re: Copy/Cut & Paste - The man they couldn't hang - 2003-11-25

So you have never used konqueror, of course you can copy/paste URL's. And you have that icon on the left of the URL sou you can delete the old URL and then click the central button and you have it or you can use the Knotes or you can ... About DBUS , there is a lot of really good apps from the other part of the universe : mozilla, openoffice, gabber, ... so it is a must a better integration just because kde is really the best but those wondefull apps from the dark side of the moon jai,jai, :-)

Re: Copy/Cut & Paste - Paul Eggleton - 2003-11-25

No, I'm afraid he's right. At least on my system, selecting some text in Konqueror (3.1.4) and then pressing Ctrl+C doesn't always copy properly. It's very irritating, but because the 3.2 release is so close I've put up with it.

Re: Copy/Cut & Paste - Spy Hunter - 2003-11-25

Have you filed a bug report? I believe most developers use middle-mouse-button copy/paste, so this bug could be overlooked for quite a while if you don't report it.

Re: Copy/Cut & Paste - Paul Eggleton - 2003-11-27

No, I haven't - I should have done earlier. However now is not really the time to be filing reports against 3.1.4.

Re: Copy/Cut & Paste - André Somers - 2003-11-25

Yes, I know you _can_. Konqueror is my main browser, I only switch to Mozilla if a site really doesn't work on Konqueror. However, I still frequently run into this problem that copy/pasting text from a webpage doesn't allways work. I see that on both my laptop and my desktop systems.

Re: Copy/Cut & Paste - c - 2003-11-25

ack. I'm sorrt, but he's right. I've been using nothing but konqueror for two years and copy/paste support is terrible (though I do love the "clear location bar" button dearly). I rely almost entirely on my mouse's middle button, because you never know what that last thing you actually managed to copy to the clipboard was.

Re: Copy/Cut & Paste - kinema - 2003-11-26

What I've never understood is why there seems to be two different clipboards. If I copy by selecting (classic X method) I can paste with the middle mouse button but if I copy or cut using ctrl-c or ctrl-x I have to paste using ctrl-v. Does KDE's Klipper copy to a differnt place then XFree86 does?

Re: Copy/Cut & Paste - Morty - 2003-11-26

It's all configurabel in Klipper. The default are different clippboards for X and ctrl- . Why I can't tell you, and I have never had any problems cutting and pasting :-)

Re: Copy/Cut & Paste - Spy Hunter - 2003-11-28

The clipboards are different because they are used in different ways. With a Windows-style clipboard, you can copy a URL with Ctrl-C, select all the text in the location bar, delete it with backspace, and Ctrl-V to paste the URL. If the clipboards are unified, selecting anything nukes the clipboard, so when you paste you just paste back what you selected. This was a very *very* common source of complaints in KDE 2. (Yes I know about the button to clear out the location bar, but some people are used to doing it the other way, and there are other situations where separate clipboards are useful).

Systray icons - Fred - 2003-11-25

Related question: when will kde programs start using the systray specifiation from freedesktop.org? It's rather frustrating that the systray icons of most GTK+ apps (like Gaim, Rhythmbox) also work fine in KDE, but most KDE's systray icons (kopete, k3b, printing icon) all appear in a seperate window in Gnome.

Re: Systray icons - L.Lunak - 2003-11-25

Given that there are KDE apps which don't use KSystemTray class directly, but use the low level API for systray (they were simply written before KSystemTray was created AFAIK), hardly before KDE4, as the low level API can't handle the way fd.o systray spec works. And given that there are certain plans to (quite radically) change the way KDE systray works (the underlying mechanism) to something better, maybe never. Just because some specification is posted at fd.o doesn't necessarily mean that everybody is suddenly going to use it. See for example the "extension to the ICCCM selections mechanism" (nobody uses that at the present time), or XDS (neither GNOME nor KDE use it, although there are some apps which use this one). Maybe these proposals will get into use eventually, maybe they'll silently die, maybe they'll be superseded by something better, who knows? That said, I think it shouldn't be that difficult to write a small utility that you'd run with GNOME, which would act like a proxy and make KDE apps appear like using fd.o systray spec to outside. So the answer to your 'when' could be 'when somebody writes this'. Maybe I'll give it a try.

Unified desktop - OI - 2003-11-25

So there is actually a move to unify the desktop on Linux. When all apps can integrate regardless of GUI toolkit used, then it won't matter which a developer chooses. Great.

Re: Unified desktop - AC - 2003-11-25

Great mess.

Expocity - Swoosh - 2003-11-25

Something for KDE to include? Or is there something similar available already? Seems that GNOME is getting ahead of KDE in several areas: integration, information managment etc. Well, it's maby time for me to also lend KDE a hand (or two). Where do I start? Comments anyone?

Re: Expocity - Morty - 2003-11-25

For something like Expocity I would for starters take a look at the advanced pager. My guess is there are some/lots of code to steal/reuse to get you started. Good luck!

Re: Expocity - Aaron J. Seigo - 2003-11-25

in which ways is GNOME ahead of KDE in integration and information management?

Re: Expocity - anonymous - 2003-11-25

Their web browser context menus have "View Document Source" in them? :-)

Re: Expocity - anon - 2003-11-25

Epiphany does? that's news to me =) You could easily make a KonqMenuPlugin to add said action, if you wanted to, and distribute it. =)

Re: Expocity - anonymous - 2003-11-25

> You could easily make a KonqMenuPlugin to add said action, if you wanted to, and distribute it. =) No offense, but that's the dumbest thing I've ever heard. =)

Re: Expocity - anon - 2003-11-25

> No offense, but that's the dumbest thing I've ever heard. =) I'm sure it would appear dumb to people who beleive viewing source is a feature appreciated by very many intermediate users =)

Re: Expocity - anonymous - 2003-11-25

Mozilla, Opera and IE think it's important enough. Is the KDE approach to make things annoying and to push users to other browsers? A context menu should let me do interesting things in the context. Easily. It's ridiculous that when I right click on an Image, I have to go to the "Image->" submenu to do anything with it!

Re: Expocity - anon - 2003-11-26

> A context menu should let me do interesting things in the context. Easily. It's ridiculous that when I right click on an Image, I have to go to the "Image->" submenu to do anything with it! This was fixed. > Is the KDE approach to make things annoying and to push users to other browsers? No, the KDE approach is to make it so that the largest amount of end users feel comfortable in KDE. This means that we should target intermediate users (not beginning OR advanced users). This allows beginning users to get a feel for the interface quickly and advance to the intermediate stage (because nobody wants to be a beginner for long). Eventually advanced users will appreciate things too. This is why view source doesn't belong in the context menus, and why it was a mistake re-adding it in. If you really want such advanced features, as I said, why not make a web developers plugin for konqueror?

Re: Expocity - anonymous - 2003-11-26

GNOME has already taken the approach of dumbing down the interface. KDE has to find a better way. KDE can be powerful, convenient and easy to use without being dumb. Aaron made the right choice. Anyone who says "implement a plugin" is very very wrong and there is not much to discuss if you honestly think that is a valid answer.

Re: Expocity - Micha - 2003-11-28

>No, the KDE approach is to make it so that the largest amount of end users feel comfortable in KDE. IE has view source in the context menu. Mozilla has it, and even "view selection source". I like to surf with Konquerer, but no "view source" in the context menu ist extremly annoing behavior. But it's up to the developers to lose market share to mozilla for such a stupid decision.

Re: Expocity - anon - 2003-11-28

> IE has view source in the context menu. > Mozilla has it, and even "view selection source". Yes, they do for historical reasons. > I like to surf with Konquerer, but no "view source" in the context menu ist extremly annoing behavior. If you use this feature, you're likely an advanced user in the scope of web browsing. What's next? Putting "Show DOM Tree" in the context menu? Oh yeah, lets put "Show JavaScript Debugger" in there also. These would be incredibly useful for web developers and advanced users as well. But should we optimize for them (the potential minority) or the majority who don't consider them an action they do everyday while using context menus (intermediate users, I'm NOT talking about Grandma, but Joe User who has been using Lindows for a few months) View source is a remenant of the early days of the web when all web users==web developers. It's time to grow up and be focused on end users. Hell, if we wanted to optimize for advanced users, we might as well put in show dom tree, since it is as useful in the modern scope of the web. Do any browsers put it in their context menus though? Nope, it historically has never been there.

Re: Expocity - anonymous - 2003-11-28

If you want a dumb interface, use GNOME. Don't destroy KDE for some mythical "end-users" niche group. You end up with a dumb KDE and your "end-user" using Mozilla anyway (with it's nice little View Source Document). You don't remove a function that has been in KDE for years and has come to be expected. That's crazy.

Re: Expocity - anon - 2003-11-28

> You don't remove a function that has been in KDE for years and has come to be expected Erm, who talked about removing a function? It'd still be there of course in menubars and via shortcut keys. > Don't destroy KDE for some mythical "end-users" niche group. heh. We aren't talking about a niche group, we are talking about intermediate users. We shouldn't optimize for newbies who won't use a context menu anyways, and we shouldn't optimize for advanced users, who often use keyboard shortcuts anyways. If you don't understand this, you have a lot to learn about 1). usability 2). why KDE was founded. KDE was founded to be easy to use for everybody, and ultimatey, that means making an interface that newbies can get accustomed to, intermediate users will be productive in, and advanced users will be comfortable in. ;>

Re: Expocity - anonymous - 2003-11-28

> Erm, who talked about removing a function? It'd still be there of course in menubars and via shortcut keys. I mean removing a function accessible via a sane interface like the context-menu. > heh. We aren't talking about a niche group, we are talking about intermediate users. I'm an intermediate user. I certainly don't write plugins to change my interface or use advanced keyboard shortcuts. I find it more "advanced" to use a smart context menu than to spend time implementing plugins or learning shortcuts that do different things in different applications. What you are doing is creating a niche group and looking down on them as if they are some dumb group who can use Mozilla with its View Document Source but are somehow incapacitated from using Konqueror. Do you see?

Re: Expocity - anon - 2003-11-28

> I'm an intermediate user. I really don't want to get an argument over pure semantics here, but are you sure than you are an intermediate user when it comes web browsing? After all, if you use View Source enough to warrant it to be in a context menu (where the MOST used items for an particular object lie), you surely can read html, javascript, css, and associated technologies. That surely sounds like a set of advanced features, does it not? > but are somehow incapacitated from using Konqueror. Do you see? Er, I never said anything about incapacitation. Please do not interpret "optimization" as such.

Re: Expocity - anonymous - 2003-11-28

HTML was designed so that the dumbest of us could read and write it. You'd be surprised at how many complete morons do that! It is true I admit that the Web is starting to be committee designed and standardized and now HTML is getting to be complicated but still the dumbest of us want to be able to use it. Think of me as that dumb kid maintaining his dumb homepage and stealing my code from other websites. I might be intermediate, but I'm not advanced. Now with a single strike you are satisfying dumb, intermediate and clever users.

Re: Expocity - jck - 2003-11-27

Well, it's not in the context menus, but you can just go to View --> Page Source, or hit "Ctrl-U" in Ephy to get the source. (visiting GNOME-er here - just thought I'd share. :)

Re: Expocity - je - 2003-11-28

Yup, view source was assigned a default ctrl-U when it was removed as part of KDE 3.2's context menu clean up. However, it was readded again recently*. * which I don't like- only advanced users and web developers will ever use it anyways in the mumble jumble code of the web that is the mix of html, javascript, arcane css, and buzzwords like "XHTML" and "stylesheets". Sure, it might have been fine in historical browsers, but it's time to move on from the historical unfriendliness of Mozilla and Netscape 2.0.

Re: Expocity - anonymous - 2003-11-28

Ctrl-U? It's really time to stop this attitude of butchering Emacs/Unix shortcuts. Practically every other Linux application (GNOME, Mozilla, OO, whatever...) support Emacs shortcuts properly by default, except KDE. It's time to stop the dumbing down of the Linux desktop. Power to the user!

Re: Expocity - anon - 2003-11-28

> Practically every other Linux application (GNOME, Mozilla, OO, whatever...) support Emacs shortcuts properly by default Really how? > It's time to stop the dumbing down of the Linux desktop. Power to the user! power to the user=good dumbing down=bad defaults optimized for intermediate users, rather than advanced users=good

Re: Expocity - anonymous - 2003-11-28

> Really how? I believe it is built into the toolkits by default. Even Qt supports proper Unix shortcuts by default but KDE overrides it. > defaults optimized for intermediate users, rather than advanced users=good defaults optimized for one niche group whatever you call them=BAD, BAD, BAD defaults optimized for everyone = Good

Re: Expocity - TX - 2004-02-01

"optimise for everyone" is almost an oxymoron. The only thing stopping it being one is the "for" in the middle.

Re: Expocity - Troy Unrau - 2003-11-25

Umm, so do we... Right Click, Open With->Text Editor I like our solution better, as it gives us options and choice -- such that we can just as easily open a webpage in kword (import html) as we can with kwrite. Now if only my kwrite build from HEAD would work for me one day on freebsd :P -- Obligatory self-promotion - visit my website at http://tblog.ath.cx/troy

Re: Expocity - anonymous - 2003-11-25

I only have "Open With..." which pops up a Window and requires you to type or click a hundred times more... That's another thing that's annoying and where KDE lacks in integration. Konqueror should inline text, images, flash, etc automatically instead of making you open separate programs!!

Re: Expocity - anon - 2003-11-25

> That's another thing that's annoying and where KDE lacks in integration. Konqueror should inline text, images, flash, etc automatically instead of making you open separate programs!! Umm.. it does embed pretty much everything that you tell it to embed.It handles text, images, and flash.

Re: Expocity - anonymous - 2003-11-25

In the default? When I try to open .swf here it prompts me for an application. Have you tried opening .swf?

Re: Expocity - Carewolf - 2003-11-25

Have you installed the flash-plugin? And let konqueror detect it? If you had you wouldnt have that problem. If you dont like that solution, you can install the native flash-plugin for konqueror from kdenonbeta, but it only works half of the time.

Re: Expocity - Rinse - 2003-11-25

Yup, just make sure the mime type is correct.

Re: Expocity - Aaron J. Seigo - 2003-11-26

we do have "View Document Soruce" in the context menu. i committed this to CVS last night, so you can all stop bitching about it now ;-P

Re: Expocity - Navindra Umanee - 2003-11-26

Yahooo! Konqueror rewls the world. :-)

Re: Expocity - Swoosh - 2003-11-26

It seems to me that GNOME is about to get ahead in a number of areas forinstant information managmanent. That was my point. If you forinstance look at Nat's work/ideas at www.nat.org dashboard, human readable language searches etc, etc Expocity is a rip-off from OS X Panther. But the other stuff seams like home brewed.

Re: Expocity - Aaron J. Seigo - 2003-11-26

dashboard is a lot like stuff i've seen in plan9 (at least i think it was plan9; it was a while back now). they called it "plumbing" though. nat's storage stuff is very WinFS-inspired. not that that makes them automatically wrong. there are other good reasons they aren't, even as concepts, ready for prime time (IMHO). but this probably isn't the thread for me to get all ranty about that... i will say that KDE isn't exactly standing still.

Re: Expocity - Navindra Umanee - 2003-11-26

FYI, Nat called dashboard a "short-lived" project implying that it was dead now.

DBUS is a load of arse - cbcbcb - 2003-11-26

I think KDE needs fewer components, not more. I don't want to have a load of daemons loaded at boot time (which dbus is in the default debian installation) nor do I want a load of daemons loaded just because I am logged in to my desktop environment. If I have an empty desktop, I want only the window manager the panel, and the background drawing app to be loaded. And they should be idle, not polling away consuming CPU time. I don't want a load of complex interacting systems which I don't understand, because it leads to bloat, security issues, and it makes the environment look different depending on whether you are using apps which support all this extra stuff, or ordinary command line tools. For example, having distinct kio_slave processes has made this bug possible: http://bugs.kde.org/show_bug.cgi?id=63088

Re: DBUS is a load of arse - rinse - 2003-11-26

>For example, having distinct kio_slave processes has made this bug possible: http://bugs.kde.org/show_bug.cgi?id=63088 OK, so it is a bad thing to open 3 connections to one ftp-server?

Re: DBUS is a load of arse - cbcbcb - 2003-11-26

Obviously yes. Public ftp servers can restrict the number of open connections and blacklist users who use too many, it doesn't work with round robin DNS, and it contradicts the user expectation which is that one FTP session in the app corresponds to one FTP connection to the server.

Re: DBUS is a load of arse - Rinse - 2003-11-26

Ok, but then kio is not to blame, Konqueror should contain an option to restrict the number of outgoing connections.

file it - Marcel Partap - 2003-12-12

give them a bug report...

Re: DBUS is a load of arse - AC - 2003-11-26

So the right way is to let the developer of each application reimplement the functionality that it has in common with other applications, because you don't like it when two applications share the code? Do you think it is safer when 20 apps use 20 different HTML implementations, so the attacker can chose which one of the 20 he wants to attack?

Re: DBUS is a load of arse - cbcbcb - 2003-11-26

I'm not complaining about code re-use, I'm complaining about having weird background daemons and excessive abstraction from the real system behaviour. Apps sharing the same HTML implementation is something KDE does the right way (app links with khtml). Sharing the http implementation is done the wrong way, and it goes wrong in bizarre ways. Eg, konqueror stops working; user kills and reload konqueror; still doesn't work; user uses ps and kills kio_slave; konqueror starts working. Also, a more tightly integrated http implementation would have made it easier to fix the stupid problems with view source causing a file to be re-downloaded, which were in KDE for about 2 years.

Re: DBUS is a load of arse - AC - 2003-11-26

Actually a less integrated and more centralized implementation would have prevented the re-downloading problem: the problem is that Konqueror and the text editor are two different applications. If they would use different HTTP stacks there is no chance that do not download it twice. Mozilla can only avoid it because it contains a text viewer. But if there would be a single process responsible for all downloads, instead of separate KIO slaves, it could easily coordinate the caches and make sure nothing is downloaded twice (and even avoid other problems, like two applications downloading the same file at the same time).

Re: DBUS is a load of arse - cbcbcb - 2003-11-26

That's bullshit. Web browsers on RISC OS have no trouble whatsoever doing this and the text editors don't even have http functionality. View source works either by the browser saving the file to disk and instructing the editor to load it, or by a (slightly strange) direct transfer protocol. The external slave mechanism needs direct communication between the browser and the cache to ensure that the slave knows exactly which objects are visible in the browser and need to be retained.

Re: DBUS is a load of arse - AC - 2003-11-26

I just tried, and my 3.1 Konqui saves the file to disk and then starts KWrite with that file. It has, however, other disadvantages: you get an ugly and useless file path in the editor. So you can not edit the HTML and then upload it, even if you have sufficient permissions.

Re: DBUS is a load of arse - Rinse - 2003-11-26

>Eg, konqueror stops working; user kills and reload konqueror; still doesn't work; user uses ps and kills kio_slave; konqueror starts working Ok, but this indicates that you do know how it works (you know which subprocesses should be killed as wel to get the program back online). About konqueror, I remember Netscape in 1998, which had similar problems (sometimes if netscape crashed (and it crashed a lot those days) I had to restart my computer to get Netscape back online.

Re: DBUS is a load of arse - kaaskop - 2003-11-26

>> I don't want a load of complex interacting systems which I don't understand Exactly, you don't understand the reason it's done. And you don't, but lots of people do want it.

Re: DBUS is a load of arse - cbcbcb - 2003-11-26

No. I don't understand how it works, so I can't assess the security risk. And I definately do not want a system daemon running all the time even if no applications are using it. The philosophy that users want is that something should happen if they instruct that it should happen, and nothing happens that they did not instruct. The fact that windows doesn't act like this is what makes people frustrated with it.

Re: DBUS is a load of arse - Birdy - 2003-11-26

But often messages are needed for functionality. For example when using hotplug-devices. Another example is kontact. Without dcop, kontact would end in a big bloatware.

Re: DBUS is a load of arse - AC - 2003-11-26

What's bad about a system daemon that's running when not used? When it's not used and doesnt do anything it takes a ridiculously small amount of physical RAM for the kernel entry in the process list and nothing more. In most cases the performance impact is positive, because the cost of keeping the process running (and swapping it out, in the worst case) is lower than restarting it.

Besides - Alex - 2003-11-26

Besides the fact that you would not even feel the difference and it allows applications to seamlessly integrate and talk to each other, D-BUS will most likely replace DCOP in some time.

Re: DBUS is a load of arse - Superstoned - 2003-11-26

quote: The fact that windows doesn't act like this is what makes people frustrated with it. well, I agree with this.. was the reason for me. KDE should restrict the amount of deamons as much as possible, imho.

Re: DBUS is a load of arse - AC - 2003-11-27

The problem in windows is not the architecture of the applications, but the lack of a good way of shutting them down without exposing users to the internal structure. Many programs use several processes, it's often a neccessary design if you want to avoid threads. The way to fix the problem is not to avoid using several processes (which are usually used for a reason, and not to annoy the user), but to create a higher level mechanism that knowns which processes belong together and shows them in a user-friendly way. Showing the name or path of the binary is a bad idea anyway, often there is not obvious connection between the icon that you clicked on your desktop and the binary path.

Standard Linux Software Installer - gururise - 2003-11-26

Okay, hear me out.. Windows has Installshield (and possibly a few other installers). But the point is, you can download one single installer, and install practically any application in Window's with ease! In linux, its an entirely different story. You've got Redhat 6.2 RPMS, Redhat 7.0 RPMS, Redhat 8 Rpms, Mandrake RPMS, Gentoo ebuilds... you get the point. Its a nightmare on linux to install software that does not have distro specific packages.... Unless you want to compile the sources (but thats not an answer for everyone). Can't the KDE and GNOME (w/the help of FD.org) agree on a standard packaging system for KDE/GNOME? This would give that system momentum and make it possibly a standard for linux. A possible solution would be AutoPackage (see autopackage.org). What do you all think?

Re: Standard Linux Software Installer - rinse - 2003-11-26

I'd say, read the interview about autopackage :)

Re: Standard Linux Software Installer - Anonymous - 2003-11-27

Havoc doesn't know anything about Autopackage.

Re: Standard Linux Software Installer - Anil Jagtap - 2005-03-11

Still, installing software on linux is a pain. Is there any reason why a standard software installer for linux doesnot exists?

Re: Standard Linux Software Installer - Roberto Alsina - 2005-03-12

No, there is no reason. It's just the inherent violence of the system.

Re: Standard Linux Software Installer - yglodt - 2007-08-07

Installing software in windows requires me the following steps: - find the website of the producer of the software - find the download link, optionally register - proceed to download - relog into windows as administrator - install the software, optionally reboot the OS Installing software on linux requires the following (current ubuntu, suse, fedora): - open the software installing tool by clicking on the menu - enter my own, or root's password, depending of the distro - find the software by typing it's name - click on install, and watch the tool resolving dependencies and install while I take a coffee Looks like the people complaining here are using linux distros that are 5 years old (even back then suse had the yast software installer)

Re: Standard Linux Software Installer - huru - 2003-11-27

InstallShield actually has java versíon which should work on Linux as well as on Windows. Never tried though, no idea how it works and naturally it doesn't integrate with native package management systems. Just thought to point it out :)

Re: Standard Linux Software Installer - AC - 2003-11-27

1. The Java version is for installing Java software 2. It sucks, it just a way to install software into a directory and find the location of some resources. It doesnt solve any of the real problemsor doesnt do anything that Loki's Setup doesnt do...

WE NEED THIS AMAZING PROJECT - Alex - 2003-11-27

Don't listen to havoc, he is clearly clueless as one of the Authors fo autopackage.org explains in the comments section. This project, once completed will be far better than any current solution today. Read the interview with AutoPackage.org's project leader: http://osnews.com/story.php?news_id=2307

Re: WE NEED THIS AMAZING PROJECT - Maynard - 2003-11-28

Havoc clearly said he is not an authority on autopackage. One concern I do have is how well it will play with rpm and deb. I think it is a very good solution for developer packaged apps which include all the libraries they need to run, and will like to be registered on the system. i.e., good for stuff like commercial apps. For things like distribution provided stuff, I do not see how it is better than the current systems. I would need to be educated more I guess.

Very well - Alex - 2003-11-28

Autopackage will attempt to use a package build specifically for the distro it is being installed on if available. SO for debian it will try to find a .deb for what is being installed and for SuSE a rpm so that the packages can be as integrated as possible.

Re: Standard Linux Software Installer - mike - 2004-08-26

Well if they want to compete with microsoft -- the big dogs they better come up with something as MOST of the windows users they want to capture as customers will ABSOULETLY NOT put up with comand lines and compiling ETC. They either make linux user friendly for the casual computer user as most of their market will be or the can give it up now as they will never be more than a novelty.

Re: Standard Linux Software Installer - sleepkreep - 2005-04-16

Completely agree Mike. I think that if linux ever stands a chance, the software for it need to become distro neutral. Autopackage has the potential to do this. Autopackage will evolve into very powerful software as they are planning to integrate it with alh all current ways of installing software (RPM,DEB,ETC.). Of course we have the gcc issues but I think that will work itself out eventually. Unfortunately developers have to change their software to support autopackage. This means that if autopackage stands a chance, developers have to start supporting it. But I think with the progress that autopackage is making, this will start to happen more and more. Of course, the way to really get autopackage in quick development, and get the supported app list to grow, is if KDE integrates it into the next release. This is an issue because autopackage isn't really ready yet. But personally I think this is OK because they promise backward compatibility. Of course this system also ensures that you will have the lastest software available. You won't have to wait for an RPM that is most likely a few versions old. Imagine having a front-end on your desktop that you can search a DB on kde-apps.org for software and install it just by clicking. This would be awesome! And it could monitor for newer versions for you!

Re: Standard Linux Software Installer - Daniel - 2006-08-26

A couple of additional possibilities for Linux installation: BitRock http://bitrock.com Also for Windows, OSX, etc. Loki Installer http://www.lokigames.com/development/setup.php3 For Linux and other Unix platforms.

Re: Standard Linux Software Installer - Tim P - 2007-03-14

I am a Linux Newbie and you guys are right . I am working to make the jump but I can not install the basic software to get started.As an ex windows moron I find this line item stuff a challange to quickly learn..

Re: Standard Linux Software Installer - zkascak - 2007-08-07

I am also relatively new to linux. I was raised on Windows, switched to Mac and now am making the move to Linux. The only drawback to a complete switch is the fact that I have had to compile any type of software I wanted. Why hasn't the group that determines what is included in the different kernel releases created a standardized system for software installation and just give it a name like linux installer. This is mostly just venting so ignore the entire reply.