xmn_ has quit [Read error: Connection reset by peer]
xmn has joined #maemo-leste
Twig has quit [Ping timeout: 248 seconds]
Twig has joined #maemo-leste
akossh has joined #maemo-leste
RedW has quit [Quit: huh upgrades]
RedW has joined #maemo-leste
Twig has quit [Ping timeout: 246 seconds]
Twig has joined #maemo-leste
Twig has quit [Ping timeout: 276 seconds]
Twig has joined #maemo-leste
<Wizzup>
arno11: I get about 24h of battery life without any OC patches btw
<Wizzup>
with modem on etc
<Wizzup>
I think when ts actually idles it will save a lot more too
<Wizzup>
arno11: so for now, we can maybe have an init script that loads nokia-modem after ofono or something?
Twig has quit [Ping timeout: 246 seconds]
Twig has joined #maemo-leste
arno11 has joined #maemo-leste
<arno11>
Wizzup: (for the battery life) cool. yes we can even do better with TS stuff
<arno11>
nokia modem must be loaded after all other modules
<arno11>
to avoid random bugs and errors
<Wizzup>
well, I think we can have the init script run after ofono
<Wizzup>
that should be fine
<arno11>
ok cool
<arno11>
Wizzup: do you have troubles with audio ringstone ?
<arno11>
or playing music ?
<Wizzup>
I haven't checked, but I will
<Wizzup>
I doubt that the same asound state works
<Wizzup>
this is why we need UCM
<Wizzup>
but I haven't checked it yet
<Wizzup>
back in a ibt
<arno11>
because default 48000hz cause troubles
<arno11>
using always same asound works fine
<arno11>
but i recommand to use default 44100hz in daemon.conf
norayr has left #maemo-leste [Error from remote client]
norayr has joined #maemo-leste
arno11 has left #maemo-leste [#maemo-leste]
Twig has quit [Ping timeout: 240 seconds]
Twig has joined #maemo-leste
arno11 has joined #maemo-leste
<arno11>
Wizzup: sicelo: i successfully removed the 15 sec incoming call bug. It is not 100% functional ATM because i need to add a new "disconnected" state to hangup incoming calls properly.
<arno11>
Anyway cmtspeech was using wrong ofono properties.
uvos has joined #maemo-leste
<uvos>
so what do we need mafw for exactly
<uvos>
ie what dose it bring to the table the usual desktop linux media frameworks dont?
<freemangordon>
like which one?
<uvos>
well all of them, so what would you gain when switching from for instance qtmultimedia with mp-ris to mafw?
<uvos>
for instance
<freemangordon>
integration with mce, for example
<freemangordon>
daemon
<freemangordon>
lighter footprint
<freemangordon>
iirc, libplayback integration
<uvos>
1. what integraton? pause on blank? we need to add mp-ris support anyhow so that the desktop applications behave, same gos for libplayback
<uvos>
2. not really a benefit
<uvos>
3. citation needed it just uses gstreamer as a backend no?
<freemangordon>
libplayback is not what its name implies
<uvos>
libplayback is a client API that allows an application to declare its playback state
<freemangordon>
mhm
<uvos>
sounds exactly like mpris
<uvos>
and mpris is universally supported on desktop applications
<uvos>
realy 100%
<freemangordon>
feel free to install KDE then
Twig has quit [Ping timeout: 276 seconds]
<uvos>
how is mpris kde?
<freemangordon>
for example
<uvos>
its not even initated by them
<freemangordon>
and you'll have DE on your mobile
<freemangordon>
this conversation is really useless
<freemangordon>
because someone does not like/does not know some API does not make that API bad
<uvos>
im not saying its bad
<freemangordon>
anyway, libplayback is integrated with th eother parts of leste
<freemangordon>
if we are to keep what we know works good on mobile, I don;t see why shall we reinvent the wheel
<uvos>
but your expending signifcant effort draging a api into the present, that duplicates a widly used available api that we need to implement anyhow because its widely used
<uvos>
so i question this
<freemangordon>
I( understand that
<freemangordon>
but I am not convinced taking desktop applications and puting them on mobile is a good idea
<freemangordon>
not to say none of them are integrated with OS/DE in the way maemo components are
<uvos>
even if you ignore any "desktop" application (i highly object to this), the problem is also that our colleagues @plamo and probubly also phosh are developing mobile focused applications that do use thes apis
<freemangordon>
I know you have little idea what I am talking about having almost none experience with fremantle as user, unfortunately I have no idea how to explain such UX
<uvos>
the "ux" has nothing to do with the api used to accive the effect
<freemangordon>
it has lots of
<uvos>
imo the "ux" will be mutch worse if the apis used are only implemented by a tiny subset of the avialble applications
<freemangordon>
I don;t need 10 media players
<freemangordon>
nor 10 phone apps
<freemangordon>
I need one that works well
<freemangordon>
BTW, OMP is a QT FOSS rewrite of the stock Nokia MP, that was written in GTK
<freemangordon>
so MAFW must be good enough to allow that
<freemangordon>
also, there is MP destop widget, which is built upon the fact that MAFW gives daemopn
<uvos>
well on fremantle they where more or less forced to go trough contortions to use nokias apis for anything to work
<freemangordon>
no
<freemangordon>
there was QtMultimedia back then
<uvos>
sure but it dosent itegrate with os at all
<freemangordon>
qyoutube uses it, for example
<uvos>
because the os bits are only implemented on the nokia api side..
<freemangordon>
what bits exactly?
<freemangordon>
also, how is the situation any better now?
<uvos>
well i would expect stuff to duck/pause for notifactions, maybe song title on the lockscreen, def things like universal media widges on h-h
<freemangordon>
right
<uvos>
ie the stuff mpris is used for on desktop
<uvos>
and plamo etc
<buZz>
i would like 'x unread sms' 'x missed calls' on lockscreen
<freemangordon>
buZz: umm, we have that
<uvos>
no we dont
<buZz>
oh? havent ever seen any
<freemangordon>
yes, we do
<uvos>
no sphone is not called "rtcom"
<uvos>
so it dosent work
<freemangordon>
well, that does not mean we *do not* have it
<buZz>
ah yeah its the 'sphone wont get features we want' argument?
<freemangordon>
right, it does not work
<uvos>
since its hardcoded to only show when its from "rtcom"
<uvos>
buZz: its not really sphones fault
<buZz>
but?
<uvos>
see above
<freemangordon>
no, it is hardcoded to read the DB with sql queries
<freemangordon>
anyway
<buZz>
that doesnt tell me why it cant read the information from the db
<buZz>
is the information in the db?
Twig has joined #maemo-leste
<freemangordon>
no
norayr has left #maemo-leste [Error from remote client]
<buZz>
can we put it in? :)
<freemangordon>
because nobody puts it there
<freemangordon>
\sure
<freemangordon>
*sure
<buZz>
but why arent we, then?
<freemangordon>
because Wizzup seems to be overloaded lately
<buZz>
is the rtcom-db-not-filled also the cause for unable to add numbers from 'recent' in contacts?
<freemangordon>
yes
<buZz>
ah, sounds important then :)
<freemangordon>
well...
<freemangordon>
we had that discussion couple of times already
<freemangordon>
no need to repeat once again
<freemangordon>
we know what/where has to be done
<freemangordon>
it is just that nobody did it already
<buZz>
alright :)
<freemangordon>
uvos: so, in your QtMultimedia example, who will lower the volume in case of notification or stop playback in case of a phone call?
<freemangordon>
shall we teach QtMultimedia on that?
norayr has joined #maemo-leste
xmn has quit [*.net *.split]
freemangordon has quit [*.net *.split]
enyc has quit [*.net *.split]
sunshavi_ has quit [*.net *.split]
juiceme has quit [*.net *.split]
_alice has quit [*.net *.split]
juiceme_ has joined #maemo-leste
sunshavi_ has joined #maemo-leste
enyc has joined #maemo-leste
_alice has joined #maemo-leste
freemangordon has joined #maemo-leste
arno11 has left #maemo-leste [#maemo-leste]
xmn has joined #maemo-leste
Twig has quit [Ping timeout: 252 seconds]
Twig has joined #maemo-leste
<uvos>
freemangordon: so we would just have someone (maybe mce, maybe some pa plugin) stop or lower all mpris clients when required
<uvos>
centrally
<uvos>
then everybody should follow, incl random media players and browsers etc
<uvos>
to enforce just lowering of the volume (as opposed to stoping playback) we should also affect the pa streams
<uvos>
so that works for games and so on too
<uvos>
you can alos have pa stop accepting writes on the soccet (on d4 we currently do this when in call mode)
<uvos>
how this affects applications is a bit uneven and i dont know if dothing this is a good plan long term
<uvos>
some applications use non-blocking writes and pause themselves when they cant write to pa
<uvos>
otheres use blocking writes and hang untill pa unblocks the stream
<uvos>
the latter is a bit undesirable ofc
<freemangordon>
ok, but IIUC that would require way more effort that just porting 50 LOC from gst 0.1 to gst 1.0
<freemangordon>
and yet, we are tied to and API, not mafw, but MPRIS
<freemangordon>
which we have no idea how it works on mobile and what downsides it has
<freemangordon>
s/and API/another API/
norayr has left #maemo-leste [Error from remote client]
Twig has quit [Ping timeout: 260 seconds]
Twig has joined #maemo-leste
Twig has quit [Ping timeout: 265 seconds]
Twig has joined #maemo-leste
norayr has joined #maemo-leste
Twig has quit [Ping timeout: 256 seconds]
Twig has joined #maemo-leste
uvos has quit [Remote host closed the connection]
xmn has quit [Ping timeout: 265 seconds]
Pali has joined #maemo-leste
arno11 has joined #maemo-leste
Twig has quit [Ping timeout: 260 seconds]
arno11 has left #maemo-leste [#maemo-leste]
elastic_dog has quit [Remote host closed the connection]
elastic_dog has joined #maemo-leste
LjL has quit [Read error: Connection reset by peer]