Hi!
When doing the headless PR I started looking into our AppParamsParser. And what it does is rather simple but some things popped up I wanted to discuss.
a) Which of the options are needed? Feels like most aren't
- kodi --lirc-dev
- kodi --no-lirc
- kodi -d X
- kodi --test
- kodi foo.mp3 bar.mp3
- kodi --legacy-res
- kodi --debug
- kodi --standalone
- kodi --settings=
- kodi --portable
- kodi --fullscreen
b) We don't we use a third party parser,
http://www.boost.org/doc/libs/1_57_0/doc...tions.html or GNU getopt ?
c) We call AppParam parsing well before application is started, so it feels a bit weird that its tied to app. Wouldn't it be better if AppParamParser just returned a struct with options, and we apply those in XBMC_Run?
fullscreen and portable are certainly used. No idea about the rest.
Linux builds have a portable mode? Or is this a different kind of portable mode than what Windows users have?
why wouldn't they? Its just not overly useful when running from packages, as the install location belongs to root.
Manual compiles work just fine with portable mode
-d <delay> is used by some of my friends to delay the startup after system boots up. this is done to be sure that other services are started right before kodi.
(2015-02-11, 18:49)xhaggi Wrote: [ -> ]-d <delay> is used by some of my friends to delay the startup after system boots up. this is done to be sure that other services are started right before kodi.
I feel like there are much better ways to accomplish this, on linux at least.
(2015-02-11, 19:09)lrusak Wrote: [ -> ] (2015-02-11, 18:49)xhaggi Wrote: [ -> ]-d <delay> is used by some of my friends to delay the startup after system boots up. this is done to be sure that other services are started right before kodi.
I feel like there are much better ways to accomplish this, on linux at least.
So yeah, too me it feels unnecessary too. Would love to hear what they are waiting for though, perhaps we are missing something? Or is it network?
mostly network. This can be done much cleaner in upstart/systemd
(2015-02-12, 13:25)wsnipex Wrote: [ -> ]mostly network. This can be done much cleaner in upstart/systemd
or in Kodi itself on startup
Similar option is also available on Windows and there we don't have systemd or startup.
wait till network is ready when you use some networking stuff and show on splash that it is waiting till network is up and press key to skip.
(2015-02-12, 13:27)Martijn Wrote: [ -> ]or in Kodi itself on startup
Similar option is also available on Windows and there we don't have systemd or startup.
wait till network is ready when you use some networking stuff and show on splash that it is waiting till network is up and press key to skip.
Hmm, I have had a patch for reacting on network like 15 times now it feels like
Keep forgetting to merge it due to some random reason
Perhaps I should dust it off once more
only want to let you know that it is used. but sure it is not necessary as we can do it outside kodi.
(2015-02-10, 11:33)Montellese Wrote: [ -> ]fullscreen and portable are certainly used. No idea about the rest.
BTW, fullscreen? On Linux we default to fullscreen, isn't this the same on windows? Just wondered why its used?
Feels like windowed is more of a developer thing no? Perhaps we should twist the setting? --window ?
we default to full screen, but once you set it windowed, it stays like that over restarts. I use that all the time on my desktop to watch TV or listen to music.
So a -fs makes sense to override that