| moparisthebest | is there an XMPP client that's recommended for running on Maemo ? | 07:10 |
|---|---|---|
| Wizzup | moparisthebest: so we're working on finishing parts of conversations that allow for group chats and the like (probably not yet media), so that'd probably be recommended | 11:25 |
| Wizzup | moparisthebest: what device do you have? | 11:48 |
| norayr | moparisthebest: i use pidgin and dino. | 12:46 |
| norayr | i like using pidgin because i like seeing different windows, and updates in those (in phosh that doesn't work, btw), and it is possible to write armenian in gtk2 apps with maemo onscreen keyboard. | 12:47 |
| norayr | also pidgin takes very little battery, and doesn't do heavy i/o. | 12:47 |
| norayr | dino draws battery and does heavy i/o, it is gtk3, so no maemo keyboard easy way, but it has http_upload, it has omemo encryption. | 12:48 |
| norayr | i wish it would be possible to build dino from handy branch, it has audio/video calls. and it can redraw itself for small screens, by hiding one of the panes, left or right. | 12:50 |
| norayr | it is good to have conversations, of course. | 12:50 |
| norayr | i was very much dependent on this way of xmpp chats, both in maemo and in sailfish. | 12:51 |
| Wizzup | norayr: as fmg said, we might have hildon input method soon for gtk3 | 12:54 |
| norayr | good. didn't notice this. usually i read everyhing, but not these couple of days. | 12:56 |
| norayr | we have a big problem with kbd, maybe i need to fork it and work on it myself. | 12:56 |
| Wizzup | what is this 'big problem' ? | 12:57 |
| norayr | Wizzup: let me start from the beginning. maemo kbd gives us utf-8 codes, not xkeycodes. before my contribution of the header file, we were not able to write in other languages in any place. today it is possible to write in any place in armenian, but i need to do 'setxkbmap am' before that. by using new uvos' backend, of course, not old. | 13:14 |
| norayr | which is also, btw, hard, because if i use a comma inside armenian text, it won't draw, i need to switch by doing setxkbmap us, then write a comma. | 13:15 |
| norayr | maybe the whole keyboard thing should be rewritten, let's say on one of my devices i use 'onboard' which works with xorg and types in any input field. | 13:16 |
| norayr | that would break old maemo things, but i think we can give up old maemo work of input at all. having 2 different backends for the keyboard means people need to be taught that we have 2 different backends. | 13:17 |
| norayr | they don't understand why by tapping they get one backend and by pressing a key they get another backend, and why the kbd behaves differently. | 13:17 |
| norayr | this is not consistent and makes people go away from maemo. | 13:17 |
| norayr | the input is one of the most common interactions between humans and machines. | 13:18 |
| norayr | it should be very convenient. | 13:18 |
| norayr | and believe me i cannot convince anyone, not only my mother or wife, but any of my nerdy friends to do setxkbmap each time they change the kbd layout. | 13:19 |
| norayr | so what i think to do, i can create a map with available languages, and xkb maps. and at the onscreen kbd language change, do a corresponding setxkbmap automatically. | 13:19 |
| norayr | i even researched how to do that in C, programmatically, via functions. | 13:19 |
| norayr | but that won't help if the user needs to type comma, or semicolon inside armenian or russian or whatever text. | 13:20 |
| norayr | they need to switch to english, type a comma, and then back. :/ | 13:20 |
| norayr | and still that would mean using the second backend. one of two, and educating the users, again. nobody wants this kind of 'education' since everybody intuitively understand that computers are made to increase the efficiency of working, to make life easier, not harder. | 13:21 |
| norayr | so maybe quick fix is a map and doing setxkbmap programmatically, and real fix is rewriting the whole kbd stuff, and deciding to not have 2 backends, and educating users, but one backend. and removing hidlonization part of input from gtk at qt. | 13:23 |
| norayr | the input is what makes my hands to search something else than maemo device. it is a torture to switch between languages even for a comma. | 13:24 |
| norayr | and i am ready to be 'educated' and use it in this complicated way. | 13:24 |
| norayr | this is the commit i am talking about: https://github.com/maemo-leste/hildon-input-method/commit/5dcba543c36c12ac70288a7b652310e275eebee7 | 13:28 |
| norayr | norayr == inky | 13:28 |
| norayr | the file i generated is hildon-im-xcode-keysyms.h | 13:29 |
| norayr | btw that's how i did it: https://github.com/norayr/gen-header-for-hildon-input-method | 13:29 |
| norayr | but that doesn't matter, that would deviate from the main discussion. | 13:30 |
| Wizzup | norayr: it might be good to capture this in an issue | 13:33 |
| norayr | thank you, i'll try. | 13:33 |
| Wizzup | uvos: this phone says xt910 in android but xt912 on the back... | 13:37 |
| Wizzup | all three of these actually | 13:37 |
| buZz | i think i'm getting a Cosmo Communicator on loan in a while | 14:00 |
| buZz | touchscreen glass is cracked i think, but works | 14:01 |
| uvos | Wizzup: thats a bit strange, but all spiders run essentaly the same android firmware so its not suprizing that works | 14:44 |
| Wizzup | uvos: they were sold as xt910 though | 14:47 |
| Wizzup | so I suppose they are all xt912, I don't know what xt910 says on the back | 14:47 |
| uvos | not sure what you mean on the back | 14:47 |
| sicelo | heh, here's a fun one - at least on my droid 4, i can't type numbers when entering a new contact in addressbook using hwkb | 14:47 |
| uvos | my xt910 dosent say anything on the back | 14:47 |
| sicelo | in the cellular number field, that is | 14:49 |
| Wizzup | uvos: yeah just to identify it I mean | 14:51 |
| Wizzup | sicelo: hm, please file a bug :) | 14:51 |
| Wizzup | this might be relatively easy to fix, but sounds odd, I think I did this without problems | 14:51 |
| uvos | norayr: we will allways need 2 backends | 14:52 |
| uvos | unless we improve the x11 backend (with atspi maybe?) to the point we dont need the toolkit specific ones | 14:52 |
| uvos | otherwise input into stuff like xterm, random nontoolkit/ niche toolking applicaitons wont work | 14:53 |
| norayr | that's what i am saying: improving x11 backend as an ulimate goal. short term but bad solution is creating a map (maemo input language to xkb map). and doing setxkbmap automatically. | 14:54 |
| norayr | which won't solve changing kbd laaayout when typing commas but it would short term make everything much more usable. | 14:55 |
| uvos | creating a him xkb map or having him create ones dinamicly is the only way it will work | 14:55 |
| uvos | sure it solves typing commas etc | 14:55 |
| uvos | a map can have 248 chars | 14:55 |
| uvos | thats enough for 2 languages and special chars | 14:56 |
| norayr | no no i believe it doesn't. i have to do setxkbmap us to be able to type commas.:/ | 14:56 |
| uvos | because the arminan map dosent have the right code | 14:56 |
| norayr | cannot write ascii with unicode layout. | 14:56 |
| uvos | thats not how this works | 14:56 |
| uvos | its neither acsii nor unicode | 14:57 |
| norayr | which one has? | 14:57 |
| uvos | its xkeysims | 14:57 |
| uvos | him just needs to create/have a map that is switches to when it opens that contains all the chars it can type in the user selected languages | 14:57 |
| uvos | that contains a xkeycode for eatch xkeysym it wants to type | 14:57 |
| norayr | i think no xkb map has ascii symbols | 14:57 |
| uvos | again its not acsii at all | 14:58 |
| uvos | but yes you have to create a map (dynamicly or otherwise) just for him | 14:58 |
| uvos | and not use one of the default ones | 14:58 |
| norayr | or use existing map as a shooooort term solution. | 14:58 |
| norayr | by mapping him's am layout to setxkbmap am | 14:59 |
| norayr | and him's ru rayout to setxkbmap ru | 14:59 |
| uvos | no, because as you correctly state the xkb maps dont line up with the keys him wants to type | 14:59 |
| norayr | that won't solve commas but at reast ih is something. | 14:59 |
| norayr | least | 14:59 |
| sicelo | and sphone (abook?) doesn't show caller's name if saved in E.164 format. maybe operator only sends local part of number? it should be somehow possible for sphone/abook to match the contact nonetheless | 15:08 |
| * sicelo is using his work sim on droid 4 for a while | 15:08 | |
| uvos | sphone uses eds functions to lookup the phone number in the address book | 15:09 |
| uvos | if eds supports converting between regions then it should work if eds just dose a strcmp then thats how it works. | 15:10 |
| uvos | so dunno | 15:10 |
| uvos | eds has specific functions to match phone numbers so i would guess it dose understand at least 00 + and local notation | 15:11 |
| moparisthebest | Wizzup: pinephone here, is that code anywhere yet? | 15:42 |
| Wizzup | yup, although some of the work in progress branches need some cleaning up before dsc_ can/will merge them | 15:43 |
| moparisthebest | norayr: latest Dino with calls is gtk4 | 15:44 |
| moparisthebest | I tried gajim which worked except I couldn't focus the input box to type messages :( | 15:46 |
| Wizzup | so the way to go in the near future is absolutely going to be conversations, but I'm surprised you can't focus with gajim | 15:59 |
| Wizzup | it's gtk2, right? | 15:59 |
| uvos | him pretty mutch breaks any application that focuses fields itself | 16:00 |
| uvos | this affects pdigen too | 16:00 |
| moparisthebest | I'm guessing gajim is gtk3 but I'm not sure right now, I'll check | 16:02 |
| moparisthebest | It's interesting I can hit tab and a name will be put in the input box, and I can hit enter to send it which works, but I can't focus or type in it | 16:03 |
| moparisthebest | I do all my phone calls over XMPP too so that'll be hard to go without | 16:05 |
| freemangordon | sicelo: I don't know what sphone uses to show caller's name, but I can assure you abook has fuzzy number matching | 16:11 |
| freemangordon | whether it works, is another story though, I am not sure it was tested thoroughly after REing | 16:12 |
| freemangordon | uvos: what 'eds functions' are used? | 16:12 |
| freemangordon | sicelo: http://maemo.org/api_refs/5.0/beta/libosso-abook/libosso-abook-osso-abook-util.html#osso-abook-query-phone-number | 16:14 |
| freemangordon | https://github.com/maemo-leste/osso-abook/blob/a731589ac51e2059b667ab8d8c84b41b0befab03/lib/osso-abook-aggregator.c#L2327 | 16:22 |
| uvos | freemangordon: https://github.com/maemo-leste/sphone/blob/eacc386bf976e999a0c2a0d0a536cebe5b7f788d/src/modules/contacts-evolution.c#L57 | 16:35 |
| uvos | this is the query used | 16:35 |
| uvos | E_BOOK_QUERY_EQUALS_SHORT_PHONE_NUMBER internally uses e_phone_number_compare_strings | 16:35 |
| uvos | so yes fuzzy matching | 16:36 |
| uvos | not sure why abook reinvents the wheel here | 16:36 |
| freemangordon | IIUC because: 1. it normalizes the phone number before doing the matching. 2. It uses last 7 digits to do the match. | 17:55 |
| freemangordon | I would always trust Nokia when it comes to something telephony | 17:55 |
| uvos | freemangordon: this is exactly what eds dose uuic | 18:34 |
| uvos | the last 7 digits is the SHORT of the query type | 18:34 |
| uvos | so iiuc these functions are the same | 18:35 |
| uvos | i would not trust nokia in anything | 18:35 |
| freemangordon | why is that? what they did to you? | 18:38 |
| uvos | i mean nokia implementations of things in maemo are honestly pretty uniformly bad | 18:39 |
| sicelo | heh. anyway, just to be sure - d4 needed some hack for call audio. is that in leste kernel or not? | 18:39 |
| freemangordon | not abook | 18:39 |
| uvos | maybe not abook, i havent looked at it | 18:39 |
| freemangordon | a side note - on chimaera chromium tries to use GPU rendering and fails strangely | 18:39 |
| freemangordon | on d4 that is | 18:39 |
| uvos | well so dose qwebengine | 18:40 |
| uvos | so that might be related | 18:40 |
| uvos | it failes to compile a shader | 18:40 |
| freemangordon | PVR:(Error): LoadCompilerModule: Couldn't load library libglslcompiler.so [0, ] | 18:40 |
| freemangordon | yes | 18:40 |
| freemangordon | do we have binaries with hacks removed? | 18:40 |
| uvos | ti git | 18:40 |
| freemangordon | umm... | 18:41 |
| uvos | hmm? | 18:41 |
| freemangordon | what is ti git here? | 18:42 |
| freemangordon | https://github.com/maemo-leste/sgx-ddk-um/tree/maemo/chimaera | 18:42 |
| freemangordon | "This branch is up to date with master." | 18:42 |
| freemangordon | so, the binaries we use on chimaera are hacked ones | 18:43 |
| freemangordon | I would bet that's the reason for the failures | 18:43 |
| freemangordon | have to run now, will check that tomorrow | 18:43 |
| uvos | not sure why the hacks would cause that | 18:43 |
| uvos | its just weakening a symbol | 18:44 |
| freemangordon | well... | 18:44 |
| uvos | well what? | 18:44 |
| freemangordon | one of the libs that was 'weakened' is libglslcompiler.so | 18:44 |
| freemangordon | iirc | 18:44 |
| uvos | sure | 18:44 |
| uvos | but i mean how would that cause an isue i mean | 18:44 |
| uvos | sure we should remove it anyhow | 18:44 |
| freemangordon | no idea | 18:44 |
| freemangordon | yes, will try tomorrow | 18:44 |
| freemangordon | ttyl | 18:44 |
| uvos | ti git is upstream | 18:45 |
| uvos | https://git.ti.com/cgit/graphics/omap5-sgx-ddk-um-linux/refs/heads | 18:46 |
| freemangordon | I know, but that's not what we distribute | 18:46 |
| uvos | sure no | 18:46 |
| uvos | im awnsering the question "what is ti git here?" | 18:47 |
| freemangordon | ok | 18:47 |
| sicelo | Wizzup: i would like to upstream spinal's patch - https://github.com/maemo-leste/n9xx-linux/commit/fbc4ce7a84e59215914a8981afe918002b191493, unless you can do it | 19:13 |
| sicelo | if i do it, please remind me how to send someone's patch so it has proper attribution. you sent my lp5523 patch and it does credit me in the git history | 19:14 |
| uvos | sicelo: git am? | 20:24 |
| uvos | or while genrateing the email? | 20:24 |
| uvos | git format-patch has an option there | 20:24 |
| Wizzup | sicelo: please do, maybe Authored-by or Suggested-by or so? | 20:25 |
| sicelo | cool, will do. i wonder if spinal can still be contacted via mail maybe. perhaps i should start with that | 20:28 |
| sicelo | heh, he's just responded to the gh issue i opened against charge-mode :-p | 22:06 |
| sicelo | email sent | 22:15 |
| sicelo | (to spinal, that is) | 22:22 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!