Review Request: Patch for using KoAbstractionController directly from FreOffice

Mani N C maninc at gmail.com
Wed Feb 2 07:32:02 GMT 2011


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 ?

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 <http://git.reviewboard.kde.org/r/100462/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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/calligra-devel/attachments/20110202/de8b629a/attachment.htm>


More information about the calligra-devel mailing list