[Martijn]

1. just register to the wiki. anyone can help improving or adding what is missing

[amet]

1. NedScott

2. 2, I think yes

[ronbaby]

just register to the wiki. anyone can help...

OK. Thanks. I had already registered, actually, but then I looked around for a "edit" button/link/tab/whatever and didn't see one. But apparently that was only for the main page. I do see an "Edit" think on most other pages.

[jmarshall]

When editing the wiki, please remember that brevity and clarity are not mutually exclusive.

[ronbaby]

Yes.

[Ned Scott]

Funny enough, just yesterday I started to update and reorganize the keymap related pages. They haven't really been touched in years, and everything is a bit all over the place. Feel free to contribute what you can.

[ronie]

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?

assuming you want to display some exif information on the osd,
it would require c++ changes in core.

currently the picture related infolabels are not hooked up to the slideshow window.

[jjd-uk]

Funny enough, just yesterday I started to update and reorganize the keymap related pages. They haven't really been touched in years, and everything is a bit all over the place. Feel free to contribute what you can.

Strange as those pages have been changed since the release of Eden, there used to be separate pages for each of the keyboard.xml sections of Global, Videos, Music, & Picutres and although I can't be 100% sure I think some detail has been lost. See Post #600 I did here http://forum.xbmc.org/showthread.php?tid...#pid942801 with links to the old pages that now simply redirect to the current Keyboard page.

[Ned Scott]

Funny enough, just yesterday I started to update and reorganize the keymap related pages. They haven't really been touched in years, and everything is a bit all over the place. Feel free to contribute what you can.

Strange as those pages have been changed since the release of Eden, there used to be separate pages for each of the keyboard.xml sections of Global, Videos, Music, & Picutres and although I can't be 100% sure I think some detail has been lost. See Post #600 I did here http://forum.xbmc.org/showthread.php?tid...#pid942801 with links to the old pages that now simply redirect to the current Keyboard page.

Those are pages that describe the default keyboard.xml keymap, and yeah, I updated that a while back. It should all be there, but placed in a table with three columns (global, video, music) and a pictures section instead of four pages.

Looking at the old versions of the pages, the only lost content seems to be the Now Playing keymappings (delete, up, down, etc), which I'll add to the new page now.

You can see the previous versions here:
http://wiki.xbmc.org/index.php?title=Key...on=history
http://wiki.xbmc.org/index.php?title=Key...on=history
http://wiki.xbmc.org/index.php?title=Key...on=history
http://wiki.xbmc.org/index.php?title=Key...on=history <--Previously was the Global page

[ronbaby]

assuming you want to display some exif information on the osd,
it would require c++ changes in core.

Well, yea, display of EXIF info (including even proper human-readable representation of longitude/latitude coordinates, such as my Lumix DMC-ZS7 is alleged to be able to tag pictures with) would sure be nice, but actually, I have some even much more grandiose ideas in mind, many/most of which are probably going to take more effort that I'll ever have time for.

I'll tell you all what I have in mind and then you can tell me which ones are impractical without core C++ changes... not that that really makes any big difference... I'm more comfortable with C++ than I am with XML. But first, before I lose the impatient readers, I have a couple more quick questions:

1) I read that (supposedly) if I already have something called skin.foo in my ~/.xbmc/addons directory, then I can (allegedly) just make a copy of that (for hacking purposes, so as not to disturb the original) by just cd'ing into my ~/.xbmc/addons directory and then doing something like:

Code:

cp -R skin.foo skin.foo2

Well, I tried that and then started up xbmc again with the hope that it would now present me with a new "foo2" skin choice, but it didn't. It was as if nothing had changed. So what did I do wrong? Is there some specific file I have to diddle in order to "register" the existence of my new "foo2" skin?

2) I happen to have a Logitech M305 mouse. This is one of many models (from Logitech and other manufacturers) that has a scroll wheel in the middle that can be pressed down (middle button) or else which can also be tilted either left or right. I would like to bind some actions to those two specific mouse actions in my personal experimental skin (scrollleft/scrollright). Can someone give me a clue how to do this? I haven't had much time since my last post to really bear down into the available documentation, but when I did glance at some of it I saw no mention of "scroll left" and/or "scroll right" input actions (but really, a lot of mice these days have these possible actions).

So anyway, about what I have in mind for a "Pictures" OSD...

Well, think of all of the things you might possibly like to do to the pictures you took on your last vacation (or your last dinner party or whatever) while viewing them, e.g. on your big screen TeeVee. Perhaps it is because once, long ago, I was (briefly) a professional photographer, but immediately, all of these things come to mind:

*) rotate 90' left
*) rotate 90; right
*) rotate 180'
*) for extra credit... rotate at arbitrary angles
*) zoom in/out... but not with keyboard commands (1,2,3...0), just with mouse commands{*}
*) when zoomed in, shift picture left, right, up or down, but again, only with mouse commands (drag & drop?)
*) have on the OSD some mouse-usable sliders that would allow adjustment of (1) brightness (2) contrast (3) hue (4) saturation

For many of the above effects (except zoom in/out and shift visible part of the current picture) there could be / should be also a button on the OSD that would allow changes made to the picture to be saved back to disk and/or to have them stashed somewhere so that they don't really affect the existing JPEG/GIF/whatever file, but instead are just saved so that the next time you fire up XBMC, when it displays that same JPEG/GIF/whatever file for you next time, it will first apply all the same adjustments, e.g. brightness, contrast, hue, saturation, rotation. (The per-picture adjustments could be saved in a separate file or else perhaps stashed somehow into the EXIF info in a way that doesn't harm anything else.) And since, when taking pictures in a given setting, it is often true that all pictures in a group will have similarly messed up contrast, brightness, hue, or saturation, it would also be nice to have a button (in the Pictures OSD) that would apply any of those kinds of changes that the user had made to the current picture also to (a) all pictures in the current directory or else (b) all pictures in the current directory with the same date stamp as the current one.

I also have in mind one more enhancement for "Pictures" that would not (probably) involve an OSD. Basically, if you have a new-ish digital camera, then you might already have this feature in your camera.

For some modern digital camera models, when you are viewing photos you have taken on the camera's LCD, if you push the zoom-out lever (once) you will see on the LCD a matrix of four (2x2) pictures that all come from the sequence right around the one that you were looking at. Then, if you press zoom-out again, you'll then be looking at a matrix of nine (3x3) pictures from the sequence, and then push again and you'll see a matrix of sixteen (4x4). So anyway, it would be Nice to have this kind of effect available too. (Thumbnails listing format is Nice, but not quite as nice as what I just described.)

Note that I am not suggesting to include the kitchen sink. I certainly would think that it would be dramatic overkill to incorporate all of the features of, say, either gimp or else ImageMagick when it comes to their vast abilities to manipulate images. But goof ups, large or small, of rotation, contrast, brightness, hue, and saturation are just very very common problems for virtually every amateur photographer, so it seems reasonable to include an OSD for Pictures that would allow the user to easily adjust these things on the fly, mostly with intuitively obvious slider-type controls.

{*} Just one last comment about mice... I went and bought one of those MCE compatible remote controls. It was basically this one:

http://www.newegg.com/Product/Product.as...6823166095

Then, I sat back on my couch and tried to use it with XBMC. After about five minutes I gave up in disgust and went and got my mouse and I've been using that instead ever since, even from my couch, to control XBMC. The remote was just too annoyingly slow whenever I wanted to just simply move the ``mouse'' cursor from one place to another on the screen. This was true despite the fact that this remote has a little round pad in the center which is supposed to be a nice of substitute for a tiny touch-pad type thing.

Anyway, the bottom line is that everything that I personally might get around to implementing in the way of new xbmc features would be (will be) all 100% mouse-oriented. I'm 100% convinced that using remotes to control XBMC is for the birds, and likewise, I don't think that I should ever need (and it does not seem that I will ever need) a keyboard sitting next to me on the couch. Why would I? Whenever xbmc needs some actual string typed in, it seems to pop up a little data entry thingy which allows selection of letters/numbers/symbols using only a mouse. So except for one annoying case of zoom-in/zoom-out on pictures (which I hope to rectify soon), I have yet to find a single thing on xbmc that I could not do with just a mouse (and often do better with just a mouse).

[ronie]

1) I read that (supposedly) if I already have something called skin.foo in my ~/.xbmc/addons directory, then I can (allegedly) just make a copy of that (for hacking purposes, so as not to disturb the original) by just cd'ing into my ~/.xbmc/addons directory and then doing something like:

Code:

cp -R skin.foo skin.foo2

Well, I tried that and then started up xbmc again with the hope that it would now present me with a new "foo2" skin choice, but it didn't. It was as if nothing had changed. So what did I do wrong? Is there some specific file I have to diddle in order to "register" the existence of my new "foo2" skin?

you also need to change the addon 'id' and 'name' in addon.xml

[amet]

2) I happen to have a Logitech M305 mouse.....

XBMC is primarily designed with remote control in mind, think about all those functions on 6 button remote

[ronbaby]

XBMC is primarily designed with remote control in mind, think about all those functions on 6 button remote

I accept that, but I can't think of any reason why XBMC should be limited to only working properly with an actual remote. And in fact, as I have said, it seems to me that (at least for the things that I personally have wanted to do so far, a mouse actually works far far better. Except of course for the one thing that I've specifically mentioned, i.e. zoom-in/zoom-out on still photos. That's something that I really want to bind to mouse actions ASAP.

But as I also mentioned (I think) I'm also interested in being able to make use of some of the additional capabilities of the mouse I have, even if they aren't strictly speaking ``standard'' on all mice. (Hell! Even a middle button on a mouse was a novelty not that many years ago! Who knows what will be considered ``standard'' or ``minimal'' five years from now? Of course, that makes no difference if XBMC is only being constructed to serve for the next six months and then be thrown away...)

So specifically, how can I bind the scroll-left and scroll-right actions available on my mouse (and a few billion like it) to actions?

It is starting to look to me as if I'll probably have to get in and hack some C++ in order to make this possible. (So it would seem that XBMC is not ``fully configurable'' via just the .xml files after all.)

And in fact, it is appearing to me that quite a lot about mouse inputs may not have been thought out very well. For example...

Looking at the final section (7.2) in this page I see the following set of defined mouse inputs:

leftclick
rightclick
middleclick
doubleclick
wheelup
wheeldown
mousedrag
mousemove

Perhaps someone can translate for me but some of these make no sense to me whatsoever. What exactly is doubleclick? Is that left doubleclick, right doubleclick, or middle doubleclick? Or did whoever designed this not realize that each button of a mouse could potentially be clicked more than one time in rapid succession? (And oh, by the way, who determines the exact time period that differentiates whatever XBMC thinks of as a doubleclick from an ordinary singleclick followed by another ordinary singleclick? Is that up to the OS, or is that configurable by the user specifically and only for XBMC?)

I also have no idea what mousedrag is, exactly. Again, is that left-drag, right-drag, or middle-drag? And more importantly, if the idea here is that mousedrag is a combination of some specific mouse button being pushed down and then, while it is held down, the mouse moving also, then if the user merely wishes to, say, left-click, but in doing so, he/she unintentionally moves the mouse very very slightly while the button is pressed down, then does that action then become a mousedrag input? If not, why not? Is there a configurable limit to the amount of movement beneath which something is just a click and above which it becomes a drag? If so where may a user configure this value? (I think it might make more sense and work better if what we think of as drag would be represented, e.g. to the various XML configuration files, as what it actually is... two separate actions, a click and a move.)

And of course, for me and for what I want to do at the moment, the really big omission/problem is that there is currently no defined name in XBMC for the (very commonly available) scrollleft and scrollright mouse inputs. That would not even be a big deal if there was some facility for binding totally arbitrary new kinds of mouse inputs...as there is in the case of arbitrary keyboard keystrokes, i.e. via <key id="123">. So? Allow me to humbly throw out a modest proposal for a new XML tag... <squeak id="nnn">. (The tag name "mouse" is already taken, it seems.)

What say you all?

Just as <key id="123"> currently allows users to bind actions to pretty much any arbitrary key that might be present on pretty much any arbitrary new-fangled keyboard, <squeak id="nnn"> could be used to bind all possible inputs, even from the rather wild 8-button ``gaming'' mice I have seen advertised, as well as whatever the geniuses in the marketing department dream up to go under next year's Christmas tree.

[ronbaby]

Oh! I almost forgot to ask... What the devil does this stuff mean??

Code:

<mouse>
      <leftclick>leftclick</leftclick>
      <middleclick>middleclick</middleclick>
      <rightclick>rightclick</rightclick>
      <doubleclick>doubleclick</doubleclick>
      <wheeldown>wheeldown</wheeldown>
      <wheelup>wheelup</wheelup>
      <mousedrag>mousedrag</mousedrag>
      <mousemove>mousemove</mousemove>
    </mouse>

I found this stuff inside the mouse.xml file inside of my XBMC installation.

I though that the idea of these XML bindings was that the tag would have a name that signified/designated a specific and particular kind of input, and then the body of the tag would indicate an ``action'' which, with a few exceptions, would be drawn from the list of actions that are listed on this page. Did I misunderstand?

The thing of it is that none of the things in the bodies of the tags shown above are listed on the page that its supposed to list all of XBMC's set of built-in (primitive?) actions.

[HenryFord]

I though that the idea of these XML bindings was that the tag would have a name that signified/designated a specific and particular kind of input, and then the body of the tag would indicate an ``action'' which, with a few exceptions, would be drawn from the list of actions that are listed on this page. Did I misunderstand?

The full list of actions can be found here:
https://github.com/xbmc/xbmc/blob/master...slator.cpp

You'll find the mouse-actions there as well. However - that is the pure file of available actions, not indicating what they actually do.

Well - to your other questions:
I think that it simply doesn't make a whole lot of sense to even think out the actual mouse-options one might have with the different mouse-devices you get on the market since the mouse can be considered way to sensitive to work with a media-center. It also doesn't make a whole lot of sense (to me at least...) to try to control a media-center with a mouse-device. Besides that fact - a lot of skins don't even have mouse-support. Seeing those points, I'd think that the valuable resources of the team would be wasted on this specific task (heck, it didn't really come up for the past few years I'm involved...) - but again: This is just a personal opinion.