Linked by Thom Holwerda on Tue 12th Dec 2006 18:37 UTC, submitted by anonymous
Linux Over the past week, some of the Linux desktop's foremost developers gathered together in Portland, Oregon at the OSDL Desktop Architects Meeting to work further on bringing order to the Linux desktop. According to John Cherry, the OSDL's Desktop Linux initiative manager, there was a good turnout of about 45 developers from the community, including major Linux vendors such as Novell and Red Hat, and ISVs like Google and Adobe."
Thread beginning with comment 191373
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: API's
by Doc Pain on Tue 12th Dec 2006 21:55 UTC in reply to "API's"
Doc Pain
Member since:
2006-10-08

"Audio is another big issue, I my self like gstreamer and xine."

And I like mplayer and xmms. :-)

"A standard 'action' api would be nice, IM/web/email even file types, no matter what DM your using it will always open that file type with that app ... not per DM settings"

By principle this would be great. But what application would be the right one? As an example: You click on a MP3 file. Fron the KDE point of view, a KDE program would be launched to play the file. But the user may want to use XMMS.

As an example from real life, my uncle is new to Linux. He got some SuSE stuff with KDE installed and wanted to play a MP3 file, so he clicked on it and there was Kaffeine, I tink, which started to scan through his CD and hard disks to find more MP3 files - instead of playing the one selected. Confusing for him. Same with video files.

A customizable connection between MIME types and programs to use would be a solution. The programs should be provided if they're referenced to in this file. By default, the user won't have to change the file / the settings. Still it should be changable, maybe with a standardized GUI frontend for users who are not that experienced.

"Hell while im on a roll, why not have /usr/share/desktop for all the damm .desktop files, so every 'app menu' system displays all the applications, without having to search /usr"

Good idea, except /usr/share belongs to system shared data only. Logical alternative to prefer: /usr/local/share/desktop (or even /usr/X11R6/share/desktop).

Reply Parent Score: 1

RE[2]: API's
by ple_mono on Tue 12th Dec 2006 22:37 in reply to "RE: API's"
ple_mono Member since:
2005-07-26

And I like mplayer and xmms. :-)

What are you rambling about?
mplayer and xmms are applictions. gstreamer and xine are application frameworks. (well, ok, xine is an application as well as a framework... -1 for me)

Edited 2006-12-12 22:47

Reply Parent Score: 3

RE[3]: API's
by Doc Pain on Tue 12th Dec 2006 23:45 in reply to "RE[2]: API's"
Doc Pain Member since:
2006-10-08

"mplayer and xmms are applictions. gstreamer and xine are application frameworks. (well, ok, xine is an application as well as a framework... -1 for me) "

You're right, xine is described as "an X11 multimedia player" with many plugins, backends and alternative GUI frontends available. So it is okay to mention it as a program - xine / gxine - (first) and a framework - xine-lib - (second). From the xine homepage: "xine is a free multimedia player."

BTW: I like xine because it runs on my SGI. :-)

Gstreamer is mainly used by Gnome video players (e. g. totem-gstreamer), but it can handle audio as well.

You can surely see gstreamer as a framework. In fact, gstreamer80 is described to be a "development framework for creating media applications". From the gstreamer homepage: "GStreamer is a library that allows the construction of graphs of media-handling components, [...]."

Once gstreamer is installed, it provided command line tools as well. They can be considered to be "gstreamer applications".

What do we have?

gstreamer = { library, framework, application }
xine = { library, framework, application }

So it's completely okay to talk about them regarding their quality of being an application. q.e.d.

Maybe you didn't know that, so I don't mind your unfair judging and your insults. I won't punish you for your individual opinion. :-)

Edited 2006-12-12 23:48

Reply Parent Score: 1

RE[3]: API's
by hal2k1 on Tue 12th Dec 2006 23:48 in reply to "RE: API's"
hal2k1 Member since:
2005-11-11

//As an example from real life, my uncle is new to Linux. He got some SuSE stuff with KDE installed and wanted to play a MP3 file, so he clicked on it and there was Kaffeine, I tink, which started to scan through his CD and hard disks to find more MP3 files - instead of playing the one selected. Confusing for him. Same with video files.

A customizable connection between MIME types and programs to use would be a solution. The programs should be provided if they're referenced to in this file. By default, the user won't have to change the file / the settings. Still it should be changable, maybe with a standardized GUI frontend for users who are not that experienced. //

KDE does this. It is a part of Konqueror, or any other KDE filemanager for that matter (Krusader, Dolphin).
http://www.konqueror.org/features/filemanager.php
http://krusader.sourceforge.net/
http://enzosworld.gmxhome.de/

Kaffeine is the default player for KDE for audio mimetypes. You can easily change this to whatever you want ... XMMS, Mplayer, VLC, Totem, Xine ... myriad choices here.

Kaffeine doesn't scan through Hard disks and CDs. Amarok might do that (on first run only), but Amarok is much more than just a simple media player. Amarok is more like a "media collection browser".

http://amarok.kde.org/
http://amarok.kde.org/index.php?set_albumName=1-4-Series&id=amaroks...

Reply Parent Score: 3

RE[4]: API's
by Doc Pain on Wed 13th Dec 2006 00:12 in reply to "RE[3]: API's"
Doc Pain Member since:
2006-10-08

"Kaffeine doesn't scan through Hard disks and CDs. Amarok might do that (on first run only), but Amarok is much more than just a simple media player. Amarok is more like a "media collection browser". "

Ah! My mistake! Of course it was Amarok. Sorry for remembering incorrectly, but because I don't use KDE I'm not very familiar with the applications connected to file types by default. So Amarok would "just play" a selected file for the second run? (I still use XMMS for MP3 playback.)

Reply Parent Score: 1

RE[4]: API's
by Havin_it on Wed 13th Dec 2006 12:33 in reply to "RE[3]: API's"
Havin_it Member since:
2006-03-10

IIRC, Amarok on first run will give the option to build a collection (and first you have to choose between MySQL and SQLite backends), but I think you can skip it and just play the file if you prefer. I'm pretty sure you first have to select paths to scan before it does so as well.

Amarok FTW, by the way ;) Like Kaffeine, it defaults to Xine but can use different player engines. For example (and it's the only one I know that can do this) it can use the Helix engine, which is obviously good if RealMedia streams are your thing.

I really like this modularity that the diversity of engines/frameworks/frontends has caused. With maybe 3 choices for each of audio subststem/engine/frontend, and cross-compatibility between them all, you basically have a choice of 3x3x3=27 different 'stacks' -- one of which is bound to actually work :/

Reply Parent Score: 1