Review Request 126660: Avoid finding the same package multiple times from different paths.
Sebastian Kügler
sebas at kde.org
Thu Jan 7 16:28:08 UTC 2016
> On Jan. 7, 2016, 3:31 p.m., Sebastian Kügler wrote:
> > src/kpackage/packageloader.cpp, line 190
> > <https://git.reviewboard.kde.org/r/126660/diff/1/?file=428735#file428735line190>
> >
> > What does the category have to do with this? We should only be going by the id (the plugin name).
>
> Andreas Hartmetz wrote:
> Depends on the scope in which an ID is guaranteed to be unique. If it's guaranteed to be globally unique and independent of category, sure, I'm all for not making it more complicated than necessary.
>
> Andreas Hartmetz wrote:
> Given that the ID falls back to the metadata file name without extension, and that you can have the same file name in different directories, it seems like you *could* have a package of the same name in different categories. The same goes for names supplied by the data in the metadata files. Some names make sense in several places.
>
> Andreas Hartmetz wrote:
> Sorry, the part about the filename doesn't apply. It comes from the documentation of KPluginMetaData::pluginId() which doesn't apply here, given that the files are all called metadata.desktop or metadata.json.
Yes, and the directory name is actually the same as the plugin name -- you can rely on that. So just a stringlist would in fact already be enough, but as I said ... why not use lst to check if it's already in there. Performance, I guess?
But yes, the only thing we need to look at is the plugin id. Nothing else matters. Well, we need to make sure that the most-local plugin is actually put in the list, otherwise you can't override with locally installed ones.
> On Jan. 7, 2016, 3:31 p.m., Sebastian Kügler wrote:
> > src/kpackage/packageloader.cpp, line 187
> > <https://git.reviewboard.kde.org/r/126660/diff/1/?file=428735#file428735line187>
> >
> > This doesn't actually add anything. A better name would IMO be: alreadyListed() or something along those lines.
>
> Andreas Hartmetz wrote:
> It also adds it to the list, though.
>
> Andreas Hartmetz wrote:
> The point is that it isn't const, and it also has a return value that matters. The name -sort of- conveys both.
That list is internal and shouldn't be reflected in the API, though... (We may entirely circumven this issue, see below.)
- Sebastian
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126660/#review90755
-----------------------------------------------------------
On Jan. 7, 2016, 3:21 p.m., Andreas Hartmetz wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126660/
> -----------------------------------------------------------
>
> (Updated Jan. 7, 2016, 3:21 p.m.)
>
>
> Review request for KDE Frameworks, kdelibs, Plasma, and Marco Martin.
>
>
> Repository: kpackage
>
>
> Description
> -------
>
> That was a problem in a scenario such as mine, where I have distro
> packages and self compiled packages. There were (from the UI)
> indistinguishable, duplicate packages in the panel's add applets
> UI, in the tray config dialog's "additional items" section, and
> probably in other places, too.
> Note that requiring to have no duplicate packages in XDG_DATA_DIRS
> by removing entries from XGD_DATA_DIRS doesn't fly because /usr
> cannot be removed for the non-KF5 things that it brings.
>
>
> Diffs
> -----
>
> src/kpackage/packageloader.cpp 9f7dd48
>
> Diff: https://git.reviewboard.kde.org/r/126660/diff/
>
>
> Testing
> -------
>
> Checked for duplicate entries in "add applets" and tray config dialog, no duplicates anymore. Also no duplicates anymore in KWin effects KCM.
>
>
> Thanks,
>
> Andreas Hartmetz
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20160107/38a364db/attachment.html>
More information about the Kde-frameworks-devel
mailing list