In this week's KDE Commit-Digest: A Trash applet, various general improvements, and support for sharing configuration layouts in Plasma. "Undo close tab" feature in Konqueror. Development continues towards Amarok 2.0, with services becoming plugins and support for the Amapche music server. Continued progress in KDevelop and KEduca. More work on album display and improved thumbnails (with RAW format support) in Digikam. A BitTorrent plugin for KGet, based on the recently created libktorrent. Directory monitoring-and-update support in NEPOMUK. Work returns to Okteta, a hex editing utility. "Connection Status" plugin removed from Kopete. Kile begins to be ported to KDE 4, whilst work begins on KGPG2. Goya, a GUI widget framework, is imported into playground.
Comments
http://ati.amd.com/support/drivers/linux/previous/linux-r-cat711.html
Release Date: Nov 21, 2007
File Size: 45.4MB
I don't want to use fglrx because it doesn't support suspend to ram. STR support is probably the single most important thing to me.
I'm using the 7.11 fglrx driver AND STR on my notebook.
I've an Asus Z9252Va (based on A6VA), with an AMD X700.
The only thing you need to do is force suspend (but that's because my machine isn't recognized).
"s2ram -f" is the command that works for me - flawlessly!!!
My distribution: openSUSE 10.3
(and Kwin4 compositing also works (although moving windows while transparent is a bit slow)
what about kwin effects ???
i dont see a update about the effects availables or the hotkey to use it.
What exactly are you expecting? They work (for me at least, hopefully the remaining issues for other people will be solved at some point).
what are the current thing that kwin can do ??
can do zoom like compiz ??
things like these.
Yes you can zoom (although I haven't figured out how to set the shortcut for zoom to something like Meta+Mousewheel). This may be a more general problem, since no keyboard shortcuts work in my install of RC1 (debian experimental).
I know we can just use KDE 3 apps in KDE 4, but is there any news of a KDE 4 port of ktorrent? It is my favorite torrent app on any platform, and basic torrent support in kget is nice, but I'd rather still use ktorrent, especially for the built in search support.
I agree. Ktorrent is THE best bittorrent client, bar none.
i'll third that motion =)
A KDE4 port of ktorrent exists a long time.
It is nearly feature complete, I still need to finish the new queue manager GUI, and after that the only thing missing is the RSS plugin and some other minor stuff.
There will probably be an alpha or beta release in a couple of weeks.
Outstanding! Thanks!
Thank you!!
besides users requests to kget handle bittorrent protocol. we also want to fully handle the metalink files. that blends http, ftp and bittorrents sources to speed up file downloads. and checksums verifications
so if you want to use a 100% bittorrent apps ktorrent is your call :)
I am very interested in Goya. To me, it really looks like a patch to the Qt framework, that I think really belongs there. Not to say that it should not be worked on, on the contrary, but I really think this should have been taken up by Trolltech. It would not suprise me if they integrated the functionality in a later release, as they seem to be doing now in other areas as well (phonon, Network Access vs. KIO, Qt Concurrent vs. ThreadWeaver, QtWebkit...).
Can we expect any improvement to the speed of KDE 4 when it is released. It seems very sluggish as a release candidate
KDE3.0 was hardly a speed demon, and the KDE3 series got progressively faster and more memory-efficient as time went on (fitting in nicely with the Coding Mantra - "Make it work. Make it work well. Make it work fast").
I see absolutely no reason why KDE4 shouldn't behave in the same way.
What exactly feels sluggish? Starting applications works fine here, painting is quick, the UI blocks considerably less than in Qt4. And that's with a debug build ...
Please, if you plan to make such a general statement, try to analyse the problem a bit more in details, and ideally file a bugreport on bugzilla.kde.org. Most developers don't browse the Dot when they're looking for issues that need to be fixed.
I think the big problem is the computer. When KDE 3.0 came out I had a 450Mhz p2. And gawd was it slow. Once I got a 1.4ghz athlon it was much faster. KDE is really just doing the same thing Apple and Microsoft have been doing for years. Using that new CPU :)
If you want speed you dont want to run modern software. As long as developers strive for eyecandy, and you give them the latest and greatest hardware this cycle continues.
Lastly remember this is open source. No-one* pays people to do the boring stuff like make sure its usable on an older system. So just get a faster state of the art machine and it will be fine.
* Where no-one is a small number of companies that service very specific customers for performance.
I haven't noticed any slower performance in KDE4. If anything, it feels faster because there is no flicker and apps start very quickly. This is on a fast machine though so it's hard to tell. Once KDE4 is released I'll put it on my EeePC and let you know how it runs on a 630Mhz celeron with 512 Mb of ram :)
That's simply not true with regard to KDE.
I have a Duron 700 Mhz PC (with 256 MB RAM) for years and I started running KDE 1 on it, later KDE 2 and then KDE 3. Although some components have been replaced (CD-ROM/burner, hard disk and graphics card) the whole computer has still the same hardware performance and I can definitely say that since KDE 2.0 KDE got faster with *every* new release.
As well the Linux 2.6 kernel did significantly improve the performance on my hardware in contrast 2.2 and 2.4 kernels.
For example I was not able to burn a CD, listen to music and surfing the web at the same time in 2002, cause music skipped, CD burning had buffer underruns, and the mouse pointer was jumping (each of the tasks alone was no problem).
Now in 2007 this is kind of workload runs without any problems and many KDE applications have greately improved their responsiveness, startupt time and task processing on this system during the whole KDE 3 cycle. I haven't testet KDE 4 there yet (just on a virtual machine at my laptop) but I am very confident that I will be able to use it without problems on it (maybe modulo some graphical effects).
This isn't true. My laptop is not a big thing, it's just a P4 whit 512 MB in RAM, and it runs smoothly, and I don't feel any speed difference, it's just buggier XD.
That is wrong. Each computer artificialy made obsolete build up the pile of hazard e-waste. Each new computer use more than a ton of materials to be manufactured. Aditionaly, not everyone has the money to buy an new computer every year, especialy if the old one can be perfectly funcional.
I hope that I can make KDE4 run on an 32mb system like is possible with KDE 3.5. At least, I want to see KDE4 runing very well (not cripled like it is needed for 32mb on KDE 3.5) on an 96mb system.
link: http://translate.google.com/translate?u=http%3A%2F%2Fwww.guiadohardware.... (funny, but "workable", google translation of an brazilian article)
With Qt4 promissing speed-ups and lower memory foot-print, and the previous kde record, I hope that KDE4 becomes light, not an MS Vista.
"With Qt4 promissing speed-ups and lower memory foot-print, and the previous kde record, I hope that KDE4 becomes light, not an MS Vista."
Until TrollTech give a way of globally switching off double-buffering - which on a 1600x1200 24bit screen can add almost 6MB *per maximised window* - apps built on Qt4 will likely take up more than their Qt3 counterparts, on balance. Apart from the double-buffering of all widgets, though, Qt4 does indeed seem more memory efficient, but KDE4 will likely take a while to optimise.
Someone posted a quick and dirty memory usage "analysis" in a previous commit digest - it's currently using more than KDE3, but nowhere near Vista levels (and I'll wager that it never will, either).
To be honest, I find it very unlikely you can run KDE 3.5.x properly on 32 mb ram (I had trouble with 192, so now I consider 256 as minimum). KDE 4 is focussing on 'usable on 256 mb', afaik, and anything below (often > 8 yo hardware) might be usable - but you'd have to turn of some stuff for that.
Well, if you see my link, you will see what compromisses were made to reach at 22mb memory usage. It will certanly not run like it would run in an 512mb sytem, but it should be suficient for some basic tasks.
And for your information, I think that last year in Brazil, most brand new computers sold had less than 256mb of usable memory. Good part of that were computers with 128mb of memory with 32mb shared for onboard video, wich means 96mb of usable memory. Today most new computers being sold have 256mb or even 512mb of memory (-32mb of onboard video). You will not find nothing with more than 1GB of memory in the main market places. So change your ">8yo hardware" to "currently being sold hardware".
I'm not asking KDE to focus use in 32mb computers, it was only an extreme exemple, but to the many people who would like to use it in their new computers, with less than 256mb of memory, or in their old but still good computers, that don't need to be obsoleted and turn in e-waste.
> I hope that I can make KDE4 run on an 32mb system
That's a joke, right!?
The whole thing just seems sluggish.
One of the worst was kopete, which I gather will improve when released, but typing on that, the letters were a good ten seconds behind my typing.
Applications were slow loading. Basically the whole thing just seemed much slower than 3.5, to the point I took it off. Time wise it just wasn't worth the time I was wasting waiting for things to open. Opening and closing windows was slower than in 3.5. I just figured this was something to do with it being a rc and would improve with the 11 dec release.
The other thing was. that little annoying thing in the top right hand corner, looks kind of like a system tray, showing some of the things I had opened. Real pain of a thing because it covered the close and minimize buttons to all the windows. I couldn't find a way to move that or make it not appear on top of the windows.
But yeah, everything to me was sluggish, even amarok. My computer is only about 3 years old, running a gb of ram. And I really hope I don't have to follow the microsoft way of life, that to run new releases you need a new computer. I was running the opensuse version, so don't know if they have done anything different to it to make it like that.
> Applications were slow loading
then something was very wrong with the installation you ended up with. apps are noticeably faster starting up on kde4 on the same hardware on my machines here. and they aren't exactly new. 3-4 years old.
> looks kind of like a system tray
it *was* the system tray ;) it works now in svn. enjoy.
Nice job Aaron. KDE4 is shaping up so fast now that one will certainly miss a lot of the action if one doesn't hake a daily update. The system tray was an obstacle like one person pointed out, I am happy that it's gone and the ugle taskbar! KDE4 is getting more beautiful, functional and usable with every update. i was even able to use Amarok 2 yesterday and I am sure to get another pleasant surprise today :)
Big thanks to the whole KDE team.
thanks Aaron.
np; for the system tray thing though you need to thank jstubbs, chani and seli. all i did was sit around and offer some suggestions on how to get what needed done (that was seli's input) in the plasma code, but jason did the actual coding work =) Chani also worked on the system tray stuff to get it up to that point before jason made the final fixes.
> the UI blocks considerably less
What an improvement... _Any_ ui blocking isn't acceptable nowadays.
Sluggish performance could happen from different reasons:
- kwin-composite is slow with repaints
- one application is locking stuff up (knotify4 for example).
- your widget theme causes problems.
- it's a debug build.
See if you can narrow the problem, you can help developers that way!
With only a few weeks left, the focus is making stuff work first. After that KDe developers can look at nice enhancements or performance improvements.
Would I be right in assuming a solid based replacement is lined up, or already implemented to replace the now removed plugin?
Yes, the plumbing in Kopete to use the KDE wide networkstatus service is already there and I'm working on NetworkManager 0.6 and 0.7 backends for this at the moment.
> We use now a dedicaced Multithreaded Thumbnail Loader instance from digiKam core for all kipi-plugins we need thumb. We never use default KDE thumbnails loader with all kipi-plugins running under digiKam.
Lovely, wouldn't it be cool to have this digikam thumbnail loader be default in KDE?
Another thing, I wonder how the digikam developers think about usability... for me, Digikam is horrible. Some features and things are great, but I would love a cleaner interface (eg get rid of the vertical sidebars, they make the app unusable). I'd say target an UI more like F-Spot or Picassa.. Better to steal properly and have something good than to develop something horrible yourself, right?
Don't get me wrong, I love much of what Digikam can do and the work being done on it, but I simply don't use it because the UI scares me away. And I think I can be considered a poweruser so it really must be (and is) bad.
So I wonder - do you guys need help from usability experts? If there are none with time to help, I would suggest just copying stuff from other UI's like F-spot...
Jos, I'm going to disagree with you on that point. I do tons of photo management and manipulation. I've tried F-spot and don't like it. I also don't care much for Picasa. They both seem targeted at the casual snapshooter. I can get a lot more done in less time with Digikam. Now, I'd agree that Digikam would benefit from some usability and UI tweaking. I just don't think that copying f-spot is the answer. (not that I claim to know the answer :-)
+1, on Linux, Digikam is the only app I use. I can't really stand Picasa, F-Spot, or (shudder) The Gimp.
I actually find Digikam very refreshing to use
I had a look at Picasa on another computer the other day, to me the whole things seemed like software that was rather dumbed down.
Digikam interface is not good, F-Spot interface is even worst (that widget in a line for navigate photos per time is useless), Picasa interface has it's problems, but it's, without doubt, the better of the 3.
Feature wise, the battle is between Digikam and Picasa.
IMHO Digikam interface is far better than F-Spot. For instance, showing the exif information in a separate window rather than in the sidebar is inconvenient for me.
Moreover F-Spot lacks many of Digikam features : preview of the effect of filters, kipi plugins, color management, ... it seems to me that Digikam display unblured pictures quicker. F-Spot is also lacking of a management of the quality of pictures (number of stars + filtering), even if it can be done using tags.
But Digikam could still steal some ideas. For instance having brightness, contrast, color, exposition, alltogether is nice.
In reply to your mail on the digikam users mailing list I already
gave a datailed account on the development process for digikam, see
http://mail.kde.org/pipermail/digikam-users/2007-November/004439.html
for details.
So for a constructive approach to improving digikam I strongly
suggest to make use of the possibilities listed there.
In particular I would like to emphasize
concrete proposals for modifications via entries in the bug tracker,
and even more importantly: code contributions.
IMO digiKam already passed Picasa and F-Spot level in its development. In discussions on mail lists, BKO entries, when talking about digiKam we are comparing with Adobe Bridge or FotoStation - industry heavyweights. It is no longer simple photo management app. And its level demands different interface than simpler tools.
If you want comparison in hardware compare controls of Nikon Coolpix camera and those of D300. Sure, in few places some refinements could be made but don't dumb down interface.
Eg. what replacement for vertical sidebars? I heard this complaint several times but no sensible proposition. And this type interface is well known for KDE users (Konqueror, Amarok).
> We use now a dedicaced Multithreaded Thumbnail Loader instance from digiKam >core for all kipi-plugins we need thumb. We never use default KDE thumbnails >loader with all kipi-plugins running under digiKam.
> Lovely, wouldn't it be cool to have this digikam thumbnail loader be default >in KDE?
Not agree... digiKam is an extragear application. It become outside KDE core. Who will maintain this code. Not me, i don't work on KDE core. I have no more free time for that.
Also, this way will add another big dependency to KDE core and will increase the complexity to maintain digiKam. So definitivly no way...
>Another thing, I wonder how the digikam developers think about usability... >for me, Digikam is horrible.
And for me this comment sound like a troll and a garbage. Continue to hurt developpers like this, and you will never see any progress in opensource world! So your request is definitivly rejected from me... This is a waste of time..
>Some features and things are great, but I would >love a cleaner interface (eg >get rid of the vertical sidebars, they make the >app unusable). I'd say target >an UI more like F-Spot or Picassa.. Better to >steal properly and have >something good than to develop something horrible >yourself, right?
The digiKam interface have been discuted with users. There re a lots of threads bout this subject in bugzilla. Do you know ???
>Don't get me wrong, I love much of what Digikam can do and the work being done >on it, but I simply don't use it because the UI scares me away. And I think I >can be considered a poweruser so it really must be (and is) bad.
>So I wonder - do you guys need help from usability experts? If there are none >with time to help, I would suggest just copying stuff from other UI's like >F-spot...
Well, you is free to use F-spot. Also, forget KDE and return to Gnome env. It certainly better...
Gilles Caulier
Your English doesn't make any sense.
I can understand it just fine.
Not everyone has English as their first language, you know.
Guess you should be happy that the default language for communication here *is* English. I wonder how well you'd be understood if this discussion were in [insert anyone else's native language]?
a quick note, i hope somebody still notices this :)
i might be dumb or ignorant (or both), but until last week i was reading only these introductions to digests - because i thought that's all there is. really, i never noticed that first link which... surprise, takes you to the actual digest !
i just thought it's a quick summary on commit and development stats.
maybe there is some way to promote actual digest link more, in case there's somebody other as silly as me ;)