this list hasn't been updated since 2013.
David Edmundson also told me that removing it was discussed recently, so
here we go! the combobox is simply replaced with a static qlabel for the
current kaboutdata, working under the assumption that when you click
report bug you want to report one for the current application not all
the stuff on bugs.kde.org
Details
Details
it builds and it can report against kwrite
Diff Detail
Diff Detail
- Repository
- R263 KXmlGui
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Comment Actions
I think the application should have a way to provide a list of components to choose from, to avoid losing the feature of selecting a component here, and therefore to make life easier for people triaging bugs.
See line 332 which supports components as part of product names like "kmail2/composer, kmail2/filtering etc.".
This could be splitted out though, i.e. given that kmail2 comes from kaboutdata::productName(), all that's need is a QStringList like "composer, filtering, etc."
I guess it would have to go into KAboutData as well, given that kxmlgui provides the standard action for report bug (apps don't instantiate KBugReport directly)
Comment Actions
We can query all components of a product dynamically from the bugzilla API as a matter of fact. I intentionally decided against this though because it is duplicating a choice we already have in bugzilla. The dialog redirects to the bugzilla report page, so the user has the option to choose a component there anyway which would mean listing them in the dialog adds nothing of value.
e.g. in dolphin I select report bug -> click Launch Bug Report Wizard -> https://bugs.kde.org/enter_bug.cgi?format=guided&product=dolphin&version=19.12.0 -> I can select a component (or leave it at the default).
| src/kbugreport.cpp | ||
|---|---|---|
| 333 | Oh, OK. Well then this code should be removed too. | |
| src/kbugreport.cpp | ||
|---|---|---|
| 333 | It's been a couple weeks, but I think appname here is the appname member variable, which is set to the productName of the KAboutData, so splitting that is required to keep backwards compatibility. Even though the product/component format is not actually documented, it is used in about half the software that set a productName https://lxr.kde.org/search?_filestring=&_string=setProductName So since we need to filter out the product out of product/component format string anyway, we may as well split and use the component as before when available. | |
Comment Actions
Oh OK. Talk about a hidden feature... How about we actually document this in setProductName?
"kate/kwrite" is actually a great use case for it.
Comment Actions
Mh, I actually was lying it's documented on the setter https://api.kde.org/frameworks/kcoreaddons/html/classKAboutData.html#a0167de5a0565e61e57e8f6ee7dcce71b :)