2011/2/2 Mani N C <man...@gmail.com> > > Hello All, > I need your comments/Inputs for the possible solutions, > 1. Write a Wrapper class for KoAbstractApplicationController which would have > all the slots and signals in it and Child(MainWindow) can create a object of > the wrapper and connect the signals to it. > 2. Remove QMainWindow inheritance from MainWindow.h and have it as a private > member of MainWindow class. In this approach we can make > KoAbstractApplicationContoller to Inherit from QObject. > 3. Have the same design but while building check if it is built > out-of-source-tree and add/remove headers from KoAbstraction. > Jaroslaw, Thanks for your hint. But I guess it can't be used in this > scenario. since we need to define slots in children(MainWindow.cpp) as well. > Or Have I got it wrong ?
I am looking at possibility of using template+aggregation. So a variant of #1. Isn't it a problem to wait one or two days more with this? > Br, > Mani > > On Tue, Feb 1, 2011 at 1:14 PM, Jaroslaw Staniek <stan...@kde.org> wrote: >> >> ok.. small hint; by coincidence I've encountered >> KEXI_DATAAWAREOBJECTINTERFACE code in >> kexi/widget/tableview/kexidataawareobjectiface.h. It'a a Q_OBJECT-like macro >> that inserts connecting methods to a class. Maybe similar macro could be >> useful in this case. >> >> >> 2011/2/1 Mani N C <man...@gmail.com> >>> >>> My bad, I agree we won't be able to connect signals. The problem I have is >>> when f-office is compiled out-of-tree the gives errors. I am trying to fix >>> this in such a way that it would compile in-source and out-of-tree. Thanks >>> for your comments, I will try to emit pure virtual methods and see. >>> Br, >>> Mani >>> >>> On Mon, Jan 31, 2011 at 7:23 PM, Jarosław Staniek <stan...@kde.org> wrote: >>>> >>>> This is an automatically generated e-mail. To reply, visit: >>>> http://git.reviewboard.kde.org/r/100462/ >>>> >>>> One of the solutions is to have emit*() pure virtual methods in the >>>> controller and implement them in f-office to emit real signals. >>>> >>>> Sebastian, you wrote in ba54ba08 3 days ago that something did not build. >>>> But it did before... >>>> >>>> - Jarosław >>>> >>>> On January 31st, 2011, 12:07 p.m., Mani Chandrasekar wrote: >>>> >>>> Review request for Calligra. >>>> By Mani Chandrasekar. >>>> >>>> Updated Jan. 31, 2011, 12:07 p.m. >>>> >>>> Description >>>> >>>> This patch removes KoAbstraction class which implements >>>> KoAbstractionContorller. >>>> >>>> Since we are reimplementing most of the functions in MainWindow.cpp I have >>>> removed KoAbstraction class and moved all the signals to MainWindow >>>> I feel the implementation should be in freoffice code instead of >>>> abstraction library. >>>> >>>> Is there any possible drawbacks in this approach? >>>> >>>> Diffs >>>> >>>> tools/CMakeLists.txt (d4e6ab5) >>>> tools/f-office/CMakeLists.txt (a212bc0) >>>> tools/f-office/MainWindow.h (f7b6149) >>>> tools/f-office/MainWindow.cpp (549b7d1) >>>> >>>> View Diff >>> >>> >>> -- >>> Mani Chandrasekar >>> >> >> >> >> -- >> regards / pozdrawiam, Jaroslaw Staniek >> http://www.linkedin.com/in/jstaniek >> Kexi & Calligra (kexi-project.org, identi.ca/kexi, calligra-suite.org) >> KDE Software Development Platform on MS Windows (windows.kde.org) > > > > -- > Mani Chandrasekar > -- regards / pozdrawiam, Jaroslaw Staniek http://www.linkedin.com/in/jstaniek Kexi & Calligra (kexi-project.org, identi.ca/kexi, calligra-suite.org) KDE Software Development Platform on MS Windows (windows.kde.org) _______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
