Some highlights from this week's KDE Commit-Digest (all in one page):
Umbrello adds a Ruby code generator.
Kalzium now has a chemical equations solver.
New recurrence code for libkcal.
Kopete adds support for receiving AIM buddy icons.
Kopete supports Richtext formatting in Yahoo! Messages.
Dot Categories:
Comments
I don't know what you're trying to say here... there's no KDE without Qt.
Don't confuse KDE qith Qt, one is a toolkit and the other a DE.
KDE may exist in a GPL world and still survive in the comercial world because you can use GTK apps with KDE, Qt by the other hand...
> Don't confuse KDE qith Qt, one is a toolkit and the other a DE.
I know pretty well what both KDE and Qt are.
> KDE may exist in a GPL world and still survive in the comercial world because
> you can use GTK apps with KDE, Qt by the other hand...
Qt can survive in both, too, so what's your point?
But anyway, I don't *want* to use GTK apps, proprietary or not, but I'd like to see KDE ones. I want to have apps that integrate nicely (design- and feature-wise) into KDE and make use of the great KDE features like IO slaves.
What affects Qt not necesry afects KDe and what afects KDE don't necesry afects Qt.
About the integration of applications that's what freedesktop.org is for, it doesn't matter what DE are you using it will be integrated, that's the importance of KDE using Freedesktop standars.
> What affects Qt not necesry afects KDe and what afects KDE don't necesry afects Qt.
It does. KDE depends a lot on the great work from Trolltech and their sustained development effort. I don't think it makes much sense to investigate them separately.
> About the integration of applications that's what freedesktop.org is for, it
> doesn't matter what DE are you using it will be integrated, that's the
> importance of KDE using Freedesktop standars.
Freedesktop is about *de-facto* standards (it puts stuff that is already widely accepted into written form). I have little hope that there will be a VFS implementation that is acceptable to all (the IO slaves won't be accepted by GNOME because they depend on Qt). So I don't see any such standard on the horizon.
No, fd.o is neither about standards nor de-facto standards, it's a test bed for creating and improving new technology which can be used by existing free desktop environments. The 'making standards' part is out of reach for fd.o, and promotion of existing technology at fd.o as well as an open ear for the existing free desktop environments' actual needs is rather lacking at the moment.
I did not talk about *making* standards. Only you did.
I was talking about http://www.freedesktop.org/wiki/Standards . That's a list of the specifications that people working on freedesktop have written up, e.g. they recorded the way menus or icon themes are defined. Note the remarks about the varying degrees of acceptance.
Yes, I know there's a software section (I guess that's the test bed you were referring to...). There's nothing there that offers the features of the IO slaves, let alone in a compatible manner.
Often when surfing with konqueror I middle-click on a link to open it in a new
tab and then continue reading/scrolling the page I was on, but then, as the
page in the new tab loads, the scrolling blocks for a short moment.
This is annoying, and I wonder if there are any plans to let each tab run in
its own thread? That should help to improve this situation, or am I wrong?
first and for most tab in konqi are in different thread , the problem is with the plugins the plugin handler is blocking till it done .
Konqueror/khtml are in no way multi-threaded. Where did you read that nonsense, because writing multi threaded GUI in Qt3 is almost impossible, only one thread can access the Qt framework at a time.
Blocking in khtml is mostly because the DOM tree needs re-layout or some script requires quite some CPU. Some plugins may block as well, but the ones for flash/video/java all use an external program for that, that doesn't block.
then this is THE thing that should change... if KDE was more multi-threaded, it'd feel much faster...
i use KDE most almost all the time but i still think that lsb is the only future for linux in order not fragment like unix to a bench of incompatible OS's and to be able to get software makers porting theirs product to linux, only one port not as much ports as distros..
so it's not just about the best and the most used.. its about the future of linux
In order for LSB to be what you claim it to be, it has to become a standard. But in order for it to become a standard, it has to formalize real, living standards. And since it is pretty much obvious that one can expect a Qt app to work in linux, not including Qt in the standard makes for a dead standard. It is not a standard for linux, it's a standard for something else.
Now i don't kno whom you mean when you say that "we need lsb", but as long as the lsb doesn't act reasonably, it's not the linux community who needs it.
> so it's not just about the best and the most used.. its about the future of linux
sorry for replying twice, but yes, the future of linux _is_ about the best and the most used
A year ago people tried to push UserLinux as a standard for the corporate desktop, again based on gtk. In addition, UserLinux should not include qt in the base distribution at all. I suppose it completely failed or does anybody know what happened to it? I think the problem is, that these people always push what the like personanly and not what their customers like to use and that is, why they fail. On Windows, people develop using C++/Java/.Net, on MacOSX developers use Objective-C/Cocoa and the future of Linux should be based on C and gtk? How many companies will develop for Linux if they should do it with C/gtk? I really think the LSB people and others should start looking what people actually use to develop for Linux and then they should try to build their standards on this, otherwise they will just fail in the same way as UserLinux or other stuff that totally neglected reallity.
> How many companies will develop for Linux if they should do it with C/gtk?
Depending on who you ask in the GNOME camp the reply to this will either be "but we have language bindings" or "but we have Mono"...
"its about the future of linux"
LSB should rather be about FreeBSD since according to their Selection Criteria at http://www.linuxbase.org/futures/criteria/ just like Qt also the Linux kernel is violating their 'License' rule as elaborated in the above link:
"The component should have at least one compliant implementation available under an Open Source license that also promotes a "No Strings Attached" environment for developers. This means that the developer would be able to develop and deploy their software however they choose using at least one standard implementation. This is interpreted to mean that at least one implementation is available under a license that meets the Open Source Definition but is *does not prohibit propriatry usage*. The rationale for this criteria is very similar to that of the LGPL."
It's particularly ironic in this regard that actually Qt prohibit proprietary use less (you can do that for money, otherwise its GPL) than the Linux kernel (you can only do that in userland, otherwise its GPL).
Could someone please apprise me of the state of KDE 4 media player, and could it play all video and audio formats (including embedded media) and VCD/DVD etc.? Just eager to have a good media player which can do what too many media players are trying (kaffeine, codeine, kmplayer, kplayer, amarok, juk, etc.). thanks.
also could we please stop coming up with "multimedia" players that cannot play video (how is it "multi"?) and image tools that cannot edit?
so i have to stop amarok and open kplayer just to play a video. as for midi support in either of them...
even better, can we kill ALL multimedia players? and just use music players to play music, and video players to play video? 90% of amarok's features are useless for video, as are most features a videoplayer should have. don't mix these two apps. i don't want to have to stop amarok to view a video. i want at most to hit pause (or just lower amarok's volume) and then click and watch the video in kmplayer, codeine or (as i prefer) in kaffeine.
the person that invented the 'multimediaplayer' should be burned.
What you refer to is not a software design issue, it's a patent issue. MPlayer with the codecs available at its homepage in Hungary can smoothly play almost every video file my copy of WMP can after I've gotten codecs from all over. Smoothly, I say, because I've taken great care to use hardware with driver support for hardware mixing and good video drivers to boot.
Unfortunately, those codecs aren't legal to download in many countries, and the fact that it makes life difficult for Unix users is just unfair.
can you please list the countries where its illegal ?
please refer to the proper law and list the number of inhabitants.
Most I'll say, because MPlayer makes heavy use of codecs from Microsoft so redistribution of those becomes problematic according to most nations copyright laws.
Assuming that you want those codecs for your FLOSS system, nearly all Western countries. The problem is that there is no license agreement for such a distribution; they're targetted at software packages for Windows or the Mac. It's shenanigans, of course.
Hello,
Has kde decided on using multimedia framework ?nmm/gst etc ? since arts is not being used for kde 4 ? whats the status for multimedia on kde4 ?
cheers
There will be a simple abstracted multimedia API so that even if KDE 4 should default to a single multimedia framework exchanging it with another one or leaving such away won't be hard (the lesson learned from the current hard dependency on aRTs actually).