TouchGfx generated project name

[john-6]

Here is what I see as ST's idea of a TouchGfx workflow.
Create a GUI project, import that project into an IDE, which in my case would be STM32CubeIDE.
Click on the .project file to import into the IDE with the same name as the board.  (Disregard and project name provided during the TouchGfx project creation.)
Experiment with the project, jump back and forth between TouchGfx and the IDE.
Throw the project away and you're on your own as to how to create a standalone GU project with STM32CubeIDE.
Nice, for seeing examples but essentially useless for creating a basis for a real project.

A real workflow would allow you to generate a TouchGfx project with an .ioc and a .project reflecting a name you want to use rather than the board name.  I don't want to use CubeMX to manually adjust many pins and parameters in order to have the board be functional as the base for a GUI.

It would provide a way of importing into the IDE, that allowed for the file structure created within TouchGfx to be totally integrated into the local workspace in such a way that you could still jump back and forth between the IDE and TouchGFX.

I've seen this issue touched on over and over and haven't seen a viable solution.  Modifying file names and .project file contents to fit within the desired IDE structure, works for compilation, but doesn't allow you to go back to TouchGFX to modify the GUI, without once again modify filenames and .project files.

I haven't seen one solution that gets me an STM32CubeIDE solution with the names I want that still allows the use of both tools without messing with names and content.

Just modifying TouchGfx Designer to create projects and .ioc files with the names provided as the project name would go a long way toward a viable development workflow.  I would be interested to know why the designers of TouchGFX decided to name every project and .ioc file the same name as the board.  This prevents a user's ability to import two GFX projects into the same workspace!

I don't believe you can provide me with a method to accomplish what I want within the existing software infrastructure.  Consider this a suggestion for an immense improvement.

[MM..1]

In your monologue you skip one important info. Is target project for DK or an ready boards, or your custom pcb, lcd,memory ... Your explained ST idea too isnt ST idea, because TGFX is long ago other company project...

Then FYI exist two basic ways:

1. your start project in TGFX = problem in names and custom hw, but prepared for DK etc.

2. start create project in MX or IDE MX = setup custom name and hw, normal way for real products.

Both require special clone rename steps in IDE, but this is Eclipse based. Simpler is in KEIL ...

[john-6]

Thanks for responding.

I didn't mention the device for the target project, which was a DK in this case, because it was irrelevant to the problem I was trying to describe.  Regardless of the device, TouchGfx creates the same project name for every project using that device.  This is one of the bigger problems with the TouchGfx tool, and it should be simple to correct.

Another improvement would be to allow the user to select the tool chain they want to use and have TouchGfx generate the project files for that tool chain in a structure that would seamlessly fit into the desired IDE's model.

 As you say I could do things the hard way as specified in your two options, but why would ST force users into either of those two methods?  People buy Discovery Kits and Eval products so that they can experiment with different technologies and quickly build working prototypes of projects that can be expanded to become the basis of a new product.  I appreciate all of the free tools that ST provides for the STM32Cube framework.  They aren't perfect but they work exceedingly well for my needs except for TouchGfx.

I just think that if there is a team still working on TouchGfx, they should consider the issues I've raised rather than just writing it off by saying you can work around the issues with a lot of manual work.