aacid added a comment.
In D18179#391915 <https://phabricator.kde.org/D18179#391915>, @michaelweghorn wrote: > In D18179#391664 <https://phabricator.kde.org/D18179#391664>, @aacid wrote: > > > Maybe an enum is better than a bool so if in the future more scaling options are implemented we don't need to change the signature again? > > > Sounds reasonable. I'll change that in the next version. INLINE COMMENTS > michaelweghorn wrote in fileprinter.h:82 > I don't really feel up to the task of convincing you. :D > The only point I can come up with is that your comment in > ab96e0c07def2f572a8bb3e32f90e597e6761627 > <https://phabricator.kde.org/R223:ab96e0c07def2f572a8bb3e32f90e597e6761627> > indicates that that commit //might// have broken binary compatibility already > and thus it might be worth considering bumping the so version anyway (in > which case I think this here should no longer be any problem, but I haven't > really had to deal with binary compatibility in the past). > > Otherwise, I don't mind adding the suggested extra methods. > > Will those extra methods then stay there forever or can the methods then be > "merged" again once another ABI-incompatible change is done? > > Just out of curiosity: Do you know of specific applications/third-party > generators,... that use libokularcore? I'm almost sure that doesn't break binary compatibility since it's a template and thus the code would end up on the app side and not the library side, but i didn't want to lose sleep making sure. Once we break ABI we could merge them back, if people realize :D calligra has a few generators for odt, odp using calligra libs. REPOSITORY R223 Okular REVISION DETAIL https://phabricator.kde.org/D18179 To: michaelweghorn, #okular, ngraham, sander Cc: aacid, fvogt, okular-devel, ngraham, darcyshen
