Review Request: Patch for using KoAbstractionController directly from FreOffice

[Jaroslaw Staniek]

2011/2/2 Mani N C <maninc at 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 <staniek at 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 <maninc at 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 <staniek at 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)