Review Request: Patch for using KoAbstractionController directly from FreOffice

[Pierre Stirnweiss]

I might be missing something, but I thought we decided that in-source
building would not get supported in Calligra. Why is it necessary for
Calligra mobile?, Why the exception?
I think that if it is not absolutely necessary to build in source, then we
should drop the possibility and have only out of source build set up.
Especially if having the two enabled means having to change the structure of
the software in an sub-optimal way.

PierreSt


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 ?
>
> 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
>
>
> _______________________________________________
> calligra-devel mailing list
> calligra-devel at kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/calligra-devel/attachments/20110202/184b154b/attachment.htm>