Just one question.

[All4Gis]

I just found out about the existence of this plugin and wanted to know what the difference is with this one https://github.com/All4Gis/CustomToolBar I developed 4 years ago and migrated to QGIS3.
The idea is the same (create toolbars for the user) I don't know what improvements you have in the code but the idea is the same from what I see.

I would just like to have information, because maybe you can integrate ideas such as drag and drop.

regards

[s-m-e]

@All4Gis Thanks for your message. By the time we started developing this project, your plugin was not available for QGIS 3. I just saw that you made it work in QGIS 3 in December. The version of toolbargenerator in this repository is a cleaned up version following quite a few different unpublished prototypes from the past about two years. One of the ideas is to have a solid "shared library" for more QGIS interface experiments. Lot's of infrastructure code is therefore shared between workbench, toolbargenerator and some more still unpublished plugins. The second idea was to become more flexible / robust with respect to finding / identifying "actions" in QGIS - the kind of task where you read your configuration (when QGIS starts) and reconstruct a toolbar from it. We've experimented with many different solutions for what you are doing in obtainAction. Changing / adapting your code for all of those methods was near impossible without a significant rewrite, to be honest, and I tried - which is why our more flexible approach was born. The entire dtype_action class deals with this problem in a fairly self-contained manner. Yet even our current solution does not work reliably, though more than yours in some spots, due to a problem that both of our plugins do not solve: Internationalization. If a user changes the interface language, both plugins break, because they then fail to identify actions. The third idea that differs is the on-disk format. Your plugin appears to be relying entirely on Qt's build-in serialization functionality, with all of its lovely edge cases and traps. I have learned the very hard way not to rely on this which is why we use a significantly more general purpose approach: A simple JSON-based format where we can control every bit of structure ourselves. One of the added benefits other than not depending on Qt is that it is fully platform independent, which is why our toolbars become exchangeable. You can export, share and import them (as long as all participants use QGIS in the same language).

Please do not understand me wrong. I do not want to trash your work - by no means. I am just trying to explain why we decided to go for a new plugin. I have to admit that one of the things I really like about your work is the configuration dialog. It's drag-and-drop enabled, ours is not. It also looks more modern and structured while our dialog is essentially inspired by UI "standards" from the 90s, a quick and dirty solution ;) By the time we published this prototype, we had spent way more time testing the underlying data models to death. Our UI could really use a facelift.

If you are interested in joining forces one way or the other, let's have a discussion :)

[All4Gis]

Thank you for answering.

In my development you can exchange tools between users, simply sharing the file ".CustomToolbars" https://gis.stackexchange.com/questions/286163/where-does-qgis-plugin-customize-toolbar-save-its-changes . is a coded file but I did so for convenience in his day, can be changed,and it's multiplatform too. On the other hand in my case does not solve the issue of internationalization, I asked in the QGIS list years ago. How to do ,but as you also access the actions of plugins is quite complex that. http://osgeo-org.1560.x6.nabble.com/Customize-Toolbars-plugin-td5214358.html

That is to say it does everything the same as yours except obviously compatibility with its other development, from my point of view

I have nothing against its development, but the idea already existed and is a plugin that works in QGIS3. When these things happen I like to refer to the original idea or the original development.we are in Open-Source world, but not everything goes.

You can simply adapt the original or do the same improved but always referencing the original idea. I understand that you didn't know of its existence but now you know.

We can collaborate or you can take ideas from mine, but always putting the reference to the original or first idea for QGIS.

[elpaso]

Just for reference, there was this one too: https://github.com/planetfederal/qgis-profiles-plugin QGIS 2.x though.

[s-m-e]

@All4Gis Crediting your work: Sure. I have pushed a new branch, issue_7. Please review. Nonetheless, to be clear, having functionality for creating custom toolbars in GUI applications has been around for as long as I can think, at least since the early 1990s. I remember doing this in MS Office 95 for instance. From this point of view, the idea in general is not new and we never said it was. In contrast, it is rather surprising that QGIS does not offer this natively.

Import/export: At the moment, if I understand your code and your answer correctly, import/export of your toolbars requires to ship the entire configuration of your plugin, i.e. all configured toolbars together. Your plugin can not import or export individual toolbars. You can also not import and export through the GUI - the user needs to locate the configuration file in his/her filesystem. This is the typical kind of problem that QGIST (and therefore the Toolbar Generator) intends to address: Audiences without meaningful technical background or noteworthy programming skills, who are likely to fail at this task. I have yet to write proper documentation, but if you try our plugin, you will see that you can import and export individual toolbars. Our data model treats them as independent, "atomic" objects.

Yes, your plugin is multiplatform - it works on multiple platforms. I suppose I have not made myself clear: Your plugin entirely relies on QDataStream and the build-in serialization of Qt-objects (read and write methods of QListWidgetItem for instance). On one single machine and operating system, this is a solid solution. But as soom as you are exchanging files written like this between different platforms (and, as such, different versions of Qt), it becomes unreliable from my experience. Not only is it therefore difficult to locate the configuration file - it can also be tricky to read it. This is yet another issue that is trivial with some programming skills but virtually impossible to solve without.

As a sign of good faith, I am going to improve the compatibility to your plugin. Toolbar Generator should be able to import settings and toolbars from Customize ToolBars in a reliable manner. We can also look into a similar export functionality.

Primary objective for this project is to produce extremely reliable GUI code. GUI application users are not supposed to touch code, clone git repos or dig for configuration files. The plugins therefore have to deal with all problems and contingencies themselves. Clean data models are part of that.

@elpaso Thanks for highlighting this older plugin.

[All4Gis]

Don't worry and I appreciate your act of good faith (that serves me well).

It doesn't make sense to keep two such similar plugins. I've already fixed bugs and user requests such as adding geoprocesses to the list and I don't have time to make improvements now.

I prefer that you if you are active with this development, take ideas from mine if you want as drag and drop etc and include them in your development if you want. If I have time I will collaborate with this plugin.

I'm closing the question.