OCT
26
2006

Kubuntu 6.10 Released

Kubuntu 6.10, codenamed Edgy Eft, is hot on the download mirrors, this release is based on the brand new KDE 3.5.5. For all your photo needs the award winning digiKam is now installed by default and renowned artwork by the beloved Oxygen artist Ken Wimer shines all over. On top of this Kubuntu makes the perfect platform for KDE 4 development and porting KDE 3 applications with all the KDE 4 development libraries available along with Qt 4.2.

Comments

What have they done with the K-Menu?
(http://kubuntu.org/images/edgydesktop.png )

-Where are the "most often used applications" (should be on top of "all applications") (This one is very useful!)
-Where is the incremental search bar? (This one is useful!)

Have they fixed Konqueror filemanager?

Selecting (in Icon mode) file_003.jpg, pressing shift, and selecting e.g. file_023.jpg does not select all files between file_003.jpg and file_023.jpg but only those inside the rectangle defined by file_003.jpg and file_023.jpg.


By Max at Thu, 2006/10/26 - 5:00am

> -Where are the "most often used applications" (should be on top of "all
> applications")
The "Most Often Used Applications" part of the menu only appears once you have used at least one application. If the screenshot is of a fresh install, no applications will show up there.

> -Where is the incremental search bar?
There is no such thing in KDE 3.5.5.


By Thiago Macieira at Thu, 2006/10/26 - 5:00am

"Recently used apps" can be turned. There was an incremental search bar???

Thanks go out to the great people on the Kubuntu team. It's been a pleasure to work with you guys (and gals). :-)

--
Simon


By Simon Edwards at Thu, 2006/10/26 - 5:00am

I like how tight and small that menu is. :)


By Ian Monroe at Thu, 2006/10/26 - 5:00am

"Where is the incremental search bar? (This one is useful!)"

Thats never been in the official KDE, the incremental search bar is provided by a patch developed by SuSE.


By Corbin at Thu, 2006/10/26 - 5:00am

Why is it still missing in official KDE 3.5.5? It is widely deployed and tested and a it improves usability of the K-Menu.

Or will KDE 3.5.6 feature Suse's new Kickoff Menu?


By Max at Thu, 2006/10/26 - 5:00am

Because it's debatable if the search bar really such a great improvement and couldn't be done better. Plus it's a fairly big change, so it has to be tested very thoroughly (also usability wise) to go in. As for Kickoff, it's not debateable for KDE 3.5.


By Daniel Molkentin at Thu, 2006/10/26 - 5:00am

> Because it's debatable if the search bar really such a great improvement

You have installed a new application. What do you do? Search all of your K-menu hierarchie? Is Google Picasa under Graphics/editor or Graphics/viewer or Graphics/photography or additional programs or...?

KDE does not support highlighting of newly installed program entries (as WinXP does). So a search bar is the only way to quickly find a random program.

> Plus it's a fairly big change, so it has to be tested very thoroughly (also
> usability wise) to go in.

If it's released with OpenSuse than it's tested and used by a wider audience than any other developer-only feature.

Look at Gnome, they are steadily improving. Keeping KDE always on the level of KDE 3.3 or 3.0 does not make things better. The K-menu was nice at KDE 3.4 times but now there are better alternatives. Waiting till everyone has switched to Gnome and then releasing KDE 4.0 won't make many people happy.

> As for Kickoff, it's not debateable for KDE 3.5.

KDE development seems to become more and more drooping. Where is all the innovation gone? If a new feature (like Kickoff) is better than the old one in 96% of all cases and slightly worse in the remaining 4% than it's "not debateable" to ship.

What about 3.5.6 beta? If Users don't like the new features, one can always revert (or improve!!!) some features. Amarok did the same as the users did not like the new layout.

KDE could be so much better by only taking the low hanging fruits.


By Max at Fri, 2006/10/27 - 5:00am

Eh? Have you followed the KDE project at all for the last year? Have you completely missed the fact that the developers are working hard on KDE4 which looks like it will bring an insane amount of cool new stuff to KDE?

It sure sounds like it...


By Joergen Ramskov at Fri, 2006/10/27 - 5:00am

Well, it's probably just under graphics. I personally love that their menu is uncluttered and simple. Some subcategories and that's it, not subcategories under subcategories. Kubuntu is the first distribution I met with a nice looking kde with not too many programs and not too many menus.


By Matthias Logghe at Fri, 2006/10/27 - 5:00am

Well, I personally don't like crippled and tiny menus like kbfx and kickoff. I need a menu with subcategories in subcategories so I can sort the entries as much as possible and am able to see the subcategories and the entries together. In kbfx you have to scroll a lot which is just horrible for me (not to mention its super tiny size), I need to have everything visible. And in kickoff (which imho looks much more usable than kbfx) you also have to scroll and you cannot look at the categories and the entries at the same time because the entries panel seems to slide of the categories (that's like the icon view mode in kcontrol, I'm feeling very uncomfortable with it). I hope KDE 4 will have a "classic" mode with the current kmenu style (which I like a lot) and a "normal" icon-sized button.


By JaKi at Sun, 2006/11/05 - 6:00am

KDE 3.x is currently in a "chilly" status. ie. It there isn't a complete feature freeze in effect, but there are strict conditions under which new features can be added to the KDE 3.5.x series.

The reason being that most exciting stuff is happening in the KDE 4 world.

Having said that, distributions are free to make their own modifications to the KDE 3.x series which others can then use. Suse 10.2 users will see a replacement for the K menu before KDE 4, and hopefully a few other distributions might make use of it as well.


By Robert Knight at Fri, 2006/10/27 - 5:00am

And besides k-menu and kickoff, there is also kbfx as menu replacement.


By AC at Sat, 2006/10/28 - 5:00am

and tasty menu... ;-)


By superstoned at Sat, 2006/10/28 - 5:00am

After using SuSE for a while, I found this feature to be very useful ever since I switched to Debian I miss this feature the most so...

Is it possible to apply this patch to other distros like Debian?


By btag at Mon, 2007/06/18 - 5:00am

I've been using Kubuntu Edgy for about a week, and I can say it's an impressive work. Very smooth distro :)

I did not like the Dapper release much, but this one feels a lot more polished. Thanks to Riddell, Imbrandon, Hobbsee, and all the others!


By Mark Kretschmann at Thu, 2006/10/26 - 5:00am

Agreed. The most useful thing for me is the patch to get rid of media:/ and replace it with /media.

Seriously, this should go into KDE itself. Accessing media files in KDE is completely crippled in a default install. Any non-kde app (and even some KDE apps) will choke on a media:/ URL. Kubuntu fixes this in a very nice way.


By Leo S at Thu, 2006/10/26 - 5:00am

Right. Also the system:/ kioslave conflicts even with the KDE trashcan on my machine. (Not to say anything about amarok/kaffeine/xine/konqueror/openoffice etc etc etc not understanding eachother because of media:/ system:/ home:/ etc). I wonder why these thing are there first of all. While I couldn't find a real use for them, I'm quite confident that some people out there do use them on purpose. But is that use worth breaking all the file system hierarchy standards and forcing all KDE and non-KDE apps to either find a way to cope with this or simply lose compatibility?


By Gato at Fri, 2006/10/27 - 5:00am

given the average user's difficulty with the unix filesystem, discussions of portability, etc and the gnashing of teeth about it a few years ago, i find these threads ironic.

trace backwards from where we are today with these urls and discover the reasons why they were added: what was the purpose, what was the motivation, etc.

i'm not overly happy with how it works right now, but the "run away! ioslaves!" meme is lacking in appreciation of the whole problem.


By Aaron J. Seigo at Fri, 2006/10/27 - 5:00am

>> given the average user's difficulty with the unix filesystem,

Not quite. Maybe the average user has difficulty with the cryptic names like /usr and /etc (I know I did) but I don't believe they have difficulty with /home or /media or similarly meaningful paths.

>> discussions of portability

Fair enough. I see that there is some attraction to presenting a consistent path across platforms. I think it is misguided though. Java tried the same thing with their UI and failed miserably. People don't care that a Java program works the same across platforms, they just notice that it works differently than the other programs on their platform.

>> i'm not overly happy with how it works right now, but the "run away! ioslaves!" meme is lacking in appreciation of the whole problem.

I don't fail to appreciate the problem. I'm saying that the solution is completely unusable for even the simplest use cases, and therefore is not a solution at all. As I have said many times, a very very common task is for a user to plug in a camera or usb thumb drive and open a file on it. If they are lucky, it will open in a KDE application that is aware of the media:/ URL and opens it correctly. If they are unlucky, which is often the case, the application will bring up an error, which will be completely incomprehensible to the user.

Kaffeine says something like "Cannot open remote files", and any non-kde app doesn't even have a chance at opening it.

This is not a little inconvenience for users, this is a huge showstopper that will prevent most users from using files on a removable storage device that isn't set up in /etc/fstab. These devices (any usb mass storage device) are becoming ubiquitous because they are so useful, but with a stock KDE it is incredibly hard to do anything useful with them.

I'm not saying ioslaves are bad. Ioslaves rock for resources that are not equivalent to a local path. fish:// if great, man:// is fine, settings:// is fine because they access resources that are otherwise not easily accessed and everything works inside them. media:/ and home:/ are bad, because they are just pointing at a local path on the filesystem, and they break applications which try to work with those files.


By Leo S at Fri, 2006/10/27 - 5:00am

Full ACK!


By Michael at Fri, 2006/10/27 - 5:00am

> given the average user's difficulty with the unix filesystem

I've set up Linux on my girlfriend's laptop (yes I know, big mistake, never give Linux to non-techies unless you're in for total maintenance). It took some minutes for her to get accustomed to the UNIX filesystem hierarchy - this means /home, for instance, not /etc or /usr. /etc and /usr are just intractable for non-techies and it really doesn't matter whether you expose them as real or imaginary filesystems.

While she can certainly browse and use the filesystem, she is defenselessly delivered to the abusive kioslaves. She cannot open the AudioCD icon on the desktop with Amarok because xine won't do audiocd:/ (fixed in the meanwhile by special efforts from Amarok). She must copy all MS Office documents that she touches somewhere in /home, just to make sure that OO.o will understand the URL. And she would possibly never have found this workaround on her own, because error messages are so obscure.

Virtual filesystems are great when they expose remote stuff or when they simplify APIs. But when they start obscuring the real (and working) filesystem from both the user _and_ applications, they simply become imaginary hindrances in the way of everything.

And if the UNIX filesystem hierarchy is bad, then by all means improve the standard, don't replace it with proprietary URLs.


By Gato at Fri, 2006/10/27 - 5:00am

Well the bottom line is that KDE isn't the level to handle such problems. Its a problem for likes of Kubuntu to solve.


By Ian Monroe at Fri, 2006/10/27 - 5:00am

So KDE should put in these ioslaves, and then each distro should patch them out again?


By Leo S at Fri, 2006/10/27 - 5:00am

media:/ works fine here in kubuntu edgy with konq and opening a file to kaffeine, kmplayer, or amarok. It's really the only way to easily access unmounted media since nothing would be in /media till it was mounted and nothing is automounted unless you tell it to be. You also have to add some entries to your pmount.allow so the non-removable media shows up.


By firephoto at Fri, 2006/10/27 - 5:00am

> media:/ works fine here in kubuntu edgy with konq and opening
> a file to kaffeine, kmplayer, or amarok

It's not media:/ that's working fine, it's kaffeine, kmplayer and amarok that are working fine again after having found ways to mediate between media:/ and their backends (instead of achieving real progress they needed to fix this). And if media:/ is working fine for you, then try to trash a file from system:/.

> It's really the only way to easily access unmounted media

It's really not the only way, you can tell kdesktop to show icons for unmounted media.

> since nothing would be in /media till it was mounted

Oh yes there would be something, the mountpoints, and konqueror/the file dialog could be smart and give them special treatment, such as device icons and a 'mount' action. Just like media:/, but without the proprietary URLs.


By Gato at Fri, 2006/10/27 - 5:00am

> Oh yes there would be something, the mountpoints, and konqueror/the file
> dialog could be smart and give them special treatment, such as device icons
> and a 'mount' action. Just like media:/, but without the proprietary URLs.

Edgy includes patches to add the extra options to the mountpoints in /media, BTW.

--
Simon


By Simon Edwards at Fri, 2006/10/27 - 5:00am

Great. That's really a wise move from Kubuntu.


By Gato at Fri, 2006/10/27 - 5:00am

Um, no. They shouldn't.


By Ian Monroe at Sat, 2006/10/28 - 5:00am

Well, then how do you propose they "fix" it? Kubuntu has done it by replacing media:/ with /media. Is there a better way?


By Leo S at Sat, 2006/10/28 - 5:00am

The ways to fix them is:
- report as bugs OR
- grab the source, find the problem and fix it, and send a patch.

Treating media://, system:// or home:// as local directories is not that big deal, most KDE applications should be easily fixable. Non-KDE applications are a different issue though and not easily solvable. Just think about fish:// protocol, as it is not known by OpenOffice.org, you cannot simply edit the file on the remote place (I think the KIO system it will download to a temporary directory though, but I didn't check it).


By Andras Mantia at Sat, 2006/10/28 - 5:00am

You are missing the point, or points actually. Fixing the problems those IO-slaves create is not the problem, the problem is that they create those kinds of bugs in the first place for no gain whatsoever. They where supposed to bring some kind of usability improvment, which clearly they don't.

Nobody can argue that media://cdrom or system:/media/cdrom gives any kind of increased usability, compared to /media/cdrom or /mnt/cdrom. It's even worse with home:// since it points to /home rather than the users home, so instead of ~/myfile you have to use home://username/myfile.

The only things those IOslaves give are a possibility for subtle bugs, and breaking compability with legacy applications. They should be removed from svn as fast as possible, and never talked about again other than as examples of horrible usability mistakes.

The other IOslaves, like fish:// as you mentioned, does not have any of this problems. They are quite different in the way they provide extra functionality, not redefining already existing ones. Since OpenOffice is not able to edit remote files anyway, fish:// does not change anything or introduce a bug. While home://username/myfile.odt does, since its actually ~/myfile.odt a simple local file witch should be editable.


By Morty at Sat, 2006/10/28 - 5:00am

Full ACK

I'm a huge fan of KDE's ioslaves except for media:/ which is driving me insane. Autodetection of removable devices is great and necessary, but the path which is given to applications should be /media. Everything else is simply broken.


By anonymous coward at Sat, 2006/10/28 - 5:00am

> Nobody can argue that media://cdrom or system:/media/cdrom gives any kind of increased usability, compared to /media/cdrom or /mnt/cdrom.

It's way too Linux-specific. I'm used to /vol/local/dvdX for local and /vol/pool/dvdrX for drives at the server. media://dvd is much more simplier and just works, no matter which station you log on. Ok, maybe non-KDE apps have probs with this, but they can't handle fish:// as well.

> It's even worse with home:// since it points to /home

Yep, as that's what it is supposed to do. For your own home theres ~. But after you typed /users/bkoffice/8/bentruth a dozend times you'll start loving home://bentruth.

And no, I'm not running KDE as root, just Kate via sudo.


By Andreas Jensen at Sat, 2006/10/28 - 5:00am

> It's way too Linux-specific.

As someone else already reminded, being the same on all platforms is not always good. Java has swing which looks the same on all platforms. Some developers love this, but the rest of the people either don't know about other platforms, or they're at no advantage anyway. They only notice that it doesn't look as it should on their platform. This is why SWT was introduced, and this why I don't know of any successful Swing app.

So really, what's the point that I could (mis-)use the same non-standard URL on other operating systems? My problem is that it's non-standard on my system.

BTW, I'm a FreeBSD user, not a Linux user, and I too have /media and /home.

> I'm used to /vol/local/dvdX for local and /vol/pool/dvdrX
> for drives at the server.

You represent a very small minority that uses many machines with many different operating systems with servers that do removable media on a regular basis (most servers really don't). This is unlikely KDE's main target, and thus it's not a reason to invent imaginary filesystems.

> media://dvd is much more simplier and just works,
> no matter which station you log on.

That's easy, just create a "/dvd" symlink on all machines. You can even automate the process provided you can detect the OS from a shell script.

> Ok, maybe non-KDE apps have probs with this,
> but they can't handle fish:// as well.

Not just non-KDE, but KDE apps too, unless someone patches them to make them work. And maintains the patch, instead of doing cool stuff, and writes some more patches for the new monsters - you don't assume media:/, home:/ and system:/ will be the last of them, do you? Just wait for doc:/info that will point to /usr/share/info and system:/doc/info etc etc. (Don't worry, just kidding)

As for fish:/, fish is different because it introduces new functionality. Without the fish KIOslave there would be no fish at all ;-). But /media would be there anyway, so no need to replace it with something that doesn't work.

> But after you typed /users/bkoffice/8/bentruth a dozend times
> you'll start loving home://bentruth

Again, symlinks are your friends:

ln -s /users/bkoffice/8 /home

Besides, the file dialog has autocompletion so it's not that bad anyway. And inventing proprietary URLs just for the sake of shorthand is silly.


By Gato at Sun, 2006/10/29 - 5:00am

I am totally baffled at why you assume that every KDE system on earth should have /media or that the user will even be allowed to create it.

What KDE is and was for a long time already, or so I believe, is a desktop for a wide array of systems. One of its strengths being that the KDE framework solves the problems for the applications just fine.

My understanding is that media:// should work fine for every KDE application and that's OK. Where it does not, it's probably worth to note, that these apps have attempted to improve over the framework, so there is a need, point proven.

Stop telling KDE it should not provide its own ways of doing things. We actually like innovation around here.

Yours,
Kay


By Debian User at Sun, 2006/10/29 - 5:00am

>> I am totally baffled at why you assume that every KDE system on earth should have /media or that the user will even be allowed to create it.

The user doesn't create it. That's up to the distribution/system.


By Leo S at Sun, 2006/10/29 - 5:00am

> I am totally baffled at why you assume that every KDE
> system on earth should have /media

I don't assume that at all, I only assume that the fact that I have non-standard KDE URL (media:/) that just happens to be the same on other operating systems (that I don't use) is of no use to me.

(And I'm not just egoistically thinking about me, when I say "no use to me" it's just a way of speaking.)


By Gato at Mon, 2006/10/30 - 6:00am

> Stop telling KDE it should not provide its own ways of doing things.
> We actually like innovation around here.

By all means I'm not trying to tell KDE not to do. I'm not the one to do that, and besides I too like innovation. I'd like a KDE way of doing things, such as making hardware access 'just work', transparently to the user.

But media:/ and system:/ and home:/ are not new ways of doing things, they are just new ways of calling things. Same old things, new names, new misunderstandings, new breakage. Worst of all, new filesystems to learn. Real innovation would be getting rid of all filesystems in the user interface, not adding new ones on top of old ones.


By Gato at Mon, 2006/10/30 - 6:00am

> That's easy, just create a "/dvd" symlink on all machines. You can even automate the process provided you can detect the OS from a shell script.

Detecting the OS is not the issue - always the same. But "all machines" is wrong. There are only a few servers, 20 at the moment, but more than 300 Workstations. X session runs on the server, but drives are workstation-local. Good luck with symlinks... ;-) (kdm runs locally, reowns the drive to the user logged in and ncs a script on the server which automounts, kinda nasty but works)

> Not just non-KDE, but KDE apps too, unless someone patches them to make them work.

If they use the kio api, all kioslave should work or it's a bug to be squashed. I've never had probs with media:/ fish:// sftp:// or camera:/ (at home). system:/ or settings:/ are rarely used, ok, but they still work. audiocd:/ does, too.

> Again, symlinks are your friends:
> ln -s /users/bkoffice/8 /home

Bad luck. You'd have to link /users to /home (not everyone is in backoffice), but it wouldn't help. Not everyone has their homes in /users, but in /u (I'm there) or the Linux-like /home (for some local only logins).

> And inventing proprietary URLs just for the sake of shorthand is silly.

They are not proprietary, they're well documented and free to use (or ignored).


By Andreas Jensen at Sun, 2006/10/29 - 5:00am

> They are not proprietary, they're well documented and
> free to use (or ignored).

There are at least two ways of speaking about proprietary. In one way you're right. But there's the other way: a method of software interaction can be called proprietary when it's free and open, but it's not an agreed upon standard and it requires special efforts from the part of other people in order to work.

This means that even if you give other people the tools to unbreak the compatibility that you have just broken, your URL language is still proprietary until it becomes an agreed upon standard.


By Gato at Mon, 2006/10/30 - 6:00am

You write...:
Yep, as that's what it is supposed to do. For your own home theres ~. But after you typed /users/bkoffice/8/bentruth a dozend times you'll start loving home://bentruth.

If you'll allow using ~ for your own home, then how is home://bentruth any better than ~bentruth?


By AC at Sun, 2006/10/29 - 5:00am

> The ways to fix them is: report as bugs

Sorry but people only report bug when they are worth fixing. Fixing the bugs introduced by the imaginary filesystems is just absurd. It would only mean piling hacks on top of hacks on top of hacks. And all you'd get is fixing other hacks (the proprietary URLs themselves). Just to get back functionality that has always been there to begin with.

The real way is not to cure the symptoms, it's to cure the disease. To eliminate the cause.


By Gato at Sat, 2006/10/28 - 5:00am

There is no need for hacks over hacks, only right way of using the KDE API and creating the correct desktop files. But whatever, I tested media:/, system:/ and home:/ URLs with KDE and non-KDE applications mentioned here. Well, amarok, kaffeine, konsole, xine and openoffice has no problems. For those who doesn't understand the URL is translated to the real path. Eg. open a file in oowriter from home:/user and when you try to save it, you will see in the file dialog: "/home/user" as the current directory. I'd say they work unless you give a non-working example. And I'd say this proves that if they don't work, it's nothing else, but a bug.
Just for the record: self-compiled KDE 3.5.5 on SUSE 10.1.
Oh, and I like the media:/ slave (i don't use the others) as it is much easier to use and remember than some path that can be different on every distribution.


By Andras Mantia at Sat, 2006/10/28 - 5:00am

The reason why some apps don't have problems any longer is that they've been hacked to either translate URLs or copy files to temporary locations etc. And these hacks need to be maintained, and new hacks will need to be written in order to accomodate new needs.

All of this just for the sake of having the same URL on all distros. And the distros already use the same URL, '/media'! Unless they're not FHS compliant (very old Linux? IRIX?).

And even if they did use different locations for mount-points (which they don't), what would be more important:

a. having URLs that can be understood by all apps on _your_ system, or
b. having URLs born incomprehensible (albeit partially resurrected by haunted application developers ;-) ) that look the same on all distros? Who cares about all distros?


By Gato at Sun, 2006/10/29 - 5:00am

Have you ever used the KDE API to write applications? If you stick to KURL everywhere you will have hard time to break media:/ or system:/ or whatever. It just works. And if you don't use KURL e.g because you have to pass the files to a non-KDE application (like xine) just use "Exec=appname %f" in you appname.desktop file instead of "Exec=appname %U" and KDE will download the file to a temporary location before passing to the application.
Really, there is no need for hacks unless in very few cases and even than it should be a minor issue to make it work. And for me both a and b is important and I would fix a rather than just throw away something because some apps have issues at this moment. But what apps, please tell me and I will test here as well...


By Andras Mantia at Sun, 2006/10/29 - 5:00am

The problem is that KURL does not really help you in most of the bugs caused by this, the remote IO-slaves have never been a problem. The problem are the unnecessary local ones like media:/. They have created bugs for every application that have the need for treating local files different then remote files. Lots of applications like Kaffeine, k3b, codeine etc have special handling of cases when these URLs are used to to make them be seen as local files. And none of these applications had this before being notified by a bug report. So it simply does not just work.

And it's not about throwing something away because some apps have issues, it's about throwing something away that does not give any benefit over the systems existing solution. And in addition it introduces unnecessary problems and create issues for applications. IO-slaves are great, but they are not the solution to everything.


By Morty at Sun, 2006/10/29 - 5:00am

There is only one specific things with media:/ and co. they are local even if they don't look so. The only case when an application has to do something special is when it is a KDE application, uses KURL, but doesn't support remote operation. Why? Because if its a KDE application and uses only KURL inside it simply shouldn't care if the KURL points to a remote or local file. If it's a KDE application, but works only with local paths and uses QStrings to store paths, it should specify that it cannot open remote URL's (uses filename %f in the .desktop file). In case of non-KDE applications, the situation is the same.
So what is in the case of using KURLs and not supporting remote files? I think this was the case of Kaffeine, Amarok and K3B as all of them pass the paths to third party non-KDE applications who don't no anything about KIOslaves. Well, just check the sources for K3B for the "hack":
if( !url.isLocalFile() ) {
return KIO::NetAccess::mostLocalURL( url, 0 );
}

The hack you are looking for is "mostLocalURL". The function is there since KDE 3.5.0, released quite some time ago.
I simply don't buy the argument that this idea is broken and needs hack in the applications. In case somebody shows me real examples (none-working apps or extra hacks because of this) I can discuss more.

Another example is from amarok:
// Note: remove for kde 4 - we don't need to be hacking around KFileDialog,
// it has been fixed for kde 3.5.3
else if( protocol == "media" || url.url().startsWith( "system:/media/" ) )
{
...
}

So if there was a bug, it was fixed in 3.5.3. Bugs can exists, this is why they should be reported so they can be fixed either in libraries or applications.


By Andras Mantia at Sun, 2006/10/29 - 5:00am

For KMPlayer, the mostLocalURL isn't such a nice solution. All KParts targeted for KHTML should not use local loops. The problem is that JS setTimeout() or other redirect ways, may fire inside such a local loop, causing a page reload. This will most certainly crash konqueror.


By koos at Sun, 2006/10/29 - 5:00am

I admit I never heard that you have to be so careful with KParts loaded inside KHTML, but in this case the problem is rather the hack used in NetAccess, than media:/ or mostLocalURL. This simply means you can never use KIO::NetAccess, right? I find this a particular case, wrong interaction between two applications, and in this case I admit a hack (or non-standard solution) is needed, like manually find out if it's a media:/ or whatever URL and translate yourself to the real path.


By Andras Mantia at Sun, 2006/10/29 - 5:00am

Pages