Here is the current list of requests for future firmware, hardware, and edit features. I will submit what I can to the Philips helpdesk. Please keep in mind that we stand a better chance of getting several small things fixed if they are easy than we will with a few difficult issues. Also, some changes may have an impact on the speed of Pronto, as well as memory usage. Please add any other issues below, and I will forward this list to Philips sometime 2nd week of Jan.

1) ProntoEdit/Firmware changes to support a "back to previous panel", maybe a max. of 5 levels back.
2) ProntoEdit/Firmware changes to support an array of user flags, a way to set/reset them with buttons, and a way to use them in a "if then else " scenario.
3) Hardware changes to support brighter backlight.
4) ProntoEdit/Firmware changes to support 8+ shades of gray.
5) ProntoEdit changes to allow multi-object select/copy/paste/move activities
6) ProntoEdit changes to allow cross-application multi-object copy/paste activities
7) ProntoEdit changes to allow a gallery to be sized differently than any other ccf file
8) ProntoEdit/Firmware changes to support different fonts (proportional, narrower, etc.)
9) ProntoEdit/Firmware changes to support buttons shapes other than rectangles.
10) Packaging of Pronto to include either screen protectors or stylus
11) ProntoEdit changes to include an IR indexing screen showing all buttons and panels that have a learned IR code attached, along with the normal editing features.
12) ProntoEdit changes to include an OKAY button on the edit delay screen, with the return key automatically pressing this button.

Hello,

What about an "alias for x sec."
It will be simulate a Press on a button for x sec.
VERY VERY Useful for fade the light with X-10 with the DIM button, or fade the TV Volume to zero (when th MUTE button place a NICE mute icon on the screen !!)

Regards,
BuP

I would appreciate a more user friendly timer:
a) Actions should be defined in edit-mode/ProntoEdit, but the time when to run the macro should be set in normal operation (i.e. use-mode without entering edit-mode!).
b) there should be a list of all pending macros
c) enable panel jumps in timer operations

Whom are you going to address at Philips (no names, just position/function)? How do we know that we are not just forwarded to /dev/null?

What happened to RF capability??????

Here are a couple more:
1. Change the font size without opening the property panel
2. Have the font for the "alias" tree in pronto edit use the "Pronto" font, so the transport icons do not look like gibberish
3. Have a function where you can replace the colors of a button by drag and drop, similar to the alt+drag replacing of icons.
4. Have a concept of Name and Label for a command button (the name might be PLAY, but the label is the play transport symbol)
5. Transparent colors in icons.
6. Fix the bug that occationally makes buttons move in to oblivion.
7. Add an interface to the IRdatabase, with support for importing codes.

These are all things that can be acheived in prontoedit, and would not require firmware changes at all.

Perhaps the program could be open-sourced...

We should break these down into three groups: "Software oriented", "Hardware oriented", and then a listing of "Most wanted", that is taken mainly from the Software group... This way, Philips can have a direction to go in rather than a "pick and choose", because they can't do all these requests in one shot.

As for the alias for X seconds... You can do that now.. Just make a macro of the button you want pressed X number of times in the macro, plus a short delay between each. For TV volume and Receiver volume down, this will work, plus, you could make a "volume all the way down" followed by a "volume up X number of steps" to set your volume level to a set point. This *should* also work with dimmers.

I'd like to see a Drag and Drop like the Alt for Icons, but have it copy the "Action" list. It would copy all associated actions to a button.

As for transparent colors in icons, there should be three (or more, but more aren't needed) check boxes in addition to the "Load, Save, Delete" in icon selection tabs. These three buttons would be "Opaque", "White is clear" and "Black is clear", allowing you to select white or black as the transparent color.

Making the timer more friendly is also good, and an "offset timer" would be a nice addition (do this in X seconds, Y minutees, Z hours).

Lastly, I would like to say that the user flags (preferably 255 or "as many as memory allows"), set, clear, (set if clear, clear if set also?), and if-then-else is the feature I'd MOST like to see. Transparent icons and varying shape buttons (round, trapezoidal, triangular) is another thing I'd like to see soon.

A nice convenience would be the ability to drag aliases from the alias window and drop them into the action list. When you have a number of aliases to insert itno the action list, this would make it much easier.

My biggest gripe is the number of steps required to attach an action (or worse, multiple actions) to a button:
Select the Button
Double-Click (or right click and select) to bring up object properties.
Select the action type--alias for example.
Find the appropriate device.
Find the appropriate panel.
Find the appropriate button.
Click OK (or double click)

Invariably, I get distracted and forget which button I was working on and either have to move windows around or back out.

It seems to me that there should be a means of opening a (floating) window that includes a table with all aliases. The ability to drag and drop the alias on top of the button to which you want to add the action would greatly simplify and speed up programming.

Along the same lines, how about the same table format for "learning" codes. Type in the device name and function name, click the learn button and the code is added to the table. Now when you need to find the code you don't need to drill down god knows how many levels to find it--look at the table, find the code, drop it on the new button.

This is the response I received from Pronto:
-------------------------------------------------

Dear Sir,
thank you very much for your reaction.
We're happy to receive cooperation offered by enthusiastic Pronto users.
If there are any suggestions, to which you have good reasons (along with other users), you're welcome to tell us. We, that is, I, have the possibility to forward this information to the responsible persons in charge, who can use it for further upgrades of ProntoEdit and the offered Software updates. At the moment I'm already busy gathering information and suggestions of Pronto users in order to range them and offer them to the responsible development staff.
I hope you can help us gaining more insight into the needs and wishes of our customers, added with specific hints and suggestions, so we can, in our turn, help you in implementing them.
Perhaps there's one point you'd have to consider in helping us: please be so kind to state clearly the need for any suggestion. The staff can then decide if it is something worth taking into account, after all it's precious computer memory which needn't be used to no great avail.
You can mail any suggestions to me, at the address which you have already used for asking me this.

Best regards,

Eduard Möllenkamp
Philips URC Support
---
Please keep all previous notes, as we need these for reference.

After reading that response, perhaps I should go into detail about the user flag implementation, Like I did a week or so ago (in the lost posts)...

first of all, user flags could be used in a variety of ways, not the least of, for example, using one button to do two different tasks. For example, my TV has a one-tuner PIP, and the VCR is hooked up to Input 2. If I had access to user flags and an if-then-else structure, I could set it up so that when you hit the PIP button first, it would turn the PIP on, turn on the VCR, and select the Input 2 for the PIP. I would also set the "PIP on" flag. (This occurs because the "PIP on" flag was false). The second time the button is pressed, the VCR would turn off, and the PIP function would turn off, and the "PIP on" flag would clear. Without the flag, this type of functionality is not possible unless you want to use two seperate panels (clearly a waste of space). There are many other features that flags could provide, because macros would become a simple programming language, rather than "just do this stuff".

How this could be implemented is have a "Flag button" that you'd place on a hidden panel. The button name would be the flag name (you could even make it so when the button was pressed, the flag would toggle state, for people who choose to put flag buttons where they are accessible).

Next, a "Set/Clear" control in the "Actions" section of button properties. This could be checked as a "set flag" or "clear flag" or "if set, then clear" or "if clear, then set" (the last two are optional, because the if-then-else construct could be used to make them).

Lastly, a "Test" control in the "Actions" section of button properties. This would be the if-then-else construct, and the window would contain three text panels: Flag would be the flag to test; True would be the button (or better yet, allow a list of actions to perform, macro-style) to execute if the flag is set, perhaps with a check box to clear the flag, and finally; False would be similar in construction to True, but executes if the flag is not set. A check box could be included to set the flag.

This adds three buttons to the left side of the Action window ("Flag", "Set/Clear", and "Test"). Please also allow if-then-else constructs to allow panel jumps, perhaps by adding a "Jump" command in the "Test" window, one each below "True" and "False" Sections.

Transparent Icons would allow complex backgrounds without having to make specialized buttons. In fact, you could make a button with no icon, and just black text on a white background. If "white transparent" was checked in the button's properties, then the background would show through all the white areas of the button (same for black if "black transparent" was checked), but all the rest of the button would be on top of the background. The whole of the button would be pressable, though.

One other thing that would be nice to control with a flag is the which panel to jump to depending on whether the flag was true or false.

Yes, that would be nice also... The thing about the user flags is, while we can think of some things now, when we actually have them, a whole bunch of uses will spring up... Flexible programming languages have that effect... you add a feature, and it becomes more useful than you ever imagined it would be.

Just going through the list on some of the simpler ones (the others I more or less agree with as is)...

3) Hardware changes to support brighter backlight.
Not sure about this one... at least not on the current Pronto. The backlight, all things considered, is much better than the competition.

4) ProntoEdit/Firmware changes to support 8+ shades of gray.
The LCD screen and display controller is limited to white, light gray, dark gray and black, period. Any other possible shades are done via dithering. Though it would be easier if ProntoEdit actually supported dithering when importing.

8) ProntoEdit/Firmware changes to support different fonts (proportional, narrower, etc.)
Depends on how much memory this would use. They would all have to be hard coded since using TTF files isn't a viable option.

9) ProntoEdit/Firmware changes to support buttons shapes other than rectangles.
I don't think that would be ideal... I feel a transparancy color for bitmaps would be better.

10) Packaging of Pronto to include either screen protectors or stylus
I've been using my remote over a year and, well, neither of those are "must have".

2. Have the font for the "alias" tree in pronto edit use the "Pronto" font, so the transport icons do not look like gibberish
It does... upgrade to IE 5.01.

3. Have a function where you can replace the colors of a button by drag and drop, similar to the alt+drag replacing of icons.
Personally, I'd find a "IR code replace" function even more useful.

4. Have a concept of Name and Label for a command button (the name might be PLAY, but the label is the play transport symbol)
It's close to that now. Each learned IR code can have it's own internal name separate from the visible label.

I sent this off to the Philips URC that responded back to me on my initial email. Hopefully, at least some of the PE changes can be made, since they already know that they are coming out with a new Pronto that might address some of the other requests.

2. Have the font for the "alias" tree in pronto edit use the "Pronto" font, so the transport icons do not look like gibberish
It does... upgrade to IE 5.01.


So now what do I do when I have IE5.01, and it still looks like gibberish?