davetcc / tcmenu Goto Github PK

When I say move from ethernet to serial remote, the code for ethernet is left behind, this causes severe problems as it means the dependencies on that are still in place.

There are a number of minor improvements needed in both UI's

• Make the controller UI production ready by making editability better, and use a sustainable method of handling updates.
• Add new sub-menus to the designer UI for recently edited projects, all sketch directories that contain menu (EMF) files and all examples packed in tcMenu.
• Auto save after generation, source of lost changes!
• Ensure structure is not dirty before any menu load operation

Logging will be needed.
Must generate the app/jfx directory.

Support stream mode connections on the above hardware using a popular driver.

When the time out triggers and the menu is reset to its default state the editor and active states are not reset as well. Sometimes leaving two items editable.

In order to compile in visual micro the .cpp and .h files containing the menu definition (which are currently the same name as the project) need to be renamed. They will be renamed in 1.2 to projectName-menu.h & cpp

This needs to be done in each of the examples too in order to avoid confusion. A note on the release must indicate that the old files be removed.

At the moment the combination of no backlight setting on LiquidCrystalIO and no option for it in the generator means it is not possible to set the backlight out of the box.

The workaround is to manually set the backlight on the IO device by keeping a reference to it, and setting the backlight pin as output with the appropriate setting.

A problem has been detected in the Java side of the API. It looks like under some circumstances messages are being buffered in the input queue and not being processed until more messages are received. Shows up more with UipEthernet than Ethernet.

Sadly I cannot launch the program.
My error message:

Java Installation:

I found this: https://stackoverflow.com/questions/22381202/a-jni-error-has-occurred-please-check-your-installation-and-try-again-in-eclips

• Make sure the code compiles perfectly and takes advantage of the chip
• Ensure that there are sufficient yields in our tasks that the WiFi is not interrupted, particularly on the colour display handlers.
• Create a remote connector that works with the Wifi adapter inbuilt in the chipset.

Support for analog joystick based input in line with the embedded code change

The designer should be able to set the read-only and local-only status of any menu item and create code for that case.

This is in progress, so far done is the work in the UI to render the extra fields and the work in the API to hold these fields.

Left to do, change the generator to generate suitable code.

At the moment there is an oversight in the distribution and library structure. This means that AT24Cx and AdaFruitGFX libraries always must be on the path, but are not included with tcMenu / IoAbstraction. Workaround: copy these two libs into your libraries directory manually for now..

AT24:
Look into how to package AT24Cx as part of TcMenu and IoAbstraction such that no such installation problems are

AdaGFX:
Move the renderer into a separate module of it's own, or look at making the renderer so that it's copied into the users program directory with sensible defaults. This would make more sense as then custom rendering is much easier, and will probably be quite common.

When naming a menu variable it should include the submenu for example

If the submenu were named settings and the item named contrast:

menuSettingsContrast.

To be determined: should only the immediate submenu be included in this or every submenu back to root? Doing recursive back to root would end up with

menuSettingsAdvancedItemName.

One option would be a setting to control this that had three options:

• Do not include submenu name
• Include only nearest submenu name
• recursively include all submenu names.

Make packaged versions of TcMenu Designer such that:

• It installs from an MSI package on Windows
• It installs as a app package on MacOS
• Keep the jar file method for Linux and anyone who prefers that method.

Ensure all compilations work with 32 bit boards. Basic optimisation too where possible.

The last area of hardwired code generation is in the menu structure initializers in the Java generation code. This needs to be replaced with a more generic system that will make it cleaner on 32-bit boards, especially ESP8266 where the compiler really doesn't like all the progmem declarations (which make no sense on 32-bit boards that are not Harvard arch. anyway.

Is it possible to add numeric keypads like these to the library? https://cdn.instructables.com/FSM/WKU0/HX0DQ2Y3/FSMWKU0HX0DQ2Y3.LARGE.jpg

It will be really useful to take values from the user. Also having to option to use this keypad with a rotary encoder will be really cool. One can, say, make a digital power supply with it.

Thank you

Common theme here, the Arduino code should have some basic unit tests that provide a degree of confidence that the library is working properly. To start with maybe something that confirms proper functioning of the menu manager / items would be enough.

At the moment it’s all a bit hardwired. Improve the widget and screen drawing options. Make it easier to extend.

There needs to be a display driver for Adafruit GFX that is optimized for monochrome displays such as a 1306 OLED unit and the Nokia 5110 display.

Simple dialogs should render to every display type, and have the ability to display onto the controller UI

Would cause far less confusion if the wire begin call was added if needed to the setup function in the sketch for Arduino.

At the moment, too much logic by far is in the LCD renderer, this needs to be factored out into the base package, and the AdaGfx based graphical renderer will be the ultimate test of this.

Although there are no remote capabilities, the #include<RemoteConnector.h> is still required for the interfaces.

Workaround until fixed is to add:

#include<RemoteConnector.h>

to either the header file generated in the sketch directory.

The flash size seems to have increased substantially and is now over 12K. Check over the includes, used static and globals, functions used.

Not really a bug, but something to look at in that there is a dependence on a very recent commit to the Print.h file - availableForWrite.

See how things pan out to see if its supported on at least AVR, SAMD and ESP8266.
Workaround: go to board manager in your IDE (Arduino IDE at the top of the board options) and update your boards.

First attempt: ESP32 support for rendering using U8G2 library for OLED displays.

Along with the license link and the site link, there should be a link to suitable documentation on each plugin entry.

Add to each entry a new parameter of type "docsLink" that optionally links to documentation. If not present, it is ignored.

Handle in all renderers:

• IpAddress item
• New TextEdit item
• Replaced remote item with custom runtime item
• List item
• Custom item

Given that the UI Generator has now become pretty much the defacto way to generate menus, at least a degree of testing needs to be added to it, to provide some degree of automated testing, saving a lot of time during release, and increasing confidence in release quality.

This first JIRA should set the stage by testing some core flows in the UI, along with the other associated JIRA that will ensure the generator itself is fully tested.

Not sure possible that the JSON format storage file is not being properly closed. needs investigation

As it says on the tin, a Python API that will connect to and remotely control the menu library, just like it's Java counterpart

At 1.3.3 there will be a breaking change in the protocol to match with the change in the library

See the library issue for more information.

On some machines it may not be possible to locate the Arduino directory, and therefore the libraries directory. In these situations pop up a dialog requesting the location of the Arduino directory.

There are some cases where no local input facilities are needed, there should be a way to configure tcMenu without adding any input controls.

Write a basic ethernet renderer that works with all APIs, this will initially be targeted at the standard ethernet libraries for ethernet shields. It will be easy to improve later for other ethernet/wifi chipsets.

As the generator will generate code that may not be compatible with older libraries, it is important that the designer can check the version of the libraries installed, and indicate when they are not up-to-date. It should also offer to update them, and only update when they need updating.

It appears that on large menu structures the name editing does not work as expected. The below appears to work on smaller menus, but the menu in question is quite large. Create a unit test that tests this case with over 200 items in three level nestings.

Copied from forum:

1. I have an item named "1Light 1".
2. I backspace the first "1" so it looks like "Light 1".
3. I type "1" and only the entry field updates everything else still says "Light 1".
4. I type "0" after the "1" and everything updates and says "10Light 1".
5. I backspace the "0" and only the field updates to "1Light 1". Everything else looks like "10Light 1".
6. I backspace the "1" and everything updates to "Light 1".
7. I write "1" once more to try to get to my original "1Light 1" but it only shows up in the field everything else says "Light 1"

Support the ESP 8266 wifi chip integrating with the example.

This should be able to configure and use the ESP8266 based wifi library.

In the example app, show how to indicate using an icon if there's a connected client, and indicate the signal strength.

The designer UI plugin facilities should be completed so that they can be shipped in separate jar files completely separate to the main UI. It is still an open question if one or more than one should be used for the initial basic set.

These plugins will contain all the code generators for displays, remotes and input. These will be automatically added to the Code generator. The idea of an I’d will be replaced by uuid, making it easy to handle shared plugins.

One of the open source projects should be used as the exemplar for others building a plugin.

The first display will probably be a 320x240 display 2.2" in size. But it should be fairly easy to use different units based on AdaGfx. Depends on the work to clean up base renderers.

Float menu item: read only item that is backed by a floating point 32 bit value. Useful for status etc. Number of decimal places should be settable.

Remote menu item: for rendering information about who's connected remotely onto the menu itself.

Action menu item: for cases where no state is needed, just fire an event when selected.

We need to write a connector facility into the menu that allows them to be controlled remotely. Initial implementation will be RS232 with the Java API publicly available.

Initial protocol will be a text based protocol using simple tag value pairs that is very easy to decode. This will also allow other languages with less competent network and byte order handling to have easy APIs.

The remote layer and protocol shall be replaceable at runtime, such that other implementations can be later added.

Before the 1.3 release which will remove the beta / in development status some small code cleanups are needed on both the embedded and Java side. From this point onwards we'll try and minimise breaking changes.

Add support for the analog DFrobot based input system using something akin to what’s documented on the wiki

Decouple the menu manager's get root call from the renderer constructor.

The analog type should provide a far greater degree of helper methods to aid with setting and reading its values. This will be in the form of helper methods to and from float and to and from a simple fixed-point numeric format called WholeAndFraction.

For remote connections there are a few things that need to happen to make it production ready. These are listed below:

• A basic level of authentication should be available that at least uses a key or pass-code before accepting connections. This is not for over internet situations, rather just for simple LAN security.
• Each menu should have a UUID generated by the designer application, this should never change during the application lifetime.
• When a menu item is updated remotely, the server should respond with a special update that also forms as an acknowledgment too.