System_Error has quit [Remote host closed the connection]
System_Error has joined #maemo-leste
joerg has quit [Ping timeout: 264 seconds]
joerg has joined #maemo-leste
alex1216 has joined #maemo-leste
yanu has joined #maemo-leste
Pali has joined #maemo-leste
<Wizzup>
should we keep a window per contact for sms, or perhaps some option to have stacked windows?
_inky has quit [Ping timeout: 256 seconds]
<parazyd>
Is it easy to have both?
<Wizzup>
I mean as an option, probably
<parazyd>
That'd be nice. I think stacked by default, and then optionally many windows.
<Wizzup>
it's different from maemo but having ~8 sms windows maybe makes less sense
<Wizzup>
it might make notifications more tricky
<Wizzup>
but modest can do it for multiple emails sources, so yeah
xmn has quit [Quit: ZZZzzz…]
_inky has joined #maemo-leste
<sicelo>
how will stacked windows work for sms in hildon? afaik, hildon doesn't really have concept of stacked windows, except when the windows on 'top' of stack are directly related to the ones below, e.g. how application settings tend to work.
<sicelo>
so how would you stack sms windows?
<Wizzup>
sicelo: stacked windows are everywhere in hildon
<Wizzup>
mediaplayer does it, modest does it
<Wizzup>
when you have a 'back' button on the top right, it's stacked
<sicelo>
yes. that i know. but that's because the top window is related to the one below. hence my question - how will you stack sms?
<Wizzup>
well, imagine we have one window for sms
<Wizzup>
then messaging a contact can just go 'one level deeper' to the conversation with the contact
<sicelo>
or, you mean have sms application, then you open one sms, and come back to main application, then choose different sms?
<Wizzup>
and then you go back to your recent sms overview
<Wizzup>
yes
<sicelo>
ok
<Wizzup>
it's an idea at least
<Wizzup>
of course this can also be a mix of sms/chat
<Wizzup>
I will try to draw up some examples of what I mean
<Wizzup>
I talked about some of this with parazyd back in august
<Wizzup>
sicelo: well, any ideas? :p
<sicelo>
no
<Wizzup>
ok
_inky has quit [Ping timeout: 260 seconds]
_inky has joined #maemo-leste
<Wizzup>
uvos: I'm waiting for a few more people to confirm the launcher stuff is all fine for them now, then I'll push it to stable
Evil_Bob has joined #maemo-leste
xmn has joined #maemo-leste
<alex1216>
The real question is how Hildon treats freedesktop or libappindicator events, if it either uses or supports them at all. When we have a new SMS, the app does not spawn a notification like that - it just does pop up with the chat window. This raises the question about what Hildon will do if there are unread insoming SMSes from several people.
<Wizzup>
right
<Wizzup>
so the way this works with the modest mail client, where you can have multiple email clients, it shows the amount of unread emails in the yellow window overlay
<Wizzup>
and then when you select it, it just brings you to the overview of your inboxes
<Wizzup>
we could do the same, be it the overview of recent sms messages (as in here https://wizzup.org/sms.png) or recent messages in general
<Wizzup>
if each is its own window, then it would be the same as fremantle, of course
<alex1216>
About "~8 SMS windows", is it the actual Hildon WM's upper limit on simultaneously open windows?
<Wizzup>
I don't think there is a limit other than memory
<alex1216>
Just wondered, how challenging is to stick with Hildon and maintain it instead of switching to ported desktop DEs and etc.
<sicelo>
yes there isn't. if you have more 'windows' than can fit in the overview, they become scrollable
<Wizzup>
alex1216: ported to what?
<alex1216>
Wizzup: desktop components ported to Maemo, such as ones existed since Fremantle times.
<Wizzup>
I'm still not quite clear on what you mean, sorry
<sicelo>
like? QBW? DCEW? we (can) have them in Leste ... at least i ported DCEW and Personal IP Address widget
<Wizzup>
we're trying to support modern XDG stuff for DEs
<dsc_>
regarding launching stacked windows for SMS; why not model after Whatsapp/telegram/Android SMS - which is: one overview, and clicking on an item will bring you to that conversation, all in the same window
<dsc_>
would be easier to make
<sicelo>
what you're describing is what Wizzup/parazyd mean too :
<sicelo>
:-)
<dsc_>
Oh, right :P /me drinks some more coffee
<alex1216>
I mean ported desktop DEs like KDE, LXDE, GNOME and E17, which are listed on maemo.org wiki at "Alt. DEs" article.
<sicelo>
alex1216: Leste has stuck with Hildon. None of those DEs are being used
<Wizzup>
dsc_: yes, that is part of what I had in mind, but we could/would have many chats in one window
<Wizzup>
so I want to have either some context, like 'sms', or 'xmpp', or 'signal', or 'all'
<dsc_>
right
<alex1216>
So, the solution is to implement tabbed interface in one window?
<dsc_>
yeah
<sicelo>
yes, sort of. and that's what stacked means in this case
<Wizzup>
yeah, stacking in the way the media player stacks
<Wizzup>
or the mail client stacks
<Wizzup>
where you "go back"
<sicelo>
also, bear in mind hildon was made for small screens, hence normal pc-style tabs wouldn't make a lot of sense (hence pidgin on maemo is a bit clunky)
<Wizzup>
right
<Wizzup>
and making hildon work well on a high res screen will also be challenging
<Wizzup>
alex1216: I wouldn't call it tabbed by the way
<sicelo>
hah! this is first update post for 2021? time sure flies.
<Wizzup>
sicelo: yeah
<sicelo>
Wizzup: for wireguard, do we support importing a conf file? or, how do we enter the connection parameters (seems they are a lot)
* sicelo
is playing with wg on laptop for first time ever (always behind the times)
Kabouik has quit [Quit: Kabouik]
Kabouik has joined #maemo-leste
Kabouik has quit [Changing host]
Kabouik has joined #maemo-leste
<Wizzup>
sicelo: yes I think there is a config file override
Twig has joined #maemo-leste
<Wizzup>
sicelo: use 'load'
<Wizzup>
I have not tested that a whole lot though
<Wizzup>
tmlind: have you tried changing operators with ofono on the d4?
<sicelo>
when roaming?
<Wizzup>
yes
<Wizzup>
I have a suspicious that my inability to connect to a data connection for three days now is related to the operator that is picked
<uvos>
Wizzup: "uvos: I'm waiting for a few more people to confirm the launcher stuff is all fine for them now, then I'll push it to stable" sec ill update
<Wizzup>
yeah I quite often get vague errors on ofono, and some calls only return if I send myself a text
<Wizzup>
dbus call that is, not phone calls
<Wizzup>
Nov 7 21:19:21 localhost ofonod[19090]: drivers/qmimodem/gprs-context.c:start_net_cb()
<Wizzup>
Nov 7 21:19:21 localhost ofonod[19090]: src/gprs.c:pri_activate_callback() 0x561b68
<Wizzup>
Nov 7 21:19:21 localhost ofonod[19090]: src/gprs.c:pri_activate_callback() Activating context failed with error: Unknown error type
<uvos>
Wizzup: regarding notifications
<uvos>
Wizzup: im pretty unhappy that maemo dosent have a central notification que
<uvos>
like kde/gnome/lxqt/android/ios/macos
<uvos>
an inauspicious ommision for sure
<Wizzup>
it was never a problem on my n900
<uvos>
sure you can work without it, but i mean then every application has to implement a notification window
<uvos>
not great really
<Wizzup>
ok so now the org.ofono.NetworkRegistration.Scan worked since I saw some callbacks complete and then when I sent myself a text it completed
<Wizzup>
so now I have three operators
<uvos>
i would recommend that we have an application that implements the relevant xdg interfaces.
<uvos>
it can open a notifcation window
<uvos>
if there is at least one noficiation
<uvos>
and then just que other
<uvos>
and then just que others
<uvos>
that way we can also not break the expectation behind the xdg specs
<uvos>
and implement the status notfier item there too
<Wizzup>
also turning the modem into Online false and then Online true I think causes segfault
<Wizzup>
uvos: we could that at some point but it would require very significant rethinking of hildon notifications
<uvos>
Wizzup: not really
<Wizzup>
I first want to stick to the existing API and make it work as daily driver rather than add more work
<uvos>
Wizzup: create a deamon that opens window that opens on creation of a xdg notification or xdg status noiftier item.
<uvos>
Wizzup: this dosent break wild west syle existing notification from random processies
<Wizzup>
sure but the window needs to go to the right app and the right place in the app for it to be useful
<uvos>
xdg spec solves this
<uvos>
notifcation items can have buttons and fields
<uvos>
that go to the app that created them
<Wizzup>
the point was that the app needs to know where to go as well
<Wizzup>
and it needs to implement that other/new spec
<uvos>
sure
<uvos>
any application you port to those interfaces (or exisitng ones like all the deskotp apps) just work
<uvos>
others continue to use thair own windows
<Wizzup>
ok, so I can first implement it the hildon way and then worry about the other way(s)? :)
<Wizzup>
It might make sense to make an issue reporting outlining what you want to do wrt the other specs
<sicelo>
since it seems most projects nowadays prefer MM over ofono, i wonder why for the d4, the ofono way was chosen
<Wizzup>
we did not chose ofono for the d4, we chose ofono before we ever used ofono
<uvos>
Wizzup: the end goal would be to have everything go though the xdg specs (since then you only get one window with severaly scrolable entrys or everything and every looks consistant etc)
<uvos>
but yeah
<uvos>
sure
<uvos>
*for everything
<uvos>
i mean we arnt very far here into implementing ofono
<uvos>
i could add mm support to sphone in like 2 days
<uvos>
but we do have ofono hw support
<uvos>
that would have to be ported to d4
<Wizzup>
and connui-cellular
<uvos>
also i suspect it would also be buggy
<Wizzup>
and icd2
<Wizzup>
and telepathy-ring
<uvos>
sure but connui-cellular
<uvos>
really is pretty rough anyhow
<Wizzup>
currently, yes
<Wizzup>
part of it is libgofono and part of it is missing time :)
<uvos>
libgofono is bah. :P
<Wizzup>
right
<sicelo>
regarding mm, it was just me idly wondering. not saying it should be used here. besides, porting N900's modem to it will likely be a nightmare
<Wizzup>
in any case I really don't know why the data access is not working anymore
<uvos>
sicelo: n900s modem is very nonstandard?
<Wizzup>
maybe I should reboot without ofono and do only qmi
<uvos>
sicelo: i mean d4 is just qmi + some quirks really
<Wizzup>
I don't think it's nonstandard, it just has its own protocol
<uvos>
uh thats the deffinition of nonstandard no? :P
<Wizzup>
it might predate qmi even, idk
<sicelo>
Wizzup: are you able to use the qmcli interface in any useful way on the d4? i have tried many times, and found it very difficult
<Wizzup>
sicelo: not often, but according to our wiki it should kinda of work
<Wizzup>
yeah so I'm on 2g now, and the last call still fails
<uvos>
works in android
<uvos>
?
<Wizzup>
I really don't have android anymore on this d4
<uvos>
?
<Wizzup>
but like I said, it worked ~4 days ago
<uvos>
how did that happen
<uvos>
ok
<Wizzup>
same sim, same device
<uvos>
hmm
<Wizzup>
and I -think- it's maybe because I'm roaming on a different operator now
<uvos>
is your connui stuff runing?
<Wizzup>
what stuff?
<uvos>
hildon-cellular-meta sutff
<tmlind>
sicelo: i was using something like this to check balance earlier with ussd: printf "AT+CUSD=1,#999#,0\r" > /dev/motmdm1, then you have to read /dev/motmdm1 to get the result, have not used for quite some time
<Wizzup>
yes, that's a read-only thing that shows the technology status
<Wizzup>
it's also unchanged for a long time
<Wizzup>
what I can try is nuke /var/lib/ofono
<Wizzup>
and see if that helps somehow
<Wizzup>
that's the directory with ini-style data for ofono, like apn settings
<uvos>
Wizzup: point is i have had trouble using qmicli after trying to connect with icd2 (which always fails)
<Wizzup>
let me remove the mode=manual I guess
<Wizzup>
uvos: icd2 only "fails" because it doesn't wait for the result
<uvos>
no
<uvos>
not for me
<Wizzup>
the call itself will usually (not in my case) still succeed
<Wizzup>
not in my case now* to be clear
<Wizzup>
I've often used that
<uvos>
yeah this has never worked for me at home
<uvos>
some times elsewhere it dose work
<uvos>
while qmicli dose work
<uvos>
but only if you dont fiddle with icd before hand
<Wizzup>
well maybe we should try to debug that some time
<uvos>
so i unistalled it
<uvos>
sure
<Wizzup>
well "icd" does nothing other than issue a single ofono call
<uvos>
ok sure
<Wizzup>
apart from the initial provisioning
<uvos>
so its ofonos fault :P
<Wizzup>
likely
<Wizzup>
in any case I can read events from rtcom database per contact now
<Wizzup>
next step is to write/add events on telepathy-ring events
<Wizzup>
and dsc has a html interface that uses the fremantle html/js/css mostly
<Wizzup>
so we might be pretty close to something semi usable in a week or two
<uvos>
not sure we want the html based thread rendering
<Wizzup>
fun fact the fremantle html/js uses alert() to communicate with gtk it seems
<uvos>
but ok
<Wizzup>
uvos: we can stop using it if we decide it's too heavy, but fremantle was able to do it
<tmlind>
looks like the packet id from date command gets messed up though easily, anything starting with 0 will be rejected by printf or something, maybe just use U1234 instead
<sicelo>
thanks. will try that next time i run the d4. actually, it's not just single-shot USSD that I need ... it's a full USSD conversation, where the network asks for multiple responses in one 'session' :-)
<tmlind>
ok
<sicelo>
it's used here for buying mobile data.
pere has joined #maemo-leste
<tmlind>
hmm looks like the ussd test script above always returns the same hex string for me no matter which command i send
<Wizzup>
looks like both my n900 and my d4 with ofono do not like vivatel
<Wizzup>
which confirms my suspicious of why it worked ~4 days ago
<Wizzup>
suspicion
<sicelo>
does it auto-roam? at least here, some sims/networks need you to enable it (via USSD, in our case)
<Wizzup>
well, it's set to enabled in ofono
<Wizzup>
I don't know what else is needed
<Wizzup>
maybe that is required and that is what calls the weird CIEV (or CEIV) messages
<uvos>
oh so not motmdm's fault
<uvos>
wasent expecting that
<Wizzup>
not clear, but maybe
<Wizzup>
it's still at fault for not letting me switch operators at least :)
<Wizzup>
but that could be the motmdm d4 as well
<Wizzup>
er ofono
<Wizzup>
uvos: interesting, the icd2 activate doesn't work here on n900 either, even though context is active
<Wizzup>
I suppose I could maybe use this case to debug
<Wizzup>
the life we choose :)
<Wizzup>
(all I really want is to walk outside with ssh on my leste phone though :()
<sicelo>
Wizzup: did you try the patch(es) for improving n900 power mgmt?
<Wizzup>
sicelo: which ones?
<Wizzup>
I'm kind of waiting for fmg to come back and rescue us with kernel 5.15 and ddk 1.17 so that we can attempt to hit OFF mode and then worry about power mgmt
<Wizzup>
since we're on 5.1 atm
<sicelo>
ah, yes 5.1
<uvos>
sgx :(
<sicelo>
there was something tony shared a few weeks ago regarding part of the problem with off/ret mode on the n900
<Wizzup>
right, we'll need those too
<Wizzup>
we don't even hit RET atm on n900 iirc
<uvos>
nope
<Wizzup>
my normal n900 fremantle (other sim) connections ok via vivatel
<Wizzup>
connects
<uvos>
librtcom documentation:
<uvos>
Network data
<uvos>
GPRS or other networking event should be stored completely. An obvious example is data tranfers.
<uvos>
whait what?
<uvos>
it wants me to log every gprs data transfer
<Wizzup>
I don't think this happens on fremantle either
<Wizzup>
not sure
<uvos>
its obviously not something you can do. imagine logging every data transfer on a 4g phone browsing some random modern website :P
<Wizzup>
fremantle definitely has a data counter
<Wizzup>
I just don't know if it stores it in the el-v1.db
<Wizzup>
my roaming data counter is 0.24GB sent and 1,51GB received
<Wizzup>
it can also warn every X MB
<uvos>
yeah sure
<uvos>
every mobile os dose this
<Wizzup>
well how do you think it does that then?
<Wizzup>
doesn't seem very different from storing the values in the db
<uvos>
do it cumulatively
<Wizzup>
but I guess their data transfers are more about MMS
<uvos>
ofc
<Wizzup>
do you have a rtcom db from a fremantle device?
<Wizzup>
that's probably quite useful to have
<uvos>
no
<uvos>
ofc not
<Wizzup>
don't you have a n900 with fremantle?
<uvos>
i do
<uvos>
but i dont have a sim to use in it
<uvos>
so no events
<Wizzup>
it should just be in /home/user/.rtcom-eventlogger/el-v1.db
<Wizzup>
it might still have some
<uvos>
should be empty
<Wizzup>
maybe, if you flashed it and never had a sim in it ever :P
<uvos>
well the ui dosent show any events
<uvos>
so..
<uvos>
but yeah can check the file at some point
<Wizzup>
what are you planning to add wrt rtcom btw?
<uvos>
sphone pushing events
<uvos>
Wizzup: where is that rtcom-eventlogger-ui example btw
<uvos>
should be usefull to see if the events are geting logged
<Wizzup>
not really, just triggers me every time I read the logs :P
<uvos>
ok ok
xmn has joined #maemo-leste
<uvos>
thats in vm
<uvos>
or dose n900 not support dpms?
<Wizzup>
I see it on the n900
<uvos>
hmm
<uvos>
thats not great
<Wizzup>
root@devuan-n900:~# xset dpms
<Wizzup>
server does not have extension for dpms option
<uvos>
uff
<Wizzup>
nevermind this ddx for now
<uvos>
so no one is really turning off the display
<uvos>
yeah
<uvos>
this ddx looks like s*it show every time i interact with it :P
<Wizzup>
anyway, if you find some time one of these days, maybe check if setting the accesspointname at least makes it work (once you already activate the context through dbus)
<Wizzup>
or just connect twice with a 10-15s break from ui, also works
<uvos>
ok
<uvos>
yeah not right now
<Wizzup>
sure :p
<uvos>
please walk me thorugh what to do
<uvos>
at some other point
<Wizzup>
settings->internet connections -> gprs network name -> edit -> set access point name
<Wizzup>
save
<Wizzup>
but sure
<Wizzup>
just ask :)
<Wizzup>
uvos: so I'm also looking at writing to rtcom log
<uvos>
mce is fixed
<uvos>
and being built
<uvos>
as a side effect you can now set the "dim" brightness in mce.ini
<uvos>
and makes it work on d4
<Wizzup>
what do you mean, at what value it dims?
<Wizzup>
or to what value it dims?
<uvos>
what value it dims to
<uvos>
in terms of brightness
<uvos>
on n900 it makes sense to turn the display backlight off with it being tansflective and al
<uvos>
on d4 not so mutch
<uvos>
now we can make it device dependant
<Wizzup>
cool
<Wizzup>
so my leste n900, on fremantle connects to the other operator
<Wizzup>
heh
<Wizzup>
so I can't test if it works in fremantle
<Wizzup>
also the network name being "Mail en Java" always gets me :D
<uvos>
the network name here is "willkommen" when you connect and then randomly later it changes to "o2"
<uvos>
that triggers me
<Wizzup>
heh
<Wizzup>
still better than "mail and java" :P
<uvos>
on leste this fails btw
<uvos>
on andorid it switches to o2 at some point but the leste ui never updates
<uvos>
ofono knows tho
<Wizzup>
it fails on fremantle with vivatel :)
<Wizzup>
so it's also not an ofono problem
<Wizzup>
at least not obviously
<uvos>
vivatel being d**** then
<Wizzup>
surprising yeah.
<uvos>
we should have some logic to switch to the other operator if something fails
<uvos>
and there are multiple availble in roaming situation
<Wizzup>
fremantle has a ui for it in the settings
<Wizzup>
but it doesn't work in our ofono on the d4
<Wizzup>
as in it's basically implemented in connui-cellular I think (or I can do that semi easily)
<uvos>
ok
<Wizzup>
(for the record settings -> phone -> network mode -> manual -> pick
<Wizzup>
)
<uvos>
hmm rtcom-eventlogger-ui isent usable without abook
<Wizzup>
uvos: what do you mean exactly?
<Wizzup>
it depends on it, but what do you mean with usable
<uvos>
/usr/include/rtcom-eventlogger-ui/rtcom-log-model.h depends on abook
<uvos>
lots of its headers include abook ones
<Wizzup>
yes
<uvos>
ergo you cant use in in an application that dosent also use abook
<uvos>
right
Wikiwide has joined #maemo-leste
<Wizzup>
uvos: well let's stay in touch wrt rtcom since we can probably share some code eventually
<Wizzup>
I have quite some notes on how rtcom works and how to log for sms
<Wizzup>
and I'll make a el-v1.db for testing
Wikiwide has quit [Remote host closed the connection]