Suggestion: Web based online designer

[intensite]

Your menu system is second to none!

Any chances for the designer to be ported to a web based application one day?

I try to keep my machine as clean as possible of third party applications, and favor web based, install free, whenever possible.
Just a suggestion.

Regards.

[davetcc]

At the moment we are focusing on native apps for both Windows and macOS. The app for Windows is already able to be installed via the windows store, and it will be the same for Mac very soon. This gives people a higher degree of confidence where it's deployed via a store.

There's a cost to adding a platform and then supporting it, and it at least seems for development many people prefer locally deployed applications.

Some of the issues for a web app for example:

• storage of the designs
• where would the code generator run
• getting the generated files and round-tripping

None of these are insurmountable, but we just don't have the bandwidth to support both. I think the compromise is an app that is easily installed from the app store, that can be easily removed after use if needed.

[davetcc]

For completeness, I'll add that we do also support earlier versions of Windows, Linux, and anyone with a store aversion via the Java client, which is a fully open-source UI that can be built by anyone who prefers to go from source. It's also distributed with each release.

[intensite]

Fair enough.

Being a web developer myself, I guess I suffer from the "When all you have is a hammer, everything looks like a nail" syndrome :-)

[dogtopus]

Being a web developer myself, I guess I suffer from the "When all you have is a hammer, everything looks like a nail" syndrome :-)

So I was screwing with TcMenu's menu declaration API and I think I accidentally built the nail. Feel free to hammer it in if you want :P.

(For anyone who's wondering: This uses its own YAML/JSON-based DSL for menu declaration and isn't compatible with TcMenu Designer's EMF project. Also it's quite experimental at this point)

[davetcc]

Let me start by saying that I'm open to all possibilities here. We'd like to get as many opinions and replies as possible here.

To be honest, the menu structures are the lesser part of the puzzle, if that were the whole picture, we could probably even provide some kind of C++ DSL that made it easy enough to build them directly in the code using macros and language support. I think a designer is still needed, to deal with display, input, and IoT plugins. For an encoder and LCD it's pretty easy to work out what to do, but for a TFT with a touch screen, theme-based configuration, and IoT monitoring/control, the initial setup gets much more complex, and without some kind of designer, would significantly increase the barrier to entry.

Let me just reiterate here, we are not trying to do anything bad, the registration was there to get an idea of who is using it, and was more aimed at commercial users than personal and educational users. We've spent many years trying to work out how to make menus easy to develop, and the result of this is freely available for all to use under an Apache license. In the future, there may be some charging structure aimed at commercial users but that is in line with many open source projects.

I've recently been spending a lot of time trying to get out the latest release, as we've now ended up with both Xamarin and Java versions of the designer UI. Honestly, it's pretty much unsustainable going forward. I'm now thinking about how we get back to one version.. Now that the current Java UI capabilities are completely in line with the App Store versions it would probably be the base. I'm even open to a web version now after the recent hell of this release cycle on three platforms, with basically two and a half code bases. One that would be open-source and have the option of using it from thecoderscorner.com or locally for those with a dislike of the cloud for non-commercial and personal use. However, I'm just not sure we have the capacity to do this, we just can't fund another large project.

Things to think about:

• Is an app in the store the right place? If it is, we could get the current Java app in the stores, and use different CSS to style it.
• Do you prefer to just download the app from GitHub (and thecoderscorner.com for a catalog of older versions)?
• Web point 1: Would we need to gain access to local storage from a web container to have the option of saving locally?
• Web point 2: How would we do the equivalent of round-tripping, is that even important. Maybe instead of putting callbacks in the project main, we could have another approach of adding them to the menu definitions file as weak aliases: https://github.com/arduino/ArduinoCore-avr/blob/6ec80154cd2ca52bce443afbbed8a1ad44d049cb/cores/arduino/hooks.c#L28

Let's say we went the web approach:

Advantages

• There would be less risk of people using a broken or out-of-date designer.
• We could easily support 1.7, 2.0, and beyond, even hosting different app versions if need be.
• The plugins would be absolutely trivial to manage in this case as they would be on the same host.
• No installation on your machine (unless you actually wanted it locally, which we'd wrap in a shell command to make it easy)
• One codebase (what a dream) would provide the CI solution, the web interface, and we could even allow a syntax similar to the link above that allowed for a no designer flow for advanced users.

Disadvantages

• We'd have to host the web application for most, as many would not want to run it locally, maybe we could reach out for sponsorship from an electronics distributor or similar. They would get a nice "sponsored by" side banner in return.
• We'd have to actually build a good portion of it, but in Java we have a very, very robust build system already that can be easily extended.
• We'd probably need people to register and log in to use the online version so that we could store designs between sessions. This increases the cost as we'd have to be GDPR compliant in everything we stored, and make sure it was sufficiently secure and backed up. People already mistreat the registration form, heaven knows what would happen with this.

[davetcc]

@dogtopus I think it would be better to get back to one code base, we've tried the two codebase approach and it really doesn't work. We already have a code generator in Java and in Xamarin. It would be better to get the improvements into the Java designer, I'd even be up for integrating the simpler JSON format. I can't stop you from creating a designer fork, but who's going to maintain it, make changes as the code requirements change, and manage any issues and questions in the forum?

[davetcc]

So my suggestion is:

1. Update the JavaUI to look better with a new CSS theme - simple task.
2. Store or Notarize for mac and either codesign or store for Windows or even brew, apt, and choco?
3. Add support for a simpler command-line approach as per the fork, and ensure it integrates into build chains well.

[davetcc]

So we have the last feature that was missing from the java UI added back in, and there is no need to register for non-commercial users. But @dogtopus you will need commercial users to register their use of the library, it was always part of the plan, and you'll see that in the UI codebase going back to the early 1.0 days. It's not evil, we have spent years writing this library, and are at the point where commercial use is expected.

[dogtopus]

I think it would be better to get back to one code base, we've tried the two codebase approach and it really doesn't work.

Yes I understand. I should clarify more that mktcmenu was more of a personal experiment since I always have the feeling that the designer expects my code to go around it instead of the opposite (me porting my existing code to tcmenu). I have absolutely no intention for it to replace the official designer or even for it to be endorsed by your side since the two are built for different goals (an ecosystem vs absolutely minimalistic).

The original post was more about me finding that I can more or less generate a web UI straight from the JSON schema that I used to validate the descriptor file so I sorta wanted to share it.

It would be better to get the improvements into the Java designer, I'd even be up for integrating the simpler JSON format.

Thanks for your interest in tcmdesc format. However I think it would be tricky to implement it in the current designer since it's conflicting a lot with the current internal design of it (one of the reason why it's an independent thing rather than a real designer fork). On the other hand though refactoring is always possible so it ultimately depends on decisions from your side.

I can't stop you from creating a designer fork, but who's going to maintain it, make changes as the code requirements change, and manage any issues and questions in the forum?

Yes I should put a stronger notice that stops people from asking help on TcMenu support channel regarding to issues from mktcmenu unless they are absolutely sure the issue was from TcMenuLib. In that case they should first reproduce it minimally in designer and submt a ticket to TcMenuLib.

Let me just reiterate here, we are not trying to do anything bad, the registration was there to get an idea of who is using it, and was more aimed at commercial users than personal and educational users.

But @dogtopus you will need commercial users to register their use of the library, it was always part of the plan, and you'll see that in the UI codebase going back to the early 1.0 days. It's not evil, we have spent years writing this library, and are at the point where commercial use is expected.

Since it's Apache and not some custom source available license or dual licensing I never assumed this was the case. However I think there is still room for improvement of the UI/UX by having an opt out checkbox on the register dialog that says something like "I will use TcMenu only in non-commercial projects and have no intention of registering." and it will prevent the box from showing again.

[intensite]

In my case, it was the Java runtime requirement that was and still is the biggest deterrent.

In my original comment almost a year ago (wow time flies), I was thinking of a web page where one would design his menu structure, click a button to validate it, and copy/paste the generated code in his project. Nothing persisted on the server. No installation, always the latest version and potentially, as mentioned by @dogtopus, easier integration to existing project's code.

In my opinion, that would be so much easier to maintain than a version for Windows, Mac, etc.

At last, I have no strong opinion on the commercial aspect, other than everyone is entitled to a living for his work if one desires.
If required, advertisement on the hosted page could be a good compromise.

[davetcc]

I agree designer has got out of hand as it is now. It's interesting that this started today because I had the realization last night that I could not continue to support a UWP App, a Native Cocoa App, along with a Java app on Windows 7, and a Linux app too. That's why I'd decided to consolidate onto Java to remove as many variables as possible.

Maybe we are all looking at this from the wrong angle, and a different solution may suit us all. Could a C++ DSL based on macros make it possible to develop directly in the C++/INO file? I'm sure it's possible to come up with something where the code is readable enough that no designer is needed whatsoever. The current plugins are a separate problem, but those could be dealt with once the DSL was in place. They could be dealt with by building out the examples further and making the plugins more self-contained.

EG something like:

SubMenu(SettingsMenu,
   BooleanItem(core params...),
   FloatItem(core params)
)

EnumEntries(Enum1, "entry 1", "entry 2", "entry 3" )

RootSubMenu(
   AnalogItem(core parameters....),
   EnumItem(core parameters...),
   SubMenu(SettingsMenu)
)

If we could get to this level of simplicity for most cases, intermediate and advanced users could generate the structure without a designer. The java designer could be kept around for people who prefer this way of working. I don't even think this is that much work to try it out..

[dogtopus]

Could a C++ DSL based on macros make it possible to develop directly in the C++/INO file?

I'm not entirely sure on this. On one hand it's probably gonna be really simple to write by hand but OTOH it might make IDEs having a even harder time trying to figure out what's going on with the definitions...

Also macros are inherently not as robust as XML/JSON with schema or even plain C++ and more undesired behaviors may be introduced.

[davetcc]

I will probably try to implement this as an option for those who don't want to use the designer at some point soon. Most C++ code relies heavily on preprocessing and macros anyway, so I doubt it will cause too many problems. What I am thinking would be very light on macros actually, and some of it would be function-based. From a compiler perspective, it would be barely more complex than now.

[davetcc]

Summary: You can remove the commercial use stuff, and I just ask that you keep a link back to the tcMenuLib git hub page.

Long story:
To be honest, I've looked at it, and writing a C++ DSL is probably not something we can do any time soon. I would say that on reflection, it's good to have another choice of designer anyway, for people like yourself and intensite who don't want the full designer app on their devices.

I'll look to expand the plugins in the main repository so that they can be used more easily without relying on a zip.

Now that we are down to one version of Designer, the Java one, we'll put back all the UX improvements that were in the MacOS app store version, to improve usability including removing mandatory registration for all users.

After long deliberation, we've decided to drop the need for commercial users to require registration, as we don't require it in the App store anyway. So you can remove that after all, apologies for the runaround there. Instead, we'll probably ask that commercial users make a voluntary small donation towards all three libraries' upkeep and handling of issues on the tcMenuLib page.