<uvos>
im pretty sure its "autor" acording to the repo lacks copywrigt
<uvos>
the sphone ringger is fine its just a recording of a model 500 telephone
<Wizzup>
I kinda like the sphone ones tbh
<uvos>
right but the notifcation sound we cant use - its copyrighted
<uvos>
the model 500 recording is fine
asriel has quit [Quit: Don't drink the water. They put something in it to make you forget.]
asriel has joined #maemo-leste
<Wizzup>
afaik we can just use the nokia ones, same like themes and everything else
<Wizzup>
as long as it's hosted on maemo.org
<uvos>
ok but i dont think thats a solution really
<uvos>
regardless we need some other default than the nokia-tune
<uvos>
using that is just asking to be scrutinized
<uvos>
anyhow regardless of what we will do, ill create a asop-sounds package
<uvos>
we can place it into extras as something to be userinstalled if we dont want it later
<Wizzup>
for audio, I think we'll at least need telepathy-ring running in the background
<Wizzup>
(for the policy to pick up on calls)
<Wizzup>
I might try my hand later at porting to telepathy-glib with ring
<uvos>
telephathy must have some interface into puse for the profile no?
<Wizzup>
for the audio? no
<Wizzup>
All of this is done by ohmd and it's a solved problem if we use telepathy afaik
<Wizzup>
it inspects telepathy dbus
<Wizzup>
but it doesn't inspect ofono for semi obvious reasons
<uvos>
i think haveing a hard dependancy between telepathy and audio routing is a huge mistake
<Wizzup>
running ring does not interfere with sms (gets delivered to both sphone and empathy), and calls not
<Wizzup>
well it's how sailfish works, and fremantle works
<uvos>
thats nice i still think its a mistake
<uvos>
those are closed ecosystems
<Wizzup>
seems to make sense to me, ohm can make sure the ringtone you play is on the speakers/hp, whereas the moment you pick up it auto switches for you
<Wizzup>
and suspects and other speakre audio
<uvos>
where everything is expected to be written for that platform and that platfrom only
<uvos>
sure but ohm should just expose some generic interface that allows you to tell it what is needed right now
<uvos>
and then telepathy uses that
<uvos>
snoopting on telepathy state is not an interface
<uvos>
snooping
<Wizzup>
It's not really snooping, it's how telepathy works (over dbus)
<uvos>
right but its the wrong way around imo
<Wizzup>
plus you can use pulse hints to affect the policy
<uvos>
telepathy should be using a ohmd/pulse audio routing interface
<Wizzup>
I don't see how that makes more sense
<uvos>
audio routing should no be passively following telephathy
<uvos>
it makes more sense because removes telepathy as a hard requirement
<Wizzup>
you could just change the policy to support other things too, which it might do given the right pulse hints
<Wizzup>
I think this is the xpolicy.conf stuff
<Wizzup>
I'm just saying that if we use telepathy, everything will work smoothly and it'll be the integration we're aiming for, which is why I'll try my hand at the telepathy-glib when tor/wireguard and audio routing work
<bencoh>
don't we already have tor plugins in fremantle?
<uvos>
ok so how this works is telephathy takes a call, and on dbus it has a signal that it did take a call right?
<uvos>
and then ohmd acts on that and switches the route?
<uvos>
am i getting this correctly
<Wizzup>
bencoh: very poorly integrated
<Wizzup>
uvos: yes, that is my understanding, it will switch the right alsa switches
<Wizzup>
maybe also do some pulse rerouting (not sure, probably depending on the setup)
<Wizzup>
and it'll cork normal streams
<uvos>
right so i honestly think this is horrid
<bencoh>
what would you do then? have telepathy-ring talk with pulse directly?
<uvos>
no
<uvos>
so id have ohmd have an interface
<uvos>
that telephathy calls
<uvos>
that way anyone can cause the audio route to change if it uses the same interface
<Wizzup>
so if I were to make a diagram of what talks to what, it'd get more complicated and we'd have to patch all the mainline stuff to talk to ohmd
<uvos>
so in effect it allows you to replace telephathy
<uvos>
the current way dosent
<Wizzup>
whereas here ohm is just clever and does the right thing
<uvos>
because only telepathy can own its dbus name
<Wizzup>
s/mainline/upstream/
<bencoh>
but, err ... we use telepathy on purpose, don't we?
<Wizzup>
why would you want to replace telepathy? you could just edit the policy and support other protocols
<Wizzup>
bencoh: yes, we will
<bencoh>
and it *is* supposed to be our middleware communication stack
<Wizzup>
(we don't use it currently for the phone calls, it's purely ofono dbus atm)
<bencoh>
unless I missed something
<uvos>
ok but then you are createing policys for specific apps
<uvos>
for no reason
<Wizzup>
uvos: in your example every app has to talk to ohm, I don't see the difference
<Wizzup>
but the way I see, we will have no communication apps other than our telepathy UIs
<Wizzup>
I see it*
<Wizzup>
whatsapp, signal, whatever, we'll make it work with TP
<uvos>
the difference is that ohm is lower level
<uvos>
its closer to the hw
<uvos>
the interface is the wrong way around
<Wizzup>
if people insist on using linphone over sofiasip, then we can have a policy entry for it, but then linphone will also need to know to tell mce to set the phone to call mode, etc etc
<Wizzup>
bencoh: I don't think you missed something
<Wizzup>
we just don't have it yet
<Wizzup>
:)
<bencoh>
:)
<uvos>
to make a comperasin this is like haveing the kernel inspect what some app is doing and then allocated memory instead of the app calling to the kernel for memory
<Wizzup>
with osso-abook hopefully ready semi soon another big gap will be filled and then I think we should be able to focus a lot on this stuff
<uvos>
and sure we want tp
<Wizzup>
uvos: I don't see it that way really, telepathy is clear about it's intentions on dbus, and our phone ohmd is clever to set up the audio routing properly, instead of making telepathy do low level stuff it shouldn't do
<uvos>
but we should make everything as loosly coupled as possible without sacrificing functionality
<uvos>
its just prudent
<uvos>
what happens if tp implodes tomorrow
<uvos>
you want to maintain it
<uvos>
no we should allways think about an out
<bencoh>
I'd be honest, I think telepathy is already in a life support mode
<uvos>
and simply reversing the interface reduces the dependancy
<Wizzup>
I think it creates reverse dependencies everywhere
<Wizzup>
the last one is decent I think to get an appreciation of the amount of work the nokia/mer folks put in to support all the features (I didn't read most of the code.)
<sicelo>
bencoh: i am not sure TP is on life support. Plasma Mobile is using it, and, I believe, maintaining it very actively
<sicelo>
yes, that's why i said it's actively maintained
<sicelo>
i don't see it imploding in our lifetime
<Wizzup>
sure, imploding is basically impossible unless we all decide to stop using dbus
<Wizzup>
I think where it lacks is feature richness that other protocols support (weird voice files/messages, etc)
<Wizzup>
I'm going to get some rest, didn't get to sleep earlier
<sicelo>
iirc it now does support those things. telegram, for example, has them
<sicelo>
anyway, i also don't follow this stuff anymore
<uvos>
this isent about the merrits of telepathy at all per say
<uvos>
and also complexity/ time spent in implementation is hardly something that speaks for some solution
<uvos>
this is about base os independance from some telephony solution
<uvos>
ie i want the base os to be independant from the specifics telephathy
<uvos>
and the audio setup is very mutch part of the base os
<Wizzup>
well, from a practical point of view it sounds like something that can take many months, and I think walking the known path here makes a lot of sense
<Wizzup>
i.e. re-use the existing stuff
<uvos>
and i very mutch _dont_ see the telephony as part of the base os as leste is usefull on any touchscreen device
<sicelo>
what's TP got to do with touch :-/
<sicelo>
anyway, /me out
<uvos>
sicelo: the device might not be a comunication device at all
<Wizzup>
well, that's fine, then one can try to remove osso-abook and tp and such
<Wizzup>
we can make that work out with deps
<Wizzup>
and if it is not a communications device, audio routing is mostly not a problem
<sicelo>
maemo has become something else. i thought it was *always* about communication devices
<Wizzup>
I think it's a nice tablet os :)
<Wizzup>
regardless of calls
<Wizzup>
like, a good mobile linux interface
<sicelo>
calls != communication
<uvos>
also in an ideal world hildon would just be a de
<sicelo>
N800 was a communication device ... skype and all
<Wizzup>
well any computer we really use is communication, so it's, idk, nitpicking
<uvos>
that you can just install over some linux distro
<uvos>
ofc thats currently not possible but idealy
<sicelo>
and therefore N8x0 had/used TP
<uvos>
i think thats all it would be
<Wizzup>
in any case I feel like we've had the discussion before, and my opinion is that we can change the inner workings once we have a full featured device and fully understand it all
<Wizzup>
until then I am not inclined to think I can think of a better way than the many dedicated nokia engineers at the time for something as complex as audio routing
<Wizzup>
I don't even understand all that they did yet
<uvos>
(ie dosent segfault all over the place, leak memory and input works fine etc)
<uvos>
dosent scale either
<uvos>
is a newer version 0.61 vs 0.58
inky has quit [Ping timeout: 248 seconds]
inky has joined #maemo-leste
<inky>
folks, i don't use sim cards. first thing i did with pinephone was i disabled its modem before switching the phone on for the first time.
<inky>
but even i would like to have address book integrated with telepathy.
<inky>
tdats the main yeature of maemo
<inky>
for which nokia n900 was called phone 2.0 in one article.
<inky>
i use audio calls rarely with jabber.
<uvos>
in no way was the above discussion about using telepathy or not
<freemangordon>
addressbook is integrated with telepathy(once I finish REing it, ofc)
<bencoh>
yeah, it was about low/middle-level integration with the rest of the ecosystem
<inky>
well may be libpurple is better, i don't know. i mean address book integrated with ability to call or message via different means.
<inky>
okay, yay.
<uvos>
tight integration is fundamentaly an evil
<uvos>
its is only good insofar it adds functionality you cant have otherwise
<uvos>
integration is a method of last resort to gain sutch functionality
<inky>
here i can agree. what makes it tight? i utderstood from the discussion it uses dbus only?
<uvos>
the audio routing system listens for telepathy dbus signals
<uvos>
only telepathy can own its dbus name
<inky>
i am always proponent of modularity and extensibility
<uvos>
thus only telepathy can change the audio state
<uvos>
unless you add another parrallel controll method
inky has quit [Ping timeout: 248 seconds]
inky has joined #maemo-leste
peetah has joined #maemo-leste
inky has quit [Ping timeout: 252 seconds]
inky has joined #maemo-leste
<Wizzup>
uvos: no, not only telepathy, it can use other info too
<uvos>
sure but it uses telepathy info
<uvos>
and anyhow it should use no info
<uvos>
its fundamently wrong for a low-level part of the stack to look at what the higher level parts and do something based on the state
<uvos>
the directive flow direction from end user application to hardware must be maintained
<Wizzup>
I wouldn't argue it's lower part of the stack
<uvos>
? its doing hardware state mangement
<uvos>
thats clearly lower level than what amounts to a fancy dialer
<uvos>
dialer backend rather
jmlich has quit [Remote host closed the connection]
<Wizzup>
specifically it implement hardware state mnagemente based on high-level policies
<uvos>
right
<Wizzup>
afk for the night I think :)
<Wizzup>
\o
<uvos>
i dont think you can convice me that it basing the execution of those policies on information i gathers rather than information it recives is sane
<uvos>
good night
<Wizzup>
Time will tell ;)
<Wizzup>
I think there is a lot to be said for services exporting their own information over dbus, which is how it works for pretty much every dbus service, and other programs reading that info to manage the hw state
<Wizzup>
ok, actually bbl now
<uvos>
"I think there is a lot to be said for services exporting their own information over dbus, which is how it works for pretty much every dbus service, and other programs reading that info to manage the hw state" where the thing using the interface is higher up the stack sure
<uvos>
thats not the case here
<uvos>
like (very relevant example) mce gets told by something using its interface that device is now in a call
<uvos>
it dosent go looking around on dbus to look and see if some specific call application is currently running/active
<uvos>
and thats the right way to do it
inky has quit [Ping timeout: 268 seconds]
<uvos>
some thin (also very relevant example) with pa, it gets told by something useing its interfaces what profile to apply to the hw state