Here's my 2c.
Overall a step (several steps!) in the correct direction, well done.
TouchGFX downloads a windows msi package that will not install on Linux.
I tried to use the 'Graphics simulator' on a STM32F429ZI Disco and that doesn't work - none of the pins are assigned let alone imports of the libraries. OK, I see TouchGFX is still being integrated and there are problems on the 746 as well. The middleware item 'Graphics' is greyed out but is active. The dropdown to select 'Graphics Framework' and 'Graphics Display' are similarly greyed out but inactive.
As a result one never knows what the colours on the IDE mean and the user is always confused. The greyed 'graphics' texts above are inactive, others are inactive, a grey cancel button is active! Text colouring should obey de facto standards and never be confusing. The graphics department need to understand the day to day needs of technical users.
Consistent icons, colours and shading are vital in order to get IDEs accepted. Grey should be reserved for 'Inactive' as with almost all GUI applications (it was a Windows, XServer and IBM GUI standard some years back, ). The graphic designers are wrong, it is misleading, more difficult to read, ambiguous and error prone. Software developers have sufficient other problems not to need to add poor graphics to them.
Grey text on white and vice-versa is difficult to read in certain light conditions, as is light yellow (or any other colour) on white or cream. Bring the contrast to usable levels.
Can we get right button and mouse over explanatory text? Where do I get documentation on what 'Graphics Simulator' means? (Right Click ->Help????)
Come to think of it, help should be available from anywhere ... right down to Reference manual RMxxxxx level.
I would also, in some cases, just want the old BSP graphics, TS drivers, Buttons, I2C peripherals - nowhere to be found other than digging and copying them deep in the file system.
The 'Additional Software' items need more than just a short description hidden at the right hand side. Clickable documentation links would help, Mouse over balloons would be better.
Rather give single option defaulted to the current release (it is a new project isnt't it?) than all versions. Use the screen space freed to provide a better description of the library (LS3xx Accellerometer and Gyro is better than MEMS, which could be anything). I need at this time to know what the device DOES and not its technology.
The old cube did not seem to remember that I was working with a board level product. The new one does not even give me the option to 'set all peripherals to default values' and include the necessary drivers.
The IDE should be extended to provide a board level view as well as the chip level view. Something like the Open MBED colour coded cards would be SO nice to have in the IDE.
It is interesting to note that nearly all the above comments do not require great changes and development of the code base, they require the presentation team to creatively use and present the features already available.
Am I the only one with this perspective?
