> On Sept. 19, 2011, 8:34 p.m., Jan Hambrecht wrote: > > Is there any reason why you are not using > > KoShape::setApplicationData/KoShape::applicationData? > > C. Boemann wrote: > yes it already used for kotextshapedata in text shapes > > Jan Hambrecht wrote: > I only found places where a frame is set to a shape as application data. > However why not have a WordsApplicationData class where you collect all the > data needed for words? Wouldn't that be a lot cleaner instead of adding > application specific data to the api of KoShape? You even described it in > your summary as "extra user data for applications". > > C. Boemann wrote: > ok, it is frames and not textshapedata that is stored there. > > however I'd like to access the anchor data from the kotext and textlayout > libraries so it's not application data. > > Also i need to transfer the anchor info from kotext library to words, so > if not through koshape then i need to modify KoTextSharedLoadingData to > transfer it. > > still it doesn't solve library access to it. > > > In short this is the cleanest solution by far
Okay, I'm going to modify KoTextSharedLoadingData instead. I'll have to figure out library access later - C. ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102666/#review6641 ----------------------------------------------------------- On Sept. 19, 2011, 3:52 p.m., C. Boemann wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/102666/ > ----------------------------------------------------------- > > (Updated Sept. 19, 2011, 3:52 p.m.) > > > Review request for Calligra. > > > Summary > ------- > > Stores a new class KoAnchor on shapes. It's kind of like an extra user data > for applications that support anchoring. > > By having a pointer from the shape to anchoring information lot's of code in > words become easier to maintain. > > Plus we will be able to finally support smart positioning of page anchored > shapes in words > > I tried to keep it out of flake, but since it was impossible to transfer that > data from KoTextLoader to words without going through hoops, and we already > had two methods in KoShape that I could change hold this (in effect void) > pointer I chose the latter. > > Tables will be able to attach it's own variation of anchoring info to KoShape > too by doing it's own subclassing of KoAnchor just like kotext does with > KoTextAnchor > > > Diffs > ----- > > libs/flake/CMakeLists.txt 4311bd0 > libs/flake/KoAnchor.h PRE-CREATION > libs/flake/KoAnchor.cpp PRE-CREATION > libs/flake/KoShape.h 55f8e97 > libs/flake/KoShape.cpp 1c3fcef > libs/flake/KoShape_p.h d055056 > libs/kotext/KoTextAnchor.h 0819c9b > libs/kotext/KoTextAnchor.cpp f324505 > libs/kotext/opendocument/KoTextLoader.cpp 6ce4695 > words/part/KWRootAreaProvider.cpp 6c30e28 > > Diff: http://git.reviewboard.kde.org/r/102666/diff > > > Testing > ------- > > > Thanks, > > C. > >
_______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
