IR v8.01 wish list

Post by **mathdon** » Tue Jun 16, 2009 9:00 am

IR8.01 Development Build 1 posted

Here, at long last, is IR8.01 Development Build 1. I have revised the FAQ that is included in the package but here are the main additions:

* Multiple selections and highlighting now work on all grids and list boxes, though on the Device Buttons and Settings grids multiselection only works when Highlighting is turned on. This is because highlighting is the only feature on these grids that works with multiple selections.

* Editing and cloning now work with multiple selections, in addition to moving, deleting and highlighting that did so in Build 0.

* Column headers are now active on all columns on which sorting is meaningful. Clicking a header sorts the grid by that column. Where the sort key is equal, original order is preserved. This means that you can sort by multiple keys by clicking the headers in order, starting with the most minor sort key. You can tell an active column header, as its color darkens slightly when the mouse pointer is over it. Repeated clicks of the same header reverse the sort order, as is usual. (Sorry, Liz, I did it without merging Special Protocols back into Key Moves !)

The Learned Signals, Devices and Protocols list boxes don't have headers, but instead there is a new Sort entry on the right-click menu.

With Settings, highlighting is bit-wise on the Raw Data grid. Settings bytes get highlighted with 8 vertical stripes, that for bit 0 being on the right. If you can't judge which bits are highlighted from their positions, just hover the mouse pointer over the grid cell. A pop-up "hint" will tell you which bits are highlighted.

When you edit or clone a multiple selection, only the common values are shown on the editing form. When you press OK, any fields still left blank will take their original values in the edited or cloned items. Here are a few examples of what you can do:

* Select a number of macros that are on unshifted keys and clone them on to the corresponding shifted keys.

* Select a number of LKP special protocol entries and change their duration, or change them all to DKP.

* Edit a number of timed macros for Tuesday and change them to the same time on Wednesday.

If you leave the Notes field blank in a multiple edit then the original notes will be left unchanged. If you want to delete all the notes, put a SPACE character in the Notes field.

Enjoy, and please report any problems.
___________________
Graham

Post by **mathdon** » Tue Jun 16, 2009 9:36 am

There seem to be continuing problems from the power outage. If IR8.01 DevBuild 1 uploaded correctly, I for one cannot download it. I've tried a second upload, to a new URL rather than an edit of the old one. It reports success but I can't download that one either. I'll try again later.
________________
Graham

Post by **The Robman** » Tue Jun 16, 2009 10:48 am

I just downloaded from the following URL without problem:
https://www.hifi-remote.com/forums/dload ... le_id=6717

Post by **mathdon** » Tue Jun 16, 2009 11:23 am

Things seem OK now. I can now download DevBuild 1 without problem. The web link Rob gives is the same as the one in my posting (an edit of the Dev Build 0 post). I've therefore deleted my second posting, which I never gave a link for anywhere.
_______________
Graham

Post by **ElizabethD** » Tue Jun 16, 2009 12:38 pm

Hurray!
I just took a quick look at the, potentially, most dangerous of changes, Replace.
I have 4 LKP(4), each with different Notes. Replaced by DKP(4). The vital information is ok but all Notes became the same.

The other thing I noticed was when I wanted to resize the columns, the sort took priority, and it sorted which at that time I didn't want. But I think this just requires to be really accurate positioning the cursor smack over the line.

Edit: I just reread the instructions regarding replace

If you leave the Notes field blank in a multiple edit then the original notes will be left unchanged. If you want to delete all the notes, put a SPACE character in the Notes field.

so I guess it's ok.

Post by **mathdon** » Tue Jun 16, 2009 3:40 pm

ElizabethD wrote:I just took a quick look at the, potentially, most dangerous of changes, Replace.
I have 4 LKP(4), each with different Notes. Replaced by DKP(4). The vital information is ok but all Notes became the same.

Did you put anything in the Notes field of the edit form? If you didn't, they should have been left unchanged, but if you put anything at all, even a space, they would all change to that. Could you clarify what you did, please. I haven't found this problem in my testing.

[Edit]Oops!

I hadn't tried it with notes in Special Protocols, only in Key Moves. I see that the note of the first selected row appears in the Notes box of the edit form. That should not happen - if the notes are not identical then that box should be left empty. I will investigate.

ElizabethD wrote:The other thing I noticed was when I wanted to resize the columns, the sort took priority, and it sorted which at that time I didn't want. But I think this just requires to be really accurate positioning the cursor smack over the line.

I hadn't noticed this as I hadn't tried to do it, but I have just tried it and the same thing happened. I'll see if I can put some leeway into this, so that you need to be a few pixels away from the divider before the sort comes into effect.
__________________
Graham

Post by **mathdon** » Tue Jun 16, 2009 4:38 pm

I think I've cracked both these problems. The Notes one was a simple omission in the code specific to Special Protocols, though I will also check that I haven't missed it for any other tabs. As for the Sort/Resize issue, sorting takes place on MouseUp, not MouseDown, so I've inhibited sorting if the mouse has been moved horizonally by more than 2 pixels between MouseDown and MouseUp. This seems to work OK.

I'll wait a few days to see what other bugs emerge, then post a revised version as Build 2.
____________
Graham

Post by **ElizabethD** » Tue Jun 16, 2009 6:50 pm

I think we're on the same page, but since I'm not sure you read my edit about it being ok, here's a recap:
Initially I just selected the LKPs, the first item's note was in the notes, replace to DKP made all the notes the same. I just repeated to double check.
Then, after reading your instructions, I cleared the notes on the replacing dialog and the replace preserved the original Notes. Repeated this and it works ok.
I gather from your comment is that you expected the Notes item on the replacing dialog to become blank due to the Notes on those keymoves being different.
Yes, it is blanking out the notes on the Keymoves sheet. Got it.

Post by **mathdon** » Thu Jun 18, 2009 7:21 am

IR8.01 Development Build 2 posted

I have now posted IR8.01 Development Build 2, which is Build 1 with the bugs found by Liz fixed. I wrote previously

As for the Sort/Resize issue, sorting takes place on MouseUp, not MouseDown, so I've inhibited sorting if the mouse has been moved horizonally by more than 2 pixels between MouseDown and MouseUp. This seems to work OK.

but I have found a better way. Experiment showed that when you re-size a column, the MouseDown event does not occur but the MouseUp one does. So now the MouseDown event sets a flag that permits sorting. If there is a MouseUp without a corresponding MouseDown, as in re-sizing, then no sorting. This avoids the arbitrariness of the two-pixel check.
_________________
Graham

Post by **ElizabethD** » Thu Jun 18, 2009 12:29 pm

I've been mangling just one 6131ext file.

Replacements I did look good. I also checked a replacement causing a conflict. This IR handled it great.

Mousing over column names to sort or change columns is wonderful.

Sorting - looks good but raised some questions in my head.
1. when I sort devices and protocols, I think I'd like to see third option, a way to revert to the original sequence. I like to keep the extender devices and protocols up top and couldn't do that after the sorts. OK, not ok?
2. I wonder if the position of, for instance, the main device and protocol which runs the extender should not be prevented from being moved. Because the sort does move'm. Color coding indicates that the pointers moved too, so it might be ok, and I uploaded to the remote and it seems ok.

Post by **mathdon** » Thu Jun 18, 2009 3:52 pm

Thanks for the comments, Liz. Your questions raise ones of my own, however:

1. What is "the original sequence"? Is that an "undo"? If so, how many sort steps would you want to be able to undo?

2. I've anguished, in other contexts, over how to tell even if an extender is present, never mind how to tell what its device and protocol are. The presence of a "[SpecialProtocols]" section in the RDF is not in itself enough to identify that there is an extender, and although I expect the extender device and protocol are generally the first ones in the E2 upgrade section, I don't think that has to be the case (even without sorting!).

I don't think moving the device and protocol of an extender should cause problems. Devices precede protocols in E2, so if you add a new device then the extender protocol will be moved in any case.

If you use sorting merely to help to find something, knowing you want later to restore the original order, then you can always use "Set Baseline" before the sort, and "Restore to Baseline" afterwards. It is also possible to re-order manually afterwards anything that you can sort, if you want to sort "with exceptions", so to speak.

I would welcome other comments on these issues, or more explicit suggestions as to what could be done about them.
________________
Graham

Post by **ElizabethD** » Thu Jun 18, 2009 7:54 pm

Ah, this is all fussing really, to keep you from getting too bored

1. Original sequence - yes it is 'undo'. As a matter of fact, Edit/undo was the first thing I looked for when i did the sort and didn't like the consequences. How many steps? Hmmm. At least one.
Aha, I didn't know you can manually drag devices up and down - so I think what I want is totally solved.

2.

I've anguished, in other contexts, over how to tell even if an extender is present, never mind how to tell what its device and protocol are

I see your point. I wonder if the presence of phantom buttons in the RDF is sufficient, but I doubt it 'cause they could be named differently. Protocol numbering might be the clue, but I don't think so.

and although I expect the extender device and protocol are generally the first ones in the E2 upgrade section, I don't think that has to be the case (even without sorting!).

Correct. I din't think about it.

you can always use "Set Baseline" before the sort, and "Restore to Baseline"

True, but not if you've already made other changes to keep. However, I think setting the baseline as you go along could be a good workflow. I just didn't think about it.

It is also possible to re-order manually afterwards anything that you can sort, if you want to sort "with exceptions", so to speak.

Being able to change sequences manually, as I just tried, really solves all of the things I mentioned.

I would welcome other comments on these issues, or more explicit suggestions as to what could be done about them.

Me too. But I suspect these are low priority items really.

Post by **mathdon** » Sun Jun 21, 2009 10:11 am

Progression of IR8.01

Since most of the enhancements in IR8.00 were concerned with RDF syntax or the special features of the URC-7780/81, average users will probably gain more from the change from IR8.00 to IR8.01 than they did in the change from IR7.15 to IR8.00. By the version numbers, however, it sounds like just a minor tweak or bug fix.

Because of this, I suggest that the next version be named IR8.10 rather than IR8.01, as this sounds like a worthwhile upgrade. The highlighting, multiple selection and sorting features now seem mature (judging by the lack of comments), apart from the need for an "Undo Sort/Move" that I will put into the next build, so I propose that the next build be posted as "IR8.10 Beta".

Suggestions made for IR8.01, and even IR8.00, that I have not yet implemented are not forgotten. I make no promises about any of them, but I will revisit them for the development of a future IR8.11. Please feel free to start an "IR8.11 wish list" as well!

Comments, please.
____________________
Graham

Post by **The Robman** » Sun Jun 21, 2009 10:19 am

I would vote to stay with 8.01 myself, as jump straight to 8.10 tends to imply that there are 9 other versions that got lost.

Post by **mathdon** » Sun Jun 21, 2009 2:20 pm

Rob, I'm afraid I disagree. My first thought, on reading your reply, was that if that's the way IR does it, then so be it, even though commercial software often misses out values. MS Windows 3 was followed by Windows 3.1, was followed by Windows 3.11, for just one example. Commercially, the first digit after the decimal is often incremented to mean a more major revision than a change to the second decimal.

But then I looked at the Release Notes, which I take to give a historic record of releases. Release 6.00 was followed by 6.10, then 6.15, then 6.20, before (presumably) the next IR maintainer took over at 7.00. Who reached 7.15, then apparently 84 releases got lost before my 8.00 appeared.

I won't fall on my sword over this, but like WagonMaster's disquiet over JP1 naming (a disquiet which I share), if it is now policy that the two-digit number after the decimal is incremented sequentially, it is a policy that I consider to be confusing. I like version number changes to give some indication, at least, of the magnitude of the revision.
__________________
Graham