In this week's KDE Commit-Digest: kdesu, the KDE application privileges manager, gets long-awaited support for the sudo method. Strigi gets .rpm and .deb package contents indexing capabilities, and can now index UTF-8 encoded text. Guidance gets a new power manager applet. Code import for the Physiks educational Summer Of Code project. Amarok gets support for MTP media devices. Work starts on porting KGoldRunner to KDE 4. Rewrites begin in the KReversi game and Oskar media player. GUI optimisations in KTorrent and KTU (KDE Translation Updater). Experiments using Kexi as a database backend in KPhotoAlbum, and rendering SVG in Unity.
Dot Categories:
Comments
What's KTU?
In the digest it says KTU (KDE Translation Updater), it's something introduced into SVN 2 weeks ago it seems. For more info and screenshots look in last weeks digest, here is a snip:
"The idea is to create an interface to fetch translations straight from KDE SVN and install them for the user. Translations can be downloaded and installed on a per-application basis."
like Firefox autoupdates on windows?
Will this work for Klik packaged applications as well? Will it break your package management software?
Are translations to be stored in home?
This is just for translations, I thought the Firefox updater did the whole application.
The way I read it, the translations get instaled on a per user base. That means install in home, and not interfer with your packagemangemnet software. As for working with Klik, I havn't the faintest idea. I guess it depends on how klik packages handles translations.
KTU downloads po-files from KDE's SVN, compiles them to mo-files and puts them into ~/.kde/share/locale/your_language/LC_MESSAGES
If you start a kde application, it will first look in $KDEDIR/share/locale/your_language/LC_MESSAGES for a translation, then in ~/.kde/share/locale/your_language/LC_MESSAGES and will use the latter if it exists.
KTU is handy for updating translations if an application was only partially translated during the release and is now fully translated available in SVN, for updating a translation after fixing errors, and for easy integration of your own translating work in exisiting installations (after your coordinator has proofread them and put them into SVN ;).
Will strigi be renamed tenor?
When is the Release of the kde Techology preview?
Is there somthing planned ?
oktober, on the 10th 'birthday' of KDE. a snapshot might come soon, but it's really really useless for non-developers... it won't show you even the smallest exciting thing. well, a few small things, like a smooth Kstars, and some random very small things, but not much to show off i'm afraid ;-)
So when will KDE 4 and all the programs assoicated with it be ready. 2007, 2008 ?
Will most apps be a true port or will the be using some kind of KDE3 library. Will KDE 4 boot even faster or will it boot slower. The reason I ask is QT4 is still slower then then QT3.
> So when will KDE 4 and all the programs assoicated with it be ready. 2007, 2008 ?
Not 2006 :p I guess Q2 2007.
> Will most apps be a true port or will the be using some kind of KDE3 library.
It might be that the one or other apps use some Q3Foo-classes but that doesn't mean they aren't true Qt4 apps. They are using 99.9% Qt4-classes and the one left-over from Qt3 for example.
But many apps are pure Qt4 *today* (in svn trunk, of course).
> Will KDE 4 boot even faster or will it boot slower. The reason I ask is QT4 is still slower then then QT3.
Qt4 is way faster in most things than Qt3. But startup time is not only based on Qt3/Qt4 but also which parts of KDE are loaded, in which order, how much they are optimized, ...
Guidance looks promising.
Will kwine also be included?
I think guidance is a set of configuration modules. Kwine is a set of tools to integrate KDE with wine, among them a cnfiguration module. So it can't be included in Guidance, but it can be included with the default KDE distribution.
Besides that, Guidance contains a module for wine configuration.
Guidance includes a module for wine configuration ("wineconfig"), which is nearing completion and includes everything from winecfg and a few extra settings.
kwine is a different project that includes various pieces to improve wine/kde integration. Its features won't (at least yet) be included in guidance.
So are you gonna replace khtml with Unity? that would be great
and why would that be great? it has not yet been determined that apples tree is better than khtml..
More developers working on the same codebase is a good idea IMHO. In particular as the both engines are derived from the same parent and thus current development appears to be a duplication of efforts (and thus a waste of resources). This is different from KHTML vs. Gecko where the code base has "nothing" in common and the design philosophy seems to be different, too.
More chefs only spoil the dinner unless they can can cooperate.
it is my understanding that KHTML offers more than enough places, where work is needed. I never saw any comment of any KHTML developer complaining about too much men power. Thus I assume the kitchen is big enough to keep all chefs happy ;-)
The above comment was from a KHTML developer, FYI.
There are no such plans at the time.
I have to say this is very sadEagle
*giggle*
Hehe, I myself wasn't really on the edge of my seat aching and waiting for the sudo patch or anything but I had stumbled accross the bug report at one point after switching to Kubuntu then trying to build KDE from source and wondering why my passwords stopped working :). Good to see Jonathan Riddell's year old patch is finally merged... I imagine he's been busy elsewhere helping make Kubuntu and KDE rock.
Great digest, thank you. BTW, who is Andreas Kling?
[Offtopic]
Commits: 2331 by 197 developers, 5139 lines modified, 1787 new files.
How is this statistics created? With the help from SVN or some other thing? I have a SVN server and would like to know how this can be done.
[/Offtopic]
its done probably with a small script issuing a few svn commands..
Thanks for info. Anyone knows which commands, the only one that seems to me to be the right one is svn diff, with some scripts that parse output.
Ask the author of the digest.
Look at the kde svn repository for areas/cvs-digest. Find a perl script called stat_svn.pl.
You pass two numbers, starting and ending commits. It iterates through each commit.
Danny does something similar.
Derek
Is there any place where we can read on progress regarding the various SoC projects? Specifically, I'm interested in progress on avKode, the ffmpeg backend for Phonon.
Cia is the page with progress report on various OSS projects. http://cia.navi.cx/
To be more helpful, http://cia.navi.cx/stats/author/carewolf :)
Is it possible for distro packagers to pre-package the indexes of known docs like those in th the /usr/share/doc tree so that when initial installs or system updates are done the indexes for the new/updated doco could be added directly to the system's index file without having to traverse a bunch of known ahead of time content?
yes they can
I can understand most of the measures but what the heck is 'Buzz'?
What's it supposed to be and how is it measured?
Hi,
"Buzz" is the name I give to a rating that I generate from several components, including commit activity, mentions on webpages, and short-term news and discussion (eg. blogs). These are added together to produce the score. Of course, the scores are not completely scientific, and are meant as a way to measure "popularity" relative to the other calculated scores.
Thanks,
Danny
We already have too many half-baked multimedia pps (NoAtun, Kaffeine, Kodeine, Amarok, Juk, KMPlayer, KMIDI, KSCD, etc). Developers should _work together_ to improve the best of these apps and not reinvent the wheel poorly everytime.
I know there is learning curve to reading someone else's code, but in the end you'll get a better, more professional, more finished, and more usable product if you build on other people's work.
I certainly wouldn't put Amarok in a list of "half-baked" multimedia applications. In fact it is better than commercial rivals such as Windows Media Player and iTunes in many ways.
I agree that it would be nice to see a KDE video player of the same quality as amarok, but there is no point telling developers that they should or should not work on a project. Most are non-paid volunteers after all.
But the good news is that if you see an area of KDE or a program that needs improvement, you have the freedom to get involved and make it happen :)
>>I certainly wouldn't put Amarok in a list of "half-baked" multimedia applications.
Same goes for juk, kaffeine, kmplayer, ....
Those applications are quite complete, very usable and certainly not half baked.
True, not all of them are loaded with features, but not every user wants a complex application that is stuffed with functionality that he/she will never use....
Kaffeine and KMplayer certainly are half baked, though Kaffeine in particular is getting there. The simple truth is that neither is stable enough to use, and I think the fact that neither ships with KDE is a reflection on this. Noatun and KSCD are finished in that they do what they're designed to and do it well, but we really don't have a good video player. I don't understand why, given their position on the bloat/features tradeoff when it comes to everything else, the amarok developers don't add video playback, but they haven't, and as it is a good video player is something we're lacking, especially in contrast to Totem. And whilst I certainly agree with letting anyone work on any player they want, I think the interests of KDE as a whole would be better served by picking one best candidate (Kaffeine would be my preference, but I'd prefer KMplayer being chosen to the situation we currently have), calling it the official KDE video player, and focussing attention and marketing on it.
IMHO, Codeine is the most complete and well-designed apps. Maybe because it's goals are so simple ('KISS'), but it's very well accomplished.
http://www.methylblue.com/codeine/
Been using it for some time, and it's very stable.
how to change volume in it?
i press "1" it shows kinda slider but i cant change anything
and btw it just crashed after closing it
ii codeine 1.0.1-3.dfsg-1 Simple KDE video player
> neither is stable enough to use
I use Debian Sarge (with Kaffeine 0.6) and Ubuntu Dapper (with Kaffeine 0.7.1), and both Kaffeine versions hardly ever crash when I'm using them. (The Kaffeine in Ubuntu Hoary, however, did crash often.)
The latest Kaffeine (0.8) just rocks. I wonder what your problem is. Particularly Totem shouldn't be a competitor to be mentioned.
If there are any problems playing videos it is sibject to the video backend (xine). For playing wmv's and avi's the right Windows codecs must be installed. The GUI is nice, stable and very usable.
kaffeine, kmplayer and kplayer all run stable on my machine. If they don't run stable on your computer, then it must be a problem with your setup i guess.
Did you file bugreports about your problems?
Totem is a rather simple video player, probably comparable with kmplayer, but not with kaffeine.
Amarok is a jukebox, not a versatile mediaplayer that should also play video.
Perhaps that changes in the future, when portable videoplayers become more common...
> But the good news is that if you see an area of KDE or a program that needs
> improvement, you have the freedom to get involved and make it happen :)
But the bad news is that if you are lucky that this effort will be met with simple indifference; if you are unlucky it will be met with open hostility.
This is probably why people start a new project rather than working on improving an existing one.
Developers need to decide if this is about them, or if it is about the product.
Not again :-(
See http://dot.kde.org/1139614608/1139690807/1139762954/1139768731/113981002...
> Not again
Did you some how expect that the problem would just go away?
> Contrary to popular belief, developers are not machines. They have heart,
> they have feelings.
The same can probably be said of engineers, but we have learned to get over it. :-)
What have we learned to get over? We avoid investing too much emotional capitol in our way of doing something. Instead, we have learned to derive our emotional satisfaction from how good the final product is.
And as I have said before, engineers are direct to the point of being blunt.
So, to be blunt: Developers have too much ego and this gets in the way of making the best product that we could. They need to get over it; this really *will* result in a better product. Otherwise, people will write HIG (CHI) guidelines and write usability report and neither will do any good because developers think that "those who do the work decide" means 'those who write the code decide' -- that writing the code is what 'the work' is.
No, I don't expect that the problem would just go away.
And do you somehow expect that the assertion that you post here again and again would make the problem go away?
As for your engineers comparison, I already have my theory in http://dot.kde.org/1139614608/1139690807/1139762954/1139768731/113981002...
Basically you did not compare the same thing.
Imagine I'm an engineer working on a gigabit optical transmitter. A big customer complaints to the company, "Look, your transmitters are crap. The laser frequency keeps changing every millisecond" and the marketing departement consults me about this problem. Surely I must take this into account for further product development, or else my manager won't be happy.
And if at the same I spend endless hours building couple of BEAM-based insect robots as a hobby, and then a coworker comes over to my office and says (bluntly), "Look, your insects are crap. They're ugly and useless. How about a talking dog?" and I'll be sure to ban this dude from my place. Not that my insects can fly. Not that my insects can talk. Not that my insects are beautiful.
It's my baby. If you attack my baby, you'd better be nice! Not that my baby can fly. Not that my baby can talk. Not that my baby is good looking. Not that my baby is genius. Not that I don't you to attack my baby. You can e-mail me bazillion times that this *will* result in a better baby (and technically I agree with you, no little objection at all), but it's *my baby* you're criticizing. You should consider the non-technical things as well, like the way you're talking about it.
And for the "too much ego" things, I can't recall any of KDE developers (that I know) have that. You should back your statement with facts. Otherwise, those included in the "developers" part might claim that you are the one who actually starts that "open hostility".