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 DCOP-inspired D-BUS.
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.
>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.
> 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.
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.
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.
> 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. ;>
> 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?
> I'm an intermediate user.
> but are somehow incapacitated from using Konqueror. Do you see?
Er, I never said anything about incapacitation. Please do not interpret "optimization" as such.
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.
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. :)
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*.
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!
> Practically every other Linux application (GNOME, Mozilla, OO, whatever...) support Emacs shortcuts properly by default
> It's time to stop the dumbing down of the Linux desktop. Power to the user!
power to the user=good
defaults optimized for intermediate users, rather than advanced users=good
> 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
"optimise for everyone" is almost an oxymoron. The only thing stopping it being one is the "for" in the middle.
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
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!!
> 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.
In the default? When I try to open .swf here it prompts me for an application. Have you tried opening .swf?
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.
Yup, just make sure the mime type is correct.
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
Yahooo! Konqueror rewls the world. :-)
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.
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.
FYI, Nat called dashboard a "short-lived" project implying that it was dead now.
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
>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?
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.
Ok, but then kio is not to blame, Konqueror should contain an option to restrict the number of outgoing connections.
give them a bug report...
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?
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.
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).
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.
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.
>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.
>> 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.
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.
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.
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 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.
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.
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.
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?
I'd say, read the interview about autopackage :)
Havoc doesn't know anything about Autopackage.
Still, installing software on linux is a pain. Is there any reason why a standard software installer for linux doesnot exists?
No, there is no reason. It's just the inherent violence of the system.
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)
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 :)