<Wizzup>
freemangordon: I tihnk it should be ready for merging now
<Wizzup>
freemangordon: also, with regards to mce cmake PR, I think we should just merge it now
<Wizzup>
uvos is mostly maintaining it anyway so there's not really a point for us to block merging it
<Wizzup>
I don't feel like learning cmake just for it, and it's also just a build system, so it's possible to break stuff, but clearl'y he's using it already
<freemangordon>
Wizzup: ok
<freemangordon>
I am not going to learn cmake as well :)
<Wizzup>
I'm waiting for parazyd to remove the mce-dev stuff first
<Wizzup>
from -devel at least
<uvos>
its not in devel
<uvos>
as parazyd has mentioned
<uvos>
should be fine right now
<uvos>
since you would just build the new mce-dev for devel
<Wizzup>
ok, let me do a phone call and set up the branches for ci
<Wizzup>
(tag etc)
<uvos>
the jenkins job should go non the less ofc
<Wizzup>
this does not require a mce config change
<Wizzup>
right?
<Wizzup>
in leste-config
<uvos>
no
<uvos>
the binary is the same
<uvos>
(well uses mutch less ram due to linkage changes)
<Wizzup>
:)
<uvos>
i kinda forget what we wanted to add new module wise after the unfork of leste mce and my sway/debian mce
<uvos>
so mce setting the modem online was one thing right?
<uvos>
i think there was a bit more
freemangordon has quit [Ping timeout: 240 seconds]
pere has joined #maemo-leste
<Wizzup>
uvos: for ofono
<Wizzup>
online modem etc
<Wizzup>
and (re-online) model
freemangordon has joined #maemo-leste
<uvos>
right
<uvos>
and i wanted to add a interem audio routing solution for sphone to mce
<uvos>
ie have mce switch to call ucm profile when it enters call mode
<freemangordon>
uvos: wait, what is missing in mce phone wise?
<uvos>
freemangordon: nothing
<uvos>
freemangordon: i just want a interem audio routing solution until pa works
<uvos>
just so i can use the phone as sutch for now
<Wizzup>
I mean we have ohm...
<Wizzup>
it's literally there and working afaict
<uvos>
oh it works on d4 allready?
<Wizzup>
no, I haven't tried that yet, that's my next step
<uvos>
ok
<Wizzup>
I don't think switching profile before the phone is picked up makes sense though
<Wizzup>
right?
<uvos>
mce has ringing and in call state
<Wizzup>
ok
<uvos>
ofc it would switch only in call
<Wizzup>
ok
<uvos>
anyhow maybe i should rather add some pa profile switching fallback to sphone instead
<uvos>
since i kinda want to have sphone work on debian and pmos too
<Wizzup>
up to you, no opinion here, I still want to go the telepathy+ohm route and such anyway
<uvos>
ok
<Wizzup>
I'm finishing up the tor+wireguard stuff for the deadline (10 sept or so), hope to go back to audio after that
<Wizzup>
probably before that date jftr
<Wizzup>
unfortunately the sailfish guy doesn't really reply
<uvos>
well i would want to have sphone contiune to work as a standalone thing for any linux system i think its quite usefull in that role (even with regards to a laptop with gsm radio), ofc that dosent preclude adding a tp backend
<uvos>
in addition to the current ofono one
<Wizzup>
how do you plan to integrate osso-abook that way?
<uvos>
good question, in reality i would like osso-abook to respond to and also execute xdg mimes for all the actions it needs (really just call this with protocoll x, message this with protocoll y and display contact z)
<uvos>
but i havent looked at how osso-aboot works yet
<uvos>
atm other address books work with sphone via this method
<Wizzup>
it works on the same backend as evolution
<uvos>
also the browser (clicking on phone numbers etc)
freemangordon has quit [Ping timeout: 250 seconds]
<Wizzup>
the point was more that it has various dialogs and other gtk-level integrations I mean
<Wizzup>
it's not just about 'launching sphone' to make a call
<Wizzup>
it's about matching phone numbers to contacts, showing the avatars, etc
<uvos>
so that works via what
<Wizzup>
probably a shared lib, but fmg would know much better than me
<Wizzup>
(and he timed out just now :p)
<uvos>
ok
<uvos>
its not just evelution?
<uvos>
the data server that is
<Wizzup>
what do you mean?
<Wizzup>
no, osso-abook specifically is most of the (gtk) interface
<uvos>
right
<Wizzup>
there is libosso-abook and also the user interface app that relies heavily on libosso-abook
<uvos>
but sphone dosent need to care about that i hope
<Wizzup>
well, I think it does, if you want to show call history, with contact options, etc
<uvos>
it just needs to have something to look up numbers in
<Wizzup>
maybe open the phone app in fremantle :)
<uvos>
right you have to have something to lookup numbers to associate with names/avatars
<Wizzup>
and send texts from the context menus
<uvos>
and to launch the contatcs app to edit the contact
<uvos>
it would use the contact: mime
<Wizzup>
or perform a sip call instead of normal call to the same contact
<uvos>
(or vcard: not sure what it is per spec)
<Wizzup>
and need to talk to osso-abook to know what the contact supports
<Wizzup>
and there's also presence in the phone app I think
<uvos>
yeah no i dont want that level of integration really
<Wizzup>
so it will know if the sip or xmpp contact is online
<Wizzup>
we'll have to fork it then eventually :P
<uvos>
that sucks
<uvos>
but ok
<Wizzup>
osso-abook has presence awareness (based on telepathy)
<uvos>
integration to the point that it dosent work by itself is a hard line for me
<Wizzup>
yeah, there's no sweet spot if the aim is integration
<Wizzup>
it could be some separate files or so
<Wizzup>
but I'm getting ahead of myself anyway, we're not close to that point now
<uvos>
ok
<uvos>
i kinda like how android works here btw
<uvos>
so on android the contacts system and app are totaly seperate from the dialer
<Wizzup>
does it integrate with signals/whatsapp/slack contecats?
<Wizzup>
contacts*
<uvos>
and only comunitace via a few mimes with the dialer
<uvos>
so they can be replaced seperately
<uvos>
so in the contacts a contact can have lots of protolls
<uvos>
and if you click on the contact with a certin protocoll it uses the intent (same concept as xdg mime) to open the right idaler
<uvos>
depending on the dialer you have installed that might be the same one for all
<uvos>
or maybe different ones depening on protocoll etc
<uvos>
thats handled by the mime system as with any other file / url whatever
<Wizzup>
so how do you get to the contact from the dialer?
<uvos>
same thing there is an intent (also sutch a xdg mime exits)
<uvos>
that goes like contact:someNumberOrScreenName
<uvos>
the contacts app gets opend with that contact then
<Wizzup>
so no context menu, but a full application switch
<uvos>
so both the contatcs app and any of the dialers for any of the procolls can be replaced without any of the other components noticing
<uvos>
right
freemangordon has joined #maemo-leste
<Wizzup>
that's too bad
<uvos>
yeah i mean ofc you loose something by haveing the componants have sutch loose coupeling
<uvos>
i think its worth the tade off tho
<freemangordon>
seems my messages disappear
<uvos>
that one worked
<freemangordon>
yeah, I restarted pidgin
<freemangordon>
uvos: do you plan to hildonize sphone?
<freemangordon>
also, if you don;t plan to add osso-abook support to sphone, I would say this is basiacally useless as leste dialer
<Wizzup>
maybe read the logs
<uvos>
freemangordon: a bit (allready have some) not too mutch that it becomes a ifdef mess
<freemangordon>
I did, thus the statement :)
<uvos>
it needs to contine to work on normal gtk2
<freemangordon>
if you integrate with osso-abook, you have no option but hildon
<Wizzup>
I think it's useful either way, but we might eventually fork it and add features we think we want
<freemangordon>
sure
<uvos>
right the way the whole stack works is everything or nothing, which i find very unagreeable in general.
<freemangordon>
but when it works, it does it in a perfect way, unlike the mess android contacts is
<uvos>
i think perfect needs to be observed from several angles
<uvos>
but ok
<uvos>
what is perfect is a matter of taste anyhow
<freemangordon>
uvos: sure, but that means one have tried both
<freemangordon>
which is not the case with you
<Wizzup>
to be clear I have not tried android either
<freemangordon>
I have
<freemangordon>
not much, but still
<uvos>
since the dialer and the contatcs app can be replaced easly at will
<uvos>
it allso needs to be said that there are many soultions for android :P
<freemangordon>
changing UI is not the same as having a broken backend in the first place
<uvos>
i heavly disagree that the backend is broken sure
<uvos>
its goals are slightly different than the fremantle one sure
<freemangordon>
uvos: and all those phone dialers on android do what exactly in a different way compared one to another?
<uvos>
differeing protocoll support, optimized for various form factors and sutch also different tastes in ui ofc.
<uvos>
diversity in implementation is a good thing imo
<freemangordon>
ok, but you still talk about UI, which is not the same as UX/functionality, no?
<freemangordon>
what diversity we have in picking up a phone call?!?
* Wizzup
zones out
<freemangordon>
what me (and I guess Wizzup) mean when we speck about osso-abok, is that it provides the same UX, no matter if we talk about dialer, email client, conversations, etc, etc
<freemangordon>
*speak
<freemangordon>
And honestly, I cannot explain that to you, you should feel it by yourself
<uvos>
this ux thing is mostly bullshit if ask me its a ui that presents certain fetures in certain ways
<uvos>
the different dialers present different features in different ways
<freemangordon>
maybe put a card in n900 running fremantle and use it as your primary device for 2-3 weeks
<freemangordon>
then we can have a discussion on what is bad and what is good about it
<freemangordon>
I agree I am biased, but my bias is based on experience
<Wizzup>
uvos: for the record having some hack in sphone to set the phone audio up properly for calls would be welcomed by me for now
<Wizzup>
just so that I can test calls once a day and see how often it 'just works'
<uvos>
i dont think a ratiol discussion is to be had with you on this, you are still useing a n900 long after its obsolete almost to the point of being non-functional because you like the way it works very mutch in every detail and quirk it has. thats fine but i excludes every doing things differently
<uvos>
*it excludes ever doing...
<Wizzup>
I think the principal thought it simple: tight integration of the frame works
<Wizzup>
s/it simple/is simple/
<freemangordon>
uvos: making things work differently doesn't make them work better. Also, the main purpose of android device is to 'present' adds to its "owner"
<uvos>
thats just plain not true regarding android
<uvos>
android is not just google or teribble oem implementations /skins
<freemangordon>
re n900 being dated - it is like saying that you're going to make a triangle wheel, because wheel is so old-fashioned
<Wizzup>
I see it a bit as what chromebooks are to normal linux devices
<Wizzup>
freemangordon: uvos: guys, this is not productive :)
<uvos>
chromebooks are very different chomeos is not an open platfrom
<freemangordon>
I know, but I am kind of fed up with bringing android to the table
<freemangordon>
*on the
<Wizzup>
It's not bad to know what it does
<freemangordon>
to my experience, there are couple of places it is better than fremantle (UX wise)
<uvos>
disregarding android because "i hate this thing" is hardly usefull.
<freemangordon>
being able to take a picture right from a chat is one of them
<freemangordon>
uvos: no, this is not the case, you got it wring
<uvos>
hah so the intents system :P
<freemangordon>
I don;t hate android, neither I refuse to admit when it does something better, see ^^^
<uvos>
allso allows you to replace the camera app with anything without the chat app noticeing
<freemangordon>
so does fremantle, there are a couple of camera applications
<freemangordon>
but that's not the point here
<uvos>
sure but you cant have the app ask for "i need one image here"
<uvos>
and then the right camera app is used to take it
<uvos>
thats what the intents system is for
<freemangordon>
good
<freemangordon>
I already admit this is something useful an good
<freemangordon>
*and
<uvos>
right so i want to bring it leste, by starting with how the interaction between contatcs and dialer app(s) works
<uvos>
*brint it to
<freemangordon>
if you can do that without sacrificing fremantle contacts UX, fine
<uvos>
not enirely see original discussion about it with Wizzup
<freemangordon>
also, how is that going to work on debian?
<uvos>
it works on debain allready
<uvos>
you click a link to a phone number in ff
<freemangordon>
there is "intents system" on debian?
<uvos>
and sphone opens with it
<uvos>
no
<uvos>
but you can use the xdg mimes to do most of what the intents do
<uvos>
(not everything i admit)
<freemangordon>
wait, wait, this is a very simple usecase
<uvos>
sure
<freemangordon>
opening by mime has nothiung to do with contacts with presence
<uvos>
sure
<uvos>
but also no
<freemangordon>
and this is what is provided by osso-abook
<uvos>
read the part with above with Wizzup
<Wizzup>
if I understand it android just doesn't do what we want
<freemangordon>
right
<Wizzup>
there is no presence integration, obviously, since many apps all do their own thing
<freemangordon>
exactly
<Wizzup>
there is no integration at all beyond notifications from apps
<freemangordon>
and some security, iirc
<Wizzup>
although I guess they might be able to scrape the contact books
<uvos>
yes
<Wizzup>
like whatsapp automatically finds/adds people
<uvos>
contacts are centalized
<uvos>
dont have too
<Wizzup>
but it works the wrong way
<uvos>
there are contacts providers
<uvos>
there can be (are) manny
<uvos>
but its a seperate interface distinct from intents
<freemangordon>
and this is what abook/telepathy provides
<freemangordon>
but, it also integrates presence
<uvos>
well it uses evoluition no?
<freemangordon>
yes
<uvos>
so you would just sphone get the contats from there
<uvos>
*have
<freemangordon>
it will be missing the presence
<uvos>
right i dont want that
<freemangordon>
so, you want android :)
<uvos>
no ofc not
<freemangordon>
also, evolution does not do aggregation
<uvos>
but i dont want fremantle exactly either (or rather the bad way it forces the implementation to work) :P
<freemangordon>
you have an addressbook and that's all
<freemangordon>
what is the bad about the way?
<freemangordon>
I really don;t understand what you dislike about it
<freemangordon>
elaborate please, in an attempt to have a productive discussion
<uvos>
honestly what i mostly want is a mobile desktop environment that tries to be like / integrate with exsting desktop linux as mutch as possible by being very xdg spec'y
<Wizzup>
I think he wants it to work outside of maemo
<uvos>
right
<freemangordon>
but why?
<freemangordon>
no matter what you do, youd desktop env will not turn into mobile
<uvos>
with any part of this desktop enviroment working as mutch as possible outside of maemo (on kde or whatever you want)
<uvos>
why?
<uvos>
ok:
<uvos>
1. ok that every one benefits (want to use you modem as a phone on your xfce laptop - sure do it)
<uvos>
2. avoid framentation hurting linux in the mobile space (leste has a great gps app or whatever - plamo a great pdf viewer - phosh has a great dialer - cant eatch on the other platform)
<uvos>
3. options (what if leste dies) best make it easy to pick stuff from its corpse to make the next thing
<uvos>
4. options for the user (close but not the same as 2.) make it easy for dude hacker to replace this one part of leste he dosent like (maybe the contacts app :P)
<freemangordon>
ok, I think I am getting your point
<uvos>
i see the past linux mobile platforms (maemo 5, meego, sfos, firefoxos, whatever ubuntu was doing) as a continous reimplementation of the same stuff that never benefited anyone because the tight integration with these frameworks made all the work peaple did one things amount to nothing when they imploded
<uvos>
i would like to avoid repeating this, in my opinion, mistake
<freemangordon>
it seems your approach is like that - because maemo specific things that work great are maemo-specific, and because they rely on maemo-specific libs, you want to sacrifice them and break the UX, just to stay compatible.
<freemangordon>
why not do it like that - bring those libs upstream?
<freemangordon>
which brings the next question - who is upstream?
<uvos>
there is no upstream, that is part of the problem true
<freemangordon>
it's us, no?
<uvos>
no
<freemangordon>
oh...
<freemangordon>
BTW, we are using lots of sailfish code
<uvos>
we lack a forum the discuss standardization with other linux mobile projects /uis
<uvos>
like desktop linux has in xdg
<freemangordon>
ok, but code wise we are the upstream for maemo-specific libs
<uvos>
sure but thats irrelivant
<uvos>
i want to avoid maemo leste being its own incompatibily little island
<freemangordon>
I understand that
<freemangordon>
and basically agree
<freemangordon>
but, how many maemo-specific packages do we have? ~200?
<uvos>
way more than 4 people can credibly improve/ maintain, which also worrys me
<Wizzup>
I'm betting on more people showing up once we have all the core bits owrking
<freemangordon>
uvos: sure, but until we can show something that works, I guess that's it
<freemangordon>
Wizzup: :nod:
<freemangordon>
abook being one of those code bits
<freemangordon>
and presenting a dialer as a leste dialer that's not integrated with abook, is not a good move PR wise, IMO
<freemangordon>
uvos: I am not saying you should do that integration
<uvos>
well i wont
<uvos>
thats a given
<uvos>
i use the sway d4 half the time
<freemangordon>
I am talking in general that applications that come preinstalled, must be maemo applications
<uvos>
im not shooting myself in the foot
<freemangordon>
didn;t get that
<freemangordon>
anyway, I think I have now a way better understanding on your approach
<uvos>
makeing sphone not work anymore on my primary(ish) device would be shooting myself in the foot
<freemangordon>
and appreciate your explanations.
<uvos>
you are very welcome
<freemangordon>
we have to think how to tackle that, maybe a fork is the right approach, as Wizzup said
* Wizzup
bbl
<freemangordon>
uvos: one thing about abook - back the when we were discussing iw we shall RE it or replace it, we were not able to find a single library or application that is even close to it in terms of functionality. So honestly, I think that bringing abook to the other platforms will only benefit them
<freemangordon>
so far it has dependencies on telepathy and eds
<freemangordon>
and I don;t see that as an issue
<uvos>
what dose it need tp for (only presence)
<uvos>
also it needs the hacked gtk2 i assume
<freemangordon>
no
<uvos>
ok what else?
<freemangordon>
(not only presence)
<freemangordon>
there is eds telepathy addressbook plugin
<freemangordon>
so, basically it creates addressbook for 'roster
<uvos>
(the hacked/ hildonized gtk2 ui is a huge show stopper i imagine)
<freemangordon>
' ' contacts
<freemangordon>
yes, there a couple of classes that rely on hildon
<freemangordon>
but, we can do that in the TODO list
<freemangordon>
*put that
<freemangordon>
right, it uses classes like hildon list view etc
<freemangordon>
so maybe those can be replaced by GTK3/4 elements, dunno
<freemangordon>
I don;t know how touch/mobile friendly gtk3/4 are
<uvos>
it gets better with gtk3 true
<freemangordon>
but, is it on par with hildon?
<uvos>
anyhow ttyl
<freemangordon>
ok
<uvos>
i think mostly, but i dont know enough to say for certain.
<uvos>
some very specific stuff ofc no
<uvos>
(like the xatom window flags and sutch)
<freemangordon>
I meant UI elements wise
<uvos>
mostly yes
<sicelo>
tmlind_: pvr/ddk1.17 working well with current (or close to current) wlroots? or still using older versions with xc-racer's patches?
<tmlind_>
sicelo: still using old version, but trying to rebase and bisect right now :) might be few more days at this rate of bisect..
<sicelo>
:)
<sicelo>
<uvos> honestly what i mostly want is a mobile desktop environment that tries to be like / integrate with exsting desktop linux as mutch as possible by being very xdg spec'y
<sicelo>
^^^ why not just use phosh? it's almost exactly that
_inky has joined #maemo-leste
inky has quit [Ping timeout: 252 seconds]
Bratch has joined #maemo-leste
l_bratch has quit [Ping timeout: 276 seconds]
<inky_>
>since its totaly impossible to detemine if something is a mult or a pointer based on just one source file
<inky_>
uvos, can you explain or link to some page? what is mult?
<inky_>
ah, mult is multiplication.
<uvos>
indent cant possibly know if SomeToken is a typedef or a global varaible declared in some header
<inky_>
Wizzup: tor+wireguard, sailfish guy.
<uvos>
since it parses one file at a time
<inky_>
i believe my friend added gui wireguard config to sailfish, may be you are talking about him? i can ping him.
<uvos>
sicelo: good question, i tried phosh on xt1602 it was not so great at the time (buggy incompleat) but that was quite some time ago
<uvos>
sicelo: i should try on a mapphone at some point
<inky_>
uvos: ok i understood completely by the following examples. you mean not possible to understand if it is a dereference or pointer.
<uvos>
right
<uvos>
sicelo: its beside the point anyhow i dont want some ui to work that way, i want all mobile linux uis to work that way, so that they can share a result in a unified platform, just like desktop linux is one unified platform where you can develop applications for that work with any de and even integrate at least resonably well by following xdg specs