KDE Commit Digest for July 22, 2005

Sunday, 24 July 2005 | Dkite

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.

Comments:

Statistics for the Week... - Anonymous - 2005-07-23

... is missing again.

Re: Statistics for the Week... - David P James - 2005-07-23

Oh, so that's why I can read it without a horizontal scrollbar showing up in Akregator...

Re: Statistics for the Week... - anonymous coward - 2005-07-23

From derek's blog: "Next on the shopping list is an uninterruptible power supply. As rsync was rsyncing the svn repository, the power went off and on very quickly. I think I got a corrupted file system in that partition, and it will take a while to get a working repository. The digest is getting it's data from anonsvn.kde.org (don't worry, it's cached). There won't be any statistics until I get things fixed."

First results from Summer of Code - ac - 2005-07-23

> Yolla Indria (yolla) committed a change to in HEAD > initial version of libppt (Google SoC project) Nice! Are there any updates as to whether this project is still on schedule, and how much can be done already? See http://developer.kde.org/summerofcode/pptimport.html

eh ? - ac - 2005-07-23

How comes the Linux Standard Base Project has declared GNOME as Standard Desktop for Linux ? http://www.linuxbase.org/modules.php?name=News&file=article&sid=61

Re: eh ? - Derek Kite - 2005-07-23

"Following libraries are essential for many desktop applications. They are not currently under consideration due to lack of resources:" referring to Qt, among others. Lack of resources is a nice way of saying lack of relevance and support in the real world. In other words, don't worry. Derek

Developer's Licences - gerry - 2005-07-24

For the slow class - I've just read the wiki on LSB, and the issues seems to be about the requirement for a developer to purchase a licence. I did not think that to be correct. My understanding is that (a) if you want to develop free software Trolltech are cool, (b) if you want to develop proprietary software Trolltech want money. Whatever one might think of point (b), regarding point (a) IIRC, everyone from RMS down seems to agree that Qt meets a free software definition. Anyone care to enlighten me and if there is no need to enlighten me, to offer their explanation about why the licensing doesn't meet the LSB standard?

Re: Developer's Licences - superstoned - 2005-07-24

i don't get it... they should dis-allow the LGPL, as it is bad for free software (it allows development of proprietary software without ANY contribution to the community. i think that is bad. the QT way of licensing forces everyone to contribute, either with code or with money. you recieve. you help. period).

Re: Developer's Licences - Scott Wheeler - 2005-07-24

You misunderstand the function of the LSB. They're an industry consortium primarily concerned with promoting a "standard base" for proprietary software vendors. Up to a point that's a good thing, but honestly most proprietary vendors don't really care much about which desktop libraries are installed as they care about where they're going to go when they're installed and that the ABI will stay stable. The LSB's more-proprietary-than-the-proprietary-guys stance has cost them quite a bit in terms of community buy-in. Roughly I'd say they have none in the OSS development community. It's not a huge surprise that the GNU project specifically is very anti-LSB. And that's a bit unfortunate since some of the conceptual goals aren't terrible.

Re: Developer's Licences - superstoned - 2005-07-24

well, if the LSB ppl are so commercially controlled, they probably try to make Trolltech LGPL their Qt... won't work, i guess, as that'll cost trolltech most of their income. pitty they are so stubborn (the LSB ppl, not trolltech).

Re: Developer's Licences - Morty - 2005-07-25

No! They are not commercially controlled, they live under some missconception that most commercially vendors have a problem with paying for their development tools. As said in the comment you answer to: "most proprietary vendors don't really care much about which desktop libraries are installed as they care about where they're going to go when they're installed and that the ABI will stay stable". Since serious business entities don't have a problem with it, they have either bought into the in the real-world-not-existing licensing problem or they are playing the politics/FUD game with the GPL/LGPL issue.

Re: Developer's Licences - Anon - 2005-07-24

Qt is free software now, as long as you don't want to sell proprietary software build on it (as we all know). Thing is I think most people think Linux is only good enough if it free (not as in beer not as in speech but as in cheapskate). For those that think so, paying for QT is a burden that would shoo developers away from Linux. My 2 cents.

Re: Developer's Licences - bangert - 2005-07-24

> My understanding is that > (a) if you want to develop free software > Trolltech are cool, > (b) if you want to develop proprietary software > Trolltech want money. This cannot be stressed enough! it basically is a better GPL because it also (meaning additionally) allows for commercial software development (in _exactly_ the same way as it would be on a Borland/Microsoft/whatever platform) i guess this license scheme should be dubbed BGPL (better GPL), which would be the opposite of LGPL (guess what the L is for) ;) yes - ESR annoys me these days

Re: Developer's Licences - superstoned - 2005-07-24

yeah, L stands for lesser :D

Re: eh ? - Anonymous Person - 2005-07-24

More information on this issue can be found on http://www.linuxbase.org/futures/ideas/issues/libqt/

Re: eh ? - mihnea - 2005-07-24

Because it's GPL so the LSB says it's not good. It doesn't meet their 'licensing criteria'. Of course, when wise people see that their criteria lead to absurd conculsions such as 'the/a real standard should not be th/ae real standard', they change their criteria to account for reality, they don't pretend to change reality to account for their criteria. Which brings us to the conclusion that the LSB people are not wise :) Considering that they also lack methods of coercion (I do hope they lack them :)), they are not dangerous and can be safely ignored.

Re: eh ? - rinse - 2005-07-24

>Because it's GPL so the LSB says it's not good. It doesn't meet their 'licensing criteria'. Which makes me wonder what kind of kernel lsb wil use :o)

Re: eh ? - ac - 2005-07-24

The FreeBSD one of course.

Re: eh ? - Kevin Krammer - 2005-07-24

The LSB somehow changed their goals. As far as I understand their original goal was to provide a common platform that ISVs could easily deploy their applications on. Nowadays their goal is to provide a common platform that makes development as cheap as possible. So while they initially (to my understanding) targeted the user machines, they now target the developer machines.

Re: eh ? - mihnea - 2005-07-24

All this licensing nonsense is getting tiresome. Telling somebody that a piece of software cannot be standard on GNU/Linux because it's being distributed under the GNU GPL is utterly absurd. We should no more debate this point. It is obvious that some people with deep emotional malfunctions (obsessive-compulsive syndrome, i suspect), who for certain reasons only known to themselves and their likes hate Qt, are trying to come up with a conspiracy and kill Qt/KDE. The point is, conspiracies don't work. Because reality is too complex for them, it's too complex for sophisticated plans. And if Adobe took them seriously, that was just a mistake on Adobe's side (of course, if many people repeat the mistake, certain regretable effects might occur, like bedirtyfying linux with primitive APIs)

Re: eh ? - Michael Thaler - 2005-07-24

KDE seems to be the most used open source desktop environement, KDE/Qt provide an excellent framework for developers to write applications. I don't think that it really matters what LSB/RedHat or whoever prefers, what really matters in the long run is technology. KDE/Qt IHMO offers developers an excelllent development framework and thus developers will chose KDE/Qt to develop applications and KDE/Qt applications will probably outdistance other applications in the long run because of that. And better applications means more users. Other toolkits can never outdistance KDE/Qt if they are actually technically inferior and if they make it harder to develop software using them. The only way to outdistance KDE/Qt is to create something that is technically superior and that makes large scale application development easier then with KDE/Qt. For now I don't see something like that.

Re: eh ? - debian user - 2005-07-24

"..what really matters in the long run is technology." ...said the marketing manager at Philips about their Video system... "And better applications means more users." ..was not exactly on the mind of the marketing manager at Sony when he was promoting VHS.

Re: eh ? - RobM - 2005-07-24

Porn works very well in KDE too, so I don't think it'll have the problems Video2000 had ;DDD Ciao, Rob!

Then prey tell - Guss - 2005-07-24

Why did Adobe, that has an investment in Qt (some of its MS-windows tools are now written with Qt, most notably photoshop album), has chosen GTK+ as the toolkit for their new Adobe Acrobat Reader for Linux ? They surely didn't have to take developer licensing costs into account (having already made that investment) ? So, why GTK+ and not Qt ? If I might hazard a guess, its because GTK+ made it into LSB and is expected to be available on LSB compatible platforms, while Qt isn't and integrating with it will potentially require more work. Unless Qt is added to LSB on the same level as Qt, we would possibly see more and more commercial applications forgo Qt in favor of GTK+.

Re: Then prey tell - Michael Thaler - 2005-07-24

I once heard that there is only one developer working on it and that this developer simply prefered gtk. I don't know if this is true.

Re: Then prey tell - rinse - 2005-07-24

acrobat reader is about 100 mb big onder Linux. So I don't think they were interested in a lsb-compliant system, they just put everything they need into the package. One of the consequences of adobes choise is that acroread does not interact well with Gnome, in dispite of the fact that they both use gtk..

Re: Then prey tell - Guss - 2005-07-24

So you all are basically saying that one of the largest software vendors in the world makes software development choices for one of its leading products, which are - based on personal preference of the developer in charge - inconsistent - stupid And by pure chance these lead to not choosing Qt. I somehow find it hard to believe. I think I have a better explanation: Adobe addresses a future where LSB compliant linux systems, containing libgtk+ (currently LSB still does not contain libgtk+) are the majority of Linux installations (regardless if any of these does or does not feature libqt), and in order to facilitate easy installation for user (and reduce binary size), they will have to build on GTK+. In the mean time, they have to package the GTK+ binaries, but that requirement is expected to be lifted at a future date, at which point the Adobe Acrobat Reader installation will be significantly reduced in size and complexity and will interact better with the underlying desktop system (which may or may not be GNOME). And this is a shame.

Re: Then prey tell - Michael Thaler - 2005-07-24

ldd /usr/bin/acroread not a dynamic executable acroread is statically linked against gtk+, it does not matter if you have gtk+ installed on your system or not. Although acroread uses gtk+, it has its own toolbar and things like Navigation tabs -> Articles do not look like they are done using gtk. Acroread is definitely not written using gtk, the gtk-UI looks more like a quick&dirty hack to get rid of the old motif UI which had serious problems like a non-working mouse wheel. Maybe it is just easier to port an existing app to gtk then to Qt because Qt more or less is a full development framework and it probably does not work very well if you mix it with other UI code like the toolbar acroread uses? But anyway, acroread is definitely not the kind of application I want to see on Linux because it is quite obvious that Adobe did not care much about the UI and if it integrates with any of the major OSS desktops.

Re: Then prey tell - mart - 2005-07-24

> Maybe it is just easier to port an existing app to gtk then to Qt because Qt more or less is a full development framework and it probably does not work very well if you mix it with other UI code like the toolbar acroread uses? Doubt it. See http://www.trolltech.com/products/qt/migrate/motif.html.

Re: Then prey tell - Maurizio Tomasi - 2006-01-11

ldd /usr/bin/acroread not a dynamic executable This message is fully understandable as the "acroread" program is a bash script which calls a binary executable. On my OpenSuse 10.0 system, the binary is /usr/local/Adobe/Acrobat7.0/Reader/intellinux/bin/acroread. Inspecting it with ldd gives to me: linux-gate.so.1 => (0xffffe000) libBIB.so => not found libACE.so => not found libAGM.so => not found libCoolType.so => not found libAXE16SharedExpat.so => not found libJP2K.so => not found libResAccess.so => not found libdl.so.2 => /lib/libdl.so.2 (0x4003e000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40042000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40050000) libgtk-x11-2.0.so.0 => /opt/gnome/lib/libgtk-x11-2.0.so.0 (0x40149000) libgdk-x11-2.0.so.0 => /opt/gnome/lib/libgdk-x11-2.0.so.0 (0x4043d000) libatk-1.0.so.0 => /opt/gnome/lib/libatk-1.0.so.0 (0x404bf000) libgdk_pixbuf-2.0.so.0 => /opt/gnome/lib/libgdk_pixbuf-2.0.so.0 (0x404d8000) libm.so.6 => /lib/tls/libm.so.6 (0x404ee000) libpangox-1.0.so.0 => /opt/gnome/lib/libpangox-1.0.so.0 (0x40514000) libpango-1.0.so.0 => /opt/gnome/lib/libpango-1.0.so.0 (0x4051f000) libgobject-2.0.so.0 => /opt/gnome/lib/libgobject-2.0.so.0 (0x40558000) libgmodule-2.0.so.0 => /opt/gnome/lib/libgmodule-2.0.so.0 (0x40592000) libglib-2.0.so.0 => /opt/gnome/lib/libglib-2.0.so.0 (0x40595000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0x4061d000) libgdk_pixbuf_xlib-2.0.so.0 => /opt/gnome/lib/libgdk_pixbuf_xlib-2.0.so.0 (0x4062f000) libc.so.6 => /lib/tls/libc.so.6 (0x4063e000) /lib/ld-linux.so.2 (0x40000000) libpangocairo-1.0.so.0 => /opt/gnome/lib/libpangocairo-1.0.so.0 (0x4075e000) libcairo.so.2 => /usr/lib/libcairo.so.2 (0x40765000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x407b2000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x40820000) libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0x40850000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0x40859000) libz.so.1 => /lib/libz.so.1 (0x40898000) libglitz.so.1 => /usr/lib/libglitz.so.1 (0x408ab000) libXrandr.so.2 => /usr/X11R6/lib/libXrandr.so.2 (0x408cf000) libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x408d3000) libXinerama.so.1 => /usr/X11R6/lib/libXinerama.so.1 (0x408db000) libXcursor.so.1 => /usr/X11R6/lib/libXcursor.so.1 (0x408df000) libXfixes.so.3 => /usr/X11R6/lib/libXfixes.so.3 (0x408e8000) libpangoft2-1.0.so.0 => /opt/gnome/lib/libpangoft2-1.0.so.0 (0x408ed000) libexpat.so.0 => /usr/lib/libexpat.so.0 (0x40912000)

Re: Then prey tell - rinse - 2005-07-24

>And by pure chance these lead to not choosing Qt. I somehow find it hard to believe. The fact that Qt is not a standard part of Windows did not stop them in using Qt for their photo album application. So why should the fact that Qt is not a standard part of Linux (although afaik every respectable Linux distribution includes Qt by default) make them decide not to use it?

Re: Then prey tell - David - 2005-07-24

"Why did Adobe, that has an investment in Qt (some of its MS-windows tools are now written with Qt, most notably photoshop album), has chosen GTK+ as the toolkit for their new Adobe Acrobat Reader for Linux ?" Because they had one developer working on it who preferred GTK, and what's more, he had absolutely no budget to go with it. "They surely didn't have to take developer licensing costs into account (having already made that investment) ? So, why GTK+ and not Qt ?" Because it isn't economically viable for using Qt yet. When it is, desktop Linux will have arrived. I'm sure Adobe spent lots of money on development tools for Windows, so why they feel they should they feel they shouldn't do so for Linux? "If I might hazard a guess, its because GTK+ made it into LSB and is expected to be available on LSB compatible platforms, while Qt isn't and integrating with it will potentially require more work." I doubt whether Adobe even knows the LSB exists, or even cares quite frankly. No one else does. "Unless Qt is added to LSB on the same level as Qt, we would possibly see more and more commercial applications forgo Qt in favor of GTK+." The reason why GTK is apparently chosen more for these sorts of things (not for a lot of *real* applications developed in companies out there though) is the fact that desktop Linux is not yet viable. Yes, you read that right - until Qt is more widely used and people see the need to pay for licenses, desktop Linux has not arrived.

G.N.O.M.E gnome nerds offer medieval environment - bb - 2005-07-24

Yes, you read that right - until Qt is more widely used and people see the need to pay for licenses, desktop Linux has not arrived. Desktop Linux has not yet arrived thanks to crappy gnome installed on major distros.

Re: G.N.O.M.E gnome nerds offer medieval environment - mark dufour - 2005-07-25

and that's a good thing, right? thanks to gnome, serious DE's under linux are not a monoculture. please leave setting deadlines for world domination to microsoft, and revel in the freedom of choice foss gives you.

Re: G.N.O.M.E gnome nerds offer medieval environme - David - 2005-07-25

"Desktop Linux has not yet arrived thanks to crappy gnome installed on major distros." Installed on what major distros? It certainly doesn't stop up to two-third of desktop users from using KDE.

Re: Then prey tell - Carlo - 2005-07-25

> Why [...] Adobe [...] has chosen GTK+ as the toolkit for their new Adobe Acrobat Reader for Linux ? Given that the Acrobat Reader 7 for Linux ist a fat and slow piece of software, that's annoying to work with, I'd be really interested what would be Adobe's answer.

Re: eh ? - ed - 2005-07-24

I don't know why LSB have decided for gnome but KDE -- last year's leader -- has increased its dominance, growing from 44 percent to 61 percent of respondants. GNOME 27 percent last year and 21 percent this year http://desktoplinux.com/articles/AT2127420238.html including gnome as standard desktop is a fucked political reasons.....

Re: eh ? - DB - 2005-07-24

I doub some poll in a forum full of KDE geeks is accurated, in that case, remember tha in www.osnews.com GNOME was the favorite DE.

Re: eh ? - Anonymous - 2005-07-24

It also won at linuxquestions.org by a nice margin. And osnews.com poll was not very fair... if you remember, they closed it before many people had a chance to vote.

Re: eh ? - DB - 2005-07-24

What im telling you, that those sites are visited by geeks, not the average user. The average user wont visit or vote in those places. If we take another stadistic, take for example distrowatch.com where ubuntu a full GNOME distro is in the number 1 position, kubuntu is to far from that. Polls are not reliable, can be biazed, exploded, etc. I don't believe the 60% of Linux user use KDE, I'd say a 40%.

Re: eh ? - Anonymous - 2005-07-24

"What im telling you, that those sites are visited by geeks, not the average user." Are there average users using Linux? ;-) What matters anyway is that KDE is a very important DE, used by too many people to exclude it from a "standard". It simply won't happen, IMHO.

Re: eh ? - DB - 2005-07-24

I think the same, but being the most used it doesn't mean that it has the be the one who will dicted the standars, it must be an important contributor, nothing else.

Re: eh ? - Anonymous Person - 2005-07-24

Just because Qt/KDE is not part of LSB, that does NOT stop distributions shipping it even if they are LSB-Compliant!

Re: eh ? - cm - 2005-07-24

> If we take another stadistic, take for example distrowatch.com where ubuntu a > full GNOME distro is in the number 1 position, kubuntu is to far from that. Not a good example since Kubuntu is not a fork of Ubuntu but part of the project. I always wondered why they listed it seperately. > I don't believe the 60% of Linux user use KDE, I'd say a 40%. Funny, first you criticise polls and then you just make up numbers of your own. How much more reliable can your estimate be?

Re: eh ? - David - 2005-07-24

"Polls are not reliable, can be biazed, exploded, etc." Wow, really? "I don't believe the 60% of Linux user use KDE, I'd say a 40%." Funny. Based on what, exactly? Is there a poll or survey somewhere?

Re: eh ? - Rick - 2005-07-25

Does people needs to be defensive here? Wtf is wrong with all of you. He is just guessing you assholes.

Re: eh ? - cm - 2005-07-25

> assholes Bzzzt. You're out. Go away.

Re: eh ? - cKahl - 2005-07-25

And the overreaction award goes to..

Re: eh ? - David - 2005-07-24

Wow. The LSB actually matter these days?! Given that most people are using KDE anyway, I doubt whether many people are going care whether their desktop is part of a standard base or not.

Re: eh ? - Robert - 2005-07-25

Is not about KDE, aren't you reading? it is about Qt, you can still use KDE but with GTK applications.

Re: eh ? - cm - 2005-07-25

I don't know what you're trying to say here... there's no KDE without Qt.

Re: eh ? - JB - 2005-07-25

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...

Re: eh ? - cm - 2005-07-25

> 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.

Re: eh ? - JB - 2005-07-25

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.

Re: eh ? - cm - 2005-07-25

> 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.

Re: eh ? - ac - 2005-07-26

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.

Re: eh ? - cm - 2005-07-26

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.

Use of threads for tabs in konqueror? - ac - 2005-07-24

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?

Re: Use of threads for tabs in konqueror? - ma - 2005-07-24

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 .

Re: Use of threads for tabs in konqueror? - koos - 2005-07-25

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.

Re: Use of threads for tabs in konqueror? - superstoned - 2005-07-27

then this is THE thing that should change... if KDE was more multi-threaded, it'd feel much faster...

but we need LSB - me - 2005-07-24

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

Re: but we need LSB - mihnea - 2005-07-24

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.

Re: but we need LSB - mihnea - 2005-07-24

> 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

Re: but we need LSB - Michael Thaler - 2005-07-24

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.

Re: but we need LSB - cm - 2005-07-24

> 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"...

Re: but we need LSB - ac - 2005-07-24

"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).

[ot] KDE 4 media player? - fast_rizwaan - 2005-07-25

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.

Re: [ot] KDE 4 media player? - c - 2005-07-25

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...

Re: [ot] KDE 4 media player? - superstoned - 2005-07-27

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.

Re: [ot] KDE 4 media player? - D. Rollings - 2005-07-25

What you refer to is not a software design issue, it's a patent issue. MPlayer with the codecs available at <a href="http://www.mplayerhq.hu/">its homepage in Hungary</a> 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.

Re: [ot] KDE 4 media player? - chris - 2005-07-25

can you please list the countries where its illegal ? please refer to the proper law and list the number of inhabitants.

Re: [ot] KDE 4 media player? - Morty - 2005-07-25

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.

Re: [ot] KDE 4 media player? - D. Rollings - 2005-07-25

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.

Multimedia backend framework decided ? - pingu - 2005-07-25

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

Re: Multimedia backend framework decided ? - ac - 2005-07-25

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).