Kernel Cousin KDE is back! Issue #44 is now up, featuring everything from a summary of KMail developments to Qt GStreamer bindings, Kopete news and much more. Grab it here.
How will the GStreamer bindings gel with KDE's current multimedia framework and applications? The KC mentioned that a KVideoWidget was on the way and that older apps could be easily ported? Any more news on this? Any progress?
Could someone involved with the multimedia stuff give an overview how GStreamer relates to the current crop of multimedia tools and applications in KDE? Specifically, how would GStreamer impact Xine/arts/noatun? Is it an either/or?
I understand that GStreamer is meant as a complete framework alla Apples QuickTime. GNOME'ers are really pushing GStreamer, so I'd like to know what the KDE multimedia people think of all this ;)
KVideoWidget integrates with aRts (and its applications Noatun & Kaboodle). GStreamer is not used anywhere in KDE.
How will the GStreamer bindings gel with KDE's current multimedia framework and applications?
Not at all, apps would need to be rewritten in order to use it. Right now I am not porting or writing any apps for it because I have enough to do until at least 3.2. I am going to maintain it and try to keep it in sync with the GStreamer stable releases though. In 9 months or so, when KDE 3.2 is out and GStreamer reached 0.5 (the version intended to ship with Gnome), I hope to find the time to do a few projects with it.
As to my understanding, GStreamer has a _much_ broader target than yust a VideoWidget. It can do for video what aRts can do for audio.
It would be invaluable, if I could install a new video codec once in the ControlCenter (or GNOME equivalent) and all video application would know about it. This an be true with GStreamer, and not only codecs, but also effects.
Can somebody with insight comment on if we are gonna get a division in the codec world as we already have one in the GUI world? It would be a pitty.
There are two ways to share codecs between KDE and Gnome: either both DEs use the same framework, or both have their own media frameworks and somebody comes up with a generic codec format. MCF's Transor API seems to aim at offering a common codec format (with a C++ interface). It doesn't solve the problem that there is no media framework for KDE though...
Right now KDE's MM development is pretty sleepy.
> It doesn't solve the problem that there is no media framework for KDE > though...
Sorry but I don't understand.
Why do you say there is no media framework for KDE ?
Isn't ARTS a multimedia framework ? I mean it can handle sound formats (mp3,ogg,wav...) as well as video formats (DIVX,AVI,MPEG...).
So what exactly is missing in ARTS to make it a media framework ?
Could you point me to some documentation to all these aRts features? The latest "news" on http://www.arts-project.org is from November 01. The "new" Handbook says video is a "planed" feature. Where is aRts development going on? There was a big kde-multimedia pow-wow in January, but I have not heard of any results. If I missed them, where can I find them?
Using aRts as a video framework, which kind of codec format is supported? Do I have to recompile aRts to support a new file format? Which file formats are supported? Which codecs are supported?
I would be really interested in some links.
Thanx a lot, Peter
Well, in fact I downloaded KDE 3.1 Beta 2 and compiled it myself.
When I had it compiled, I found that I could use kaboodle to read my videos, very simply.
I'm pretty sure that ARTS in CVS has XINE plugin, which enables ARTS (and thus kaboodle and noatun) to play any video that is supported by XINE (so DIVX, DVD, MPG etc...).
The only webpage I found about xine plugin for arts is http://rambo.its.tudelft.nl/~ewald/xine/ but it seems dead currently.
Thanx, your link works for me.
So, is this a hack or will this become the official way KDE will go? (In case there has been a decission about this at all.)
Arts does not support transporting video over its pipelines, the Xine plugin can only be used for playback. This is not sufficient for recording, converting, applying filters (like effects or de-interlacing)... In other words, you can not use Arts to write a TV recorder, a video editor, a video converter, a video conferencing system, video mail recorder, video broadcasting and so on...
How are chances KDE will adopt GStreamer? Is there some other solution in the race?
Sorry to tell you this but GStreamer is far from going anywhere. It's buggy, incomplete and slowly developed. Not to mention that even under GNOME it fails all the time. aRts is working correctly so far so why do you want to have it replaced. I fear the idea to see KDE mature more and more towards GNOME.
I don't give a sh*t is KDE is going towards GNOME or away from it. I just want a working multimedia environment. If that is GStreamer, ok. If it is aRts, I am happy. Right now, there is nothing working.
Well sorry to pop your bubbles then. aRts is the first real working multimedia framework that i came along. It is your own fault if you can't handle or setup your system correctly. If you have that much problems then you should consider buying a Distro and obtain 60days Customers help with it too. These people may help you getting your hardware set up correctly.
What crack are you smoking man?
He's an anti-GNOME troll. If you look in the other articles, it's always him who flames GNOME down without valid arguments. Ignore him.
Hehehe what kind of Troll. Post shit here and then comes back and let it look like it's someone else. Stof you are a long history known Flamer. You, Aged Person and so on are probably the same sick insane persons.
If I am Aged Person I would be flaming at GNOME.
You are a general Flamer. No matter what Desktop.
Find me a post where I'm actively flaming down GNOME or KDE.
Yes, NOW you're suddenly quiet.
> Why do you say there is no media framework for KDE ?
aRts is an analog synthesizer and soundserver.
Gstreamer is a development framework for creating things like media players, audio editors, video editors, streaming broadcasts, etc.. It can use Arts as it's sound server.
Gstreamer and aRts sound like a perfect pair. gstreamer is simply just one abstraction layer above aRts, and would enable applications like noatun to process much more than they do now.
The initial reaction(2001) from the arts developers when gstreamer was announced in this thread:http://lists.kde.org/?l=kde-multimedia&m=97923203709340&w=2
Just saw an uplifting thread, seems as the tone has changed.http://lists.kde.org/?l=kde-multimedia&m=103536600426123&w=2
It would be great if there were KDE wrappers for GStreamer. I am using GStreamer right now and it provides pretty much a full multimedia framework out of the box that *just works*.
does anybody know the details of why mouse cursors can have transparency and other things (like windows) can not?
Or does XCursor use this fake transparency (taking screenshots etc.)? If yes, wouldn't that be awfully slow?
Because cursors and windows are almost completely unrelated.
Mouse cursors are guaranteed to always be on top of every window, so supporting them is easier.
Modern hardware provides special support for cursors. The cursor is quite seperate from windows, so it was relatively easy to support HW-acceleration for it without changing major internals of the protocol.
The new "physical display" screen in the KDE Control Center is interesting. It would be fair that it also includes the gamma correction, so that it turns unuseful to always launch KDE with "startx -- -gamma 1.5", for example.
Until then, why don't you just put it in your .xinitrc. Ie, this is my config:
xgamma -gamma 1.4 &
xset m 40/10 &
The default gamma setting should ideally be placed in the monitor secion in /etc/X11/XF86Config! e.g: Section "Monitor"|...|Gamma 1.5|EndSection. You can also set gamma values for each color (RGB) separately. See the XFree docs.
If resolution and depth are in the KDE ControlCenter, I think it is also the place of the gamma correction...
If I use KDE, it is not to go in the files of /etc or in .xinitrc (however, while waiting better, I will modify it, thank you ealm). A KDE user generally prefers to find such a parameter in the control center, of course...
Sure, it's more convenient for beginners not to touch "dangerous" files like /etc/X11/XF86Config, and if you are using KDE =only= and have just =one= monitor, then you can certainly get away with using xgamma or a KDE config module. But nevertheless: the gamma value is a highly monitor specific value that should be set correctly for each monitor, but should be used for all accounts. That's the job of the admin, and it is done in the XFree config. The gamma value is nothing that you will change every other day, so I can't see why firing up vi is such a problem -- except for Lindows users and Linux newbies, of course. ;-)
Ir seems that you understand few things about the end users.
I don't need to call an administrator, I am the user-administrator of my PC. Many such user-administrators don't know how to modify config files, they search in the KDE Control Center... (and no, they are not newbies, they only don't want to become experts). The many end users who are not self administrators also search in the KDE Control Center. It is the right place of a such parameter.
Yes, I don't change the gamma value every day, as the resolution and the depth. However, with KuickShow, I may change the gamma parameter as I want, I don't call an administrator ! Is it logical to allow the end user to change the gamma correction in one program and not for all ?
In Windows, the graphic card driver allows anybody to change the gamma correction (in advanced properties of display, so in the config panel = Windows Control Center), and you, you want to forbid it on KDE !!
Believe me, when you have a monitor too dark, it is VERY important to change the gamma correction. For ANYBODY.
> Is it logical to allow the end user to change the gamma correction in one program and not for all ?
The gamma value isn't there to fix broken images. If they are too dark, then you are supposed to brighten them up. (Using "b" in kuickshow, for example.) But there's still xgamma, anyway.
> [...] you want to forbid it on KDE !!
Oh, dear. No! Who am I to forbid bloat ... err. I mean features. But seriously, you are right: On desktop systems there often is no admin at all, and today's users are often unable and unwilling to read and understand the numerous docs. I'm just worried that you are misusing the gamma value and encouraging others to do so. ;-)
I have a question too, about the gamma. My monitor is extremely dark. I am now using a stupid 14 "monitor, cause it is the only one i have witch can produce a normal bright vision. But i really wanna use my normal 17 "monitor. Believe me, i'm no newbie or something like that, i know windows 98 as the palm of my hand, and i know for sure, that i can't change the gamma value. My graphics card just can't. So i've been searching the interent, to find a program that can adjust my gamma, but i can't find it. I've used a program called "adobe gamma"beforem to brighten up my vision :p but i can't find it anymore. Is there someone who knows a program to adjust the gamma, please tell me where to download it. Cause looking at a 14" monitor really gives you bad eyes. ( everything is so small :P:P)...
please help me...;)
I'm struggling with far too bright screen image and gamma value. I'm using Kde 3.2.0, Xfree86 4.3, and ATI Radeon 7500 all-in-wonder, HP71 monitor.
When starting xdm with parameters like "xdm -- :1 -gamma 0.2" gamma value seems to be ok set to 0.2.
When starting up kdm using default values from Xf86config (or kgammarc), then gamma seems to be set to 0.4, regardless of what value is put in Xf86config or kgammarc. Why is gamma limited downwards to 0.4 in kgamma?
Does anyone now how I can force gamma to e.g. 0.2 when using kdm/kde?
Just figured out that if S-VHS TV-out is disconnected during boot, the gamma value is set coorectly. So this problem is related to the radeon drivers in X11.
This was also mentioned in http://forum.gentoo.org.
I am very pelased that RandR support is already planned for KDE.
But from the control panel, it seems that the resolution must be used
for all the virtual desktops. I would really like to select a different
resolution/depth per virtual desktop, as I am able to do with the Amiga.
Having multiple desktop is handy, but having them at different resolution
is perfect. Games, for example, are typically better at lower resolution,
while sometimes, I'd like to look at the pictures of my digital camera
at their full resolution, which is not comfortable to look at for long.
That is no longer the case with the latest version (Jim included per-screen support and I've added that to my stuff too); I just need someone to test it...
Oops, you said virtual desktops ;) That's on my to-do list now.
Well, I called them 'virtual desktops' because that's the name under X...
Although they are just called screens in Amiga jargon.
> I would really like to select a different resolution/depth per virtual desktop,
Is'nt it more important to have real different virtual desktops, with a different set of icons for each one ?
Also, for Kicker, a different set of icons per desktops in the Lancher applet would be very fine...
and i'd like to have different kicker settings per desktop (like on desktop 4, kicker rolled up ...)
The more I use my computer for different tasks, the more I use the virtual desktops. I have the one called Internet-Office, the one called Photos, the one called Songs, the one called FTP, the one called Tasks, the one called Windows (win4lin)... Each desktop has its function, has its taskbar, its colour, and needs its set of icons (on the desktop and in Kicker). Each desktop needs to become independant, to become a computer, so that I will have several computers in one...
I think it's very important for a personnal computer, and here Linux may have a good advantage on Windows and Mac...
(another nice improvement would be to have the content of the preview Desktop applet when typing Ctrl Tab)
Get 'em here: http://yoyo.its.monash.edu.au/~meddie/patches/screenshots/
This is now in kdenonbeta/kcmrandr, and works like a charm with the latest XFree86 CVS.
Ahh man, Keramik is so beautiful. :-)
Yeah but the fonts really suck ! I wonder if Linux will ever have decent fonts one day ! sigh !
fonts are probably ok, but look bad because of compression