JUL
10
2007

KDE Commit-Digest for 8th July 2007

In this week's KDE Commit-Digest: Akademy 2007 draws to a close. Dolphin embedded as the file management view in Konqueror. Plasma continues to mature, with new data engines for Tasks and Bluetooth, and EBN and Task Manager Plasmoids making an introduction. Further progress in Javascript bindings through QtScript; import of Kimono (C#) classes. More basic functionality added to Kollagame, a game development IDE. Initial work in the KWin/Xinerama and 2d Projection for Marble Summer of Code projects, with continued progress in the Icon Cache, KOrganizer Theming, KRDC and Music Notation projects. KListView gets support for keyboard navigation, and a new, more descriptive name: KCategorizedView. KIconCache renamed to KPixmapCache to reflect its wider benefits to graphics across KDE. Paint mixing improvements and general speed optimisations in Krita. KMail and Mailody now share account identities. Support for more digital camera models in Digikam libraries, with the porting of many image plugins to KDE 4. More interface and collection management work towards Amarok 2. More effects for kwin_composite. Decibel is moved to playground/pim. system:/ and home:/ KIOSlaves removed, with preparations to remove media:/ in the near future.

Comments

"system:/ and home:/ KIOSlaves removed, with preparations to remove media:/ in the near future."

If those kioslaves are going away whats being added to replace them? I always found media to be really useful (quick and easy access to the USB devices or my CD I just put in... I guess I could use /media but that doesn't have the option to eject or set the special properties and the like which I found very useful).

On a side note Kollagame looks very nice, theres quite a lack of simple and easy to use game engines available in the open source world. Hopefully the scripting language(s) used are relatively simple and easy to use.


By Sutoka at Tue, 2007/07/10 - 5:00am

I have no problem with getting rid of home:/, but why the other two? I dont use system too often, but I still like it. Hopefully you can replace it with sysinfo instead, which is probably more useful and looks cooler.

As for media, unless it is being replaced by solid:/ or something like that, i would really not like to see it go. I use it often and it does a lot of things that you cant do by just going into /media.


By DR at Tue, 2007/07/10 - 5:00am

Afaik, Kubuntu has patches which allow you to use /media with all features media:// had - so that might be the reason why they remove it ;-)


By superstoned at Tue, 2007/07/10 - 5:00am

And KDE was already quite adept at handling mounting and unmounting of removable media back in the KDE2 days. So media:// did not really solve any problems, it just introduced a different way to do it. Besides it was mostly different Linux distributions ways of doing automounting that caused the problems for the old way of handling it. With the introduction of HAL those issues has been mostly resolved.


By Morty at Tue, 2007/07/10 - 5:00am

Yes... and we're having some problems about those now... we're still waiting for the lead maintainer of that patch to get back to us, but as far as I can see, the /media change has brought its own share of problems, perhaps more than the problems it tried to solve.


By Juan Carlos Torres at Tue, 2007/07/10 - 5:00am

"system:/ and home:/ KIOSlaves removed, with preparations to remove media:/ in the near future."

Finally, not a day to soon. They where supposed to bring some kind of usability improvement, which clearly they didn't. So it's good they get removed. Unfortunately it does not bring back all those wasted hours fixing bugs they caused.

"If those kioslaves are going away whats being added to replace them?"

Nothing would be the best option IMHO, since they reimplement existing functionality already present in the filesystem.


By Morty at Tue, 2007/07/10 - 5:00am

> They where supposed to bring some kind of usability improvement, which clearly they didn't.

Mostly wrong. For me they work far better than any other solution.


By Chaoswind at Tue, 2007/07/10 - 5:00am

> Mostly wrong. For me they work

Me != 90% of the users. Saying it "works for me" doesn't prove the argument 'wrong'.

The problems with media://
* IO slaves can't be nested, so with media:// it's impossible to browse a ZIP archive at a CD-rom.
* Applications which only knew UNIX filepaths (e.g. The Gimp) can't access files on media://
* Applications can't recognize /media/xyz and media://xyz point to the same file.
* KDE applications which weren't patched for media:// thought they were network paths, and limited abilities to browse/play the files, or copied them to a local folder first.

These are all problems that /media doesn't have, because it's just a UNIX path!! Using media:// is IMHO the wrong solution for the problem:
* I can imagine you're using media:// to hide the other UNIX root folders (dev, etc, usr, ..). I've seen patches somewhere where Konqueror only showed /home and /media. Mac OS X does something similar. This offered real usability improvements to users.
* I can imagine you're using media:// to have some mounting shortcuts in the context menu. These can be added to normal /media too. In fact Konqueror already recognizes SMB folders to treat them as special.

Bottom line: media:// introduces more problems then it solves, and the stuff it solves can be implemented in a better way.


By Diederik van de... at Tue, 2007/07/10 - 5:00am

> Me != 90% of the users.

That's unimportant, for this.

> * IO slaves can't be nested, so with media:// it's impossible
> to browse a ZIP archive at a CD-rom.

Is'nt there coming support for nestet slaves with strigi?

Besides, /media exists.

> Applications which only knew UNIX filepaths (e.g. The Gimp)
> can't access files on media://

/media exists.

> Applications can't recognize /media/xyz and media://xyz point
> to the same file.

Why should?

> I can imagine you're using media:// to hide the other UNIX root folders

No.


By Chaoswind at Tue, 2007/07/10 - 5:00am

> > Applications which only knew UNIX filepaths (e.g. The Gimp)
> > can't access files on media://

> /media exists.

Please, don't be so freak. If a common user is browising him documents stored in a CD (so KDE opened a konqueror in media://cdrom) and there is a image, ths common user CAN'T open it with Gimp. Should he write /media/cdrom in Konqueror URL? do you really think so? so you know what usability is? do you imagine common users knowing which apps can work over kisolaves and which ones no?

> > Applications can't recognize /media/xyz and media://xyz point
> > to the same file.

> Why should?

Because they are in fact THE SAME ??? please...

Please, give reasons of why is convenient to use media:// kioslave instead of be opposite to any good ghange.


By Iñaki Baz at Tue, 2007/07/10 - 5:00am

> If a common user is browising him documents stored in a CD (so KDE opened a
> konqueror in media://cdrom) and there is a image, ths common user CAN'T open it > with Gimp

Unter Kubuntu, this works. The URL is then rewriten to /media.

> Because they are in fact THE SAME ??? please...

Does'nt answer the question.

> Please, give reasons of why is convenient to use media:// kioslave

media:// supports audio-cd://
media:// shows any existing drive, regardless whether they are mountet or not.
media:// is a kio-slave, not a tool anywhere in in kicker.


By Chaoswind at Tue, 2007/07/10 - 5:00am

> Under Kubuntu, this works. The URL is then rewriten to /media.

Yes, I use Kubuntu. Now it works but in earlier version it didn't.

> > Because they are in fact THE SAME ??? please...

> Does'nt answer the question.

No? what do you need? /media/cdrom/file and media:/cdrom/file are exactly the same file. How do you say they aren't?


By Iñaki Baz at Tue, 2007/07/10 - 5:00am

I want a clear answer, why it should bother me, that an application can't understand that media://* and /media/* point to the same file. I had never a problem with tha, nor can i imagine a real situation, where this could become a problem.


By Chaoswind at Tue, 2007/07/10 - 5:00am

The question is: give us a reason why there should be two DIFFERENT ways to reach the same path, one of which it isnt precisely posix-compatible (media:/)


By Vide at Tue, 2007/07/10 - 5:00am

because media:// is easier??? if there will be no substitution, I dunno where to look if I want to mount a disk, sorry. Or do I need to go back to the console for that?

Are system:/ and remote:/ gonna go as well? what about trash:/? Sorry, but I use all those, and a lot - I'd miss them. And I'm very well at home at the commandline. These KIOslaves can't be missed by average users, as they don't know any other way to do the things these slaves did.

If there will be no alternative, I think it's very bad to remove them. /media can't be used, I don't see my dvd drive there, and I can't rename media, nor mount and unmount them. There are folders there for drives which aren't connected at all, etcetera... So we'll at least need the Kubuntu patches for /media (but apparently those have problems as well) or keep media://


By superstoned at Wed, 2007/07/11 - 5:00am

YOU DON'T NEED MEDIA:/. Fullstop.
You need a place where you can find all the devices you have in your system (not only discs), which is a bridge to /media/cdrom0 if you've inserted a data cdrom, which is a bridge to audio:/ or kaudiocdcreator (or whatever) if you've inserted and audio-cd and so on. But you don't need to have another layer which is not only "KDE only", it's "compatible KDE apps only".


By Vide at Wed, 2007/07/11 - 5:00am

No, I don't need media:/, I agree, we need something else which offers the same functionality. Which doesn't exist, and media:/ does, so I'd rather keep it...

kind'a not-so-smart argument you got there.


By jospoortvliet-f... at Wed, 2007/07/11 - 5:00am

Well, just be a little more patient, man! :)
You know all the pillars are there, it will be a few hours/days hacking to get the thing we all need. I trust in KDE devs :)
(an d man, it was the same Kevin who created the media:/ slave that deleted it, so I think there are good reasons behind it)


By Vide at Thu, 2007/07/12 - 5:00am

Reasons were given. And don't bug a user of an envirmonet, based on extrem usage of virtual filesystems, with posix-nonsens.


By Chaoswind at Wed, 2007/07/11 - 5:00am

"media:// supports audio-cd://
media:// shows any existing drive, regardless whether they are mountet or not."

These are probably two of the best examples, which the Kubuntu patch doesn't do anything about AFAIK. audiocd:/ kio-slave is one of the killer kio-slaves, but without media:/ most people wouldn't find out about it, and it wouldn't show up in /media either.

And the argument that the Gimp can't open the file is pretty bad since the gimp wouldn't have less problems opening a file via fish, http, or smb. Saying that a feature should be removed because "a luser will be confused!!!" is a horrible argument which is the cause of the feature-hate that appears in the GNOME camp that so many KDE users have ran to KDE to seek refuge from.


By Sutoka at Tue, 2007/07/10 - 5:00am

I'm checking the behavior right now, and I guess, if currently (at least) Kubuntu's KDE is smart enough to realise the CD I just inserted is an audio CD (as it is, because offered opening KAudioCreator to me), it can just be smart enough to offer opening audiocd:/ instead of /media/cdrom0.

BTW, I always hated media:/ and specially home:/, so this is a welcomed change. I only used media:/ on Slackware because it had the "Unplug safely" option. system:/ on the other hand is handy sometimes and I guess is a kind of known starting point for Windows migrants.

Other ioslaves lying around are applications:/ and settings:/ While those are interesting I'm not sure if anybody (or anything) uses them, besides settings:/ is a nice way to access KPanel functionality in a Windows-like manner (Yet I prefer KPanel's tree, and BTW "System Preferences" sucks).

On the other hand, I miss (not because of being really useful, but because of the coolness factor) a packages:/ ioslave, allowing Mac-style drag&drop package management.


By Shulai at Wed, 2007/07/11 - 5:00am

KAudioCreator isn't close to as easy to use as audiocd:/.

/media does NOT solve the problem of mounting un-mounted file systems, or accessing redbook (i.e. audiocd) filesystems in an EASY manner. home:/ never really served a purpose (since you could get to any home directory already by typing ~USERNAME (and it would autocomplete for you!)).

So really, whats the solution to mounting filesystems that aren't mounted? How do you remount a file system if you unmount it (without removing the device/cd and then reinserting it)? To me nothing else provides the functionality in an easy to use manner that'd make removing media:/ a good idea (though I like the idea the person had to make it so media:/ was symlinks to the mounted directory when they're mounted, or to audiocd:/ for CDs, that seems like it'd fix the 'gimp won't work' problem to me).


By Sutoka at Wed, 2007/07/11 - 5:00am

I totally agree with you. I acknowledge the problems brought to the linux world by introducing abstractions like media:/, but currently media:/ offers functionality users are dependend upon and which is hard to get somewhere else. So we can't remove it without alternative, imho.


By jospoortvliet-f... at Wed, 2007/07/11 - 5:00am

I didn't said you should use KAudioKreator. audiocd:// is more Unixy indeed :-)

I said that I guess making KDE able to open audiocd:// instead of KAudioCreator is trivial (I even bet is just a service menu file), so it is no reason for keeping media:/ ioslave around.


By Shulai at Wed, 2007/07/11 - 5:00am

>Besides, /media exists.

Exactly, and by that you summed up the main reason why media:// should be removed. It was supposed to be a usability improvement, and it clearly shows it's not. And nobody ever gave any reasonable explanation why media://cdrom should be more usable than /media/cdrom.


By Morty at Tue, 2007/07/10 - 5:00am

> It was supposed to be a usability improvement, and it clearly shows it's not.

And that's nonsens. On Kubuntu, it clearly shows it is!

As long, as there is'nt an equal solution, the decision to remove media:// is only stupid. KDE is'nt GNOME. Who cares if only 5% used media://. Remove it as default-handler, but don't remove the code and bother people with personal problems. That's not kde'ish.


By Chaoswind at Tue, 2007/07/10 - 5:00am

You always can pick the code and mantain it yourself. IIRC KDE is modular enough to allow installing extra ioslaves on a default distro build (e.g. you don't have to compile your own KDE to keep using media, just the ioslave).


By Shulai at Wed, 2007/07/11 - 5:00am

And if the cdrom is an audio cd? It WONT show up in /media in that case!


By Sutoka at Tue, 2007/07/10 - 5:00am

My dvd drive doesn't show up either, and my harddisks can't be renamed. media:// simply has usable features ppl need, which /media can't fully provide. Fix that first, before removing a usable feature.


By superstoned at Wed, 2007/07/11 - 5:00am

ehm... it has a unmount option?!? And besides, I don't SEE a /media/cdrom. The contents of /media here are just a few folders, named things like 'sdc1' and t1 and t2 and t3 etc. - pretty useless for an average folder. Media://, on the other hand, shows my harddisks (I've renamed them as well) and my DVD which I inserted. A rightmouseclick gives options to eject, mount, preview, open with... In /media a rightmouseclick gives the same options all other folders give, which doesn't make sense.

media:// is even for me, and I'm pretty unix-adepty, very important.


By superstoned at Wed, 2007/07/11 - 5:00am

>The problems with media://
> * IO slaves can't be nested, so with media:// it's impossible to browse a ZIP archive at a CD-rom.

What's bad with symlinking? this is just because when you click a device in media:// you'll find yourself at media://device instead than at the real path.

* Applications which only knew UNIX filepaths (e.g. The Gimp) can't access files on media://

Oh well, since when the technological advancement should be blocked by
prehistoric age software (and gimp-core is, GEGL is programmed since year 2k
and still isn't there....)

* Applications can't recognize /media/xyz and media://xyz point to the same file.

Look above, the easy solution is for media:// to be only a collector of
symlink (a la kio-sysinfo) : anything converted in the real path when clicked.

* KDE applications which weren't patched for media:// thought they were network paths, and limited abilities to browse/play the files, or copied them to a local folder first.

Still read first answer. Having all the storage periphals in the same place
was something really usable and comfortable, one of the pro of kde against
it's main competitor...

PS: I never used any stupid patch to hide anything, just /media isn't enough:
for example it doesn't detect at all removable drives, resulting in a single
fixed folder (with uncomfortable name) which may be empty exactly as /mnt...


By mat at Tue, 2007/07/10 - 5:00am

[My keyboard's somewhat broken so sorry if I missed a few letters now and then]

"I've seen patches somewhere where Konqueror only showed /home and /media. Mac OS X does something similar. This offered real usability improvements to users"

Hiding expected functionality is never a usability improvement. If something's right there, then show it; not doing so is a solid indicator that the implementor is suffering from Microsoft Brain Damage. MBD is a serious and contagious disease which has destroyed my ability to use software such as Windows and Gnome without becoming terminally frustrated at its confusing illogic, and unfortunately its effects appear to be manifesting bit-by-bit in Kubuntu.

Hell, even my mother (who usually doesn't care about computers and tends not to feel emotions related to them at all) was somewhat angry to discover the amount of files and file information (like the extension) hidden by Winows Explorer (can't remember what she was trying to do now).

Pervasive hiding of useful, relevant, and important information destroys discoverability, hence preventing any user from learning more than whatever subset of things they already know, and it frustrates experienced users by pulling the rug from under their feet *again* in the name of paying lip-service to usability, when real usability improvements are few and far between (eg. I can't, off the top of my head, think of any Kubuntu changes to KDE which made it easier to use, but I can think of several which made it harder, by removing features or making the user jump through hoops to use them).

I think from now on my motto is going to be "Usability through Obscurity: Just Say NO!"


By Waywocket at Tue, 2007/07/10 - 5:00am

What're you talking about? No one is hiding useful, relevant, or important information here. If you had a konqueror view right now that showed only /media and /home/user it would be very useful (just like the home view right now), because that's where you (probably) are spending 99% of your time. If you want to see the whole filesystem, then click the root view. Nothing is being hidden.


By Leo S at Tue, 2007/07/10 - 5:00am

Are you using Kubuntu? In Kubuntu's version of Konqueror, most of the entries under / are hidden and I don't know how to disable that behaviour (I don't know what you mean by 'root view', sorry). If you want to go to one of the hidden directories, you just have to know it's there so you can type it into the address bar.
That said, if anybody *can* tell me how to disable this, I'd be grateful.


By Waywocket at Tue, 2007/07/10 - 5:00am

sudo rm /.hidden


By Cyrille Berger at Tue, 2007/07/10 - 5:00am

Ah, thanks a lot.


By Waywocket at Tue, 2007/07/10 - 5:00am

I think that "show hidden files" is even quicker ;) (AFAIK it should do the job)


By Vide at Tue, 2007/07/10 - 5:00am

It's stupid anyway. And confusing. The expected meaning for "hidden files" is "dot-files", and that is what vanilla Konqueror (file:/) shows when you check the option.


By Shulai at Wed, 2007/07/11 - 5:00am

Iff you are a unix-weenie, then the expected meaning is "dot-files". The rest of humanity doesn't carry that expectation after all. I'm not convinced that a distribution like Kubuntu should be targeting unix-weenies. The hardcore users are already well catered for by things like the *BSDs, Slackware etc.

--
Simon


By Simon Edwards at Wed, 2007/07/11 - 5:00am

Because you're a geek. So, since you have more computer knowledge than the rest of people, just add this tiny little piece of knowledge to your KB.

I hope .hidden is going to be some kind of "standard" (at least a freedesktop draft) because it's the best way to handle this.


By Vide at Wed, 2007/07/11 - 5:00am

Oh, sorry. I remembered incorrectly how it worked on Kubuntu. I thought that the "home" view only showed media and home, not the root view. Indeed, hiding directories in the root view is a mistake like you say.


By Leo S at Wed, 2007/07/11 - 5:00am

They added that patch for one release, and immediately removed it after the release as everybody complained.


By superstoned at Wed, 2007/07/11 - 5:00am

Oh, yes, the best for the usability is the bare console without KDE, right?


By mat at Tue, 2007/07/10 - 5:00am

For some tasks, it actually is, yes. For others it isn't, of course.


By Andre at Tue, 2007/07/10 - 5:00am

Romeving media:/ is BAD.
I use it a lot, and just going to /media ISN'T nearly as easy and usefull. :(


By Iuri Fiedoruk at Wed, 2007/07/11 - 5:00am

It seems to be a new trend of commit-digest saying "what is being removed" without telling "What will be the alternative of the removed feature!" causing much hue and cry of kde users ;)

I presume that KDE4 will get a "My Computer" like interface/place where things are automagically (using dbus+hal+solid) and seemlessly accessible/mounted/unmounted.


By Asif Ali Rizwaan at Tue, 2007/07/10 - 5:00am

> It seems to be a new trend of commit-digest saying "what is being removed"

The commit digest just reports what developers write in the messages attached to their code changes. They are primarily written for other developers to read so that they can follow changes in the code base. They are also written in the context of various mailing list and IRC discussions going on, so they might not make complete sense without them.

The commit digest doesn't show every commit either, that would make it very long and probably very boring. Somewhere along the way there seems to be a juiciness filter which extracts the most interesting commits.

The price you pay for getting this bleeding-edge news is that it isn't checked, reviewed and polished like a full press release.


By Robert Knight at Tue, 2007/07/10 - 5:00am

That juiciness filter is DANNY. Danny goes through more than 3500 commit messages each week, and filters out those 100 interesting ones. He spends many hours on this, each and every week again...


By superstoned at Wed, 2007/07/11 - 5:00am

Danny is my hero!


By Oscar at Wed, 2007/07/11 - 5:00am

and that's deserved. I've seen him do it, at aKademy. And he does a lot more, like the interviews, artwork etcetera... That guy really is a machine, you know. He goes on and on and on...


By jospoortvliet-f... at Wed, 2007/07/11 - 5:00am

Pages