have the designer be more PlatfromIO compatible/friendly

[emaayan]

currently the designer only allows placing all the source file in src folder
in certain configuration this sort clutters the src file because you can have several configuration in a src folder
you can create an src filter that will pickup a main file based on a name scehem matching the configuration
so for example main-nano.cpp would have just a arduino env:nano configuration and will use only main-nano config
but main-esp32 will use env:esp32 etc..

if the designer could be configured to place src files in a more flexible locations that would help

addtionally the designer could automatically locate the platfrom.io file and be able to know what tcmenu libraries it has (it could modify it automatically)

or just build a plugin for platfrom io ;) (kidding ... or am i, platfromio itself is cli driven after all)

[davetcc]

I do ask any other users to chip in here please and feel free to contradict what I've said here, at the end of the day, I'm just another user of the UI, and have a way of working with it that I'm used to.

Ref the clutter, that will go away in 3.2, there are new source location options, that create a generated folder, both within the src directory, or at the top level.

I would say designer works pretty well with platformio (I use it pretty much exclusively, using both Arduino IDEs now and again to confirm it works there too, but it does not attempt to integrate too deeply, there are too many combinations, for example, I use platformIO integrated into CLion IDE, others may use another IDE, there is no way to know across all these IDEs which environment is chosen in a given IDE.

You can see how I use it for reference (I basically set my libraries directory to the lib directory in this repo): https://github.com/davetcc/tcLibraryDev and then I manually keep the libraries up-to-date. The choice here is yours, but I really don't want to make designer fish around in the hidden directories trying to guess which environment is active.

However, I think there is a little low-hanging fruit that can be provided in designer, through the designer CLI - https://www.thecoderscorner.com/products/arduino-libraries/tc-menu/tcmenu-cli-workflow/ I could add a --platform option to the generate command, to allow you to change the active platform direct from the CLI, right before you were going to build. So you'd do something like

tcmenu generate --platform ARDUINO32

[tomelgato]

Not sure if i do something wrong, on PlatformIO
But i ended up letting the Designer save the *menu.c and *menu.h file to my source directory. Then i rename and move the h file to my includes location.
The main files i discard or copy out the newly added things and add to my source.
So yes, i agree to the threadstarter that a configuration for target dirs & names would be very welcome ;)

[davetcc]

I mean basically, if there's some low-hanging fruit, that can be optionally enabled for advanced users, I'd be up for doing some small modifications to the code generator once I've recovered from adding the multi-language and Unicode support. Those two have really taken a bit of a toll, they have taken a lot longer to implement than expected and even left some other projects I wanted to work on stalled for some time now.

But at the moment I don't think I'm completely clear on what we're talking about here, it seems that 3.2 will solve a few of the issues people have, but not all. As I see it there are a few things that could be done with low cost.

• Add an option to the CLI "generate" command that provided the platform so that it is easier to build for different boards. EG something like tcmenu generate --platform ARDUINO32
• Provide an option when using platformIO to write header files into the include directory (turned on by selecting an advanced option).
• There is already an option to not create the callbacks in the main sketch file, the callback function "edit" button allows you to only define the callback function and implement it yourself. Are you saying you don't want the main to be created at all?

[emaayan]

i may wait for 3.2 to get a better feel of it, but for example let's say i need to generate 2 emf files, for one project ,they will both use the same code base libraries to call, but the menus would be for example one for LCD arduino one for OLED.

[davetcc]

I think let's wake this up after 3.2 as all my focus at the moment is on a few critical bugs in the library and getting Unicode/i18n over the line.

[tomelgato]

I think it would be already helpful if you can configure per project / emf file the target paths and names of the builder files in designer.

Btw. what happens if the designer code build finds an existing file with modifications (main.cpp)?

[davetcc]

As per last discussion let's wake this up after 3.2 is out, and I've had chance to recover from the really large dev tasks that have come out of it. At the moment, I can't think properly about this and this needs a lot of thought to ensure we don't break anything.

[davetcc]

I've opened #409 to discuss at least the starting point for this. I think the first pass would focus on being able to change plugins per environment as that's been asked for a few times, and I can see that being useful for us as well in our projects, and my first take is to have another drop-down under platform that chose the "environment" IE plugins to use. This gives the most flexibility and allows all processors with all possible hardware combinations. Then from the cli it would be possible to do something like: tcmenu generate --platform ARDUINO32 --env OLED_ROTARY_WIFI or tcmenu generate --platform ARDUINO --env ANALOG_DF_ROBOT

I'd be up to make a few smaller changes at the same time to make it fit better with advanced workflows, but it would have to be in a way that did not clutter the UI with too many options, or make the default case more complex. I think that given most would be platformio and Arduino CLI users integrating this into the tcmenu cli command would be preferable.