On Tue, Nov 15, 2011 at 12:45 AM, Carsten Haitzler <[email protected]> wrote:
> On Mon, 14 Nov 2011 12:26:51 -0200 Gustavo Sverzut Barbieri
> <[email protected]> said:
>
>> On Mon, Nov 14, 2011 at 1:20 AM, Carsten Haitzler <[email protected]>
>> wrote:
>> > On Mon, 14 Nov 2011 13:08:55 +1000 David Seikel <[email protected]> said:
>> >
>> >> On Mon, 14 Nov 2011 11:59:57 +0900 Carsten Haitzler (The Rasterman)
>> >> <[email protected]> wrote:
>> >>
>> >> > On Mon, 14 Nov 2011 10:31:01 +1000 David Seikel <[email protected]>
>> >> > 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".
nah... there we go, again. Same history as icons, we make them edje
only, then it suck and we must hack some compat on top.
I'm not saying I'm against having sounds in edje, just making them the
rule and having to hack things on top of it later. If someone have
free time to work on a new sound set, then to change a theme to make
crazy use of it... go ahead. But right now we lack enough resources to
create a simple theme to replace b&w :-D
also, bear in mind some actions are not visible... at least not as in
Edje. If you change the volume, you may have sound feedback without
visuals (okay, you can force people to have visual popup to make that
trigger sound, but there we go...)
As for the argument of being inconsistent.... it's sad but it's true,
unfortunately most of the bad comments about E/EFL is that it fails to
match into other desktops. From that default e17 mouse cursor (that I
really don't see a reason to exist) that keeps changing from one
application to another, to icons and toolkit theme.
Yes, I know every other environment would have the problem if they
had no apps... but they do have the apps and most users of KDE never
run GNOME apps to notice, vice versa. But we're always running KDE or
GNOME apps as we have no applications :-( Few E17 developers notice
how bad it is, maybe because getting used to, maybe because all we use
is xterm + firefox :-D
Then, if the widget theme (edj) is a major difference we want to
keep, why not cooperate on other stuff such as sound and cursor theme
could cooperate with other toolkits for a less alien environment?
>> 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.
I'm not against having this. I'm against forcing this.
>> 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?
no idea if it's implemented, but in theory it would be used to make
clicks at the right side of your windows to have louder volume at the
right speaker. If you have 4 monitors and the alert window appears at
the rightmost, then it would be louder at right. Etc.
>> 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.
You can still have that, in theme and the whole system does not need
to know about it.
I'm worried about important and useful core events. These are simple
to have right now and in a standard way. People complain about these
things missing, actually it was an user complaining that originates
the discussion, with me saying I can do the aforementioned
infrastructure for e17 release.
Here comes a problem of reality x excitement. Living in excitement
left us without these sounds for years. Even the most fancy systems
out there, such as iOS, Mac and newer Windows, still do fine with
simple sound feedback. Never heard someone saying "god, I wished the
slider made a gorgeous effect when I change it", it's more like "I
don't even notice, just when I'm using it without looking at it".
Really a lesser feature to be so excited of its possibilities.
that said, I'm not AGAINST SOUNDS IN EDJE, particularly for games and
some specific cases, such as a media center, this can be a killer
feature to impress people and ease development. I just don't see it
being useful in the window manager.
> 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.
I'm not saying that.
Moreover, for efficiency reasons libcanberra will be more efficient as
it will cache decoded samples at a central place (ie: pulseaudio) and
provide mixing at that level if possible. If you have your WM and 50
apps, you have all of that replicated with edje :-(
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: [email protected]
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
