On Tue, 15 Nov 2011 02:52:49 -0200 Gustavo Sverzut Barbieri
<barbi...@profusion.mobi> said:
> On Tue, Nov 15, 2011 at 12:45 AM, Carsten Haitzler <ras...@rasterman.com>
> wrote:
> > 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".
>
> 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?
well your argument here is that we keep the annoying difference visually
because we want to keep it but not sound? as such i actually care about sound -
a lot. i want it to be powerful and flexible. i care about it like i care about
the graphics too. if there is a reason to keep the graphics using our own infra
then there is a reason to keep the sound too - maybe not for you, but for me it
is. if the argument is just "users don't like e because it is different and
doesn't match their gtk/qt/whatever apps" then that is the point at which this
project gives up and shuts up shop. the whole point IS to do something
differently AND better. this project isn't about "lets just do exactly what
everyone else does and make it use less memory". it's fundamentally against what
this project stands for to do what you suggest. if i didn't care about sound =
i'd probably agree with you, but i do care and i want to do something better,
and not just "fall into line". e has never been about falling into line. not
from the very first day.
>
> >> 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.
it'll be the only mechanism to start with as frankly.. i want this for things
like phones and tablets.. where freedesktop sound themes don't exist and are
not relevant. so it has to work there first... and in working there... it works
on your desktop too.
> >> 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.
that's a bit tough as the object is known within window, but not relative to
screen... but now i get the idea - you wanted to use object geometry (and then
canvas, ecore-evas, window etc.) and figure out spatial info from that.
> >> 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.
i don't see a problem with general events. e already has several of these, so
things like pagers, can work at all as modules. can you expand on what the user
was complaining about? :)
> 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.
well it's useful for things like widgets and technically edje already acts as
an abstraction mechanism - emit signal to edje obj and it can react both
visually.. and with audio. the whole sound event system would make sense to use
that layer just like its used for everything visual.
> > 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 :-(
that is true, but we have a much bigger problem already with that and images.
--
------------- 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
