1:16 a.m.
hi Great list,
I just find that the libgnome-2.24.1-7.fc10 has been disabled "esd" when it
is built.
This has caused the "gnome_sound_play()" doesn't work and some package such
as
"stardict" cannot play sound.
Why should we disable esd in libgnome? Could we enable it?
Thanks.
9:28 a.m.
On Sun, 01.02.09 15:16, 平天韩 (hanpingtian(a)gmail.com) wrote:
hi Great list,
I just find that the libgnome-2.24.1-7.fc10 has been disabled "esd" when it
is built.
This has caused the "gnome_sound_play()" doesn't work and some package
such
as
"stardict" cannot play sound.
Why should we disable esd in libgnome? Could we enable it?
esd is considered obsolete. gnome_sound_play() has been replaced by
the more generic, powerful, platform-independant and dektop-agnostic
functionality found in libcanberra.
http://0pointer.de/lennart/projects/libcanberra/
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
9:59 a.m.
Lennart Poettering wrote:
esd is considered obsolete. gnome_sound_play() has been replaced by
the more generic, powerful, platform-independant and dektop-agnostic
functionality found in libcanberra.
But existing programs use that function, and disabling libesd support (which
works with PulseAudio) means it'll try to use OSS output (which doesn't
work with PulseAudio).
Kevin Kofler
7:46 p.m.
Right. How about enable esd in libgnome please?
2009/2/1 Kevin Kofler <kevin.kofler(a)chello.at>
Lennart Poettering wrote:
> esd is considered obsolete. gnome_sound_play() has been replaced by
> the more generic, powerful, platform-independant and dektop-agnostic
> functionality found in libcanberra.
But existing programs use that function, and disabling libesd support
(which
works with PulseAudio) means it'll try to use OSS output (which doesn't
work with PulseAudio).
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
6:42 a.m.
On Sun, 2009-02-01 at 22:31 -0500, Jens Petersen wrote:
----- "平天韩" <hanpingtian(a)gmail.com> wrote:
> Right. How about enable esd in libgnome please?
I suggest you file a bug in bugzilla if there isn't one already and see what happens.
Will probably be closed as WONTFIX. The API docs made it clear that the
libgnome sound support was a build-time option.
The application should be fixed to use more modern API.
Cheers
7:49 a.m.
But when you break something as major as libgnome, steps should be taken to
ease the transition. Perhaps the function could be forwarded? I'm not really
much of a programmer, but I recognize that you can't just break
functionality in core libraries like that and expect everyone to fix their
apps up "just like that." Fowarding the function (for compatibility
purposes) while deprecating it would probably be more ideal. In any case,
that's just my two cents...
On Mon, Feb 2, 2009 at 6:42 AM, Bastien Nocera <bnocera(a)redhat.com> wrote:
On Sun, 2009-02-01 at 22:31 -0500, Jens Petersen wrote:
> ----- "平天韩" <hanpingtian(a)gmail.com> wrote:
> > Right. How about enable esd in libgnome please?
>
> I suggest you file a bug in bugzilla if there isn't one already and see
what happens.
Will probably be closed as WONTFIX. The API docs made it clear that the
libgnome sound support was a build-time option.
The application should be fixed to use more modern API.
Cheers
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
8:56 a.m.
On Mon, 02.02.09 07:49, King InuYasha (ngompa13(a)gmail.com) wrote:
But when you break something as major as libgnome, steps should be
taken to
ease the transition. Perhaps the function could be forwarded? I'm not really
much of a programmer, but I recognize that you can't just break
functionality in core libraries like that and expect everyone to fix their
apps up "just like that." Fowarding the function (for compatibility
purposes) while deprecating it would probably be more ideal. In any case,
that's just my two cents...
For a core piece of an API keeping compat is certainly important. But
this is sound events, don't forget that. Quite frankly, most people have them
deatcivated anyway.
It has been documented that this can be disabled at compile time and
it's pretty unimportant anyway and there is a much better replacement
available. Hence I'd assume that the advantage of getting rid of this
legacy cruft will always be more attractive then keeping it around.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
9:18 a.m.
On Mon, Feb 2, 2009 at 6:56 AM, Lennart Poettering <mzerqung(a)0pointer.de> wrote:
On Mon, 02.02.09 07:49, King InuYasha (ngompa13(a)gmail.com) wrote:
> But when you break something as major as libgnome, steps should be taken to
> ease the transition. Perhaps the function could be forwarded? I'm not really
> much of a programmer, but I recognize that you can't just break
> functionality in core libraries like that and expect everyone to fix their
> apps up "just like that." Fowarding the function (for compatibility
> purposes) while deprecating it would probably be more ideal. In any case,
> that's just my two cents...
For a core piece of an API keeping compat is certainly important. But
this is sound events, don't forget that. Quite frankly, most people have them
deatcivated anyway.
It has been documented that this can be disabled at compile time and
it's pretty unimportant anyway and there is a much better replacement
available. Hence I'd assume that the advantage of getting rid of this
legacy cruft will always be more attractive then keeping it around.
What about the possibility of rewriting gnome_sound* to use libsydney?
I know it's not the most exciting work available, but that would some
to be the correct long term fix. It's not like the libgnome API can go
away prior to GNOME-3.0.
--
Dan
11:05 a.m.
On Mon, 2009-02-02 at 07:18 -0800, Dan Nicholson wrote:
<snip>
What about the possibility of rewriting gnome_sound* to use
libsydney?
I know it's not the most exciting work available, but that would some
to be the correct long term fix. It's not like the libgnome API can go
away prior to GNOME-3.0.
It's not possible to provide an ABI or API compatible replacement,
because gnome_sound_* exports some esound specific APIs. For example,
gnome_sound_connection_get () and gnome_sound_sample_load().
So if you're going to change the semantics, the apps will need to be
fixed. And if the applications need to be fixed, I don't see the
difference between rewriting the few lines of code to use libcanberra
and adapting it for a libgnome API with different semantics.
12:20 p.m.
On Mon, Feb 2, 2009 at 9:05 AM, Bastien Nocera <bnocera(a)redhat.com> wrote:
On Mon, 2009-02-02 at 07:18 -0800, Dan Nicholson wrote:
<snip>
> What about the possibility of rewriting gnome_sound* to use libsydney?
> I know it's not the most exciting work available, but that would some
> to be the correct long term fix. It's not like the libgnome API can go
> away prior to GNOME-3.0.
It's not possible to provide an ABI or API compatible replacement,
because gnome_sound_* exports some esound specific APIs. For example,
gnome_sound_connection_get () and gnome_sound_sample_load().
So if you're going to change the semantics, the apps will need to be
fixed. And if the applications need to be fixed, I don't see the
difference between rewriting the few lines of code to use libcanberra
and adapting it for a libgnome API with different semantics.
Well, it seems like you could easily just keep most of the stub/noops
for non-esd and create a canberra-specific path for
gnome_sound_play(). That would probably cover most of the apps that
just do a fire and forget gnome_sound_play(file). That would be API
compatible with the non-esd libgnome.
--
Dan
6:59 p.m.
On Mon, 2009-02-02 at 10:20 -0800, Dan Nicholson wrote:
On Mon, Feb 2, 2009 at 9:05 AM, Bastien Nocera
<bnocera(a)redhat.com> wrote:
> On Mon, 2009-02-02 at 07:18 -0800, Dan Nicholson wrote:
> <snip>
>> What about the possibility of rewriting gnome_sound* to use libsydney?
>> I know it's not the most exciting work available, but that would some
>> to be the correct long term fix. It's not like the libgnome API can go
>> away prior to GNOME-3.0.
>
> It's not possible to provide an ABI or API compatible replacement,
> because gnome_sound_* exports some esound specific APIs. For example,
> gnome_sound_connection_get () and gnome_sound_sample_load().
>
> So if you're going to change the semantics, the apps will need to be
> fixed. And if the applications need to be fixed, I don't see the
> difference between rewriting the few lines of code to use libcanberra
> and adapting it for a libgnome API with different semantics.
Well, it seems like you could easily just keep most of the stub/noops
for non-esd and create a canberra-specific path for
gnome_sound_play(). That would probably cover most of the apps that
just do a fire and forget gnome_sound_play(file). That would be API
compatible with the non-esd libgnome.
It's already just stubs, and it would break apps that rely on
gnome_sound_connection_get () and gnome_sound_sample_load() to work. I
also don't think we're interested in keeping libgnomeui in the future.
I'd rather spend time answering questions on how to make libcanberra
work with your app rather than spending time doing a half-working
work-around in libgnome.
7:31 p.m.
On Mon, Feb 2, 2009 at 4:59 PM, Bastien Nocera <bnocera(a)redhat.com> wrote:
On Mon, 2009-02-02 at 10:20 -0800, Dan Nicholson wrote:
> On Mon, Feb 2, 2009 at 9:05 AM, Bastien Nocera <bnocera(a)redhat.com> wrote:
> > On Mon, 2009-02-02 at 07:18 -0800, Dan Nicholson wrote:
> > <snip>
> >> What about the possibility of rewriting gnome_sound* to use libsydney?
> >> I know it's not the most exciting work available, but that would some
> >> to be the correct long term fix. It's not like the libgnome API can go
> >> away prior to GNOME-3.0.
> >
> > It's not possible to provide an ABI or API compatible replacement,
> > because gnome_sound_* exports some esound specific APIs. For example,
> > gnome_sound_connection_get () and gnome_sound_sample_load().
> >
> > So if you're going to change the semantics, the apps will need to be
> > fixed. And if the applications need to be fixed, I don't see the
> > difference between rewriting the few lines of code to use libcanberra
> > and adapting it for a libgnome API with different semantics.
>
> Well, it seems like you could easily just keep most of the stub/noops
> for non-esd and create a canberra-specific path for
> gnome_sound_play(). That would probably cover most of the apps that
> just do a fire and forget gnome_sound_play(file). That would be API
> compatible with the non-esd libgnome.
It's already just stubs, and it would break apps that rely on
gnome_sound_connection_get () and gnome_sound_sample_load() to work. I
also don't think we're interested in keeping libgnomeui in the future.
That's exactly my point. Since ESD support has been removed in fedora,
anyone trying to do gnome_sound_connection_get() will just get -1 back
anyway. Furthermore, the gnome_sound_play() docs say that the sound
may or may not play. So, why not just make it play a file with
libcanberra? If it fails, oh well. You're in exactly the same
situation you're in now. It seems pretty easy to me:
void gnome_sound_play(const char *filename)
{
#ifdef HAVE_LIBCANBERRA_GTK
ca_context_play(ca_gtk_context_get(), 0, CA_PROP_MEDIA_FILENAME,
filename, NULL);
#endif
}
I understand not wanting to write new apps to use gnome_sound_play
since it's deprecated. But it's existing API that can't be removed.
Why not have it work for apps that haven't been ported yet (or can't
be ported)?
I'd rather spend time answering questions on how to make
libcanberra
work with your app rather than spending time doing a half-working
work-around in libgnome.
Sure. I would not suggest that new apps use gnome_sound*.
--
Dan
10:24 a.m.
On Mon, 2009-02-02 at 17:31 -0800, Dan Nicholson wrote:
<snip>
That's exactly my point. Since ESD support has been removed in
fedora,
anyone trying to do gnome_sound_connection_get() will just get -1 back
anyway. Furthermore, the gnome_sound_play() docs say that the sound
may or may not play. So, why not just make it play a file with
libcanberra? If it fails, oh well. You're in exactly the same
situation you're in now. It seems pretty easy to me:
void gnome_sound_play(const char *filename)
{
#ifdef HAVE_LIBCANBERRA_GTK
ca_context_play(ca_gtk_context_get(), 0, CA_PROP_MEDIA_FILENAME,
filename, NULL);
#endif
}
It's easy but broken because it's missing all the other properties that
libcanberra can use and give to other applications. For example, we
don't know whether it's a sound event (click/pop/whatever), or a help to
pronunciation in a dictionary.
I understand not wanting to write new apps to use gnome_sound_play
since it's deprecated. But it's existing API that can't be removed.
Why not have it work for apps that haven't been ported yet
Because it's hardly more work to fix the applications themselves.
(or can't
be ported)?
Those were always in trouble.
> I'd rather spend time answering questions on how to make
libcanberra
> work with your app rather than spending time doing a half-working
> work-around in libgnome.
Sure. I would not suggest that new apps use gnome_sound*.
And I don't see how adding a broken work-around to gnome_sound_* would
help us fix the applications properly.
Cheers
11:04 a.m.
On Tue, Feb 3, 2009 at 8:24 AM, Bastien Nocera <bnocera(a)redhat.com> wrote:
On Mon, 2009-02-02 at 17:31 -0800, Dan Nicholson wrote:
<snip>
> That's exactly my point. Since ESD support has been removed in fedora,
> anyone trying to do gnome_sound_connection_get() will just get -1 back
> anyway. Furthermore, the gnome_sound_play() docs say that the sound
> may or may not play. So, why not just make it play a file with
> libcanberra? If it fails, oh well. You're in exactly the same
> situation you're in now. It seems pretty easy to me:
>
> void gnome_sound_play(const char *filename)
> {
> #ifdef HAVE_LIBCANBERRA_GTK
> ca_context_play(ca_gtk_context_get(), 0, CA_PROP_MEDIA_FILENAME,
> filename, NULL);
> #endif
> }
It's easy but broken because it's missing all the other properties that
libcanberra can use and give to other applications. For example, we
don't know whether it's a sound event (click/pop/whatever), or a help to
pronunciation in a dictionary.
That's exactly the gnome_sound_play API: play this sound file, please.
You don't care about any other metadata. If they did care about more
metadata, they probably wouldn't have been using gnome_sound_play in
the first place.
> I understand not wanting to write new apps to use
gnome_sound_play
> since it's deprecated. But it's existing API that can't be removed.
> Why not have it work for apps that haven't been ported yet
Because it's hardly more work to fix the applications themselves.
> (or can't
> be ported)?
Those were always in trouble.
> > I'd rather spend time answering questions on how to make libcanberra
> > work with your app rather than spending time doing a half-working
> > work-around in libgnome.
>
> Sure. I would not suggest that new apps use gnome_sound*.
And I don't see how adding a broken work-around to gnome_sound_* would
help us fix the applications properly.
I didn't say anything about fixing applications properly. I'm talking
about making an API that exists in the platform continue to work until
it can be removed. gnome_sound_play is a crappy API for getting sound
in an application, but it exists and is in use. Why not just make it
continue to work since it's so simple?
--
Dan
4:18 p.m.
> I'm talking
> about making an API that exists in the platform continue to work until
> it can be removed.
It can be removed now. Convert apps over to libcanberra.
Agreed. For some time all of libgnome has essentially been marked as
deprecated by gnome and is being actively migrated away away from.
Details can be seen here http://live.gnome.org/LibgnomeMustDie and has
been part of the Project Ridley which is well over 2 years old.
http://live.gnome.org/ProjectRidley
Peter
4:34 p.m.
On Tue, Feb 3, 2009 at 2:10 PM, Linus Walleij <triad(a)df.lth.se> wrote:
> I'm talking
> about making an API that exists in the platform continue to work until
> it can be removed.
It can be removed now. Convert apps over to libcanberra.
You can't remove it. That would break the API, something that GNOME will not do.
Again...
Porting apps to libcanberra is the right thing to do. Convert every
single one you find. But, gnome_sound_play is in the platform until
GNOME-3.0 comes along and API can be broken. In that case, why not
have gnome_sound_play actually do something useful since it's dead
simple to do it?
--
Dan
8:02 p.m.
2009/2/4 Dan Nicholson <dbn.lists(a)gmail.com>
On Tue, Feb 3, 2009 at 2:10 PM, Linus Walleij <triad(a)df.lth.se>
wrote:
>> I'm talking
>> about making an API that exists in the platform continue to work until
>> it can be removed.
>
> It can be removed now. Convert apps over to libcanberra.
You can't remove it. That would break the API, something that GNOME will
not do.
Again...
Porting apps to libcanberra is the right thing to do. Convert every
single one you find. But, gnome_sound_play is in the platform until
GNOME-3.0 comes along and API can be broken. In that case, why not
have gnome_sound_play actually do something useful since it's dead
simple to do it?
Agree. I think we shouldn't force apps to use new API by disable old API
which works fine.
--
Dan
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
9:09 p.m.
On 02/03/2009 05:34 PM, Dan Nicholson wrote:
Again...
Porting apps to libcanberra is the right thing to do. Convert every
single one you find. But, gnome_sound_play is in the platform until
GNOME-3.0 comes along and API can be broken. In that case, why not
have gnome_sound_play actually do something useful since it's dead
simple to do it?
It's pretty useful to have gnome_sound_play do what it's doing now.
It's making people ask how to make sound work again, and they are
learning about the right way to do it with libcanberra.
Being realistic, people will never change unless they have to. Whether
that happens now, or in GNOME 3.0 is pretty much irrelevant. It has to
happen sometime, might as well be now.
8:08 a.m.
Christopher Aillon wrote:
Being realistic, people will never change unless they have to.
Whether
that happens now, or in GNOME 3.0 is pretty much irrelevant. It has to
happen sometime, might as well be now.
But the thing is, apps have not been ported in time for Fedora 10, so it was
a mistake to disable this in Fedora 10, it should be reenabled in an update
ASAP.
You need to get apps ported in Rawhide first, then the API can be disabled
for the next release.
Kevin Kofler
9:28 a.m.
On Wed, 2009-02-04 at 15:08 +0100, Kevin Kofler wrote:
Christopher Aillon wrote:
> Being realistic, people will never change unless they have to. Whether
> that happens now, or in GNOME 3.0 is pretty much irrelevant. It has to
> happen sometime, might as well be now.
But the thing is, apps have not been ported in time for Fedora 10, so it was
a mistake to disable this in Fedora 10, it should be reenabled in an update
ASAP.
You need to get apps ported in Rawhide first, then the API can be disabled
for the next release
https://bugzilla.redhat.com/show_bug.cgi?id=475442
I also don't think it should have been done in a released version. We
won't be changing this for rawhide though.
Cheers
12:50 p.m.
On Wed, Feb 4, 2009 at 5:08 AM, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
You need to get apps ported in Rawhide first, then the API can be
disabled
for the next release.
This really goes to the heart of the matter. When and how is it okay
to introduce changes to APIs that applications depend on. I'm not
saying they can't be changed, but are we making our best effort at
minimizing the disruption when changes are introduced?
Packaging metadata only goes so far, we don't have a facility to flag
a change like this as its not exposed in a way that packaging can
express as a depchain. I doubt we could have caught this with an
automated tool before it landed in a repository even if was a mistake
not meant to be pushed as an update.
-jef
8:54 p.m.
The problem here is we disable the esd supporting when build libgnome. But
if we enable it, gnome_sound_play() works just fine.
( I have tested this.) So I think although we have removed esd from
Fedora 10, but we shouldn't disable esd supporting in libgnome. Right?
2009/2/2 Lennart Poettering <mzerqung(a)0pointer.de>
On Mon, 02.02.09 07:49, King InuYasha (ngompa13(a)gmail.com) wrote:
> But when you break something as major as libgnome, steps should be taken
to
> ease the transition. Perhaps the function could be forwarded? I'm not
really
> much of a programmer, but I recognize that you can't just break
> functionality in core libraries like that and expect everyone to fix
their
> apps up "just like that." Fowarding the function (for compatibility
> purposes) while deprecating it would probably be more ideal. In any case,
> that's just my two cents...
For a core piece of an API keeping compat is certainly important. But
this is sound events, don't forget that. Quite frankly, most people have
them
deatcivated anyway.
It has been documented that this can be disabled at compile time and
it's pretty unimportant anyway and there is a much better replacement
available. Hence I'd assume that the advantage of getting rid of this
legacy cruft will always be more attractive then keeping it around.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
10:27 a.m.
On Tue, 2009-02-03 at 10:54 +0800, 平天韩 wrote:
The problem here is we disable the esd supporting when build
libgnome. But if we enable it, gnome_sound_play() works just fine.
( I have tested this.) So I think although we have removed esd from
Fedora 10, but we shouldn't disable esd supporting in libgnome. Right?
The application you're talking about is broken in the first place for
assuming that gnome_sound_play() would always be working.
File an upstream bug (or one in the Fedora bugzilla) against the
application at hand, and it will be fixed.
Cheers
11:09 a.m.
On Mon, 2009-02-02 at 07:49 -0600, King InuYasha wrote:
But when you break something as major as libgnome, steps should be
taken to ease the transition. Perhaps the function could be forwarded?
See below in the thread, we can't because the libgnome API exposes
esound internals.
I'm not really much of a programmer, but I recognize that you
can't
just break functionality in core libraries like that and expect
everyone to fix their apps up "just like that." Fowarding the function
(for compatibility purposes) while deprecating it would probably be
more ideal. In any case, that's just my two cents...
It's been deprecated for a while already. See:
http://library.gnome.org/devel/references#api-platform
And from the API docs:
"
These functions also allow for the fact that no sound may be supported
on the current platform.
"
So if your application _required_ to have sound working, then it was
broken in the first place...
5567
days inactive
5570
days old
25 comments
11 participants
participants (11)
-
Bastien Nocera -
Christopher Aillon -
Dan Nicholson -
Jef Spaleta -
Jens-Ulrik Petersen -
Kevin Kofler -
Lennart Poettering -
Linus Walleij -
Neal Gompa -
Peter Robinson -
平天韩