In this week's KDE Commit-Digest: Significant progress in Colour Mixing in Krita. A new, more usable sidebar for okular. International Date Line support, and the merge of Summer of Code work in Marble. Solid is used for hardware detection in Digikam. KRunner uses Strigi for filename-based searches. The ability to switch cursor themes without restarting KDE. Timelines for multiple timezones, rich-text support and other journal improvements in KOrganizer. Support for storing bookmarks in Akonadi. Initial porting of the Kollision game to QGraphicsView. Support for KNewStuff2 in KWordQuiz and KVocTrain; KNewStuff2 support (and the spectrum viewer) removed in Kalzium until KDE 4.1. Initial import of Blitz, an improved graphical effect and filter library for KDE 4.0.
Comments
That's what Kubelka and Munk were originally interested in: calculating the reflectivity of metal flakes in a suspension. In a funny way it turned out to work for non-metallic pigments, too.
I don't know of any work on simulating metallic colors on a computer screen using K-M, though. It should be an interesting research area. People have done a Phd on similar stuff.
Horray for solving this bug/feature:
Bruno Virlet committed changes in /trunk/KDE/kdepim/korganizer:
Possibility to add timelines for different timezones.
Bug 18726: korganizer multiple timelines for timezone differences
It means another very old bug (around 2400 days) has been solved.
The previous one that was about this old, had an age of (only ;) ) 2000 days,
and was solved by Thomas Zander.
I haven't heard anything about Quanta (and Eric) for a very long time. What can we expect from it for KDE 4.x. Thanks!!
I second that. I hope a less clutered interface and perhaps integrated PHP debugging :D
hello!
does anybody of you know about the release plans of LinuxMCE for KDE4? Wasn't it the plan at the beginning to deliver it LinuxMCE with KDE4.0? I hope someone could answer this question and the following one ^^:
will LinuxMCE use plasma? In my opinion this would be a really good idea and it would make the interface look more united into kde. At the moment the latest version (0704) isn't really stable and fast (and i've got a dual core cpu and 2gb ram).. so why is it so slow? (i've got the kubuntu+linuxmce dvd from the servers)
hope you've got some answers for me
Bernhard
I think you will hear more about this really soon...
thx for the answer.. i'm dieing waiting for some news ^^
Yeap, I believe Aseigo alluded to an upcoming announcement concerning LinuxMCE in a recent blog post of his. Just stay tuned: I'm sure there'll be interesting news soon.
yeah.. i've also read it... because of these announcements i can't wait ^^ always this little word... soon.. brr..
well.. to all guys who develop or review or anything else on kde: take the time you need and don't hear to me and the other guys who can't await anything ^^
I'd like also to know if it's gonna using still vdr as tv backend or if
it will have a standalone method (I hope as customizable as the one in freevo)
to look and record TV shows. Not all of us are interested in using our MCE
as a live-vdr thus recording continuously to hard-disk.
yes, i'm working on a story for theDot here. we got a submission but it was a bit on the short and boring side. unfortunately it arrived just as my semi-vacation was starting and then i ended up talking with the linuxMCE people which only brought in more information for me to assimilate =) but it'll be here.
and no, the plan never was to bring it in for 4.0, but the work it in post-4.0 (whether that means an interim linuxMCE/KDE release between 4.0 and 4.1 or just releasing with 4.1 proper is yet to be confirmed). there is a prototype version available right now based on kde3, which is what the upcoming article will cover.
I literally wait and very passionately read commit digests! Keep the great work up!
I've noticed something minor yesterday. On the same machine, when you double-click on a desktop folder on Windows the explorer opens _instantly_. When you try the same on KDE's desktop, even though I have set konqueror to be preloaded (and checked it shows on 'ps' listing and it shows on kdcop too), it doesn't feel instant. It feels like it needs 0.4-0.7 seconds to come up.
Why is that? No further optimization possible?
yeah.. i've got the same feeling about the performance of konqueror (maybe also dolphin.. can't remember atm ^^)
i'm experiencing this with all apps in linux.
maybe new CFS scheduler will change the situation?
Well, I don't know how preloading works with Konq, but I assume we can probably preload it to the point where it's just a matter of calling .show()...
Yes, but AFAIK konqueror can only go as fast as to force some instance to create another window. And it takes some time.
I have hacked some time ago something faster - spawning hidden instances of konqueror with prepared windows and just telling it to show() using DCOP.
The code (quick and dirty) is here:
http://ola-os.com/inne/konqffm/konqffm-0.1.tgz
Usage:
- apply patch to konqueror, recompile, install
- Start konqffm.py - it stays in system tray and manages hidden instances.
- Install desktop files and in directory properties move "Konqueror FFM" to top, so that opening directories is handled by FFM code.
Desktop files provide fallback to standard kfmclient if konqffm.py is not running.
I don't think it's a matter of optimization.
I'm currently on Windows, and each time I open up an Explorer window it instantly shows *without* contents (just the interface parts). It takes a bit less than a second to show the contents of the folder.
Showing the UI right away is what makes Explorer feel so 'fast'.
It's a kernel issue. You not only need to preload konqueror, you also need to pin it in memory. The linux kernel doesn't preload pages the user might often need access to fast, and it doesn't provide hinting mechanisms for the desktop to suggest such things. The Linux kernel really isn't optimized nor designed for desktop usage.
sorry, but thats just spreading FUD from several kernel threads we had recently. There is no truth in the above. Simple test; try the same on a machine with nothing in swap.
I suggest profiling the stuff to see where the real time comes from and you will notice that a large chunk of waiting time is in X11. Well, we know that X11 is a bit behind in advancing the state of the art ;)
We'll get there.
hm.. i don't know if it's just me but imho X11 seems to be the most unstable part of linux (distributions). at least it needs some improvements (hotplugging of devices (i know xrandr 1.2)) easier configuration (without xorg.conf) and improvements on switching between sessions also needs to be improved so that it doesn't flicker when xorg kills itself and starts itself and so on (4 times on my ati system :-( (isn't there a project which implements grafics support into the kernel to improves this situation).
this was just my subjective view of the things and i would appreciate if someone who really knows this whole stuff would correct me if i'm wrong.
The project xorg is the better version of xfree which had some bad management and eventually died (as far as free software can die). The result is that only some time ago (2 years?) xorg got new blood and started becoming alive.
In other words; its true that a lot of work needs to go into that code base. And if you are a developer you should consider joining them. For the benefit of all free desktops :)
ok.. thx for that clarification. yes i'm a developer but sadly i haven't got time for these things atm :-( i need to work on 2 other projects atm and personally i would like it more to work on KDE4 ^^ but we'll see... maybe i've got time and skill enough to work on both *hope so* ^^
friendly greetings
Bernhard
I am not only talking about swap, I am also talking about buffers and cache, the whole interconnected shebang of VM. Konqueror loads various plugins and scans sycoca database. These are files that could be speculatively preloaded into cache, and are in all desktop versions of Windows (since W2K). Konqueror could be rewritten to not do this things and X.org could be rewritten to require fewer context switches, but in all cases that is just working around deficiencies in the kernel.
You know, when Windows desktop dies, the way I normally restart it, is getting the task manager and from the File menu choose 'New Task (Run...)' and type 'explorer'. So it _seems_ like their desktop and explorer is actually the same thing.
On the other hand, we have two separate applications kdesktop and konqueror.
I am not saying (in fact I can't say that due to lack of knowledge) that it's not a kernel deficiency, but it might be (also) a design issue.
Yeah, I heard someone else push those patches based on the logic that in one usecase it makes a difference to get things from disk into mem before the user realizes he needs it.
Unfortunately this conceptually can't scale. You can't optimize for one usecase and not make a lot of other usecases get worse. And that is why it didn't get into the kernel, not because someone thought the desktop is not cool or whatever.
Bad ideas die, fact of open source life ;)
its a pitty :
http://www.golem.de/0708/54109.html
sophisticated sound technology , cross plattform , ... :/ and not in kde 4.0
what OS includes NMM by default? and given the design of phonon, all it would take is for some even mildly motivated hacker to step up and complete the backend. that, really, is the problem here.
some people are sad that phonon-nmm is out in playground now, but that wasn't a centralized decision that was made. it was the direct result of virtually zero interest from *anyone* to work on it. which, to me, says volumes about the vitality of the nmm development community.
yeah, it's a cool technology. but it takes more than cool technology. it also takes people doing that "last mile" of work to make sure it is available to people.
honestly, i can't really think of anything more useful the nmm development community could do in the effort to spread the usage of their technology than to get that phonon backend together. it's not a huge amount of work, particularly for someone already familiar with nmm, and would bring a large number of apps to nmm.
I suspect it's also because aside from nebulous claims about it being cool and the integrated network being the future, NMM is doing a poor job of explaining why anyone should care about it.
I can't think of the last time I wanted to take advantage of or control "remote multimedia devices or software components". Perhaps if I was building a dedicated multimedia machine, but for a normal desktop? Am I missing something here? Why should the average user care about NMM?
well, the average user shouldn't, because thats the job of the developers. nmm is about the "future of entertainment" (or electronics in general, everything is going to be connected somehow...). look at stuff like http://www.apple.com/appletv/ .
the point is, things like that only will happen of the infrastructure is there. if kde ships with nmm it would be a huge success for nmm. i don't know why they (the nmm developers, that is) don't put more effort in this... getting nmm on computers today will get you cool applications for it much sooner.
nmm, kde and linuxmce collaborating would be really interesting, at least to me.
who cares about nmm... or anything else really. the point about phonon is just that it has to work and play all the media files. the backend is really unimportant, or does anybody really think sound sounds better coming from nmm than from xine?
personally i am really fond of vlc (because it works and they decided to go for qt4 ;) ) and hoped for the vlc-backend-soc-projet to be accepted, but really it doesnt matter, as long as the thing works!!!
the point is, phonon will only do what its backend is able of. so nmm should be important to you, because it does much more than xine... maybe you should look up what nmm is about.
Hehe, with the integration of phonon in Qt4.4, maybe VLC team will separate their soft in one UI and a phonon backend.
would be so nice.
To me it looks like the NMM people have done a lot(1) getting Phonon backends together, way more than any comunity from the other backends. Most files are copyright Motama, the guys behind NMM.
And with 1.0 released yesterday, a guess may be they have been prioritizing getting it ready before concentrating on the Phonon backend. Much like how the Plasma developers have been concentrating on building the libraries rather than writing plasmoids :-)
(1) Based on copyright in the backend files, the history is not avaliable in websvn due to the move to playground.
NMM can be cool, but at the moment it's just a toy. The last I tried it it was so damn hard to compile it I doubt any distributions will include it.
The way forward right now is Xine. It has been around for years and it works, despite the GStreamer coming we've all heard about.
Not only that, but it seems fairly simple to program an interface to xine, seeing the number of apps using it and the apparent ease of creating xine's phonon backend.
Actually, in the current state of things, I don't see Gstreamer or NMM bringing anything on the table which would be that interesting for a simple desktop.
If they bring in multimedia framework, allowing edition as well as playing, i.e. creating of powerful editing tools as well as media players, that would be interesting. But Im' not sure Phonon is ready for this either.
Answering to myself : well, NMM could bring portability, which would be cool.
Seems a Phonon backend is included in 1.0.
It is indeed interesting and certainly powerful, but I think its use is more in companies and bigger structures than the regular joe.
Normally, each 2 week, i post some screenshot on the dot (in the digest news), but this week, i am unable to do it. If someone find how to solve my problem, i will post some screenshot again. Everythings compil well unless 43% in kdelibs
[ 43%] Built target kcm_phonon
/usr/bin/make -f solid/solid/CMakeFiles/solid_static.dir/build.make solid/solid/CMakeFiles/solid_static.dir/depend
make[2]: Entering directory `/home/kde-devel/kde/build/kdelibs'
solid/solid/CMakeFiles/solid_static.dir/depend.make:1: warning: NUL character seen; rest of line ignored
solid/solid/CMakeFiles/solid_static.dir/depend.make:1: *** missing separator. Stop.
make[2]: Leaving directory `/home/kde-devel/kde/build/kdelibs'
make[1]: *** [solid/solid/CMakeFiles/solid_static.dir/all] Error 2
make[1]: Leaving directory `/home/kde-devel/kde/build/kdelibs'
make: *** [all] Error 2
makeobj[0]: Leaving directory `/home/kde-devel/kde/build/kdelibs'
The make file is binary, i cant edit it. And my hard drive died, i copied the kde account to the new drive, this can be the problem, but i did a chmod 777 -r on it, so it is not a permission error.
"The make file is binary" ?
It should be a text file, something like:
# CMAKE generated file: DO NOT EDIT!
# Generated by "Unix Makefiles" Generator, CMake Version 2.4
kdecore/CMakeFiles/kdecore.dir/fakes.o: /home/alex/src/KDE/kdelibs/kdecore/fakes.c
kdecore/CMakeFiles/kdecore.dir/fakes.o: /home/alex/src/KDE/kdelibs/kdecore/kdecore_export.h
kdecore/CMakeFiles/kdecore.dir/fakes.o: /opt/qt4/include/QtCore/qconfig.h
If it's not, it has been damaged due to your disk problems.
Alex