Version 2.2.0Alpha - question regarding menu restructuring

Hi,

I am looking for clarification as to why certain main window text menu elements have been removed.

There are now some inconsistencies that are showing up within the program because these do not exist.

I don't agree with restructuring the main text menu structure of an application unless there are compelling reasons to do so.

Right now some of the plugin elements that are dynamically assigned to the menu structure are now orphans and end up out of sequence.

....typical output after starting up the application after a small amount of menu use is as follows..

void DBusMenuExporterPrivate::addAction(QAction*, int): Already tracking action "&Delete selected" under id 36
void DBusMenuExporterPrivate::addAction(QAction*, int): Already tracking action "&Fullscreen" under id 38
QG_LayerWidget::update: nullptr lastLayer
void DBusMenuExporterPrivate::fillLayoutItem(DBusMenuLayoutItem*, QMenu*, int, int, const QStringList&): No id for action
void DBusMenuExporterPrivate::fillLayoutItem(DBusMenuLayoutItem*, QMenu*, int, int, const QStringList&): No id for action
void DBusMenuExporterPrivate::fillLayoutItem(DBusMenuLayoutItem*, QMenu*, int, int, const QStringList&): No id for action
void DBusMenuExporterPrivate::fillLayoutItem(DBusMenuLayoutItem*, QMenu*, int, int, const QStringList&): No id for action
void DBusMenuExporterPrivate::fillLayoutItem(DBusMenuLayoutItem*, QMenu*, int, int, const QStringList&): No id for action
void DBusMenuExporterPrivate::fillLayoutItem(DBusMenuLayoutItem*, QMenu*, int, int, const QStringList&): No id for action
void DBusMenuExporterPrivate::fillLayoutItem(DBusMenuLayoutItem*, QMenu*, int, int, const QStringList&): No id for action
void DBusMenuExporterPrivate::fillLayoutItem(DBusMenuLayoutItem*, QMenu*, int, int, const QStringList&): No id for action
void DBusMenuExporterPrivate::fillLayoutItem(DBusMenuLayoutItem*, QMenu*, int, int, const QStringList&): No id for action
void DBusMenuExporterPrivate::fillLayoutItem(DBusMenuLayoutItem*, QMenu*, int, int, const QStringList&): No id for action
void DBusMenuExporterPrivate::fillLayoutItem(DBusMenuLayoutItem*, QMenu*, int, int, const QStringList&): No id for action

Sadly, this is one reason, why we are still in alpha state.

The changeover was very extensive and has happened now. I agree with you, this was not only a win for LibreCAD, there were couple of issues meanwhile. Not only from coding view, also users were irritated.

We have to think over this. Maybe a comparison between latest release versions 2.0.11, 2.1.3 and master branch 2.2.0 alpha can help.
But we also have to consider the new toolbar and menu creator features, which were trigger for menu reorganization I think.

I'm not opposed to restructure the menu again, but it has to make sense.


Armin

OK... I found the changes were made around issue #698 ...just as an fyi

My particular view on text menus are that they are like streets within a city.
People become familiar with the routes available and choose the path that
makes the most sense for them.

When people rip up the streets in the city it gets everyone in an uproar.

I liked the approach borland provided with the original windowed quattropro(spreadsheet).

They provided the standard menu.
Then they provided a mapping tool that would allow you to restructure the menu to your own liking,
save that mapping to a new filename, and assign it as the default menu you wished to have loaded on application startup.   The 'default' menu was always available as the fall-back if people really screwed up their menu structure...and people that wanted to customize were free to 'play'.  But they did not interfere with people that were used to the existing structure.  

Unfortunately Borland fell afoul of Lotus and their 'Look-and-feel' lawsuit....and that set the lawyers up for the next 10 years.

The lesson I learn from Borland is that if you wish to allow for changing the menu structure you should not change it yourself.  Especially if it has been around in it's current form for a long time.

Adjust the menu structure so that the menu itself can be 'tokenized' and the actions have handles that can be accessed at runtime.  Then provide a bootstrap routine to build the menu structure at runtime on application startup.  Borland's approach even provided provision to map 'hot-keys' to specific actions.

The menu configuration file can be as simple as a xml file with a special extension ...such as 'default.mnu' ...
and if you have concerns that a default.mnu file can be corrupted you can ensure continuity by ensuring each application revision has a command-line switch that allows a 'factory-reset' of the default.mnu file to the standard menu structure for that version of the application.

As to whether you use a command line switch or a line in a central configuration file to specify the location and name of the menu structure file to be loaded on startup...that is a decision for the community to make.