<kiva>
osso-xterm is the best terminal for Pinephone Keyboard, but to plain Pinephone it is almost unusable...is there any skill full enough compile fingerterm that is originally to N9 and Jolla terminal to Leste: https://github.com/reMarkable/fingerterm
<kiva>
I tested it with Jolla Phone (it is default terminal in developer mode) and have to say it clever in many ways.
<kiva>
although that github page says that is ugly hack to make work those devices, I think it is quite mature and does not have issues.
Kabouik has quit [Remote host closed the connection]
Kabouik has joined #maemo-leste
Kabouik has quit [Changing host]
Kabouik has joined #maemo-leste
stlucas__ has joined #maemo-leste
noidea__ has quit [Ping timeout: 256 seconds]
uvos__ has joined #maemo-leste
<uvos__>
not sure how hard that would be, depends on how mutch it depends on jolla specifics like the jollavkb
<uvos__>
mainly i think it makes more sense to improve/replace hildon input method
<uvos__>
since the vkb bein terrible is a problem in lots of places on ts only devices not just the terminal
<Wizzup>
uvos__: so I'm thinking it might make the most sense if we (maemo) fork sphone and change it to fit our needs and then figure out how we can merge some of the features back, because I feel like I keep running into problems where what I want to do and build doesn't match what it is that you want to do. I want to make a maemo-native call client with nice tp and rtcom integration and your view is
<Wizzup>
diametrically opposed where you want a generic thing that run everywhere
<Wizzup>
we could put sphone in the extras repo and make it possible for people to install it and replace whatever fork I might come up with so that users can decide what they want to install
<Wizzup>
but I'm finding it very demotivating to work on this and I don't want to continue working on it this way
<Wizzup>
no hard feelings, I'm just noticing that it's actually having a pretty negative impact on my general willingness to work on this
Wikiwide has quit [Remote host closed the connection]
Wikiwide has joined #maemo-leste
ceene has joined #maemo-leste
fab_ has joined #maemo-leste
<sicelo>
might be mistaken, but i seem to think there was a Fremantle port of fingerterm
Wikiwide has quit [Remote host closed the connection]
Wikiwide has joined #maemo-leste
Wikiwide has quit [Ping timeout: 255 seconds]
<uvos__>
Wizzup: your welcome to do whatever you like, but that patch is simply fundamentally broken
<uvos__>
you cant change how sphone logs events without also changeing how it interprets those events when reads them, this breaks literally everything that touches events
<uvos__>
you cant force all plugins names to change thair display names to apease the logging plugin
<uvos__>
and yes i know since the backend id is for that instance of sphone only that that atm sphone dosent give you a uid for the pluin to use besides the display name
<uvos__>
but the way to solve that is to extend sphone to add a concept of a backend uid
<uvos__>
not to simply force every display name into some scheme
<uvos__>
you also have failed to explain where exacly there is a requirement for sphone to log as ring/ in other code used in leste
<uvos__>
since this is wrong after all its not ring/ that is loging its sphone
<uvos__>
ultimatly sphone needs some way to know for an event in the db that 1. it loged it itself and 2. some specific backend is associated with this event
<uvos__>
this may need the database format to change somewhat
<uvos__>
maybe by adding a agend field for sphone to put sphone/ofono or something like that
<Wizzup>
I don't think sphone needs to know that it logged it itself
<Wizzup>
It just needs to know that it was a phone call that it can show
<Wizzup>
Saying that it can't be "ring" is fundamentally misunderstanding how it works
<Wizzup>
ring never logs to the db, conversations does, sphone does, and on fremantle, rtcom-call-ui and rtcom-messaging-ui does
<Wizzup>
ring is just the connection manager
<Wizzup>
if conversations would log as "conversations/ring/tel/account0" that would be very wrong and sphone shouldn't do it either
<Wizzup>
for the record I changed my db with a single update query and I haven't seen the recent calls break at all
<uvos__>
there is no "wrong" i want a way to detemine who logged an event
<uvos__>
Wizzup: yes you did
<Wizzup>
that is fine, rtcom doesn't let you use local_uid for this
<Wizzup>
so don't use it for this purpose
<uvos__>
sphone cant detemine the backend anymore for the events you changed
<uvos__>
or it would log post pathc
<uvos__>
so it cant call those events back in recents
<uvos__>
it will try the default backend
<uvos__>
but that can be wrong ofc
<uvos__>
same with sms
<uvos__>
the patch as is is simply unworkable for this reason and the missuse of backend->name
<uvos__>
regardless of how the db shall look
<Wizzup>
I saw that and suggested that you can add some other field so that the name can be something sensible
<uvos__>
yes thats fine adding a concept of a uid for the backends is a good idea
<uvos__>
altho i would prefer this to be a uint64 or so
n900 has quit [Ping timeout: 268 seconds]
<uvos__>
but that dosent change that this patch is nak as is
<Wizzup>
I already closed it because I don't feel like workng on it
<uvos__>
that that was also pointless
<Wizzup>
a uint64 would be very limiting and I don't think it makes sense
<uvos__>
since the bugfixes for vcm are fine ofcourse
<Wizzup>
no, they're pointless without rtcom logging the way it's supposed to be on maemo
<Wizzup>
the local_uid literally is the backend identifier and the associated account, it belongs in local_uid in that way and without it it's pointless
<uvos__>
thats totally unrelated to vcm not performing hangup correctly
<uvos__>
and sure we can find a way to do this, but your patch is not the way
<uvos__>
form sphones perspective it being ring/ is btw not ideal because this leaks an abstraction detail sphone uses vcm and vcm happens to use tp/ring and ring happens to use ofono
<uvos__>
and this leaks a implementaton detail from 2 layers below sphone into sphone so its not ideal from that perspective too
xmn has joined #maemo-leste
<uvos__>
so i think it makes sense to understand where exaclty it is nessecary for it to be ring/ exactly and nothing else
<Wizzup>
the local_uid is the (tp) account name
<Wizzup>
and since this is used by not just sphone but other places too, it has to match
<Wizzup>
so if the sim card is used to send sms or call, the local_uid needs to be the same
<uvos__>
ok and what happens if at some point its not tp
<Wizzup>
parsing the local_uid to extract bits is not how it's meant to be used
<Wizzup>
then it'll just be some other opaque string
<Wizzup>
libpurple/whatever/somename
<Wizzup>
or just 'ofono' if you want
<Wizzup>
(which wouldn't work with multi sim)
<Wizzup>
note that conversations does do some local_uid parsing to allow one to filter by all messages from a specific protocol, but it doesn't try to match a part of it to some backend, the string as a whole is used for that
<uvos__>
ok and why is it nessecary to assoicate something with a tp account? anyone wanting to deal with this event to call back the assoicated contact or so
<uvos__>
should be asking sphone to do so
<uvos__>
this is also why i want there to be some way to id who logged the event
<uvos__>
to know who to ask about it for eg. a call back
<Wizzup>
not a tp account, it's a opaque identifier for finding the associated way to talk to it
<Wizzup>
you don't need to id who logged the event, you just see if you have a backend that says it owns local_uid
<uvos__>
right so whats wrong with sphone/vcm/account0 vs ring/tel/acount0
<Wizzup>
it doesn't match anything on the system
<Wizzup>
and it'll make the sms and calls seem to come from different accounts/simcards
<uvos__>
this gives you who to ask (sphoen) it gives sphone who to use (vcm) and the account
<Wizzup>
and it won't group well
<Wizzup>
vcm is irrelevant here, ring is the one doing all the work
<uvos__>
its relevant to sphone, sphone must what backend to use for the event
<uvos__>
and thats vcm
<uvos__>
vcm using ring is something sphone dose not know about
<Wizzup>
no, sphone just checks with it backends if any of them is ring/tel/account0
<Wizzup>
and then it knows
<uvos__>
and ideally it should not know about this since its an implementation detail
<Wizzup>
it doesn't have to parse local_uid at all
<Wizzup>
it just matches it
<uvos__>
still not ideal since now you rely on vcm using ring and not grand_new_connection_manager
<uvos__>
anyhow this is small fry
<uvos__>
compared to the 2 main problems with the patch
<Wizzup>
I think for me to address these we need to decide how to change the logging style
<uvos__>
not really, just add a uid string to the backend struct and the assocated code that matches based on it in backends, calls and messages
<uvos__>
then the loging code can use that uid or local_uid
<uvos__>
and what we have the backends set this strng we can fight over
<uvos__>
*then the loging code can use that uid for local_uid
<Wizzup>
I think that is what I suggested on the pr
<Wizzup>
I'll see if I can find some energy to do it today
<uvos__>
yes i did not reject that
<uvos__>
i reject the patch as is
<Wizzup>
btw, at this point I'm 99% sure the call issues are kernel related and not vcm
<uvos__>
please also reopen the pr without the offending patch
<uvos__>
btw i added dtmf support
<uvos__>
not that it works since no backend supports it
<uvos__>
but the ui and sphone-core now dose support dtmf
<Wizzup>
ok, it is pretty simple to add this to vcm, but of course with our ofono this still won't work
<Wizzup>
(but a temporary amixer hack would make it work on mapphones)
<uvos__>
dtmf can be implemented by any plugin
<uvos__>
so we could have a dtmf-alsa pluging just for mapphones
<uvos__>
untill we make it work via ofono
<Wizzup>
I think the ofono 2.x has support for it now in the qmimodem, but we don't know how that fares on mapphones
<uvos__>
yeah, no idea ofc
<uvos__>
btw sphoen will also now throw an error as a message box when the sms ui is opened but no plugin is servcing sms's
<uvos__>
this is not as good as some solution that removes the related desktop files
<uvos__>
but at least no longer simply nothing happens
<Wizzup>
ideally the desktop files would be split into some additional pkg
xmn has quit [Ping timeout: 264 seconds]
<Wizzup>
then this can be controlled by installing sphone-ofono or sphone-vcm or something
<uvos__>
more like sphone sphone-call and sphone-sms and the packages have the related plugins and a config file to activate the feature
<uvos__>
and the related desktop files ofc
<uvos__>
anyhow im not great with debian packaging
<uvos__>
so i need expirament with how to make this work
<Wizzup>
I think you can make debian/sphone-ofono.install and have the .desktop files be listed there
<Wizzup>
I can do it if you know how you want it
<uvos__>
not yet
<uvos__>
also i think i need to rething how Modules= works in sphone.ini (also for mce) because this will be a mess
<uvos__>
with multiple packages with config files all overrideing Modules= turns into insanity
<Wizzup>
with leste-config it might not be necessary to worry too much about it
<uvos__>
nah it will
<uvos__>
we also want a speical mapphone only module
<uvos__>
that would also override modules=
<uvos__>
just dosent work with so manny cobinations
<Wizzup>
ok
<Wizzup>
I got an email from nlnet than we have just under three months to claim the various ports and other funding goals
<Wizzup>
apart from xt1602 most things are working to a degree at least
n900 has joined #maemo-leste
<uvos__>
may xt1602 got stolen :(
<uvos__>
*my
<uvos__>
i think we can write that one off
<uvos__>
it also worked to a degree
<uvos__>
i did boot to hildon on it
<Wizzup>
do you have the image around? I have one here
<uvos__>
good question
<Wizzup>
but yes, I was also considering writing it off for the funding
<Wizzup>
btw the latest vcm stuff also at least makes it possible to hang up xmpp and sip calls without issues
<uvos__>
audio still dosent work or dose it now/
<uvos__>
?
freemangordon has quit [Read error: Connection reset by peer]
freemangordon has joined #maemo-leste
<inky>
folks, can u suggest to what to do, i have 2 problems
<inky>
first, when i click on a received audio in dino
<inky>
it opens maemo media player, and it doesnt play anything
<inky>
second is more important. on my droid audio is played with very low volume
<inky>
but volume is up, and alsamixer shows everythin maximally up
<dsc_>
uvos__: stolen? :P
<dsc_>
some thief is running maemo-leste right now
<inky>
Omg
<inky>
My droid was playing audio ideally
<inky>
Should i install pavucontrol or pulse is not used anymore? Now we have pipewire? What is the mixer to use?
<Wizzup>
uvos__: no, no audio yet, I don't know why yet
<Wizzup>
but tp-rakia and sofiasip still works on fremantle so we'll get it to work
<uvos__>
dsc_: yeah i was using it for navigation on my vespa poped into a place for 10 minutes, forgot about that it was attached to the bike and poof gohne on my return
<uvos__>
Wizzup: ok
<uvos__>
Wizzup: not so usefull yet for sphone but progress
<uvos__>
dsc_: the xt1602 running android at the time (dual boot)
<uvos__>
so no thief runing leste
<uvos__>
except
<dsc_>
uvos__: I left my phone in a bar yesterday and after 10min it was still there (thankfuly)
<uvos__>
i also got a d4 stolen at a convetion center in boston
<uvos__>
that one dident have android on it at all
<uvos__>
so this thief is def running leste
<uvos__>
:P
<dsc_>
lol
n900 has joined #maemo-leste
<uvos__>
inky: check pavucontrol-qt
<uvos__>
inky: this has all the volumes your should require
<inky>
uvos__: tryint, ty
n900 has quit [Ping timeout: 256 seconds]
<Wizzup>
uvos__: right, the issues with audio for sip aren't in sphone but rather vcm or farstream or tp-rakia/sofiasip
<Wizzup>
uvos__: so something needs to act on a dtmf pipe?
<uvos__>
Wizzup: yeah you get a DtmfRequest dwon that pipe
<uvos__>
sphone_dtmf_t in the request is SPHONE_DTMF_* or SPHONE_DTMF_STOP start and stop a dtmf tone
<uvos__>
struct contains a CallProperties struct
<Wizzup>
ok, I suppose having something that calls amixer a few times to send a tone would be useful for now
<uvos__>
you are expected to check this to see if you are responsable for dtmf for this call
f_ is now known as f_`
<uvos__>
the related backend needs BACKEND_FLAG_DTMF
f_` is now known as f_
<uvos__>
the gui checks this to see if it needs to present the option for dtmf
<uvos__>
right now only commtest sets BACKEND_FLAG_DTMF
<uvos__>
you can use that to test the code
akossh has quit [Quit: Leaving.]
n900 has joined #maemo-leste
uvos__ has quit [Ping timeout: 264 seconds]
xmn has joined #maemo-leste
akossh has joined #maemo-leste
joerg has quit [Ping timeout: 264 seconds]
joerg has joined #maemo-leste
uvos__ has joined #maemo-leste
leste has quit [Remote host closed the connection]
joerg has quit [Excess Flood]
joerg has joined #maemo-leste
leste has joined #maemo-leste
leste has quit [Remote host closed the connection]
leste has joined #maemo-leste
System_Error has quit [Remote host closed the connection]
Livio has joined #maemo-leste
System_Error has joined #maemo-leste
stlucas__ has quit [Ping timeout: 240 seconds]
Livio has quit [Ping timeout: 264 seconds]
stlucas__ has joined #maemo-leste
<Wizzup>
uvos__: btw in case you didn't see, I made a new pr
<Wizzup>
ah you saw it
System_Error has quit [Remote host closed the connection]