dfaure added inline comments. INLINE COMMENTS
> hallas wrote in kbookmarkowner.h:120 > Good point (both of them) > > What are our binary compatibility promises? Is //every// version of > frameworks always binary backwards compatible? Or do we have a window every > now and then where we can make source compatible changes but not binary > compatible? I don't mind changing this to be using settings and getters, but > that just makes this API stand out from the rest. All the other APIs in the > class are virtual functions which should be overwritten by the actual owner. > I know this does not argue against our binary compatible promise though :D Every version of KF5 is source and binary compatible (just like Qt5). The next time for a possible BC breakage will be KF6 (when Qt6 comes out), so not just yet. Two alternative solutions: - creating a KBookmarkOwnerV2 interface, deriving from KBookmarkOwner. This is a typical solution for extending interfaces, but it's somewhat cumbersome (ugly name, downcasting...). - adding a getter/setter to another class where it would make more sense, maybe KBookmarkMenu? Would the app that you have in mind, have access to it? REPOSITORY R294 KBookmarks REVISION DETAIL https://phabricator.kde.org/D20209 To: hallas, #frameworks, ngraham, cfeck, dfaure Cc: kde-frameworks-devel, michaelh, ngraham, bruns
