KDE Commit-Digest for 5th October 2008

In this week's KDE Commit-Digest: Support for image file previews in the "FolderView" Plasmoid, which are enabled by default. Kross support for making comic providers using scripting languages in the "Comic" Plasma applet. First fully-working version of the QEdje script engine for Plasma is moved into kdereview, then into kdebase. More progress in the "Weather" Plasmoid, more integration of D-Bus in PowerDevil. A more accessible configuration option to enable "show my bookmarks" as the start page in Konqueror. Initial implementation of session management in Konsole. Support for editing multiple languages at the same time with the scripting API of Lokalize. First version of an Enhanced Metafile Format (EMF) generator for Okular. A collection of new data plugins in Kst. Configuration support for thumbnail cache options in Gwenview. Support for playing music during a slideshow in kipi-plugins (used by Digikam, etc). Preliminary support for the PIMO concept in NEPOMUK (a key idea of the framework). More refinements to the search bar in Kate. First parts of a "partly-usable" Media Devices applet in Amarok 2. "Ink" receiving support, and the ability to preview file transfers for the WLM protocol in Kopete. More work on a "cost breakdown" view in KPlato. Work on improving the handling of lists in the "TextShape" of KOffice. A draft of a TCP-based real-time syncing model in Okteta. Optimisations in KDevelop and KHTML. Removal of the wizard in Parley. Kapman moves from playground/games to kdereview. Initial import of KJots rewrite, with plans to port to Akonadi, NEPOMUK, and Plasma. Read the rest of the Digest here.

Dot Categories: 

Comments

by Emil Sedgh (not verified)

...Thank you, Danny

by Debian User (not verified)

Hello Danny,

just don't burn out fellow. :-)

Yours,
Kay

by Vlad (not verified)

thanks danny, big appreciation from me :)

vlad

by Anon (not verified)

More like "Yeah! Yeah! Yeah!"! A warm "welcome back" to Danny and the Digests :)

by T. J. Brumfield (not verified)

That sounds like one heck of a week for commits.

by Leo S (not verified)

Thanks Danny!

And my favourite commit this time around is:
>> Don't load mimetype icons at startup, they decrease the startup time by 6-10x

Thanks Harald Sitter for that. I've always wondered why a simple dialog like kfind sometimes takes ages to load (so long that I sometimes think its not going to happen at all and try to launch it again).

by R. J. (not verified)

thanks for the digest

by Bob (not verified)

> Support for image file previews in the "FolderView" Plasmoid

I'm a bit confused about the difference between plasma and regular applications. Can FolderView not be implemented by embedding the dolphin folderview kpart into a plasmoid? From the way things are written, it sounds like plasmoids need to be programmed from scratch and are different to kparts in some way. I'm sure this isn't the case, but I don't understand why plasmoids could not just be implemented using window manager like features e.g. plasmoids could jut be regular apps with the title/menu bar turned off with some transparency.

by Christian K. (not verified)

YES, that would be great!

And we would get rid of so much trouble we always have with these plasmoids.
Instability of one would not affect any other. The common themes and colors would apply for those too (if not particularly overwritten) - leading to a badly missed consistently look and feel ... The longer I think about it, the more advantages coming to my mind.

That really sounds like a CHANCE!

by Michael "It doe... (not verified)

Actually, I thought that FolderView did use Dolphin to view the folder. It simply needed to hook the UI in.

As for a rewrite, it won't happen. For one, libplasma has been moved into KDELibs, so binary compatibility needs to be maintained. Secondly, Plasma needs to be able to work with any window manager, and not just with KWin. Thirdly, Plasma needs to work on many use-cases not related to the current desktop. Fourthly, it'd be difficult work with very little benefit.

by Anon (not verified)

"Actually, I thought that FolderView did use Dolphin to view the folder"

Nope :)

by Diederik van de... (not verified)

Nope, but they do use 'libkonq' for the context menu's.

by Aaron Seigo (not verified)

> I'm a bit confused about the difference between plasma and regular applications

"regular" applications are stand-alone applications with top-level windows of then own and tend to use primarly or only 'native' widgets with most of the UI pretty well hardcoded. plasma uses a canvas based approach and is highly modular allowing for the creation of various designs out of small building blocks; amarok's context view is a non-desktop example of this.

> Can FolderView not be implemented by embedding the dolphin folderview kpart into a plasmoid?

it could, and it would suck in many various ways. from how it is rendered to the interaction mechanics, it's just not "perfectly" suited.

in kde1, kfm did the desktop icons (like nautilus does today in gnome); in kde2 (and kde3) it was broken out into its own application called "kdesktop" which was basically a specialized, but somewhat limited, file manager for the ~/Desktop folder; in kde4 we have something much closer to an actual file manager, but which goes for a more modular approach over all, where the listing is just one component but still deisgned for the "on the desktop" use case, which something like dolphin isn't.

the good news is they share a lot of the same code, just repurposed for the specific use cases.

in the case of file previews, folderview uses the KFilePreviewGenerator class for that .. the same class that Dolphin, Konqueror and the file dialog uses.

the real question is getting the code sharing going at the right level, such that we aren't duplicating code, ending up with featureless UIs but also have interfaces that well tuned for their use cases.

" I don't understand why plasmoids could not just be implemented using window manager like features e.g. plasmoids could jut be regular apps with the title/menu bar turned off with some transparency."

you could. and then you'd have a poorly interacting, difficult to manage, hugely resource consuming system that requires far more code for each component to be written.

it would also make things like coordinating activities, zooming and all that other stuff not only a lot more difficult but *require* a decent compositor and for the controlling app to do all the management. basically, it would require smashing much of plasma into kwin. both are already complex enough as it is.

so, in summary, we would lose visual integrity, developer simplicity and performance with what you suggest.

not exactly a great idea in my books.

by Debian User (not verified)

Hello Aaron,

I agree with you, Plasmoids seem preferable with a more optimized UI.

Still, in the absence of such UI, why not view single or tiles of documents inside a special purpose Plasmoid that loads KParts. Like I would have a pile of documents that I currently work on, one that I have to review and one that was released a few days ago.

Doing that with Nepokuk tags and queries, it would be a nice way to organize my work with that. I guess, I may even give up on KMail for mail reading with an interface like that.

How far are the Python bindings to Plasma with 4.2 anyway? Would I be able to bridge KParts and Plasmoid from scripting now? Can I make my own containment with it too?

Yours,
Kay

by Aaron Seigo (not verified)

> How far are the Python bindings to Plasma with 4.2 anyway?

complete, working and in kdebase/workspace.

> Would I be able to bridge KParts and Plasmoid from scripting now?

should be able to, yes, using the full PyKDE bindings and a QGraphicsProxyWidget (which lets you stuff a random QWidget onto the canvas)

> Can I make my own containment with it too?

If you can make a plasmoid out of it, you can make a containment out of it.

by Debian User (not verified)

Hello Aaron,

thanks, I shall try it. To merge Plasma, Nepomuk and KParts will be very exciting.

Yours,
Kay

by Janne (not verified)

Not 100% related, but... I feel that the folderview-plasmoid is great in theory, but it doesn't go far enough. I mean that if I open a folder in folderview, it gets opened in Dolphin. when I first did that, it felt "unsmooth" and jarring, since I was expecting it to be opened inside folderview itself. Opening it in Dolphin (which requires Dolphin to be launched, and brand-new window appearing on the desktop) causes a delay, and requires me to move my attention from Folderview to Dolphin, disrupting my workflow.

Yes, I filed a bugreport(* about it, but not much seems to have happened.

* = https://bugs.kde.org/show_bug.cgi?id=171889

by SVG Crazy (not verified)

I think that's the way it is supposed to work. When you opened a folder on the old desktop (kdesktop) the file manager was opened too. The difference now is that you can have a huge number of folders shown on the desktop, not only de ~/Desktop. The plasmoid you want is kinda a filemanager plasmoid, wich folderview isn't. (I think it possible to do with plasma too).

by Janne (not verified)

"I think that's the way it is supposed to work."

I know, and I feel that it's wrong. Using Dolphin breaks the workflow, and introduces a delay, since it takes some time for Dolphin to launch.

"The plasmoid you want is kinda a filemanager plasmoid, wich folderview isn't. (I think it possible to do with plasma too)."

Folderview already kinda is a filemanager. I mean, you can do basic filemanagement with it. I fail to see why opening folder inside folderview is suddenly an "advanced" filemanagement-feature that should not be there.

Since Folderview immediately launches Dolphin when you open a folder, then what's the point of having Folderview? Why not bypass it completely and use Dolphin instead? I mean, you would probably end up in Dolphin in any case.

Of course it makes sense that actual _files_ are opened inside relevant apps, but I don't understand why folderview couldn't handle opening of folders.

Quickaccess-plasmoid CAN open folders inside the plasmoid, and it feels very natural way of working. So it could be done. When folderview launches plasmoid, it feels unexpected, unnatural and jarring.

by SVG Crazy (not verified)

>>>Since Folderview immediately launches Dolphin when you open a folder, then what's the point of having Folderview? Why not bypass it completely and use Dolphin instead? I mean, you would probably end up in Dolphin in any case.

The point of using folderview is basically the same point of having a file on ~/Desktop file on KDE 3, showing files on the desktop.

On KDE 3, we had a ~/Desktop view on the desktop, now, with folderview, we have this feature extended!! We can have multiple views on the Desktop. This is very useful when you work, for instance, with some files on your $HOME/Project folder and have to upload it on a Network folder. You could have two folderviews (one for the project file, another for the network) and copy the file from one view to another just dragging and dropping the file! This is just one of the possibilities.. I can see many others using Nepomuk, for instance.

Folderview is a new and extended way of getting a view on the Desktop.. on KDe 3.. we could only have ~/Desktop view on desktop.. on KDE 4.2, it will be possible to have this old way of doing things (like kdesktop) and the new way.. using multiple folderviews...

Folderview, IMHO, isn't a filemanager, although it can do some of the things filemanagers do (like copy, move delete files/folders). It is exactly what the name suggests, a view.

by SVG Crazy (not verified)

>>The point of using folderview is basically the same point of having a file on ~/Desktop file on KDE 3, showing files on the desktop.

Just to make it more complete.. The point of using folderview is basically the same point of having a file on ~/Desktop file on KDE 3, showing files/folders on the desktop.

by Janne (not verified)

"The point of using folderview is basically the same point of having a file on ~/Desktop file on KDE 3, showing files/folders on the desktop."

If that was it's point, we would still be usign the old system. But we are not. We are using folderview so we could have something better.

Besides: if folderview could open folders inside folderview, it would still be displaying contents of that folder, would it not?

It really seems to me that people are arguing against this suggestion because of dogma. That is, they are saying "folderview should not do that because it's meant to simply display files and folders". Should we tie our hands because of some narrow definition? No, we should work to make each and every piece of KDE as good as possible. Extending functionality of folderview in this manner would not make it worse, it would make it better. So why shouldn't it be done? Because of dogma that says "folderview is only supposed to show contents of a folder"?

by Mikko (not verified)

The idea of Folder View is not to have an Plasmoid what allows you to move inside of folders and so on. It's idea is to open the files (folders are files too) with correct applications.

It would be stupid to click folder and get it opened on folder view and not on filemanager, because when you open a PDF or text file, you get it opened with correct application.

The folder view is not only for filemanagement. It is for filtering files and when integrating with nepomuk, it filters just files or stuff what you want. So you dont always see folders with it.

Folder View is "Window" to files, it shows what you want it to show. To give you a easy access for wanted files, so you dont need to search and track them first.

I like the way that Dolphin gets opened. I hate the Kubuntus quicklaunch because it does not open the wanted folder to dolphin, but I need first click wanted folder and then "Open". I want to get filemanager opened fast (If I dont have such already!).

by Janne (not verified)

"The point of using folderview is basically the same point of having a file on ~/Desktop file on KDE 3, showing files on the desktop."

The point of using folderview is to give us a system that is more powerful and flexible than traditional "files on the desktop" is.

"On KDE 3, we had a ~/Desktop view on the desktop, now, with folderview, we have this feature extended!! "

Yes we do. So? Does that mean that further improvements are not needed? And why do you feel that you need to tell me about the greatness of having several folderviews running? What does any of that stuff have to do with my suggestion?

"Folderview is a new and extended way of getting a view on the Desktop.. on KDe 3.. we could only have ~/Desktop view on desktop.. on KDE 4.2, it will be possible to have this old way of doing things (like kdesktop) and the new way.. using multiple folderviews..."

That has nothing to do with my suggestion.... Why are you telling me the greatness of having several folderviews when I suggest that we should be able to open folders inside folderview? It has nothing to do with the subject at hand.

"Folderview, IMHO, isn't a filemanager"

It already does some filemanagement-stuff. Why shouldn't it do some more (that is: open folders)? How exactly would it make folderview WORSE?

by SVG Crazy (not verified)

>>That has nothing to do with my suggestion.... Why are you telling me the greatness of having several folderviews when I suggest that we should be able to open folders inside folderview? It has nothing to do with the subject at hand.

Well, all that explanation was because you asked what's the point of folderview if you can't browse files.... I just answered you question.

>>It already does some filemanagement-stuff. Why shouldn't it do some more (that is: open folders)? How exactly would it make folderview WORSE?

My opinion is that your suggestion would bring some complication to folderview. If you want to open a folder inside itself, there MUST be a way to come back to beginning. Make it automatically doesn't solve the problem because it can really be confusing (how much time to wait to come back to previous folder? and if I don't want to come back to previous folder at all?). It would have to be solved with some navigation widgets (like trees, breadcrumbs, or something like that). But folderview is a view, it is not intended to navigate.

This is just one of the problems. On 4.2, as I said before, there will be an option to make folderview behave like the old kdestop (making folderview be the desktop itself). Imagine the mess it would be to click a folder on this desktop and not opening the file manager!! Navigate through the desktop itself wait some minutes and come back automatically to the first folder? Where is that file that was where on my desktop some minutes ago? it's gone???? It would be VERY confusing!!!

I think that maybe a file managemer plasmoid could be done.. why not? There's a mini web browser plasmoid already there.. why not a mini file manager? (In fact, probably it can be done with plasma and dolphins kpart, who knows!).But that's not folder view is about.

The "problem" here is the concept. Folderview is a view, not a mini file manager/browser.

What do you expect when you click on a txt file? Kwrites opens... an image? Gwenview opens... an svg file? Inkscape opens... Where is the "jarring" about that?... The same thing with folders... Dolphin opens. It is the way things work... just that.

by Janne (not verified)

"My opinion is that your suggestion would bring some complication to folderview."

Not really. It would be one checkbox in settings ("Open folders inside folderview yes/no"). In the actual folderview there could either be a button that takes you back to the beginning, or it could be done automatically after few seconds of inactivity.

"On 4.2, as I said before, there will be an option to make folderview behave like the old kdestop (making folderview be the desktop itself). Imagine the mess it would be to click a folder on this desktop and not opening the file manager!"

That's a question of implementation. It could very well be that if the folderview is used as a containment, it would use filemanager instead. Why? Because that makes sense. This is about what makes sense.

"I think that maybe a file managemer plasmoid could be done.. why not?"

What would be the point if we already have folderview, that does 95% of what is needed? I have no need for a "filemanager-plasmoid". I just want an existing plasmoid to behave in a manner that makes sense and would actually make the plasmoid better.

And by your logic, we aleady have a filemanager-plasmoid: Quick Access, since quickaccess can handle the hi-end task of opening folders...

"The "problem" here is the concept. Folderview is a view, not a mini file manager/browser."

In other words, the problem is dogmatism. You think that Folderview should not have this feature, not because it wouldn't work or something like that, but because "folderview is supposed to be a view, not a mini-filemanager".

Had KDE-project itself behaved like that, we would not have KDE running in Nokia's internet tablet, because KDE's mission-statement (which has since been altered) said "KDE creates desktop-software for UNIX-like OS'es", and internet tablet is not a desktop...

"What do you expect when you click on a txt file? Kwrites opens... an image? Gwenview opens... an svg file? Inkscape opens... Where is the "jarring" about that?... The same thing with folders... Dolphin opens. It is the way things work... just that."

There's a difference between files and folders. Folderview is obviously capable of displaying contents of a folder. So when I open a folder in folderview, I obviously expect it to open inside folderview, since that is clearly something folderview can do. Like I said, Quick Access plasmoid does practically same thing as folderview does, and it knows how to open folders inside itself. What's the difference?

When user clicks on a file (a .jpg for example) he already expects it to open in an application. When he's inside an app that handles folders (like folderview does) he usually expects them to opened inside that app. This is somewhat similar to opening a folder inside Dolphin, and having Dolphin open a new Dolphin-window for the folder...

I have yet so see any technical reasons why this features should no be in there. It would not make the plasmoid worse in any way. All I hear "this is the way it works." or "it's just a view".

by Jonathan Thomas (not verified)

One could use the same reasoning to demand that Dolphin becomes an all-purpose, KPart'd file viewer/web browser and that it would be "Dogma" to say that doing what it does is just the way it works. Dolphin does what it does, Konq can serve the same purpose and more.

Similarly, Folderview serves a purpose (displaying a folder on your desktop), and a file manager displays folders and more.

by Grósz Dániel (not verified)

"How exactly would it make folderview WORSE?"

If you open a folder, you would have to go back (several levels if you do file management in the plasmoid) if you want to see the desktop. E. g. sometimes the user opens the Documents folder, sometimes starts an application... if the documents folder was opened right in the plasmoid, they would have to go back whenever they want to start an application from the desktop, while they otherwise might want to have a folder inside Documents open all the time.

by Morty (not verified)

The point of folderview is to give quick access, from the desktop, to (a limited) amount of files(or folders). It's not supposed to be a filemanger or file browser. The limited filemanger capabilitieas are only to preform the task taht comes natural for files on the desktop, like open, delete, rename, copy or move plus the ability to arrange the files.

by Janne (not verified)

You are tied to dogma. You think that "because fodlerview is meant to display contents of a folder, it must not actually open folders". Well, why not? Because of that narrow definition?

Quick Access plasmoid handles folders just fine, why couldn't folderview handle them as well? Is that difference justified because of some dogma that says that folderview must not open folders?

Or is this because of some weird sense of "competition", which says that fodlerview must not threaten Dolphin in the filemanagement-area in any shape or form? So we should cripple folderview, so Dolphin gets used more?

If folderview could handle opening of folders, it would not make it one bit worse in any shape or form. And we should be striving to make each and every component of KDE as good as it could be. Crippling software so people would use some "fully featured" version instead is done with proprietary software, not, free software. If we can make folderview more fucntional with no drawbacks, then why shouldn't we do it?

"The limited filemanger capabilitieas are only to preform the task taht comes natural for files on the desktop, like open, delete, rename, copy or move plus the ability to arrange the files."

To me, opening a folder inside the folderview is very, very natural. The fact that it opens Dolphin instead is unnatural and jarring.

Besides, folderview is supposed to bring us new, improved, flexible and powerful way of handling files on the desktop. And now you tell me that the functionality of the folderview should be limited so it would be more similar to the way traditional desktop handles files? Well, folderview is not "traditional desktop", it's something new and better.

by SVG Crazy (not verified)

>>Or is this because of some weird sense of "competition", which says that fodlerview must not threaten Dolphin in the filemanagement-area in any shape or form? So we should cripple folderview, so Dolphin gets used more?

C'mon, threaten Dolphin??? File management is much more than navigation through folder. I think nobody on KDE team has this "weird sense of competition" you say...

Anyway, I think what you want is a mini file management plasmoid, and I think that it can indeed be done (and would be great). But that's not folderview.

Folderview in concept is a containment that shows files and it must be "static" because this containment can be the desktop itself. There's no dogma at all (it is the concept). In fact, plasma is the most "mutant" and flexible thing I ever saw on a desktop, a plasmoid can be done with just some lines of code... Well, the explanation and my point of view is explained on the last response I gave you. I'm done here..

peace and love!

by Raul (not verified)

I think your are right, folderview should remain as it is, but it would be interesting to have a plasmoid that also does file managment. We already have alternative panels Why not have alternative folderviews?

by SVG Crazy (not verified)

I agree with you and that´s what I am trying to explain that a view is something "less" than a browser, so folderview is not intended to be a browser. File manager plasmoid would have this responsability (and actually, I think it can be done).

by The Dude (not verified)

+1

To me this seems like a very reasonable 'feature'.

by Anon (not verified)

I'd also like to see this. I can't quite put my finger on why it doesn't feel like it's missing in kdesktop, but in KDE4 the behaviour definitely does feel "jarring", as you say.

by Oscar (not verified)

I read about all these cool features and all the goodness that comes and I'm no longer allowed to use KDE at work. It pains me but the exchange connectivity really is a make or break kind of thing for me. And for many others I'm sure.

Sadly KDE is no longer my primary desktop. Now I'll have to endure XP instead. KDE will however keep it's place in my home environment.

But how I'd love an application (KDE-PIM) that could talk MAPI to exchange and free my laptop from Microsoft. Going to XP feels like stepping back in time, as well as in features. :-(

Sorry for being such a wet blanket.

by Harry (not verified)

We're facing the same problem. Although often the community does not see the importance of the issue: Exchange connectivity is *very* important for many companies. At out company it is also blocking the transition to 'Linux-only workstations'.

I sincerely hope that KDE-PIM will get full working Exchange connectivity with the work that is being done on the OpenChange Akonadi back-end. Can someone give a status report?

Regards, Harry

by Thorsten Schnebeck (not verified)

Thats why I have to use Kontact3.x on a KDE4 desktop at work. But opening attachments always uses KDE3 apps in favor to KDE4 apps (Kubuntu 8.04)

Bye

Thorsten

by winter (not verified)

If you are making the change to linux only work stations, start from the server side. There are two thins I see. Exchange has IMAP support. Outlook can connect to IMAP. So you could either install a nix based IMAP server and have the Outlook zombies connect to that and use publish iCal calendars. Or you could enable IMAP support on your Exchange server and have Kmail connect to it. There are ways to do it that don't require some fancy Exchange replacement/support. It's usually just the IT department is too scared to roll out something new. So they keep paying the MS dues and the boss wonders what is going on. It's like that it almost every IT department I've worked in. When I suggest we enable IMAP support for flexibility reasons, I am met with fear and trembling.

by Vide (not verified)

100% agree... Still today (sadly) it's way easier to migrate servers than client, and when you migrated serers to not-(so)locked-in-platforms, you can easily migrate clients, if you want. Use Zimbra to achieve almost 99% of Excahnge features, for example, if you want something easy to install, comemrcially supported and paying license fees is not a problem (and it shouldn't, you are using Exchange after all). Users can then just use Outlook as they did or use whatever other client supporting well-known standards

by Pascal (not verified)

If it's actually important for the company, then pay someone to work on mapi support for Akonadi.

by Oscar (not verified)

It's not important to the company at all. They've standardized on XP and most people are content with that. I who used KDE on my previous job would love to keep doing that, but alas, I have to conform and use the tool I'm given. I can hardly ask them to modify their infrastructure to fit my needs.

If however my infrastructure would seamlessly integrate into theirs then it would be a different matter entirely.

And I'm not rich enough to pay a developer. I do donate some money to KDE and related projects every now and then, but that's as much as I can do.

But I keep hearing about exchange connectivity from linux applications and I haven't given up hope.

by Leo S (not verified)

>> It pains me but the exchange connectivity really is a make or break kind of thing for me. And for many others I'm sure.

I have the freedom to run Linux at work, and we run an exchange 2007 server. I used to run Outlook 2007 in VirtualBox, but after CrossOver Office gave away their software for free, I'm now running Outlook 2007 in Linux directly. Works great!

by Jos (not verified)

Run Windows in a VirtualBox. I do it and it's great.

by Jon (not verified)

Stop using Exchange! Really. Everytime someone sets up an Exchange server got kills a puppy. :(

By using Exchange corporations are keeping themselves locked into Windows. A better solution is to use Zimbra. Really my organization uses Zimbra with 30,000 clients (a University). It works great and it has even more features then Exchange does, like a wiki.

by Holger F. (not verified)

"Support for playing music during a slideshow in kipi-plugins (used by Digikam, etc)"

What? Great I already love it before I have seen it. Somewhere I read about fancy 2D and 3D transitions and now music support. Seems like the kippi using tools will do anything one would expect from a kool presenter tool. Keep up the excellent work.

------------
Danny, thanks for providing this great news!
------------

BTW, does anybody know if there is any work done at the grammar and spell check front (Sonnet ...)?

by Jordi (not verified)

The spell checker is working pretty decently.
The grammar checker will depend on some external project being able to do decent work. So far seems that there are no plans for it. So I don't think there will anything there in 4.2 or 4.3

by Holger F. (not verified)

To bad. But thanks for the information. If I remember correctly the developer of OOos LanguageTool once used to code for KOffice. To he isn't anylonger.

by Thorsten Schnebeck (not verified)

*me* wonders.
Since such a long time I have problems with standard konqi and flash. Sometimes a site works, but on a reload the nspluginviewer crashs.
OTOH using kmplayer *for me* leads to rock solid flash experience in konqi - also with KDE4 using kmplayer-0.11.rc4.
Why is knpplayer(that uses the same Adobe flashlib) not standard? Why is nspluginviewer so unstable?

Bye

Thorsten

Reference:
http://mikearthur.co.uk/2007/12/konqueror-with-latest-adobe-flash-howto/

This might have to do with your distro. I'm not 100% sure though. Yes, nspluginviewer just not working with KDE4 Konqi for many sites.