libdbusmenu-qt: bundled and static, or standalone?

[redtide]

I forgot about this, should we do like ksystemnotifieritem and make it a bundle or making yet another standalone and make it as external dependency?

[sebholt]

Do you mean, should we make it a static library or a dynamic library, as discussed in this stackoverflow question.

I'm in favor of making it dynamic library. It's probably harder to pack, but we can make fixes to the library (e.g. to the dbusmenu part) without having to rebuild all apps that use it. Also it avoids (some) license clashes. For example I'm unsure what the legal status of a static LGPL-2 library in a MIT licensed application (QasMixer) is. It's all open source, so I'm not too worried, but I know that Debians legal people care about this stuff.

[redtide]

I guess so 😞
I would like to have this one to replace the old until KDE people could accept my proposition and then remove our version in favor of their one.
libdbusmenu-qtilities? IDK.
As said in the lxqt-panel issue, I strongly believe that lxqt and kde teams should adopt the project and maintain it for anyone in a single repository.

[sebholt]

We can decide on that later, since the libdbusmenu-qt isn't on the public side of libstatusnotifieritem.
If it is easier for you to bundle it now, then let's do that. We can link to libdbusmenu-qtilities in later releases without having to change the ABI/API of libstatusnotifieritem AFAIK.

Also related, please see #2

[redtide]

I asked it to avoid to upload also those file and start immediatly by linking to it from the beginning, so also have the right CMakeLists, but if this makes things complicated for ABI compatibility then OK, let's bundle it.

[sebholt]

I think it doesn't matter if we bundle or link libdbusmenu-qtilitiessince we don't make it's interface public in libstatusnotifieritem. The only method/symbol that must stay unchanged is

• StatusNotifierItem::setContextMenu.

That's the only Menu related method/symbol that we export.

[redtide]

If this is the case I would like to keep its code out of the repo and history and start immediatly with a project apart, to be replaced later by, if will be, a new working and maintained libdbusmenu-qt.

[redtide]

I invited you to the project. Same problem because of private or can you see it?

I almost finished locally to setup the project, except some details about the CMake targets and I discovered that the updated version in KSNI has only the DBusMenuExporter class, not also the Importer, so I guess there will be some work to restore the old one and update it to work correctly like the other?

[sebholt]

I invited you to the project. Same problem because of private or can you see it?

No, it's all good this time. I accepted the invitation, thanks.

[redtide]

I added some stuff but still not working because missing references in libraries.
dbusmenu is kinda done but I suspect there is no exported symbols, IDK what it miss or what is made in the wrong way, I'm too tired now :P