--- Log opened Sun Sep 23 00:00:27 2018
03:56 -!- xenos1984 [~xenos1984@22-164-191-90.dyn.estpak.ee] has joined #navit
03:56 -!- mode/#navit [+v xenos1984] by ChanServ
13:15 #navit: <+jkoan> hi @all
16:27 #navit: <@KaZeR> hi
16:27 #navit: <+jkoan> What's up KaZeR?
16:44 #navit: <@KaZeR> not much. almost caught up with the stuffs that were preventing me to work on navit
16:44 #navit: <+jkoan> Nice :)
16:44 #navit: <@KaZeR> also i did some work with qt5 recently for something else. This should help me resume work on the qt5/qml2 UI
16:45 #navit: <+jkoan> Really cool
16:45 #navit: <@KaZeR> now that we have multiple person working on the build system, pipeline, packaging etc i should be able to focus on that
16:45 #navit: <+jkoan> Qt5 has frame buffer functionality?
16:45 #navit: <+jkoan> Yes, would be cool
16:46 #navit: <@KaZeR> yes and it kicks ass. My Jeep's setup boots directly to navit via the framebuffer on a raspberry pi. No X, no screen flickering. Feels really native
16:47 #navit: <@KaZeR> i should make a video
16:47 #navit: <+jkoan> I will try to build Qt5 for tomtom, but I think qt will not leave much of the 32MB ram over or navit.
16:48 #navit: <@KaZeR> 32MB is really not a lot but it might be worth a shot. If it works it's going to be really nice
16:49 #navit: <+jkoan> I will give it a go, but I think I will encounter problems with it :D
16:50 #navit: <+jkoan> What do you think about cleaning up the PRs? :X
16:52 #navit: <@KaZeR> yep that's needed
16:54 #navit: <+jkoan> #309, 435 and #452 can be closed? all need to be reworked
16:55 #navit: <+jkoan> for #559 i am not sure it the discussion is finished and if we can merge it
17:08 #navit: <@KaZeR> ok for #309
17:09 #navit: <@KaZeR> i'll give a shot at #435 it might be easy to finish it (and i need that fix for a raspberry pi build)
17:09 #navit: <@KaZeR> #452 might be worth fixing too, since lains provided a potential solution
17:12 #navit: <+jkoan> #452 this would be a really big improvement, right?
17:16 #navit: <@KaZeR> well not really big, but nice
17:16 #navit: <@KaZeR> it would still depend on an external program to use it. But that's the point: make it possible for an external program to route to a bookmark
17:17 #navit: <+jkoan> what if we would buld this like a plugin, one plugin then could be local save and another one could be cloud sync as example or as well something like "navit sync"
17:18 #navit: <+jkoan> my idea would be basic functions in the core (for example exachange a list) and the bindings and plugins can use this api to provide a function which could for example be file save
17:27 #navit: <@KaZeR> i'm not sure i follow. can you expand a bit on that?
17:28 #navit: <+ilovekiruna> hi KaZeR, hi jkoan
17:32 #navit: <@KaZeR> hey ilovekiruna 
17:34 #navit: <+jkoan> the general idea is to keep the core as minimalistic as possible. this would mean that the core only gets some api funktions which provide rw access to the bookmarks (probably we already have this trough the navit object) and the real bookmarks plugin for example the file_bookmarks plugin wuld use this to api to provide his functionality. This would also provide the advantage that for example android could add a sync between contacts and 
17:34 #navit: <+jkoan> navit (contact addresses=bookmarks). Only a idea
17:34 #navit: <+jkoan> hi ilovekiruna
17:38 #navit: <@KaZeR> jkoan: ha i see. the thing is that currently bookmarks are a core feature. I'm not sure if it would make sense to move them outside of core. Do you?
17:39 #navit: <@KaZeR> we can still provide synchronization via an external mean. For example a webdav plugin would allow to synchronize the bookmark file to something like owncloud
17:44 #navit: <+jkoan> i think it would make sense to keep core as small as possible but have a defined api to write plugins which can be hosted out of tree. there for we would need header files (libnavit-dev). Then your spotify plugin could be a independent plugin which could have its own checks by assuming that the api is working. on the navit side we would have unit tests aper api to test that the api is really working like we intended. Of course this would 
17:44 #navit: <+jkoan> be much work, but i think it but we worth it. Then you could download a plugin and snap it into navit. But this would fir require defined programming apis and headers. and there for i think a clean and tiny core would be the best
18:04 #navit: <+ilovekiruna> KaZeR: am starting to look at auxmap again
18:04 #navit: <+ilovekiruna> any news about the split of navit.xml?
18:04 #navit: <+jkoan> i asked KaZeR todwas whats to do with the PR, yes
18:06 #navit: <@KaZeR> ilovekiruna: great, i count on you to fix our docs :D
18:16 #navit: <+ilovekiruna> KaZeR: first i had to understand things myself
18:16 #navit: <+ilovekiruna> jkoan: are we still on farming?
18:17 #navit: <+jkoan> "on farming"?
18:23 #navit: <+ilovekiruna> jkoan: device farm
18:24 #navit: <+jkoan> i didn't done work into this direction in the last time
18:26 #navit: <+ilovekiruna> me, neither for long
18:28 #navit: <@KaZeR> we still have access to the aws device farm, just in case :)
18:28 #navit: <+jkoan> KaZeR: the idea was to build our own device farm
18:28 #navit: <+ilovekiruna> KaZeR: the question was a little different ;-)
18:28 #navit: <+ilovekiruna> :-o, jkoan, was faster
18:29 #navit: <+jkoan> i already collected old android phones ;)
18:29 #navit: <+ilovekiruna> am also trying to get what i can
18:29 #navit: <+ilovekiruna> what i am proud of, is to have two sailfish phones 
18:32 #navit: <+jkoan> KaZeR: any idea how you would setup something like this? my idea was a master server which accepts test request and schedules those to the nodes which have the phones attached to it
18:32 #navit: <+ilovekiruna> those could also be used, one permanently, the other temporarily
18:32 #navit: <+jkoan> ilovekiruna: (y)
18:33 #navit: <+ilovekiruna> KaZeR: is the map in navit checking for change of layout (day / night) in every redraw=
18:34 #navit: <@KaZeR> jkoan: the scheduling part isn't difficult i think, the hardest part would be to setup the test suite
18:36 #navit: <+jkoan> yes and no, i think also the setup between devices and decice familiys will be a problem (android vs iphone vs tomtom vs wince and so on)
18:37 #navit: <@KaZeR> ilovekiruna: on vehicle updates : https://github.com/navit-gps/navit/blob/07006013135b619029f26df579a0ac6acb86cd4a/navit/navit.c#L2955
18:52 #navit: <+ilovekiruna> jkoan: that's why I suggested earlier to use a tool like appium or selenium which have built-in support for several platforms
18:53 #navit: <+ilovekiruna> but i remember it didnt run for you
18:53 #navit: <+jkoan> yes, but dident tested so far
18:53 #navit: <+jkoan> (again)
18:53 #navit: <+jkoan> currently i troubleshoot tomtom ;)
18:57 #navit: <+ilovekiruna> no problem
18:57 #navit: <+ilovekiruna> I think i will look at it again once my other navit issue is solved
18:58 #navit: <+jkoan> okay
18:58 #navit: <+ilovekiruna> KaZeR: saw this comment https://github.com/navit-gps/navit/blob/98e7489e1098e22ec13097ea09c2af49a8889a59/navit/navit.c#L3205
18:58 #navit: <+ilovekiruna> is this about changes in the code or rather in the navit.xml?
18:58 #navit: <+ilovekiruna> i feel rather the second one
18:59 #navit: <+jkoan> i think switch to dark mode when under earth 
19:00 #navit: <+ilovekiruna> jkoan: so anytime we loose signal?
19:00 #navit: <+ilovekiruna> i mean gps signal?
19:00 #navit: <+jkoan> no, from the mapdata
19:01 #navit: <+ilovekiruna> is there an osm tag for tunnels?
19:01 #navit: <+jkoan> i think so, but dident looked
19:02 #navit: <+ilovekiruna> what do you think about the lack of signal idea? could also cover for example parking houses, etc
19:02 #navit: <+ilovekiruna> and i guess rather easy for different devices  unlike a light sensor
19:03 #navit: <+jkoan> but this could happen also randomly, but why not a second link to a layout so the user could chose what should happen 
19:04 #navit: <@KaZeR> ilovekiruna: that would have to be code, as only the app knows if we are in a tunnel or not
19:04 #navit: <@KaZeR> > jkoan | no, from the mapdata 
19:04 #navit: <@KaZeR> exactly. although i'm not sure that we import the tunnel data currently
19:08 #navit: <+ilovekiruna> KaZeR: what do you think about my ideas to avoid mapdata for this?
22:39 -!- xenos1984 [~xenos1984@22-164-191-90.dyn.estpak.ee] has quit [Quit: Leaving.]
--- Log closed Mon Sep 24 00:00:28 2018