On Mon, 14 Nov 2011 12:26:51 -0200 Gustavo Sverzut Barbieri
<barbi...@profusion.mobi> said:
> On Mon, Nov 14, 2011 at 1:20 AM, Carsten Haitzler <ras...@rasterman.com>
> wrote:
> > On Mon, 14 Nov 2011 13:08:55 +1000 David Seikel <onef...@gmail.com> said:
> >
> >> On Mon, 14 Nov 2011 11:59:57 +0900 Carsten Haitzler (The Rasterman)
> >> <ras...@rasterman.com> wrote:
> >>
> >> > On Mon, 14 Nov 2011 10:31:01 +1000 David Seikel <onef...@gmail.com>
> >> > said:
> >> >
> >> > > I have this marked to reply to properly later, but something came
> >> > > up in IRC.
> >> > >
> >> > > Perhaps libcanberra could be optionally added to this edje sound
> >> > > stuff for XDG system sounds support. It could be like edje fonts -
> >> > > the edje scripter can choose to use a font built in to the edje, or
> >> > > a system font. So they could choose to use a sound built into the
> >> > > edje, via the sound stuff that's there already, or a system sound
> >> > > via libcanberra.
> >> > >
> >> > > We can blame k-s for the basic idea of using libcanberra, devilhorns
> >> > > and I added the "we can do both" part.
> >> >
> >> > what i saw of libcanberra when i looked maybe a year or so ago was it
> >> > was a simple sound event player - play sample X by token name on
> >> > event Y. this can be supported, but it's definitely limited.
> >> > something to add along the way - maybe after the initial stuff is
> >> > solid.
> >>
> >> That's what I was saying in IRC, that libcanberra was way more limited
> >> than your new sound code.
> >
> > yup. :) can be done as an addition later as its a simplifies subset of whats
> > there in the proposal.
>
> Sure, but to clarify what I mean:
>
> I think that SOUNDS IN E should not be in Edje, rather going with
> libcanberra for consistency with the whole world.
completely disagree here. by thius logic we should drop evas and edje and just
use gtk.. or qt to be "consistent with everyone elses gtk or qt themes". so are
you making the argument to kill edje and evas and elementary and use qt and
gtk? because that's the same logic behind your "don't do something better or
more powerful, just do the lowest-common-denominator so you blend into other
desktops".
> 1. not all actions are visual to have an associated edje and thus sound.
> 2. xdg sound themes are supported elsewhere, like gnome/kde = consistency
> 3. one can turn off the sound in a central place.
>
> this is much like before we just had e17 icons, then we started to
> support FreeDesktop.Org icons... bit painful, so the sound we can
> start easily.
that is a different case. each and every application provides data you display.
sound and visual themes are not provided by each application so there is no
overwhelming requirement to fall in line - as people have to do themes for
e/elm anyway... they can do sound themes too. and they can package it all into
the same theme they already do. a single download an they're done.
> Actually if there is interest I can provide the functions below, and
> people can plug them into E17 and write a configuration:
>
> unsigned int e_sound_feedback(const char *event_name, const
> Evas_Object *reference, Eina_Bool loop);
> unsigned int e_sound_feedback_win(const char *event_name,
> Ecore_X_Window reference, Eina_Bool loop);
> void e_sound_feedback_stop(unsigned int id);
>
> object is used to provide spatial sound whenever supported and also
> finds out the owner window class/name to be fed to libcanberra.
can you explain more?
> One could go in E codebase and call:
>
> //on startup
> e_sound_feedback("service-login", NULL, EINA_FALSE);
>
> //on logout
> e_sound_feedback("service-logout", NULL, EINA_FALSE);
>
> // on error dialogs
> e_sound_feedback("dialog-error", dia_base, EINA_FALSE);
> e_sound_feedback("dialog-warning", dia_base, EINA_FALSE);
> e_sound_feedback("dialog-information", dia_base, EINA_FALSE);
>
> // on urgent windows
> e_sound_feedback_win("window-attention", xid, EINA_FALSE);
>
> // on screenshot module
> e_sound_feedback("screen-capture", NULL, EINA_FALSE);
>
> very simple and will match whatever sound the user choose in their
> apps. Of course, similar to icon themes we'd have to provide our own
> theme selector configuration tool.
this doesn't do what i want to - which is the ability to have sound work with
input to provide not just your 1-off sample beeps as this is, but literally tie
it into actions like dragging a slider and where the position is, or scrolling
or any number of things.
i do agree we need sound outside of edje - as an actual library and api, but
that doesn't preclude edje having such features anyway and later using that
sound api itself.
> --
> Gustavo Sverzut Barbieri
> http://profusion.mobi embedded systems
> --------------------------------------
> MSN: barbi...@gmail.com
> Skype: gsbarbieri
> Mobile: +55 (19) 9225-2202
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
