| uvos | maybe they could check thair inventory and tell us what cell they have that is the largest that fits into the d4's battery bay | 01:15 |
|---|---|---|
| uvos | then they could sell us the bare cell with maybe some nickle stips attached for us to solder to the original bsm/my pcb | 01:16 |
| uvos | since unfortinatly parametic search on li-ion cells is not something you can just do as a consumer | 01:17 |
| uvos | even selling us the bare cell from the e960 battery without the nexus bms would be a start | 01:18 |
| Wizzup | I am not sure if they would be willing, but we could try | 02:24 |
| Wizzup | uvos: actually I kind of like it | 03:11 |
| Wizzup | I guess they could get the droid4 size easily from a eb41 search | 03:18 |
| Wizzup | I asked him | 03:25 |
| freemangordon | uvos__: do we want osso-abook(the library) to do hildon_uri_open()? I guess yes, but just to confirm. | 09:14 |
| freemangordon | I know addressbook (the application) should do, albeit using hildon_uri_open_filter() | 09:14 |
| freemangordon | hmm, no, lib should not try anything but TP | 09:22 |
| freemangordon | or not? | 09:44 |
| uvos__ | why not? the lib is bound to be used in other applications where this is usefull | 09:57 |
| uvos__ | not least sphone itself | 09:57 |
| freemangordon | so you expect abook lib to call sphone back to dial a number? | 10:18 |
| freemangordon | I am trying to make the big picture clear to myself | 10:18 |
| freemangordon | and more or less agree lib shall do hildon_uri_open() calls | 10:19 |
| freemangordon | but that will not work properly without some sane defaults | 10:19 |
| freemangordon | or sphone registering itself as osso service | 10:19 |
| freemangordon | (in case of sphone) | 10:19 |
| freemangordon | imagine: | 10:19 |
| freemangordon | we don't tha TP ting account | 10:20 |
| freemangordon | user wants to dial a phone through sphone abook lib contacts chooser | 10:20 |
| freemangordon | sorry for the typos | 10:20 |
| freemangordon | "we don't have TP ring account" | 10:21 |
| freemangordon | so, she presses the phone field, lib sees there is no ring account and calls hildon_uri_open() | 10:21 |
| freemangordon | this will open osso-addressbook by default :) | 10:21 |
| freemangordon | OTOH, I don't think XDG shall be primary and osso fallback | 10:23 |
| freemangordon | BTW, I don;t think we shall limit hildon_uri_open() fallback logic to tel/sms only | 10:24 |
| freemangordon | we may want to fallback to pidgin (for example) for chats etc | 10:24 |
| uvos__ | freemangordon: it dose that allready for everthing except tel and sms | 10:25 |
| uvos__ | pidgen should work ever since we added xdg support to libhildonmime | 10:25 |
| freemangordon | umm, where did you see that? | 10:25 |
| freemangordon | in abook lib I mean | 10:25 |
| uvos__ | sec | 10:25 |
| uvos__ | ok looks like its only for mail which makes sense, yeah chat is tp only | 10:30 |
| uvos__ | freemangordon: to the above | 10:32 |
| freemangordon | mhm | 10:32 |
| freemangordon | so no fallback currently | 10:32 |
| uvos__ | freemangordon: frankly i dont see the usecase of abook-lib ever calling osso-addressbook to handle anything | 10:32 |
| freemangordon | hildon_uri_open() will do it | 10:33 |
| uvos__ | so we can just hardcode abook-lib to ignore osso-addressbook | 10:33 |
| freemangordon | no | 10:33 |
| uvos__ | why not? | 10:33 |
| freemangordon | because this might be a valid use-case | 10:33 |
| uvos__ | i dont see how a hildon_uri_open from abook-lib should ever end up in osso-addressbook | 10:33 |
| freemangordon | can't imagine now, but that looks like a huge hack | 10:33 |
| freemangordon | because osso-abook is registered as soos service | 10:34 |
| freemangordon | sec | 10:34 |
| uvos__ | i know why it dose it | 10:34 |
| freemangordon | https://github.com/maemo-leste/osso-addressbook/blob/master/data/osso-addressbook.desktop | 10:34 |
| uvos__ | but i mean there is no usecase for a abook widget to ever open osso-addressbook to handle a url | 10:34 |
| uvos__ | since osso-addressbook then pops up the "add contact" dialog | 10:34 |
| freemangordon | exactly | 10:34 |
| uvos__ | and that makes no sense if the user clicked on the link inside the abook in the firstplace | 10:34 |
| uvos__ | so just filter away the osso-addressbook in every uri_open call in abook | 10:35 |
| freemangordon | osso-addressbook is just an application | 10:35 |
| freemangordon | and there is no issue when user clicks link from it (already added filter) | 10:35 |
| uvos__ | its an application that registers a osso-service | 10:35 |
| freemangordon | but if it is not osso-addressbook that uses the lib | 10:36 |
| freemangordon | then we have an issue | 10:36 |
| uvos__ | i dont see why, every call to libhildonmime from abook-lib simply filters away the osso-addressbook service and everything works fine | 10:36 |
| freemangordon | no, we can't do that | 10:36 |
| uvos__ | why not? | 10:36 |
| freemangordon | I mean - this is ugly hack | 10:36 |
| uvos__ | i dont think its that ugly really | 10:37 |
| freemangordon | what about abook applet then? | 10:37 |
| freemangordon | umm... | 10:37 |
| freemangordon | wait | 10:37 |
| uvos__ | what about it? | 10:37 |
| freemangordon | scratch that | 10:37 |
| uvos__ | a bigger problem i see is the other direction | 10:37 |
| freemangordon | why should be osso-addressbook any special? | 10:37 |
| uvos__ | i mean if you dont want it to be special | 10:38 |
| uvos__ | you can implement something like android intents | 10:38 |
| freemangordon | no idea what it is | 10:38 |
| uvos__ | android intents allow handlers to have specific purposes | 10:39 |
| uvos__ | ie the dispach can give a hint that: this schal be used to communicate | 10:39 |
| uvos__ | or: this shal be stored in some address book | 10:39 |
| uvos__ | etc | 10:39 |
| freemangordon | we have similar already | 10:39 |
| freemangordon | not same, but similar | 10:39 |
| uvos__ | well the services dont work that way | 10:40 |
| freemangordon | hildon-uri actions | 10:40 |
| freemangordon | they do | 10:40 |
| uvos__ | afaik libhildonmime has no way of being told to only consider handlers of a certain type | 10:40 |
| freemangordon | yes, see the second parameter of hildon_uri_get_actions_by_uri() | 10:41 |
| freemangordon | so there seems to be some idea we can extend | 10:42 |
| uvos__ | well that | 10:42 |
| freemangordon | but, I don't really want to go into that | 10:42 |
| uvos__ | dosent really have that kind of granularity that android intents have at all | 10:42 |
| freemangordon | sure | 10:42 |
| uvos__ | like what dose NORMAL and NEUTRAL even supposed to mean | 10:43 |
| freemangordon | still trying to grok :) | 10:43 |
| uvos__ | anyhow the clean solution would be to have "open" and "store" be different actions | 10:43 |
| uvos__ | and xdg-open only responds to "open" (obviously) and osso-addressbook only to "store" | 10:44 |
| uvos__ | that would be copying android essentally | 10:44 |
| uvos__ | the sliglty less clean solution (but imo not bad) would be to just hardcode filter away osso-addressbook in abook-lib | 10:44 |
| freemangordon | dunno, really sounds like a hack to me. that way we say osso-addressbook is the only addressbook on the system, which contradicts to what you are fighting for all the time :p | 10:47 |
| uvos__ | this is true, and i use gnome contacts some | 10:48 |
| * freemangordon puts his devil's advocate hat on | 10:48 | |
| uvos__ | but in the end gnome-contacts dosent use libhildonmime anyhow | 10:48 |
| uvos__ | so it has no effect | 10:48 |
| freemangordon | right, but we limit osso addressbook provider | 10:49 |
| uvos__ | this is another big problem for this whole construction of course, firefox will never choose a osso-service to handle something | 10:49 |
| freemangordon | it shall never I think | 10:50 |
| uvos__ | why not? | 10:50 |
| uvos__ | we could have speical .desktop files for osso-services | 10:50 |
| freemangordon | dialer shall register with xdg, no? | 10:50 |
| uvos__ | that call libhildonmime with some parameters | 10:50 |
| uvos__ | that then are registered with xdg | 10:50 |
| uvos__ | anyhow not important right now | 10:51 |
| freemangordon | right | 10:51 |
| freemangordon | hmm, I wonder why is not osso-addressbook kalled for emails | 10:52 |
| freemangordon | *called | 10:52 |
| uvos__ | probubly modest is just head of it in the list | 10:54 |
| uvos__ | *ahead | 10:54 |
| freemangordon | That'd be really crazy if Nokia counted on that | 10:55 |
| freemangordon | ok, will check that when I have some time, have to run now. ttyl | 10:56 |
| arno11 | Wizzup: sicelo: i tweaked transition.ini a bit (a lot in fact) and result is crazy: the UI is now really fast (even without overclock) | 11:57 |
| arno11 | apt-worker is a big concern too. must be disabled i think, without overclock n900 is unusable for 5 min at least when apt-worker is running... | 12:10 |
| Wizzup | arno11: what kind of changes? | 14:20 |
| maxwelld | i am sorry for this but why are they writing fremantle under this video? https://invidious.protokolla.fi/watch?v=liaaYHuQmf0 | 14:27 |
| maxwelld | isn't it the name of the wind? | 14:27 |
| maxwelld | omg | 14:28 |
| maxwelld | they are writing it under all videos. | 14:28 |
| maxwelld | sorry. | 14:28 |
| arno11 | Wizzup: almost every 250 ms parameters to 50ms and disabling all zoom and animations (which are already not really working) | 14:57 |
| Wizzup | care to share the diff | 14:58 |
| Wizzup | ? | 14:58 |
| arno11 | of course | 14:58 |
| Wizzup | well, actually, take your time, I'm going to sleep soon :) | 14:58 |
| arno11 | ok no probs man :) | 14:58 |
| Guest224 | arnoll: how much it would save memory of N900, if there is solid background and only one desktop screen? | 19:03 |
| Guest224 | *arno11 | 19:04 |
| Guest224 | maybe not much, but even 1 MB counts. I think it is something between from 1,1 to 3,3 MB. | 19:11 |
| arno11 | Guest224: yes between 1 and 3MB | 21:00 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!