[seniorivn]

in the kodi source code https://github.com/xbmc/xbmc/blob/0978b1...c.cpp#L575
it is an Android specific  hardcoded function. Would be nice if on platforms other than android it would call some other function that would rely on addons functionality to do actual voice input.

[lbdroid]

in the kodi source code https://github.com/xbmc/xbmc/blob/0978b1...c.cpp#L575
it is an Android specific  hardcoded function. Would be nice if on platforms other than android it would call some other function that would rely on addons functionality to do actual voice input.

Probably because voice recognition is an Android feature that they're leveraging, rather than creating an implementation of voice recognition.

[seniorivn]

in the kodi source code https://github.com/xbmc/xbmc/blob/0978b1...c.cpp#L575
it is an Android specific  hardcoded function. Would be nice if on platforms other than android it would call some other function that would rely on addons functionality to do actual voice input.

Probably because voice recognition is an Android feature that they're leveraging, rather than creating an implementation of voice recognition. 

I understand that they use android speech recognition apis in that part of code.
My proposal isn't about android, it's about expanding this feature on other platforms by creating simple api for addons to implement.

There are tons' of options for speech recognition out there, the only  reason it's not available in kodi is a lack of flexibility of kodi as a platform.

[Karellen]

the only  reason it's not available in kodi is a lack of flexibility of kodi as a platform.

Well, I don't know how accurate that statement is. Dont forget time, manpower, knowledge, interest, willingness and expertise that are all required by the volunteer project.

[seniorivn]

the only  reason it's not available in kodi is a lack of flexibility of kodi as a platform.

Well, I don't know how accurate that statement is. Dont forget time, manpower, knowledge, interest, willingness and expertise that are all required by the volunteer project. 

Well, all those reasons you mention are the reasons why kodi is in that state(considering all of these it's unbelivably good) But it is frustrating to face it when kodi lacks some features and the only way to fix it is forking and patching

[Karellen]

But it is frustrating to face it when kodi lacks some features and the only way to fix it is forking and patching

And maybe that is "why kodi is in that state". Instead of contributing upstream and improving, many of these forks won't share their work.

[lbdroid]

the only  reason it's not available in kodi is a lack of flexibility of kodi as a platform.

Well, I don't know how accurate that statement is. Dont forget time, manpower, knowledge, interest, willingness and expertise that are all required by the volunteer project.  

Well, all those reasons you mention are the reasons why kodi is in that state(considering all of these it's unbelivably good) But it is frustrating to face it when kodi lacks some features and the only way to fix it is forking and patching 

I'm not sure how to take that statement. If feels like you're trying to attack, but the information you present is actually something extremely positive.
Imagine trying to fork and patch windows media player!
So right off the bat, the fact that this is even possible is an ENORMOUS advantage.

You probably should also learn that forks are NOT all dead ends. Some of the more impressive (major) forks, like MrMC and the now defunct SPMC, DO feed back into Kodi proper.

There are, of course, a number of kinds of forks that do NOT feed back;
-- pirate forks,
-- amateur hour,
-- ill-advised hacks.

And on top of that, the very use of git means that ALL or nearly all contributions MUST be sourced from forks, by very definition.
As an individual developer, you create your personal fork, you work on your fork, adding commits, you submit your commits upstream to be included in the base.


Now here is the thing. Obviously, people who contribute to Kodi HAVE considered voice input, which is pretty clear based on the availability under Android. But like I said, Kodi did not implement the voice recognition functionality, rather they just leveraged what was already available in Android. And while you may be right that there are voice input libraries or services available on other platforms, NONE of them are as ubiquitous as voice input is on Android. It isn't nearly as simple as saying "it can be done" -- there are significant technical hurdles in the way of getting there.

So here is an idea for you;
Instead of complaining about the Kodi platform being overly rigid, how about you come up with a well developed concept on how this can be implemented in a universal and well organized manner. Or how about you take the initiative by forking Kodi, and starting work on this feature. If you were to take this approach, I'd advise maintaining close communication with the lead Kodi developers throughout the project to make sure you are working it in a direction that is consistent with the goals and code quality requirements.

[davilla]

Sharing the source code is not the issue. The source code of forks is there, waiting for someone to backport it. 

Most forks will not "contribute upstream" because the process of doing PR's into kodi source is quite painful. PR reviews turn into bike shedding and nits about code cosmetics and the focus of intent becomes completely lost.  Speaking for MrMC, we refuse to be involved in doing PR's for Kodi. Tried that before, turned into a complete waste of time and frustration. We have better things to do than fight over which side the '*' goes or if an 'ifdef' should die in a fire.

[seniorivn]

oh my god, guys either i'm realy bad at expressing my self in general, or it's just my pure english, but i'm not trying to attack anyone or anything, especially kodi as a project. It was supposed to be feature request/proposal. That's it.

Can we get back on track? Is there anyone working on that part of the project here?
I'm not sure i have enough time/motivation to code this fix without any guidance(since i know nothing about kodi internals).

[lbdroid]

oh my god, guys either i'm realy bad at expressing my self in general, or it's just my pure english, but i'm not trying to attack anyone or anything, especially kodi as a project. It was supposed to be feature request/proposal. That's it.

Can we get back on track? Is there anyone working on that part of the project here?
I'm not sure i have enough time/motivation to code this fix without any guidance(since i know nothing about kodi internals).

I'd be happy to help you with general questions, although I too, have limited knowledge of the inner workings of kodi.
You probably want to start off by figuring out how to convince it to compile.

[seniorivn]

oh my god, guys either i'm realy bad at expressing my self in general, or it's just my pure english, but i'm not trying to attack anyone or anything, especially kodi as a project. It was supposed to be feature request/proposal. That's it.

Can we get back on track? Is there anyone working on that part of the project here?
I'm not sure i have enough time/motivation to code this fix without any guidance(since i know nothing about kodi internals).

You probably want to start off by figuring out how to convince it to compile. 

this is really funny
Luckily there is a simple way to achive that, just use pkgbuild/ebuild as a cheat sheet

I'd be happy to help you with general questions, although I too, have limited knowledge of the inner workings of kodi.
 

My main question would be something like: could you point me on a function that could be called inside that function that triggered on mic button and etc, and this function would send a signal that any plugin could implement a handler for. That way creating voice input with python-speechrecognition package would be as simple as it can be.
Also it probably should send current virtual keyboard language/layout

[Karellen]

oh my god, guys either i'm realy bad at expressing my self in general, or it's just my pure english

No, not at all. I think you are just misinterpreting the tone. We are not attacking you in any way, we are just making statements in response to your statements. Thats all.

[seniorivn]

oh my god, guys either i'm realy bad at expressing my self in general, or it's just my pure english

No, not at all. I think you are just misinterpreting the tone. We are not attacking you in any way, we are just making statements in response to your statements. Thats all. 

that's not about your tone, that's about the focus of your reaction, instead of focusing on the feature request you discuss my additional thoughts,  and it is probably because my tone was considered attacking and etc. The reaction was not how i expected it to be, and i don't like it, since i don't feel that en english my understanding of "why?" is 100%.

Anyway less bullshit, more productive conversations.

[lbdroid]

oh my god, guys either i'm realy bad at expressing my self in general, or it's just my pure english

No, not at all. I think you are just misinterpreting the tone. We are not attacking you in any way, we are just making statements in response to your statements. Thats all.  

that's not about your tone, that's about the focus of your reaction, instead of focusing on the feature request you discuss my additional thoughts,  and it is probably because my tone was considered attacking and etc. The reaction was not how i expected it to be, and i don't like it, since i don't feel that en english my understanding of "why?" is 100%.

Anyway less bullshit, more productive conversations. 

Well I can't speak for everyone, but I never considered your "tone" to be at all attacking.

"Other thoughts" are always very important in a feature request. Its never as simple as just "implement this". There are a lot of details and planning that go into things. Thoughts about how to do it the best way possible. Thoughts about how to do it as efficiently as possible. Thoughts about how to do something in a way that is future proof and easy to maintain. And believe it or not, but discussing these details are probably the biggest part of getting a new feature implemented -- the coding itself is usually fairly minor, so the more of these details we can figure out in a well organized manner now, then even if you or I don't actually contribute code to the project, the easier it ultimately becomes for someone else to implement the feature and the closer we end up being to satisfying your feature request.

Make sense?