IDE Version 2.0.0 - why remove MX ?

[jcslb]

Why, oh why have you separated IDE and MX such that .ioc files can no longer be opened in IDE?

I cannot imagine any benefits and it makes the IDE significantly worse, such that I've felt compelled to revert to version 1.19.0 ( go to Help -> About STM32CubeIDE -> Installation Details -> Installation History -> select version -> Revert)

I couldn't find any other means of feeding back my strong dislike of this change other than a post like this. I hope version 2.1.0 comes out soon and re-integrates MX and IDE!

[McClean]

Oh.. i dont believe it! The version 2.0 suxx. How can st ruin a fine solution without any need? 

[vybor]

ST software team is deceiving customers. Two separate applications require more resources than one integrated.

Separated solution require one more JVM and load some common resources second time. ST needs new software team. Any way, it's not serious to worried about two hundred dollars to add 32 GB of RAM to developer workstation.

[vybor]

Problem of CubuMX is terrible product architecture. 

It not use OSGi possibilities. It is old home made product. It is a mess of plain jars with old classpath headache.

Dynamic OSGi platform is exelent base for product like CubeMX. It has functional to add, update and remove separate bundles. No need to invent wheel and spend money and time.

Bad interface, when parameters are edited in tiny window, which must be scrolled, a big area is occupied by useless at the time pinout view. GUI must be redesigned to be more dynamic.

ST had several years to make CubeMX good and stable Eclipse RCP application which can be used as standalone app to be used with any IDE. And can be used in CubeIDE without problem.

ST used OSGi very badly, export and import directives in manifests do not use version ranges. It is amateur level.

[fred bar]

I would not go that far. The software team does what product managers plan to do. Problem is not how it is done, which would be on their shoulders. Problem is the direction the product is headed to, which is above them.
Anyhow, i always felt eclipse was a bad choice, VC is not a better choice. If only they used netbeans at the beginning, and now switched to a being a jetbrains clion plugin, we would all be in much better hands and using much better technical solutions.

[vybor]

OSGi is exelent base if used right.

CubeMX does not use OSGi. It is not Eclipse RCP application.

CubeIDE is badly made Eclipse RCP application.

JetBrain use Java for C/C++ IDE and it is work fine.

Look at MANIFEST.mf files in CubeIDE. They are terribly bad.

Eclipse 4 does not impose any restrictions on the graphics library used.

OSGi is one of the best and usefull Java specification.

[vybor]

Cube is sample of total negligence.

Look at MCU/MPU selector. It is student's work.

When main window had started user even don't start select a MPU. Nevertheless, table in right-botton side contains

all the MCUs. It is wastefull use of resources.

All MCUs has prefix STM32. User have to type useless 5 symbols. After each new symbol request is made and two

lists is updated and filled with new items. Very long at begining. Now one use long lists for scrolling while searching. If items not fit in visible area, user enter next symbol to narrow presented list. 

Presented MCUs product info is useles, when developer starts CubeMX to develop product, he know about target MCU much more than presented in CubeMX selection window. All this functionallity can be safelly removed.

Now there is bad selection process

1 user enter s - app handle request and filled two list with all 4876 MCUs. Useles info, too long to scroll.

2 user enter t - the same

3 user enter m - the same

4 user enter 3 - the same

5 user enter 2 - the same

6 user enter H - 387 MCUs are found. too long to scroll.

7 user enter 5 - 131 MCUs are found. too long to scroll.

8 user enter 0 - 13 MCUs are found. At this step there is convenient list to select from

In good GUI search proccess must start from step 6. 3 symbols to enter. Now one have to enter 8.