<rafael2k_>
if possible, leave it available. It is already in a reasonable shape for distribution!
Twig has joined #maemo-leste
akossh has joined #maemo-leste
k1r1t0 has joined #maemo-leste
<Wizzup>
ok
xmn has quit [Ping timeout: 268 seconds]
xmn has joined #maemo-leste
pere has quit [Ping timeout: 260 seconds]
elastic_dog has joined #maemo-leste
elastic_dog is now known as Guest5516
Guest5516 has quit [Killed (molybdenum.libera.chat (Nickname regained by services))]
rafael2k__ has joined #maemo-leste
rafael2k_ has quit [Ping timeout: 252 seconds]
ceene has quit [Ping timeout: 252 seconds]
ceene has joined #maemo-leste
xmn has quit [Quit: ZZZzzz…]
<buZz>
is chimaera daily-driverable yet? :P on d4
<Wizzup>
no
<Wizzup>
tmlind: https://wizzup.org/warning.txt just got this when toying with hdmi on d4, not sure it's related to hdmi
<Wizzup>
buZz: it will be daily-driverable when we have tp-ring working properly, conversations as sms ui, and the tp calls work out of the box
<Wizzup>
but uvos doesn't like the tp work I did for sphone, so we have to either fork sphone to something like phone and potentially merge back later, or just create a new ui for phone calls and stop using sphone
<buZz>
ah, there's no sphone for chimaera now?
<Wizzup>
there is, but it doesn't work how it's supposed to work
<buZz>
ah yeah , thats a drag
<Wizzup>
if you have a different definition of 'daily-driverable', then you can feel free to try it
<Wizzup>
I want it to be like maemo fremantle in UX
<buZz>
well, do calls/sms/mobiledata work?
<Wizzup>
e.g. contacts icons show up, names show up, recent calls in main dialog so I can easily call back a missed number a little bit later, sms from conversations with a UI, delivery status reporting, message read marking, etc
<Wizzup>
without that it is not 'daily driverable' imo
<Wizzup>
this is probably gconf data, maybe it's in rtcom db
<Wizzup>
not sure, but we definitely don't have this atm
<Wizzup>
it's possible this is just aggregated from rtcom db
<buZz>
hmhm
<Wizzup>
but yeah the recent calls list we get for free
<Wizzup>
it's an existing gtk widget :)
<Wizzup>
well, from a foss maemo lib
<buZz>
i havent decided for my battery monitor, if i want to build my own history of old stats, or just use the 120second values from upower, it seems its a bit .. empty?
<buZz>
that batteryeye thing did its own collection
<buZz>
atm its still realtime only, and seems to have something wrong, its drawing way too much cpu for what its doing
branon_ has joined #maemo-leste
branon has quit [Ping timeout: 260 seconds]
pere has joined #maemo-leste
<Wizzup>
back late rtoday
<buZz>
ciao
uvos__ has joined #maemo-leste
<uvos__>
buZz: sphone works just fine on chimeara incl sms
<uvos__>
its just that sphone and comversations with sms are not compatabil
<uvos__>
but this istent a change that came with chimeara
<buZz>
just fine = just as poorly as on beowulf?
<uvos__>
sure not change
<uvos__>
so its just as unfinished
<buZz>
ah, so there's a plan to finish it?
<uvos__>
sure
<uvos__>
well atm it looks like it will just be forked (wich means i will stop working on it - at least for leste purposes)
<bencoh>
oh?
xmn has joined #maemo-leste
ceene has quit [Ping timeout: 248 seconds]
noidea__ has quit [Quit: Leaving]
noidea_ has joined #maemo-leste
<Wizzup>
uvos__: so the way I see it there are a few things that conflict. (1) is that you said using voicecall-manager was 'unacceptable' from an architectural pov, whereas for maemo leste it makes a lot of sense to share things with sailfish. I can rename comm-telepathy to comm-sfos-voicecallmanager is that somehow solves the problem. (2) We're trying to make a free phone os like maemo, and your UX ideas
<Wizzup>
don't seem particularly compatible - we want integrate things that look and work (to some extend) like maemo, you want the dialer to be the main window with no obvious recent calls like in maemo.
<Wizzup>
My thought was that we could have all this maemo work be contained in modules: one that interfaces with tp through voicecall-manager, one gtk module that has more rtcom integration and separates out the dialer
<uvos__>
eh 2 i dont really care about
<uvos__>
since sphone allready has a way to swich what window is the "first"
<Wizzup>
but you've repeatedly opposed it, it seems, so I don't know how to deal with it, for example, how do I get others to check out or try the work? there's no way to build it for the repo
<uvos__>
(hint its just what you pass to c in the .desktop file)
<uvos__>
*-c
<Wizzup>
so it's not that I -want- to fork sphone, but I want to make it like maemo, and I don't really see a way out of this if you're not ok with optional modules with extra dependencies
<uvos__>
so sure make recents the first window, ill just change it back locally
<Wizzup>
like, I am very happy to accomodate requests, make things modular, make it sensible, but I spent over a week on the tp stuff (mostly non stop) and I think it makes a lot of sense for *maemo* to use sfos code, at least in this case
<uvos__>
im not against using sfos code, im against having yet another deamon doing the same thing
<uvos__>
and im not against having jet antoher deamon as a stopgap either
<Wizzup>
hmm ok, maybe I misunderstood then
<uvos__>
im also agaisnt integrating more rtcom dialogs
<uvos__>
beacuse i want to port to qt
<uvos__>
and this would get in the way
<Wizzup>
as in, please don't read this as me not liking criticism on a pr, I'm happy to put in a lot of time and make it more to your wishes, but I don't see a big architectural problem with sphone having a module to interface with voicecall-manager, since I see sphone as 'the phone interface for maemo' with is pretty generic
<Wizzup>
and I understand you see that part differently (re: architecture)
<Wizzup>
well, how do you suggest we proceed? I can fix up the PR, maybe rename the module, and see if I can make some mock up gtk module with rtcom lib in it (just to play around)
<uvos__>
Wizzup: i understand you point to, you want it to work like freemantle as soon as possible, i would rather it take longer if that means cleaner code
<uvos__>
or cleaner arch more than code
<uvos__>
anyhow
<Wizzup>
(btw I have a lot of ideas/thoughts on qt, but it is currently extra work to go for it now)
<uvos__>
Wizzup: sure ill merge the module if you clean it up (and maybe sip works?) as a stopgap (that ok ill replace it myself but please help me with tp then)
<Wizzup>
I'm glad we found some understanding and I'm sorry if I'm pushy.
<Wizzup>
so I'll: (1) clean up the PR, maybe rename it if you want to sfos-voicecallmgr instead of comm-telepathy (2) see if I can make SIP work at least audio routing wise
<Wizzup>
at that point we'll probably have to collaborate on sip addresses
<Wizzup>
and independently I can at least try to make a gtk module with the rtcom widget in it, see how it works
<uvos__>
Wizzup: sure sounds good
<Wizzup>
btw: the current state of sip is that it can get incoming calls, answer them, gstreamer says it sets up audio, but I don't see the audio in pulseaudio
<Wizzup>
so there's something finnicky there, but the other parts seem to work
<uvos__>
Wizzup: ok hmm, no idea on that front
<Wizzup>
yeah, I'll dive into it a bit later
<Wizzup>
ok, cool
* Wizzup
is less stressed now
<Wizzup>
time for a coffee :)
<uvos__>
oh and can you see the inline comments on gh now?
<uvos__>
or shal i paste them somewhere
<Wizzup>
I thought that maybe my browser was not wide enough to see them, but not really, the way I understand the gh comments work: (1) I get emails about each one of them (2) they show up as 'unresolved questions' and (3) there is something interwoven in the code view that shows the comments
<Wizzup>
for some reason I don't see anything besides the two messages in the main view of the pr
<Wizzup>
(not sure why the bottom is black, but there's no chat there either)
<Wizzup>
Is it maybe somehow saved in your browser but not submitted?
<uvos__>
im on a different device right now
<Wizzup>
ok, no rush
<uvos__>
maybe i have to make the comments public somehow
<uvos__>
i must be missing something
<Wizzup>
I know what to do mostly anyway, at least for rev 1 :)
<uvos__>
instead of just commenting i started a "review" and apreantly it wont show for others (with no indication that it is so) untill i submitt the review
<uvos__>
TIL
<uvos__>
Wizzup: ^^ should show now
<Wizzup>
ty!
uvos__ has quit [Remote host closed the connection]
uvos__ has joined #maemo-leste
k1r1t0 has quit [Read error: Connection reset by peer]
<sicelo>
USSD: Credit: E0.00. Data: 500.00MB. Carry Over 287.13MB.
<sicelo>
why i still love N900 ... we depend on USSD in these parts
arno11 has joined #maemo-leste
<bencoh>
oh, that thing works? neat
<sicelo>
yeah. without working USSD, it gets difficult to use the SIM
arno11 has quit [Quit: Lost terminal]
<Wizzup>
does it not work at all, or do we have an idea of what the problems are?
<sicelo>
on droid 4? maybe just needs porting
<rafael2k>
sicelo, no
<rafael2k>
I dont have this send-ussd
<rafael2k>
which package it is? In theory we should have ussd supported in the PinePhone, but without UI
mardy has quit [Quit: WeeChat 3.5]
<sicelo>
that sucks then (@Pro) ... would definitely be nice to support it
<sicelo>
maybe our community needs someone with a OnePlus 6/6T too ... these devices are getting popular among devs, and if we support them, we probably get more hands
<sicelo>
rafael2k: ofono-scripts ... i know ussd works on pp, at least with modemmanager
<sicelo>
rafael2k: yes. i'm running it on my N900 with linux 6.2-rc6. can't say i see magic, but seems somewhat useful for sure.
<rafael2k>
uvos, ussd over at works pretty well also, why it is useless (not that we should use it... but it works)
<uvos>
rafael2k: sure it works.. on the pinephone. my point is we cant rely on ussd working over at, or there even beeng a at interface at all
<Wizzup>
sicelo: one kernel tree I mean :)
<rafael2k>
sicelo, I can jump to 6.2 soon in the PP... but then I'll be on my own, as Mobian seems to like 6.1. but no problem at all, as they just pick the patches from megi and apply
<Wizzup>
uvos: my dutch carrier seems to have ussd codes, although I assumed it didn't
<rafael2k>
ahhmmmm
<sicelo>
Wizzup: understood :-)
<Wizzup>
uvos: which is your carrier?
<uvos>
some sublet of telefonica
<sicelo>
rafael2k: i guess there's no rush to switch kernels. i have just recently got into the habit of testing every new rc to catch N900 regressions early, since it gets supper annoying when they're discovered a long time later
<rafael2k>
with list-modems script, check in "ServiceNumbers = "
<rafael2k>
sicelo, got it
<rafael2k>
What I'm doing is backporting stuff from 6.2 to 6.1
<rafael2k>
like the sun6i-csi, ov5640 drivers
<rafael2k>
and keep with the "Mobian" fork (which is not really from Mobian as I realized they just rebase Megi's kernel fork work)
<rafael2k>
but I like that there are many people using, so I'm not alone in the boat
<Wizzup>
rafael2k: hm, I am not sure if those service numbers are correct, at least on my d4
<Wizzup>
I think mine does ussd, but they are not listed there
<Wizzup>
but again - d3
<Wizzup>
d4*
<rafael2k>
I found the USSD to check balance there... but of course the carrier could fuck up that field and put garbage / outdated info
<soldan>
when im install something with apt or even with the application manager, it doesnt add a launcher, i have to launch the app from the terminal, it is normal?
<Wizzup>
if it is a debian package, it appears in the debian launcher sub menu
<Wizzup>
if it is a maemo leste package, it should appear
<soldan>
ohh, ok!
<Wizzup>
maybe some trigger doesn't work and they will show on restart
<Wizzup>
but normally it should appear
Twig has quit [Remote host closed the connection]
soldan has quit [Ping timeout: 260 seconds]
<uvos>
if it isent a leste package it should still appear
<uvos>
but in the debian menu
Daaanct12 has quit [Remote host closed the connection]