XMBC 2.15 Beta

[BriHecato]

I can reproduce Kukurykus first bug. I think that's the way action listbox works - hovering+scrolling works like selecting.

About second bug. For example i've choosed rightclick action, then I hover and scroll up to reach chording (without extending action list), chording window appear, then I move mouse off the XMBC (I've check multiple position of mouse, over and off XMBC windows) and press ESC - chording window disappear, no questions for save.

[Kukurykus]

Well, if I want to scroll to some position that isn't fine some window I didn't choose is opening meantime.

I'm at work now and after your post I tried to reproduce a bug from second point. I CAN'T! When I'm back home I try it again, but I tried it many times yestarday and I'm sure there it working wrong way as I described.


EDIT:

I'm back home and it is like yestarday so differently than in my work and it seems on BriHecato comp. For some reason this bug presists here what I described before and BriHecato tried to reproduce. :/

Why only here?

[Kukurykus]

1) I'm not sure is it bug, but there's something about the newest update (delay in chording) what could work better.

For example when I set some action to left and right button during first 500 ms (so holding LMB and pressing RMB before 500 ms is passed) it works great, but unfortunately it affects some behaviours of left mouse button during those 500 ms.

When I use it simply to LMB click it's okey, I can click anything I wanted before dealy time is passed. But when I want to drag something then I have to click (press) and hold that item / image I pressed by left mouse button and wait 500 ms is passed. Only then I can move mouse to drag something I clicked 500 ms earlier. I mean a cursor of mouse react in no time only I click something, but the action of dragging works only after 500 ms


In my opinion I should be able not only to click / select something during that first set time of dealy but also to be able to do all other things they were supposed to be done by 'designer' of some tool, so like draging (before XMBC chording dealy is passsed).


2) What about making some simkeys commands deprecated (but left to be still in use) and change them a little bit, I mean all which contains these signs: <>

For example are they really needed when we write {waitms<100>}. Wouldn't it be better to make them uniform to be alike others simkays so the way like {waitms:100}

[phil]

In my opinion I should be able not only to click / select something during that first set time of dealy but also to be able to do all other things they were supposed to be done by 'designer' of some tool, so like draging (before XMBC chording dealy is passsed).

I think you are missing the point here... Its simply not possible to do what you want without changing the application that implements the window itself. XMBC cant do this. All XMBC can do is either block or not block, and the timer just reduces the not block effect.
The dragging (for example) will not begin until the application/window receives the button down message.
Once a button down has happened, then a button UP must follow or the button will be "stuck" down.
So if your using the option to block (so the orriginal button action is not actiavted) then XMBC does not (and can not) send the button down until it knows if you are chording or not - hence the term blocking. The timer just relieves the impact somewhat.

So either you don't block the original input or you do (with or without a delay). The timer reduces the impact of the block - but of course, you have to wait 500ms (well you can reduce that, but then you may miss the chord) before the button down action is passed. There is no other way of doing it (that I can think of).

2) What about making some simkeys commands deprecated (but left to be still in use) and change them a little bit, I mean all which contains these signs: <>

For example are they really needed when we write {waitms<100>}. Wouldn't it be better to make them uniform to be alike others simkays so the way like {waitms:100}

You mean the text? Sure - they should all be consistent. Behind the scenes, it will accept a or <x>. Come to think of it, you probably don't even need the ':'!!
But yes, the descriptions should all be consistent.

Phil

[Kukurykus]

Haha I didn't know that. I just tried 3 version of simkays and they all worked!!!

{WAIT<2>}{MADD:100,200}
{WAIT:2}{MADD:100,200}
{WAIT2}{MADD:100,200}

I didn't mean text, but the usage. But yes, that should be consistent in description too for everything.

Personally I'm going now to stop using {WAIT<2>}. I will use {WAIT:2}. And I won't use {WAIT2}, because it's not redeable when I look at some of my long codes.

Thank you for info Phil.


Regarding first point. Too bad it can't work different way. Well I may set 250 ms delay, so I have time to press 2 buttons, (second after first). Unfortunately it's not so easy even with practise for all buttons, so I chose safe 500 ms. If I had to press LMB and then "stable" RMB then 250 ms is fine, but when after LMB I need to press "unstable" middle button then often I need more time like 500 ms to be precise. Problem is that 500 ms is too long time when I want to use only LMB not to click something only but to drag as well. Everything up to 250 ms is almost that you don't see difference, but everything over make big difference and each time I has to remember about that delay and make sure that about 500 ms passed

Maybe in some future something like fast initial double LMB click would be an option to send signal to XMBC that you want to break original function of LMB with other button chording. Btw I can't imagine I needed more than one second to drag or some other default action. When I use draging often then it's terrible even that half of second, but fortunately I do it mostly occasionally, but still...

I remember you wrote that Windows doesn't recognise double click or something like that... Anyway my idea is when you do that fast click I mentioned with a time of let's say up to 100 ms between 1st and 2nd click, and then holding LMB button as continuation of second click, XMBC would cancel chording and work like 250 ms, 500 ms or even 10 seconds was already passed. This way we could have a workaround for the problem I met.

[phil]

I remember you wrote that Windows doesn't recognise double click or something like that... Anyway my idea is when you do that fast click I mentioned with a time of let's say up to 100 ms between 1st and 2nd click, and then holding LMB button as continuation of second click, XMBC would cancel chording and work like 250 ms, 500 ms or even 10 seconds was already passed. This way we could have a workaround for the problem I met.

Well windows obviously recognizes double clicks, but not in th mouse hooks - its done at a higher level (after the hooks).
It might be possible to look how long it has been since the last press and cancel chording in that case - I'll have a think.

[phil]

Here is 2.15 Beta 15.

If you have check for beta versions enabled, you should get notified of a new version and prompted to update in the next day or so. This is the most efficient method (bandwidth wise) as the updates are only a fraction of the size of the full install. Otherwise, you can get the full installation beta HERE. Note that this link will always get you the latest beta version!

Changes since v2.15 Beta 14:

• #462 - Fixed bug when scrolling the button action combo boxes.
• #461 - Renamed all simkey tags in the help screen so the text is consistent.

There are updated translations in the template file for 2.15 Beta 15 but I have updated all the translation packs so no additional work is required.

Once again, I expect this to be the final beta before 2.15 drops unless more show stopper bugs are found.

Any problems, PM me a copy of the log file (or post a snippet in a code block here).
NOTE: I'm Back to work next week so the updates will slow down a bit again!

Thanks,
Phil

[injtsvetkov]

#461 - Renamed all simkey tags in the help screen so the text is consistent.

Untitled.jpg

I hope it's a bug but there still are commas+spaces between some of the tags and some are separated by spaces only. Or maybe I have misunderstood and you meant something different in #461?

[phil]

#461 was to change {tag<n>} and {tagn} with {tag:n} only. No commas or spaces were addressed nor did I intend to at this stage - I was saving that for a fuller makeover at a later date!

If you want to change commas and spacing, you could create your own translation template to do that right now

And in any case, I wouldn't consider spelling, grammar or text layout to be bugs generally as it does not effect the operation of the software which is what I would consider a "bug".

[injtsvetkov]

I was saving that for a fuller makeover at a later date!

That's what I wanted to know, thanks
And thanks for the tip about the translation template thing, frankly I haven't thought of that, it's a good idea but I will wait for the fuller makeover

GO GO GO 2.15

[Kukurykus]

I can't wait to see what "we" will be working on next beta version

If no "click and hold' or 'double/triple clicks' then I wonder what other fresh ideas come up to make XMBC better. I doubt it will be so easy like with 2.14 and now with coming soon 2.15.

That's off topic, so please don't make discussion about. Better think hard by now what could we test in Beta 2.16 to post later in appriopate theard our new great ideas!


btw I just posted 190th post if you didn't check it, that was last number of post in previous beta (2.14) theard. So it seems from now on all new betas need about 190 (or maybe 200 soon ) posts to be released ha ha

[Kukurykus]

Well windows obviously recognizes double clicks, but not in th mouse hooks - its done at a higher level (after the hooks).
It might be possible to look how long it has been since the last press and cancel chording in that case - I'll have a think.

If possible there can be implemented also other method of canceling chording - moving mouse about specified pixel distanse. So in this specific case when I click LMB and I don't want it waited for another click of other mouse button some amount of time whatever it will be pressed or not I can move my mouse of just one pixel before it happen. This will cause chording cancelation so let me continue dragging in no time.

What do you think Phil about this solution?

[phil]

That might work - but one pixel probably is too little.... That's something to play around with in the next version I think

[injtsvetkov]

That might work - but one pixel probably is too little.... That's something to play around with in the next version I think

Absolutely

[Kukurykus]

It's an idea for another Beta, but I couldn't wait to post it.

I'm sorry the quality isn't best, but it's only a sample showing what I mean.

If you still wonder what I entered there here's plain text: {holdms:100}{return}{waitms:250}{ctrl}{shift}q{waitms:750}{shift}{f3}{waitms:250}{ctrl}x{waitms:250}{alt}o{tab}{aset:215,160}

There are different tags, where each got its colour, so for example normal letter without curly parenthesis are black (or if you want white with 1 px black stroke), wait and hold tags can be in different shades of green, red for modifier tags, cyan for moving, purple for extended keys and yellow for the rest like function keys. That's only example, the colours you see are custom, I didn't think what tags should got what colours yet too sersiously. Let's do discussion about it if Phill say it's worth of doing in next beta. (maybe in new Beta theard, if Phil say so)

How that should work:

If possible when you write something it's black untill you enclose it into curly parenthesis, then it's going to change colour of appriopate tag. I know it might be hard, because it's going to be something like live editor it reacts for everthing you're entering into blank to be ready to change it when closing bracket is typed.

I have more codes like this, more twice wider even, and sometimes it's hard to me to read it or to find parts of it to not feel I'm lost. When there are colours it's more reaable and easy for editing.

Ps. the 1 px black stroke is used in that colour text you see. it's why it's so bold, but maybe with other font that would look much better. I used that stroke as yellow, white and other light colours were be not very visible.