[ronbaby]

I've only been fiddling with XBMC, and only a little, as time permits, for just two or three weeks now. I'm still trying to get a handle on the whole thing, and doing my best to understand the thing, based on what seems to be... well... less than optimal documentation (e.g. in the wiki).

I'm not at all sure that I have properly grasped the structure of XBMC, so I need to ask what amounts to rather a basic question. But first let me give a bit of background...

I gravitated to XBMC in the first place because I was led to believe that it was/is "highly customizable". (I assumed that this meant that it could be customized to a great extent _without_ actually dredging into the C++ source code. Not that I really mind all that much dredging into C++ source code, but, you know, a requirement for C++ hacking skills is not normally something that I personally tend to associate with products being touted to the general public at large as "highly customizable.")

So anyway, I'm now wondering to what extent that characterization... of XBMC as being "highly customizable"... really gives a newcomer an accurate impression of the thing.

I'm just going to throw out a rather trivial example, and see if maybe someone here will (I actually hope) show me how my current impression is wrong, and how XBMC is indeed "highly customizable" after all.

OK, silly example: Let's say that I want to customize my copy of xbmc+Confluence so that whenever I am looking at a photograph, if I hit the "5" key on my keyboard, the effect will be for the display of the current still picture to be removed from the screen and replaced instead by a display of the preceding .JPG file in the current directory (if any).

Simple enough, right?

Can this "customization" be done by any Joe Schmo off the street _without_ him having to learn C++ first?

Can this customization be effected merely and exclusively by fiddling relevant .xml files, and without ever touching any C++ source file?

My initial impression is that the answer is "no", and I'll explain why...

I am looking at the source for the following function:

bool CGUIWindowSlideShow::OnAction(const CAction &action)

which exists within a file called xbmc-11.0/xbmc/pictures/GUIWindowSlideShow.cpp

and am getting the general impression from the body of this function that action bindings for specific keys are in fact rather entirely hardwired, and not readily amenable to ordinary end-luser fiddling/rebinding (short of hacking this specific C++ source file, that is).

Is that a correct impression on my part? Or have I gotten it all wrong?

[Martijn]

wiki.xbmc.org/index.php?title=Keyboard.xml

You are looking too much through the eyes of a programmer instead of user

[Hitcher]

You simply change the keymap.xml to use '5' instead of right arrow.

[amet]

I've only been fiddling with XBMC, and only a little, as time permits, for just two or three weeks now. I'm still trying to get a handle on the whole thing, and doing my best to understand the thing, based on what seems to be... well... less than optimal documentation (e.g. in the wiki).

I'm not at all sure that I have properly grasped the structure of XBMC, so I need to ask what amounts to rather a basic question. But first let me give a bit of background...

I gravitated to XBMC in the first place because I was led to believe that it was/is "highly customizable". (I assumed that this meant that it could be customized to a great extent _without_ actually dredging into the C++ source code. Not that I really mind all that much dredging into C++ source code, but, you know, a requirement for C++ hacking skills is not normally something that I personally tend to associate with products being touted to the general public at large as "highly customizable.")

So anyway, I'm now wondering to what extent that characterization... of XBMC as being "highly customizable"... really gives a newcomer an accurate impression of the thing.

I'm just going to throw out a rather trivial example, and see if maybe someone here will (I actually hope) show me how my current impression is wrong, and how XBMC is indeed "highly customizable" after all.

OK, silly example: Let's say that I want to customize my copy of xbmc+Confluence so that whenever I am looking at a photograph, if I hit the "5" key on my keyboard, the effect will be for the display of the current still picture to be removed from the screen and replaced instead by a display of the preceding .JPG file in the current directory (if any).

Simple enough, right?

very

Can this "customization" be done by any Joe Schmo off the street _without_ him having to learn C++ first?

yes

Can this customization be effected merely and exclusively by fiddling relevant .xml files, and without ever touching any C++ source file?

yes

My initial impression is that the answer is "no", and I'll explain why...

I am looking at the source for the following function:

bool CGUIWindowSlideShow::OnAction(const CAction &action)

which exists within a file called xbmc-11.0/xbmc/pictures/GUIWindowSlideShow.cpp

and am getting the general impression from the body of this function that action bindings for specific keys are in fact rather entirely hardwired, and not readily amenable to ordinary end-luser fiddling/rebinding (short of hacking this specific C++ source file, that is).

nope, you do it in keymaps

Is that a correct impression on my part? Or have I gotten it all wrong?

no, yes

look at http://wiki.xbmc.org/index.php?title=Keyboard.xml, that will show you how to map different keyboard keys to a relevant xbmc functions. you can simply map the "next" function under Pictures

Code:

<MyPictures>
    <keyboard>
      <delete>Delete</delete>
      <numpadfive>Right</numpadfive>
    </keyboard>
  </MyPictures>

<numpadfive>Right</numpadfive> will mimic what arrow right does once you are in picture viewer screen... as you see, sky is the limit(or maybe a little lower)

[HenryFord]

To tackle your original question: Yes, XBMC is highly customizable. This starts with you being able to completely map your keys to whatever you want them to do and ends in the wider variety of Add-Ons and Skins (which are customizations after all).
All in all you can do a whole lot with XBMC without even knowing the language it is written in.

Edit:
Argh - amet beat me to it.

[ronbaby]

I sincerely thank all of you who replied. As should be obvious, I am still on the very steep early part of the learning curve when it comes to xbmc, but I do hope to be able to repay the kindness you've all shown me by making useful contributions to the project at some point in the future, after I've mastered the basics and when I know my way around.

Something else should also be obvious, and perhaps could go without saying, but Ill say it anyway... I am certainly most pleased and relieved to know that in fact, my impression was wrong, and that xbmc does in fact, and apparently, live up to its reputation for customizability, as illustrated quite clearly in amet's response to my original posting. That having been said however, the responses so far, and in particular amet's, are in some ways as troubling as they are encouraging and enlightening. Allow me to explain.

amet wrote:

Code:

<MyPictures>
    <keyboard>
      <delete>Delete</delete>
      <numpadfive>Right</numpadfive>
    </keyboard>
  </MyPictures>

Certainly, nothing could be more clear. Amet has been kind enough to show me the exact code to achieve the exact result I had had asked for, and for me this answer is indeed quite enlightening. In one simple example it shows me the basic/general motif that's used within xbmc to achieve certain effects for certain inputs within certain contexts. I infer from this that this general motif could be abstractly expressed as follows:

Code:

<PrimaryGUIContextName>
      <InputDeviceName>
          <InputSignalName>ActionName</InputSignalName>
    </InputDeviceName>
</PrimaryGUIContextName>

Assuming that this general motif holds, and that it exemplifies that Right Way to connect pretty much any specific input to any specific action in any specific context, then it would seem that the only other other things that I will need in order to become an all-powerful xbmc customizer are:

1) A comprehensive list of all valid PrimaryGUIContextNames
2) A comprehensive list of all valid InputDeviceNames
3) A comprehensive list of all valid InputSignalNames
4) A comprehensive list of all valid ActionNames

Even before I posted yesterday, just by stumbling around (and with the help of Google) I was able to find for myself item #4 in the list above right here: http://wiki.xbmc.org/index.php?title=Action_IDs. Obviously, it is indispensable (especially to any budding customizer) to have access to the reference material on that page, and thus, I am damn glad that someone put that page up. That having been said however, I am not persuaded that the actual effects of invoking each of the actions mentioned on that page, in each of xbmc's various possible contexts, is made clear by the simple listing appearing on that page. Just as a trivial example, as I have just now learned, when I am looking at a list of subdirectory names under "Pictures" (in Confluence) pressing the -> key (direction pad right) on my keyboard causes the Confluence view options to come out of hiding, whereas pressing the <- key, counterintutively, has no effect whatsoever. In short, just saying that "left" means "left" and "right" means "right", as the aforementioned page does, is, I would say, somewhat less than all that might be needed for newcomers and experienced xbmc'ers alike to fully grok the actual (and quite obviously context-dependent) semantics of even a simple "left" action, let alone all of the other standard built-in symbolic action names known to xbmc.

But let's set that issue aside for now.

Curiously, right near top of the page describing xbmc's built-in action primitives, there is a link to a different page containing a
List of built-in functions. Obviously, somebody somewhere thinks that this second group of built-in action primitives is, in some important way, different from the first group, but I've yet to see where the material differences, if any, are either enumerated or explained. (But perhaps I just missed it and perhaps someone will be kind enough to point it out to me.)

Before I leave the subject of actions to move on to the other three categories of symbolic names I've mentioned in my list above, I do have just a couple more noob questions about the coding of actions.

My (naive?) assumption, based on the handful of examples I've seen so far is that the action portions of xbmc's various .xml files are always simple, and that there is no general purpose programming language hiding here. Please do correct me if I'm wrong, but I assume that there are no do/while loops or if/then/elses or the like within the action portions of the .xml files, right? Even assuming that this is the case, I would still be inclined to wonder whether or not multiple actions may be simply composed together, for example:

Code:

<InputSignalName>Action1,Action2,...</InputSignalName>

The only other question I might have relating to the coding of actions is whether there is any significance to whitespace. Certainly, within all of the small handful of examples I've seen so far, there seems to have been care taken to insure that no extraneous whitespace appears within the body of the <InputSignalName></InputSignalName> tags, but I'd like to know if that is only by tradition, or if there's something that will in fact go wrong if extraneous whitespace appears within the bodies of these tags.

Returning to my list of four categories of symbol names (above), with regards to #3 (Input Signal Names) I will say that I had a little bit of trouble yesterday finding a comprehensive list of these... because I apparently was googling improperly... but today I've managed to find my way to this page where at least most of what I'm looking for seems to be present. What isn't clear to me is where I would go to find analogous pages that would list the xbmc standard symbolic names for inputs coming in not from keyboards but instead from mice, on the one hand, and remote controls on the other hand. If someone could point me to such pages, that would be greatly appreciated. Once I have all three in hand, I'll certainly feel that I have a complete list of all of xbmc's standard symbolic input names. (Oh! I almost forgot to ask about key combinations. In the list of symbolic key names on the page I just linked to I'm not seeing any symbolic name for, for example, Cntl-Alt-F1, however I'm certain that I could think of a useful action to bind that specific key combination to. But when I want to implement such a binding, what symbolic name should I use for the key combination? Are key combinations like this all coded using the <key id="xxx">Action</key> form mentioned at the top of the page? Are all possible or plausible key combinations codable as a single key code number?)

As regards to symbolic name category #2 from my list above, where would I find a list of xbmc's standard symbolic input device names? Thanks to amet, I now know that "keyboard" is one of these, but I feel sure there are others, and since my own true desire is to add customizations that primarily or exclusively will be accessed via a multi-button mouse, I most assuredly want to know what xbmc's standard symbolic name for mouse-type devices is. (Could it be something as obvious as "mouse"?)

Finally, regarding symbolic name category #1 from my list above, where would I find the comprehensive list of all symbolic names for all GUI contexts? I want to be clear. Coming at this whole thing (xmbc) as I have, cold, and with no prior knowledge of any of this stuff, I can assure everyone most solemnly that I would never (and could never) have guessed, apriori, that the symbol "MyPictures" would have any special significance to or within xbmc. (Perhaps this is just an artifact of the fact that I'm not fundamentally a Windows guy. For more than 30 years, Windows has been something that I've only just barely tolerated, and only on those rare occasions when it has been inescapably necessary to do so. Whereas the unadorned word "pictures" may, for most Windows users, implicitly conjure up the symbolic name "MyPictures", it most certainly doesn't immediately do that in my case.)

In closing let me just say thanks again, and in advance, to all who have been (and who hopefully yet will be) kind enough to enlighten me on the matters discussed herein. I say again that I do hope to repay all kindness shown me, in the future, by becoming a useful contributor to the project at some point, and not just (as I am now) a noob with a seemingly endless list of (silly?) questions.

[jmarshall]

Could you please summarise all that into a set of numbered questions that are no more than a sentence?

[ronbaby]

Could you please summarise all that into a set of numbered questions that are no more than a sentence?

By all means, if that will make it easier. (I'm not sure why you want them numbered. Is there a daily quota for silly questions form noobs? If so, have I just exceeded it? Or is that that what we are about to find out? :-)


1) What are the actual semantics of each of the actions listed on this page in all contexts? (I do understand that a full and complete answer to this question may perhaps requite the writing of a massive ten volume set of reference books... a ten volume set which has not yet been written... so it's perfectly OK if you don't even try to supply a full answer to this one, and in fact I would suggest that you don't. But if you have any brief response which you think might be helpful to my general understanding, then that would be appreciated.)

2) What are all of the differences between actions and built-in functions? (In what way or ways are these things distinct and different?)

3) May (or do) any of the various .xml files which XBMC reads and interprets contain any sort of thing that those familiar with ordinary imperative general-purpose programming languages would refer to as "control structures" or "flow of control structures" (e.g. do/while, if/then/else/fi, and so on and so forth) ?

4) In those places within the various .xml files that XBMC reads and interprets where the symbolic name of an action primitive may appear, may more than one symbolic name of an action primitive be written?

5) If the answer to (4) above is "yes" then what is the correct syntax for writing sequences of multiple action primitives in such contexts?

6) In those places within the various .xml files that XBMC reads and interprets where the symbolic name of an action primitive may appear, is whitespace significant in any way? (And if it is in fact significant, then exactly how is it significant?)

7) Where may I find a list of XBMC's standard symbolic names for all of the various kinds of specific inputs which may be generated by (or from) mice?

8) Where may I find a list of XBMC's standard symbolic names for all of the various kinds of specific inputs which may be generated by (or from) remote controls?

9) Within the various .xml files that XBMC reads and interprets, how does one symbolically name keyboard combinations (e.g. CNTL-ALT-F1) ?

10) Where may I find a list of all of XBMC's standard symbolic names for all of the various kinds of input devices that XBMC may receive input from?

11) Where may I find a list of all of XBMC's standard symbolic names for all of the various specific GUI contexts to which input->action bindings might be applied?


That's it for now. Have I exceed my daily quota? :-)

[jmarshall]

Short answer to most questions: Check ButtonTranslator.cpp/Key.h.

1. The code holds the key to this. Generally, the only place actions are actioned are where it makes sense - i.e. they do what makes sense in the context in which you're in. e.g. Play whilst on a file will generally play the file. Play whilst in fullscreen will revert to playing from a ffwd/rewd/paused state. The actual list of actions is in Key.h and the translator for everything is ButtonTranslator.cpp.

2. Built-ins are global functions that are typically more elaborate in that they can take parameters. Built-ins are typically actioned at the app level, whereas actions may be actioned at the control, group, window, or app level, as they're context-aware.

3. Skins can do if/else (though not elegantly), and Python can do whatever you like. Typically you'd use the latter in this context should that be necessary (i.e. run a script from a keypress that does whatever it is you want to do).

4. Not in keymap files, no. You could do it from a script, however. Skins can do it (i.e. you can have multiple <onclick> actions in a control.

5. You do it from a script.

6. Whitespace will generally be stripped prior to interpreting things. There are a few exceptions to this, particularly within a skin, but nothing that applies to keymap editing.

7. Key.h

8. Key.h, plus some interaction from the LIRC stuff (see ButtonTranslator.cpp). IIRC you setup LIRC to map LIRC buttons to XBMC buttons. The remote.xml file(s) then take XBMC buttons to XBMC actions. It's rather convoluted in this case - cleanups welcome.

9. Using attributes - keyboard.xml should have examples. Attribute names can be found in ButtonTranslator.cpp

10. ButtonTranslator.cpp details this.

11. They're currently window-based. So <global> then overridden in <windowname>. Window names are specified again in ButtonTranslator.cpp.

[Dilligaf]

The simple answer for the non programmer is there is a complete functioning Keyboard.xml to start with and edit to your liking. Most functions can be deduced from this.

[ronbaby]

The simple answer for the non programmer is there is a complete functioning Keyboard.xml to start with and edit to your liking. Most functions can be deduced from this.

Perhaps my only real problem then is that I am actually a programmer. :-)

In truth, I do believe that I am spoiled, in the sense that I'm rather accustomed to studying languages where there is a single comprehensive reference document that spells out in some detail the entire syntax, semantics, and vocabulary of the language that I'm trying to learn.

As far as syntax, yes, quite certainly any non-retarded self-respecting baboon could most likely get a pretty good sense of the syntax of XML, just from glancing at the various examples available already in the XBMC wiki, if not also from the numerous other available online sources describing XML. After all, the syntax of XML is just not that complex. That leaves only semantics and vocabulary. As regards to vocabulary, the ``reference'' in this case, as jmarshall has been kind enough to elucidate, is at present somewhat scattered. There's much material documenting symbolic actions names and symbolic key names in the wiki pages that I already referenced in this thread, which is a Good Thing. But other categories of names are not at present documented in the wiki and must instead be learned by perusing relevant C++ source files. And the actual semantics for many/most/all of the symbolic action names that are pre-defined by XBMC are at best only lightly touched on within the wiki. Leaving both novice and old hand alike to either intuit meaning, or learn the action semantics by experimentation (i.e. running XBMC and just sort-of trying things), or else, again, by dredging into the C++ source code... an endeavor which may or may not be enlightening, even for those who do speak that language.

My hope is that the foregoing will not be interpreted as a ``complaint'' per se, but rather as a mere unemotional observation that the documentation currently available in the wiki could be improved. I feel the need to emphasize that I most certainly did not show up here only to whine and complain (nor even to unintentionally appear to do so), and thus, to forestall any possible perception that I'm just a whiner, and also as a gesture of gratitude for the kindness and help that have been given to me here in these fora so far I would like to volunteer to work on improving the wiki (and on eliminating the very shortcomings I've noted) if the XBMC powers that be will have me that is, and if I'm not judged to be still too ignorant for my contribution to have any value.

So, um, where do I file my application to become a wiki contributing editor? I feel like I've learned a lot, even just from this present exchange, and I'd like to contribute something back by adding what I've learned (and what I can deduce from what has just been taught to me) to the wiki for the benefit of any and all future aspiring XBMC customizers who, like me, might suffer from the sad and unfortunately widespread affliction known as "programmer".

Now that I got that out of the way...

I want to say also that I'm already quite sure that I will have (and do have) other and additional questions (for jmarshall or whomever) about the answers jmarshall has provided to my specific questions... several of which I'm quite sure I do not fully understand (in particular the answers to #1, #2, #3 and #11)... and additional questions also (e.g. about the location where all of the other tags that I've noticed inside of XBMC's various .xml files are documented)... but I'm not going to ask any of those questions just yet. I need some time to digest and study what jmarshall has already given me before I come back for a second helping.

There is one question that my burning curiosity will not allow me to delay however, and although it may at first appear so, this question is not entirely unrelated to the other questions I've been asking...

I've seen what I believe you folks call the On Screen Display that comes up whenever I nudge my mouse while playing any kind of video. It's beautiful. No doubt about it. In fact it is so beautiful that I have been thinking how lovely it would be to have a very similar sort of thing also available (with a very similar sort of look, and invoked in an identical sort of way) whenever one is viewing a still photograph using XBMC. (Obviously, one does not rewind, fast-forward, pause, or adjust the audio on a still photograph, but there are numerous other kinds of controls that I can easily imagine that would be applicable to stills. And I suspect that most folks here are imaginative enough so that the rest of you could also imagine some things that might be Nice to be able to do to still photos as XBMC is displaying them, full-screen.)

So my question is just this: How hard (or how easy) would it be to implement something like this, i.e. an OSD-like pop-up thingy for the "Photos" context? Does the XML-based configurability of XBMC extend so far as to allow even this sort of thing to be added without any fiddling to the core C++ code? (If not, that would be OK, but if so, then I will be even more impressed by the configurability of XBMC than I already am. And of course, if the response is that somebody else has already implemented such a thing, in one skin or another, then I reserve the right to be utterly blow away, and will immediately beg to know which skin I can find this in.)

[jjd-uk]

For ordinary users the wiki contains most of the required information at:

http://wiki.xbmc.org/index.php?title=Keyboard
http://wiki.xbmc.org/index.php?title=Lis..._functions
http://wiki.xbmc.org/index.php?title=Ope...nd_Dialogs
http://wiki.xbmc.org/index.php?title=Action_IDs
http://wiki.xbmc.org/index.php?title=Lis...C_keynames

[da-anda]

and here is some docu about the window names and actions: http://wiki.xbmc.org/index.php?title=Keymap

[Memphiz]

Man you really talk to much - keep it short - not all people are able to spent that much time on one thread... :p

[ronbaby]

Man you really talk to much - keep it short ...

Sorry. I have been frequently misunderstood, so nowadays I prefer clarity over brevity.

Boiling down my last message, it just comes down to this:

1) Who do I talk to if I want to volunteer to help with the wiki?

2) On a scale from 1 to 10, how hard would it be to implement an OSD-like thing for "Pictures", and could it be done strictly and only by diddling .xml files?