KApiDox udpate
Hi, I have 2 questions about kapidox, as there is no active maintainer, please consider answering even if you don't feel so concerned, because at the end, you are: 1) What scripts except kapidox runs over the metainfo.yml files? Should I keep some keys words for compatibility? 2) For 2 weeks I have a pending review: https://git.reviewboard.kde.org/r/127747/ . In my opinion, it brings a lot of good for project visibility. It's not perfect but usable, and I want that this first proof of concept is used and accepted before making it perfect (or as perfect as possible). Could you give me the magic "Ship it" or else tell me what is wrong for you? I'm ok to become maintainer of kapidox after I get the "Ship it" word. Cheers Olivier -- Olivier CHURLAUD Engineer Student at Ecole Centrale de Lyon in Dual Degree at TU Berlin, M.Sc. Elektrotechnik @: oliv...@churlaud.com tel: +49 (0)1575-2931348 in: http://linkedin.com/in/olivierchurlaud web: http://olivier.churlaud.com
Re: Review Request 127866: Oxygen: Fix QCache usage
> On mei 15, 2016, 8:51 a.m., Hugo Pereira Da Costa wrote: > > To be honest, I am quite puzzle by this whole thing. > > Now, every insertion in the cache requires at least two searches in there > > and (in many case) at least one copy constructor being called. This is > > quite expansive ... (even though this happens only if the object is not > > found in the cache). > > > > Also: not sure I understand what issue we are trying to fix and how: why is > > it that if the object inserted in the cache is immediately deleted, just > > retrying an indefinite amount of time will "fix" the issue. Are we not just > > transforming a crash into a freeze (infinite loop) ? > > > > The Qt documentation is very vague about cases where the object is deleted > > immediately, and the only case it mentions is: " In particular, if cost is > > greater than maxCost(), the object will be deleted immediately." > > Well, in such cases (that should not appear here), the infinite loop will > > not help. Right ? > > Since we have no idea on how "predictible" the other deletion cases are, I > > don't think the fix is a good fix. > > > > Does that mean that we should change the code in order to use references > > rather than pointer everywhere ? (as you did in the first patch on this > > topic) ? > > > > Or get rid of using QCache (because this absence of guarantee at the > > insertion stage is too much of a pain to handle) ? > > > > Or just commit and wait for bug reports about freezes ? (but with a happy > > coverty) ? > > Michael Pyne wrote: > For the most part the requirements are determined by the current return > type within the code. If we return a pointer then currently it has to have > come directly out of the QCache. Since QCache is assumed to be the owner, the > calling code won't delete the pointer ; but if the caller won't delete the > pointer then we'll have a memory leak if we return a pointer to something > that had been new'd instead. > > References (i.e. QColor&) are a similar issue; it's safe enough to return > a reference to something held within the QCache, but we can't return a > reference to a local variable since that reference will invalidate as soon as > we return from the function. Of course a reference to a cached QColor may > *also* invalidate with the next call to an insert method of that cache, but > that's a separate story. > > It is unfortunate that the Qt docs are vague about this, since if the > **only** thing we had to worry about was cost being >maxCost(), we could > pretty much just mark 'ignore' for all the Coverity issues associated with > this (and I'd be fine doing that). The docs do kind of hint at that but don't > make it clear if is the only way that an entry would be deleted immediately. > > I think you're right that a loop is not a good idea... I was figuring > that eventually QCache would remove enough other items to make it work but > then I suppose QCache::insert() would have done that with the very first > attempt. > > As far as other options, I would definitely recommend against QCache for > the QColors: I'd say just hold onto specific QColors directly (perhaps in a > QHash) and, if possible, return them as values instead of references. > > I'm not sure if we could get away with the same for TileSets, but if so > it would again make things easier. If we can't we could look into making > TileSet an implicitly shared class so that we can return it by value cheaply. > > I wouldn't recommend a commit only to make Coverity happy. I've marked > other reports as "False Positive" and even "That's a bug, but we're ignoring > it" before. But it does seem to me that if a crash *is* possible (especially > in underlying library code) we should do something to avoid it. > > Either way I'll see if I can work up a revised patch but I'd still > appreciate advice on what's workable or not within Oxygen. Disclaimer: i'm not an oxygen dev! I just read the patch and want to share my opinion :) I'm also quite puzzeled with this change.. A cache is "usually" being used to store the result of a "heavy" operation and use that result the next time to speed things up. That principle sounds great to me and should be used in places if needed. A better approach would be to speed up the slow operation to make caching simply not needed, but that's a different story. The changes you've made now make QCache usage heavier and most certainly much more difficult to follow because of the added while loops to keep an hypothetical case from happening. If QCache requires measures like this then perhaps we should not be using QCache at all. I understand you're trying to do your best, Michael Pyne, but a patch like this feels like heading in the wrong direction to me.. I don't know if it's usefull, but there is als QPixmapCache [1] (which uses a QCache internally, but seems to behave as a
Re: Review Request 127866: Oxygen: Fix QCache usage
> On May 15, 2016, 8:51 a.m., Hugo Pereira Da Costa wrote: > > To be honest, I am quite puzzle by this whole thing. > > Now, every insertion in the cache requires at least two searches in there > > and (in many case) at least one copy constructor being called. This is > > quite expansive ... (even though this happens only if the object is not > > found in the cache). > > > > Also: not sure I understand what issue we are trying to fix and how: why is > > it that if the object inserted in the cache is immediately deleted, just > > retrying an indefinite amount of time will "fix" the issue. Are we not just > > transforming a crash into a freeze (infinite loop) ? > > > > The Qt documentation is very vague about cases where the object is deleted > > immediately, and the only case it mentions is: " In particular, if cost is > > greater than maxCost(), the object will be deleted immediately." > > Well, in such cases (that should not appear here), the infinite loop will > > not help. Right ? > > Since we have no idea on how "predictible" the other deletion cases are, I > > don't think the fix is a good fix. > > > > Does that mean that we should change the code in order to use references > > rather than pointer everywhere ? (as you did in the first patch on this > > topic) ? > > > > Or get rid of using QCache (because this absence of guarantee at the > > insertion stage is too much of a pain to handle) ? > > > > Or just commit and wait for bug reports about freezes ? (but with a happy > > coverty) ? For the most part the requirements are determined by the current return type within the code. If we return a pointer then currently it has to have come directly out of the QCache. Since QCache is assumed to be the owner, the calling code won't delete the pointer ; but if the caller won't delete the pointer then we'll have a memory leak if we return a pointer to something that had been new'd instead. References (i.e. QColor&) are a similar issue; it's safe enough to return a reference to something held within the QCache, but we can't return a reference to a local variable since that reference will invalidate as soon as we return from the function. Of course a reference to a cached QColor may *also* invalidate with the next call to an insert method of that cache, but that's a separate story. It is unfortunate that the Qt docs are vague about this, since if the **only** thing we had to worry about was cost being >maxCost(), we could pretty much just mark 'ignore' for all the Coverity issues associated with this (and I'd be fine doing that). The docs do kind of hint at that but don't make it clear if is the only way that an entry would be deleted immediately. I think you're right that a loop is not a good idea... I was figuring that eventually QCache would remove enough other items to make it work but then I suppose QCache::insert() would have done that with the very first attempt. As far as other options, I would definitely recommend against QCache for the QColors: I'd say just hold onto specific QColors directly (perhaps in a QHash) and, if possible, return them as values instead of references. I'm not sure if we could get away with the same for TileSets, but if so it would again make things easier. If we can't we could look into making TileSet an implicitly shared class so that we can return it by value cheaply. I wouldn't recommend a commit only to make Coverity happy. I've marked other reports as "False Positive" and even "That's a bug, but we're ignoring it" before. But it does seem to me that if a crash *is* possible (especially in underlying library code) we should do something to avoid it. Either way I'll see if I can work up a revised patch but I'd still appreciate advice on what's workable or not within Oxygen. - Michael --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127866/#review95480 --- On May 8, 2016, 5:03 a.m., Michael Pyne wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/127866/ > --- > > (Updated May 8, 2016, 5:03 a.m.) > > > Review request for kde-workspace and Hugo Pereira Da Costa. > > > Repository: oxygen > > > Description > --- > > This should mostly complete the QCache fixes I kicked off in a previous RR, > 127837. Hugo noted there were many other similar usages, and boy he wasn't > kidding! ;) The long story short is that these usages can theoretically cause > use-after-free behavior (which can lead to crashes and even undefined > behavior if the compiler ever gets smart). > > *NOTE* It is -much- easier to review if you download the diff to your git > repository for oxygen and then
KDE Frameworks 5.22.0 released
15th May 2016. KDE today announces the release of KDE Frameworks 5.22.0.
KDE Frameworks are 70 addon libraries to Qt which provide a wide variety of·
commonly needed functionality in mature, peer reviewed and well tested·
libraries with friendly licensing terms. For an introduction see the·
Frameworks 5.0 release announcement.
Attica
Properly check if a URL is a local file
Baloo
Compilation fixes for Windows
Breeze Icons
Many new action and application icons.
Specify offered extensions as per change in kiconthemes
Extra CMake Modules
Android deployment: support projects without things in share or lib/qml (bug
362578)
Enables KDE_INSTALL_USE_QT_SYS_PATHS if CMAKE_INSTALL_PREFIX Qt5 prefix
ecm_qt_declare_logging_category: improve error message when using without
including
Framework Integration
Remove platformtheme plugin as it's in plasma-integration
KCoreAddons
Provide a way to disable inotify use in KDirWatch
Fix KAboutData::applicationData() to init from current Q*Application
metadata
Make clear that KRandom is not recommended for cryptography purposes
KDBusAddons
KDBusService: turn '-' into '_' in object paths
KDeclarative
Don't crash if we have no openGL context
KDELibs 4 Support
Provide a fallback MAXPATHLEN if not defined
Fix KDateTime::isValid() for ClockTime values (bug 336738)
KDocTools
Added entity applications
KFileMetaData
Merge branch 'externalextractors'
Fixed external plugins and tests
Added support for external writer plugins
Added writer plugin support
Add external extractor plugin support
KHTML
Implement toString for Uint8ArrayConstructor and friends
Merge in several Coverity-related fixes
Correctly use QCache::insert
Fix some memory leaks
Sanity check CSS web font parsing, avoid potential mem leak
dom: Add tag priorities for 'comment' tag
KI18n
libgettext: Fix potential use-after-free using non-g++ compilers
KIconThemes
Use appropriate container for internal pointer array
Add opportunity to reduce unneeded disk accesses, introduces KDE-Extensions
Save some disk accesses
KIO
kurlnavigatortoolbutton.cpp - use buttonWidth in paintEvent()
New file menu: filter out duplicates (e.g. between .qrc and system files)
(bug
355390)
Fix error message on startup of the cookies KCM
Remove kmailservice5, it can only do harm at this point (bug 354151)
Fix KFileItem::refresh() for symlinks. The wrong size, filetype and
permissions were being set
Fix regression in KFileItem: refresh() would lose the file type, so a dir
became a file (bug 353195)
Set text on QCheckbox widget rather than using a separate label (bug 245580)
Don't enable acl permissions widget if we don't own the file (bug 245580)
Fix double-slash in KUriFilter results when a name filter is set
KUrlRequester: add signal textEdited (forwarded from QLineEdit)
KItemModels
Fix template syntax for test case generation
Fix linking with Qt 5.4 (wrongly placed #endif)
KParts
Fix the layout of the BrowserOpenOrSaveQuestion dialogue
KPeople
Add a check for PersonData being valid
KRunner
Fix metainfo.yaml: KRunner is neither a porting aid nor deprecated
KService
Remove too-strict maximum string length in KSycoca database
KTextEditor
Use proper char syntax '"' instead of '\"'
doxygen.xml: Use default style dsAnnotation for "Custom Tags" as well (less
hard-coded colors)
Add option to show the counter of words
Improved foreground color contrast for search & replace highlightings
Fix crash when closing Kate through dbus while the print dialog is open (bug
#356813) (bug 356813)
Cursor::isValid(): add note about isValidTextPosition()
Add API {Cursor, Range}::{toString, static fromString}
KUnitConversion
Inform the client if we don't know the conversion rate
Add ILS (Israeli New Shekel) currency (bug 336016)
KWallet Framework
disable seession restore for kwalletd5
KWidgetsAddons
KNewPasswordWidget: Remove size hint on spacer, which was leading to some
always empty space in the layout
KNewPasswordWidget: fix QPalette when widget is disabled
KWindowSystem
Fix generation of path to xcb plugin
Plasma Framework
[QuickTheme] Fix properties
highlight/highlightedText from proper color group
ConfigModel: Don't try to resolve empty source path from package
[calendar] Only show the events mark on days grid, not month or year
declarativeimports/core/windowthumbnail.h - fix -Wreorder warning
reload icon theme properly
Always write the theme name to plasmarc, also if the default theme is chosen
[calendar] Add a mark to days containing an event
add Positive, Neutral, Negative text colors
ScrollArea: Fix warning when contentItem is not Flickable
Add a prop and method for aligning the menu against a corner of its visual
parent
Allow setting minimum width on Menu
Maintain order in stored item list
Extend API to allow (re)positioning menu items during procedural insert
Re: Review Request 127866: Oxygen: Fix QCache usage
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127866/#review95480 --- To be honest, I am quite puzzle by this whole thing. Now, every insertion in the cache requires at least two searches in there and (in many case) at least one copy constructor being called. This is quite expansive ... (even though this happens only if the object is not found in the cache). Also: not sure I understand what issue we are trying to fix and how: why is it that if the object inserted in the cache is immediately deleted, just retrying an indefinite amount of time will "fix" the issue. Are we not just transforming a crash into a freeze (infinite loop) ? The Qt documentation is very vague about cases where the object is deleted immediately, and the only case it mentions is: " In particular, if cost is greater than maxCost(), the object will be deleted immediately." Well, in such cases (that should not appear here), the infinite loop will not help. Right ? Since we have no idea on how "predictible" the other deletion cases are, I don't think the fix is a good fix. Does that mean that we should change the code in order to use references rather than pointer everywhere ? (as you did in the first patch on this topic) ? Or get rid of using QCache (because this absence of guarantee at the insertion stage is too much of a pain to handle) ? Or just commit and wait for bug reports about freezes ? (but with a happy coverty) ? - Hugo Pereira Da Costa On May 8, 2016, 5:03 a.m., Michael Pyne wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/127866/ > --- > > (Updated May 8, 2016, 5:03 a.m.) > > > Review request for kde-workspace and Hugo Pereira Da Costa. > > > Repository: oxygen > > > Description > --- > > This should mostly complete the QCache fixes I kicked off in a previous RR, > 127837. Hugo noted there were many other similar usages, and boy he wasn't > kidding! ;) The long story short is that these usages can theoretically cause > use-after-free behavior (which can lead to crashes and even undefined > behavior if the compiler ever gets smart). > > *NOTE* It is -much- easier to review if you download the diff to your git > repository for oxygen and then run "git diff -b" to ignore whitespace > changes, particularly for the QPixmap changes. > > For QPixmaps we return values instead of pointers, so we simply make a > separate copy to be cached when we do insert. For QColor we return references > to values so we *must* return pointers, and those have to be owned by a > QCache to avoid memleaks. So I added a helper function to loop until the > cache accepts the new entry. TileSets are a similar concern, except those > have manual loops since I was uncertain about whether TileSet's copy > constructor was the best idea or not. > > This fixes a ton of Coverity issues (59717 - 259733, 259739, 259742 - 259752, > 1336154, 1336155) and might be associated with Qt bug 38142 and KDE bug > 219055 (which doesn't actually appear to be a dupe of a different bug to > me...). > > > Diffs > - > > kstyle/oxygenstylehelper.cpp 612ba37 > liboxygen/oxygenhelper.h a6453a0 > liboxygen/oxygenhelper.cpp 4843604 > liboxygen/oxygenshadowcache.cpp 907e586 > > Diff: https://git.reviewboard.kde.org/r/127866/diff/ > > > Testing > --- > > Compiled without warnings, installed and ran `oxygen-demo5 -style oxygen`. > Used the GUI Benchmark feature to automatically cycle through all the listed > features -- no crashes or obvious rendering errors. > > > Thanks, > > Michael Pyne > >
Re: Review Request 127924: Warn about KDateTimeParser::parseDateUnicode not being implemented
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127924/#review95479 --- +1 - Aleix Pol Gonzalez On May 15, 2016, 10:44 a.m., Albert Astals Cid wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/127924/ > --- > > (Updated May 15, 2016, 10:44 a.m.) > > > Review request for kdelibs and John Layt. > > > Repository: kdelibs > > > Description > --- > > It's been like that for years, so i don't think anyone is actually using it, > but at least give a warning in case someone is. > > I'll do the same thing to kdelibs4support if approved. > > > Diffs > - > > kdecore/date/kdatetimeparser.cpp a416808 > > Diff: https://git.reviewboard.kde.org/r/127924/diff/ > > > Testing > --- > > > Thanks, > > Albert Astals Cid > >
Review Request 127924: Warn about KDateTimeParser::parseDateUnicode not being implemented
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127924/ --- Review request for kdelibs and John Layt. Repository: kdelibs Description --- It's been like that for years, so i don't think anyone is actually using it, but at least give a warning in case someone is. I'll do the same thing to kdelibs4support if approved. Diffs - kdecore/date/kdatetimeparser.cpp a416808 Diff: https://git.reviewboard.kde.org/r/127924/diff/ Testing --- Thanks, Albert Astals Cid
