In this week's KDE Commit-Digest: Resurgent development work on KDevelop 4, with work on code parsing, code completion and the user interface. Support for converting the KVTML XML-based format to HTML in KDE-Edu. Support for the much-wanted feature of multiple album root paths in Digikam. Various continued developments in Amarok 2. Multiple additional comic sources for the Plasma Comic applet. Support for Kopete plugins written in Python, Ruby, JavaScript and other supported languages through the Kross scripting framework. A simple command-line application for playing media supported by Phonon. WavPack, TrueAudio and Speex format support added to the TagLib support library used by JuK and Amarok. Audio device work (utilising Solid) in KMix. Work begins on KsCD by a team of French students. Various optimisations in Plasma and Dolphin, amongst other applications. okular moves to a shared FreeDesktop.org library for PostScript format support. KGhostView finally removed in favour of okular for KDE 4.0. Code for supporting Apple OS X Dashboard applets via WebKit imported into playground (not for KDE 4.0!)
Comments
Last I looked, there was a option in kpdf's configuration dialog to ignore the print-protected "feature."
whoa! Thank you! Next time I will check more carefully the config dialog.
DRM in Okular is optional. When compiling Okular, set -DOKULAR_FORCE_DRM=OFF as a compiler parameter. Isn't OKULAR_FORCE_DRM set to OFF by default? This will allow you to have a GUI config where again you have to turn DRM off.
This is a pain - how about keeping the runtime config and scrapping the compile time one?
I totally agree. This should be a runtime configurable parameter or set to 'off' on compiling time by default.
when you use compiste, the shadow in the desktop doesnt dissapers when you close kickoff, you need start a new window o aplicattion and the shadows go away, now im compiling from svn, but wanna now if is solved ???
I have to say when I first heard that Amarok 2.0 would be using covers in the playlist and compacting it I was more then a little scared. Being a huge fan of Amarok previously, I loved the playlist and didn't think that this would improve it all only make it more bloated. I was wrong, that video put into perpective how cool this will be. Thank you everyone for your hard work and innovation!
I really appreciate this comment. Despite what people sometimes seem to think when we are posting development screenshots ( Even though, I have to admit, it has not been that bad lately ), we are not out to destroy Amarok.:-) We are, more than anything else, all Amarok users ourselves.
On the other hand, we had also gotten to the point where 1.4.x, which, in its current incarnation, is a really great and solid music manager/player, can only be improved so much without compromising stability or simplicity. So we decided to "go for broke" and try something completely different, while keeping the Amarok "Spirit" intact. All this work is slowly starting to come together now, and I am more exited than ever about Amarok2.
Aaron has an interesting post at (http://aseigo.blogspot.com/2007/11/oxygenation.html), where he shows the great work being done to oxygenify the beloved Big K. One thing that puzzles me however, is this: why was the search bar in the right hand side removed? I know you can do "gg:" for a Google search etc, but I thought the bar was a pleasant touch. Is there an option to re-enable it for those feeling sentimental?
Oh and thanks for your perseverance and durability in providing these great digests Danny & crew; your motivation and dedication to the cause is admirable!
Both search bars: Web Search & Directory Filter, are totally configurable in Konqueror on KDE 3.5.8 -- you can add them to the Location ToolBar and remove them from it using: "Settings -> Configure Toolbars" I would presume that this would also be the case in 4.0.0. If they are missing, there are going to be a lot of disappointed users.
It's OK if they are configurable, but please make they appear in the default config. People always complain about the "bad defaults" in KDE. And if this is true (no google/wikipedia/youtube/etc bar), they are right this time.
Remember that only a few will search in the configs dialogs to get the bar back, many will simply switch to Firefox
The search bar is the first thing I remove in any browser I use. I think the space is better used for the address bar, especially on lower resulution screens. Plus, with the "gg:" or "g" and other configurable keywords, I don't lose any functionality.
Of course, you're probably right about most users.
ACK. That's actually my favourite personal complaint about "bad defaults" in KDE. I spend way too much time removing this IMO useless duplicate feature from konq's interface every time I get to a new KDE setup. (On the upside, I'm getting pretty good at removing it, these days :)
I hope it won't get any harder to remove the search bar (or anything else in the toolbars) than it is now.
Agree, it's the first ting I remove too. I have never found Konquerors interface to be too cluttered, but that one is plain annoying.
I have be added to the list of the 'google and the likes' search bar.
But on the other side, the 'filter bar' is realy nice, and I can't find it on my mdv2008. I found it on a mandriva 2007 powerpack at scool, and it was a good surprise.
I think this would have been a great default in filemanager mode. (I mean, it's the like of a 'ls|grep xxx', wich I used to open a konsole just to easily do that... F4 rox, but an integrated bar in konqui is so much easier...)
wow, such a filter bar would be great!
But i dont agree with the searchbar. The searchbar has to be default, the user expects this, specialy new users. Advaced users can remove it with no problem, new users won't even know that it exists
Little tip: you can actually use wildcards in the location bar in konq.
So type in *xxx* in there, and you see the stuff.
Yeah, not very discoverable :(
Wow - I had no idea about this - that's great, thanks!
I think the default interface should show most features of which the user can remove those they don't use. If there is only keyword search, the user will not even notice this feature, while they notice the search box with the Google icon.
The searchbar has never been a part of konqueror, it's just a plugin.
So the screenshots with it "removed" simply do not have it installed.
That's a plugin that I can't live without, too. Which reminds me, is Apple still making money off my Konq Google searches? Also, how can KDE get a customized Google page like:
http://www.google.com/firefox
http://www.google.com/microsoft
http://www.google.com/linux
Has anybody checked into this? Would be kool for Konq to have a unique Google page!
Is/was Apple really making money off Konqueror Google seaches? That sounds bizarre. Any source on that?
I do like your idea of a Konq Google page though.
I remember reading a while back that searches from Konq's Google toolbar were somehow identified by Google as coming from a Safari browser. Therefore, searches that led to revenue-generating clicks were generating revenue for Apple. I don't know the details, just that it got me a bit out of sorts back then. Maybe somebody else here has details...?
AHHHH!
The real significance of the filter bar was for cutting straight to the chase when trying to locate files. It's completely essential to konqueror's function as a killer file manager. I've been searching Konqueror for about ninety minutes now. The search bar appears to have been relocated. It's just not possible that the search bar has been removed, not after all the assurances that Konqueror would not be tampered with.
Yeah, found the Konqueror plugins and got my filter bar. TY so much!
Hi,
I just migrated to 4.1 from 3.5.9 and can't locate the filter bar :( Where did you find it ?
It seems i have the "Directory Filter" activated under Configuration/extensions, but it seems it can only filter by mime type, the input filter seems to have disappeared. Have you encountered the problem ?
Many thanks,
Romain.
Where did I find it? In 3.5.9, I'm afraid. If you want it in 4.x, it looks like you have to open ****ing Dolphin! I just spent 40 minutes searching through all all Came up on this page while the configure toolbar lists, and my hands are shaking from frustration.
I think that this functionality will restored to Konqueror eventually. I wish I knew for sure.
I finally got some satisfaction by using find to locate Konqueror 3.5.9 and putting the absolute path (/usr/bin/konqueror), in a link to the application in ~/Desktop, and then using folderview to put the link on the Desktop... and there it is, Konqueror, running in KDE 4.1!
Where's the bug report? I'm not fully sure what feature it is that you want re-implemented, and a detailed bugreport would help.
[quote]Hi,
I just migrated to 4.1 from 3.5.9 and can't locate the filter bar :( Where did you find it ? [/quote]
Uh... in 3.5.9 :(
KPPP shouldnt be dead, its widely used in third-world countries who still use dialup...
last time i tried it wasnt working, is there anyone on it? what happened to its Solidifaction? in trunk, its still the kppp of kde3, but just not working...
Well, if sth like Knetworkmanager can replace Kppp, I don't see why it should be ported. Kppp is needed for getting on the web through phone lines and people who are travelling a lot need this. So is there any replacement for it?
If Knetworkmanager or any already-ported application could do this there is no reason to fix kppp.but afaik, there is no application for Dialup connections except kppp for kde(4).so we need kppp...
the ideal thing is that kppp detects the modems automatically using solid and uses them, but its not changed from kde3 time, except that it doesnt works.gives errors when connecting, dialogs are messed up and...
this shouldnt be a hard job to fix the problems, kppp is ported already, just its buggy.
networkmanager a replacement for kppp?
Networkmanager barely works for simple configurations in my experience. Now to have to set up this monstrosity for dialup?
Derek
Is it possible to run Kwin Composite with ATI proprietary driver and XGL?
I have tried a lot of things without success.
Any help will be very appreciate :)
I'm not really an expert but my basic understanding so far is: The brand-new ATI proprietary driver (FGLRX) has built-in AIGLX. So you dont need XGL. XGL has proven extremely sluggish and unstable here but YMMV.
Yes, I know about it, but it has a terrible performance, no video playback, and some times frames appear and follow you mouse.
> and some times frames appear and follow you mouse
try inserting option "XGL_NO_VISUAL_GLITCHES" "true" into your xorg.conf ;)
The word from X.org is that as of 7.3 that XGL isn't working yet. The code doesn't even build.
Therefore, consider using it experimental.
I use X.org 7.2, and XGL works well, I can run compiz, but, Kwin Composite refuses.
And am I the only one who cannot do kwin opengl compositing with an Intel card and AIGLX (although Compiz works) ?
I have it working on a i965. The key thing was to put
export LIBGL_ALWAYS_INDIRECT=1
at the beginning of startkde. I'm also using EXA, but I'm not sure if that makes any difference.
"Sebastian Trueg committed changes in /trunk/KDE/kdebase/runtime:
[...]next week K3b gets ported to KDE4![...]"
wonderful :)
Yes, exciting! Did anything ever come of the project to make a user-friendly wizard for K3B? I remember reading some tidbits about it a while back, and then it disappeared. I personally didn't feel it necessary, but it looked cool. Anyone?
Months ago in the KDE-Look site someone posted a mockup of a kicker replacement idea (http://www.kde-look.org/content/show.php/Kde4+Mockup?content=28476). Does anybody know whether something in Plasma is moving toward that direction? I think the Create-Communicate-Configure thing and the task oriented menu is very original (no other OS's have it) and much more usable than the other kicker replacement idea I've seen. Will we ever see something like that?
"Will we ever see something like that?"
Depends entirely on whether or not someone writes it ;) Plasma has the long-term goal of making the development and deployment of replacement panels, taskbars etc trivial, and something like this could probably be knocked in a few hours in Python or Ruby (which *hopefully* will be supported by Plasma, via Kross) or in slightly more time in Javascript, or slightly more time still in C++.
> Plasma has the long-term goal of making the development and deployment of
> replacement panels, taskbars etc trivial, and something like this could
> probably be knocked in a few hours
Yeah, and that's the problem. I hope someone takes the implicated security issues into concern: malware will be more easily developable and deployable with this, and that users could look at the source code to verify the authors intent doesn't improve on that in reality.
IMHO it is very important that KDE accepts code only from kde community sites (kde-look.org, kde-apps.org, kde.org ) and those put up a small verification/code review workflow for script snipplets like those for Plasma, else the ease of developing for KDE could seriously backfire, especially onto the new users that will pour in with the 4.0 release. regards.
It's no more dangerous than Firefox extensions, to be honest (Firefox has a far, far larger installed base than KDE, and there is no epidemic of malware there), but I wouldn't be at all surprised to see whitelisting/ blacklisting/ signing implemented, if only because it would make a useful addition in a corporate environment.
I think it should be the default, not just an option. Having such a desktop metaphor would make KDE unique. It would not be Windows nor Macintosh nor Gnome, it would be KDE only. It could renovate the whole desktop thing. IMHO. :)
C'mon - you should have realized by now that plasma doesn't care about user opinions. They just want to develop a face-lifted piece of crap kde3 look-alike.