<_uvos_>
freemangordon: i dont get any of your points
<_uvos_>
rn any desktop app can and dose play notifcation sounds itself - ingoreing the profile
<_uvos_>
if you implement libnotify sounds then we have a chance to have those respect the profile
<_uvos_>
as we can for instance not play those when the profile saies to be silent
<_uvos_>
so i dont see how this is not a sreight imrovement
<_uvos_>
regarding actions i dont understand what you mean, if you imelment actions aplications can and do use those, its more about getting existing destop applications to work than anything else
<_uvos_>
i dont see why "if i implement actions, they will get used" is a problem
<_uvos_>
the categories work sortof ok
<_uvos_>
another imrtant failing of the notification system is, btw that non hardcoded notifications dont stack
<_uvos_>
this is for instance a huge roblem with gpodder and telegram
<_uvos_>
both of these create a notification for an event (message for telegram or finished download for godder)
<_uvos_>
unfortionatly h-h will simply create a new window for eatch
<_uvos_>
notifcation
<_uvos_>
this quickly effectively hangs the system with open windows
<_uvos_>
if you for instance get a lot of messages with telegram catching up to some chat or godder downloading an entier podcast season
<_uvos_>
btw also if a application dosent set an image h-h will substitue a big "image could not be loaded icon" this is qute undesirable as the message image is optional in spec, but this makes it look like there is somehing worng
<_uvos_>
i think letting the user choose we
<_uvos_>
*if he wants the device to vibrate for "other" libnotify notifcations is quite sane
<_uvos_>
idealy per category
<_uvos_>
but i agree that is schould probubly default to no
_uvos_ has quit [Quit: _uvos_]
akossh has quit [Quit: Leaving.]
Daanct12 has joined #maemo-leste
joerg has quit [Ping timeout: 265 seconds]
joerg has joined #maemo-leste
Daanct12 has quit [Quit: WeeChat 3.8]
Daanct12 has joined #maemo-leste
macros_2ndPC has quit [Ping timeout: 252 seconds]
macros_2ndPC has joined #maemo-leste
Twig has joined #maemo-leste
Daanct12 has quit [Quit: WeeChat 3.8]
Daanct12 has joined #maemo-leste
xmn has quit [Ping timeout: 257 seconds]
ceene has joined #maemo-leste
xmn has joined #maemo-leste
arno11 has joined #maemo-leste
<arno11>
Wizzup: hm i forgot to ask you if you have cmt_speech and omap_ssi loaded on boot
<freemangordon>
arno11: re n900 3d performance - I am not sure it worths it spending time on that
<arno11>
freemangordon: really not essential
<arno11>
just for fun
<freemangordon>
n900 has bigger issues performance wise than this - like, no matter what we do, there will be no usable modern browser
<arno11>
indeed
<arno11>
that's the main issue
<freemangordon>
mhm
<freemangordon>
and that's a HW limitation
<freemangordon>
256MiB of RAM
<arno11>
yes but swap works fine
<freemangordon>
sure, but it is slow
<arno11>
with overclock not
<freemangordon>
just don;t get me wrong - I love n900 and I am still using it as my daily device (with fremantle)
tmlind has quit [Ping timeout: 250 seconds]
<freemangordon>
but I don;t feel it makes sense to put too much effort in regards to leste
<freemangordon>
given there are so many other things that are not device specific and we still lack
<freemangordon>
like conversations, or BT, or ...
<arno11>
not a lot of things
tmlind has joined #maemo-leste
<arno11>
conversations is not user friendly but works
<arno11>
BT ok but is it essential in 2023 ?
<freemangordon>
hmm? do you drive a car?
<arno11>
oh yes
<freemangordon>
and no, conversations do not work
<arno11>
? what do you mean
<freemangordon>
well, not properly at least
<freemangordon>
they are still not properly integrated with TP, or were not, last time I checked
<freemangordon>
also, you cannot start a chat
<arno11>
it is possible using a bitlbee gateway
<dsc_>
start a chat with whom freemangordon :)
<freemangordon>
dsc_: contact :p
<dsc_>
via...
<dsc_>
:)
<freemangordon>
address book
<freemangordon>
;)
<dsc_>
which is a GTK widget
<freemangordon>
no, that's one way
<freemangordon>
but, conversations should handle TP requests for chats
<freemangordon>
arno11: dsc_ just reminded me one more big thing we lack - properly expose addressbook via either dbus or some other means to non-gtk2 applications
<freemangordon>
dsc_: BTW, did you see mafw progress?
<freemangordon>
gst-renderer that is
<dsc_>
sec
<arno11>
freemangordon: yes indeed
<dsc_>
I think it is important to emphasise my skills is over at C++ *GUI* development, not "low-level" TP/rtcom/dbus work (expectation management)
<freemangordon>
umm,... I don;t wanted to sound like I accuse anybody
<freemangordon>
I am just saying that we lack functionality, which IMO is more important than 3d performance on n900 :)
<freemangordon>
*didn;t want
* freemangordon
needs more coffee
<arno11>
lack of coffee is always the main issue :)
<dsc_>
as we speak I'm working on groupchat support, which is mostly graphical (GUI and a little bit of rtcom) but *not* TP, I will however dive into TP later but this an area where its "hit or miss" - For example fmg or Wizzup would work 10x as fast here in figuring stuff out
ceene has quit [Ping timeout: 252 seconds]
<freemangordon>
dsc_: oh, I was left with the impression you work on OMP
<dsc_>
same @ OMP; when it goes "too deep" I hit an obstacle - initially the request was "fixing the QML" but that quicly turns into "mafw gst renderer needs to be fixed"
<dsc_>
which has nothing to do with Qt GUI dev
<dsc_>
i.e: I am unwilling to go outside my lane, so-to-say ;)
<freemangordon>
dsc_: right, that's why I fixed it an now it works :)
<freemangordon>
(mafw-gst-renderer)
<freemangordon>
thus my question 'did you see mafw-gst-renderer is fixed'
<dsc_>
were you able to try the C snippet I provided where it tests for an available renderer?
<freemangordon>
yes
<dsc_>
I did try your fix but couldnt get it to work, something with needing to run a daemon... some other stuff, i dunno
<dsc_>
I think there were 2 fixes
<freemangordon>
there was an issue with starting the daemon
<freemangordon>
but now everything is ok
<freemangordon>
the example on maemo.org works as is
<dsc_>
okay ill check OMP out
<freemangordon>
I am able to play internet radio with it
<freemangordon>
dsc_: keep in mind that at least in virtualbox VM we have issues, as XV is not supported but is required by it
<dsc_>
via OMP?
<freemangordon>
no
<freemangordon>
via example code on maemo.org
<freemangordon>
lemme try to find it
<dsc_>
alright
<dsc_>
im using QEMU btw
<freemangordon>
does it have XV acceleration?
<freemangordon>
xvinfo
<dsc_>
doesnt seem like it
<dsc_>
"no adaptors present"
<freemangordon>
:(
<dsc_>
IIRC I did try your fix but the renderer just wouldnt show up
<dsc_>
but then failed to mention it
<freemangordon>
it will not work in the VM now
<freemangordon>
because of that said lack of XV
<dsc_>
ic
<freemangordon>
ok, I'll try to come-up with a fix and will let you know when I am ready
<freemangordon>
we have to agree though on what the fallback would be
<freemangordon>
glimagerenderer?
<dsc_>
performance certainly wouldnt be of importance as VM is solely for dev
<freemangordon>
it is not about the performance
<dsc_>
pick whatever is easiest I suppose
<freemangordon>
the problem is that x11imagesink does not support color key
<freemangordon>
so UI will look weird
<dsc_>
you dont have to fix the VM
<dsc_>
i can just use real hw
<dsc_>
nobody will watch media in a VM anyway
<dsc_>
right?
<freemangordon>
developing there will be hard, no?
<freemangordon>
not really
<freemangordon>
our dev environment should be usable
<dsc_>
its ok, a little slower but my workflow is already with a remote debugger, VM or real HW doesnt matter much
<dsc_>
ok
<freemangordon>
hmm, ok
<freemangordon>
well. you can start with real HW then, until I fix it under VM
<freemangordon>
arno11: another big thing - media player ;)
<dsc_>
well, that depends on if I can actually boot into real HW (drained battery issue)
<dsc_>
lets see
<freemangordon>
ugh
<freemangordon>
this is d4, right? if yes, you should be able to boot to android to charge
xmn has quit [Ping timeout: 252 seconds]
<arno11>
freemangordon: mplayer with smplayer works great. even able to stream online content. internet radio works well with audacious. but ok it is not user friendly
<dsc_>
i have a working d4
<dsc_>
so thats good
<dsc_>
anyway, what I was working on just now was figuring out the db schema for rtcom regarding groupchats
<dsc_>
Wizzup is sending me an example db soon that contains xmpp group chats for reference
akossh has joined #maemo-leste
fab_ has joined #maemo-leste
<arno11>
Wizzup: tweaks in the code only run once a call is made. if you have error messages when you start cmt_pulse that means something is wrong between cmt-dbus-ofono-modem. So that's why i asked for modules on boot (cmt_speech and omap_ssi).
<arno11>
cmt_pulse must start with absolutely no errors
arno11 has left #maemo-leste [#maemo-leste]
<sicelo>
freemangordon: i agree regarding n900 3D performance. still worth working on the vrfb stuff though?
<sicelo>
arno11, yes you may send me an email, absicsz at the popular G provider
<Wizzup>
CMTSPEECH: backend_common: CMT Speech Data state machine activated with SSI_CONFIG_REQ.
<Wizzup>
ERROR: CMTSPEECH: backend_common: ERROR: SSI_CONFIG_RESP returned an error 1
<Wizzup>
cmtspeech_ofono_test: ERROR: invalid state transition
Twig has quit [Ping timeout: 276 seconds]
pere has quit [Ping timeout: 252 seconds]
<Wizzup>
arno11: I do have them loaded on boot btw
Twig has joined #maemo-leste
Daanct12 has quit [Ping timeout: 260 seconds]
Daanct12 has joined #maemo-leste
pere has joined #maemo-leste
uvos__ has joined #maemo-leste
<uvos__>
btw i have been migrateing my rather complicated home audio setup from pulse to pipewire
<uvos__>
and so far have been not so terribly impressed
<uvos__>
its a pretty "special" setup, but so are our phones
<Wizzup>
I use pipewire because it's great for echo cancellation
<Wizzup>
and it seems just a bit more clever than PA for that
<Wizzup>
can't comment on other things
<Wizzup>
s/echo cancellation/noise cancellation/
<uvos__>
ok
Daanct12 has quit [Quit: WeeChat 3.8]
pere has quit [Ping timeout: 255 seconds]
<uvos__>
so so my setup looks like this: so i have a htpc that has a creative xi-fi and is connected to speakers in 3 rooms, so the 7 channels are split into 3 stero sinks. My main workstation is a amd epyc server mainboard with no soundcard (dont ask) that networks streams the audio to the htpc that then is supposed to output that to the right channels
<uvos__>
so far this has been a pretty unplesent expirance migrateing this setup to pipewire
<dsc_>
maybe I need to start omp from the device itself, not ssh (possible dbus issue)
<dsc_>
freemangordon: so this C snippet worked for you? strange
<dsc_>
I will document my findings on Github
<dsc_>
(c)(tm)
<dsc_>
and continue with conversations
<freemangordon>
sec
<arno11>
Wizzup: i think you should try pa_test first instead of cmt_pulse to see if record/play works. then try cmt_pulse -a -v -v to check if there is a specific error before trying to call.
<arno11>
i'm pretty sure we forgot a small thing.
<arno11>
sicelo: ok i'll send you an email adding few more details to be sure it works
<arno11>
sicelo: email sent. LMK if something is wrong