| Frameworks |
In freedesktop.org specification, the category is Network. Most applications
under this category can also be used in local network, like FTP client,
browsers, P2P clients, cloud storage clients. So I think "Network" is the
best name for this category.
The "Internet>Terminal" category actually doesn't include anything because it
doesn't have a <Include> block. "Terminal" sub-category is already included
in "System" category. So I removed it.
Depend on D24424
| No Linters Available |
| No Unit Test Coverage |
| Buildable 17343 | |
| Build 17361: arc lint + arc unit |
I wonder how to untangle this dependency, because a change in Frameworks can't (shouldn't?) depend on a change in a consumer (yes, same issues as toys).
+1 based on the explanation of following the FDO spec more closely. I'll leave Frameworks folks to figure out how to untangle the implementation details. :)
kf5-network.directory has been added to plasma-workspace.
The trouble is still here: if we land this patch and released new frameworks, it won't work with older plasma workspace (like 5.17.0, 5.16.x).
Maybe pinging a few Plasma people may be more effective, or though a mailing list thread. I don't know.
The trouble is still here: if we land this patch and released new frameworks, it won't work with older plasma workspace (like 5.17.0, 5.16.x).
Talk me through what will happen. Do they end up in lost and found?
In terms of the circular dependency, it does indeed seem very weird. Task for the KF6 board at least.
So, the state is:
ksycoca needs to know the name of the menu to use at compile time
That menu is therefore in the framework
The directory files it references are not.
IMHO the part that seems most wrong is that ksycocacocacooca needs the name at compile time. If we were on gnome we would want to load gnome's menu structure surely? Though maybe we need to at least have some menu so that ksycococoaoca loads all the applications even if they end up in the wrong "dir".
I also think these *.menu and *.directory files should not be required at compile time. And they should better be in same repository because they are connected so closely.
In this patch, we added a new file kf5-network.directory in plasma-workspace and reference it here. But this means frameworks 5.65 will depend on plasma-workspace 5.18. Any other combination, like frameworks 5.65 + plasma 5.17 or frameworks 5.64 + plasma 5.18, will break.
The dependency D24424 has been landed three month ago. Do you think it is safe to ship this patch now?
The question is the same. What happens with older Plasma with newer Frameworks?
It may be that nothing really breaks, of course.
Then how about I copy this file applications.menu to plasma-workspace? After one or two years, we can delete this file from frameworks. But for compatibility, it will exist in both repositories for some time.
It is still does not answer the question on what happens with *already released* Plasma.
if we copy applications.menu to plasma-workspace and patch it there, it will only be shipped with future plasma releases.
Existing released plasma can still get the old menu from kservice even with newer frameworks and it is not updated.
Isn't it going to conflict with the kservice-provided one? I simply don't know, but it should be answered before deciding.
If it does not conflict, do you mean postpone the kservice patch until Frameworks 6?
I am not 100% sure. It seems installed under /etc/xdg/menus/*.menu. You can install as many *.menu files as you want but keep different names.