[03:10:19] *** Quits: OLFDB (~olfdb@212.86.59.230) (Ping timeout: 252 seconds)
[11:47:13] *** Joins: OLFDB (~olfdb@79.140.112.145)
[11:48:12] <OLFDB> Hi, is there already a function to persist changes in the configuration into navit.xml?
[12:34:56] *** Joins: ilovekiruna (~ilovekiru@2a02:8108:d00:110:c148:52f5:d957:d25)
[12:34:56] *** ChanServ sets mode: +v ilovekiruna
[19:38:42] <Navit> <jkoan> Nö I don't think so
[19:39:10] <Navit> <jkoan> Just something for some gui internal settings
[19:46:24] <Navit> <jkoan> But I would also like to have this unified. But I also thought about a new config system to move away from attributes which need to be defined by navit core. More like config option which define a data-type a default and a function to set, read and save/export them. Then my idea would be sqlite for internal/expert settings and ini-files for user settings. Also styles could be handled by mapnik layouts (which would
[19:46:25] <Navit> need to be implemented obviously), because mapnik has really nice layout editors
[20:40:07] <Navit> <ilovekiruna> am not really a friend of a sqlite system
[20:40:34] <Navit> <ilovekiruna> I would rather suggest to make the settings more comprehensible by improving navit-configurator
[21:08:10] <Navit> <jkoan> i don't wanne have any tool needed to adjust settings, everything needs to from within navit itself (including helping text for all options) the only exception may be layout (not osd-layouts) with mapnik editor as said before
[21:10:33] <Navit> <jkoan> and sqlite (or any other storage) would just be the internal structure where those user edited settings will be stored. But saving them into ini (for example) would also be an option. But i would like to move away from xml as is complicated for a lot of users
[21:15:35] <Navit> <ilovekiruna> what is the big difference between ini and xml?
[21:15:49] <Navit> <ilovekiruna> for me it is mostly syntax
[21:15:59] <Navit> <jkoan> exactly
[21:16:48] <Navit> <jkoan> and users are lazy and forget cloasing tags for example oder dont know that thy can be an issue
[21:16:57] <Navit> <jkoan> just one example
[21:17:20] <Navit> <jkoan> fro us technical people this isnt a problem, but for others it is
[21:17:59] <Navit> <jkoan> also i think parsing and rewriting a ini-file is simpler than an xml-file when we implement some form of gui setting save
[21:45:03] <Navit> <ilovekiruna> it just sounds like really quite a lot of work
[21:45:25] <Navit> <ilovekiruna> and I like to be able to save things in ascii compared to doing edits in a database 😉