---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/100462/#review1384
---
I suggest that if http://git.reviewboard.kde.org/r/100640/is pos
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/100462/#review1379
---
Now final (?) fixes pushed to tools-koabstraction_refactoring1-s
On Thursday 10 February 2011, Jaroslaw Staniek wrote:
> FYI
> The refactoring is mostly done (compiles), so now it'll be tested.
>
> http://community.kde.org/Calligra/Libs/KoAbstraction#Refactoring
>
One thing I'm running into right now (I'm trying to make it possible to close
FreOffice and to
FYI
The refactoring is mostly done (compiles), so now it'll be tested.
http://community.kde.org/Calligra/Libs/KoAbstraction#Refactoring
--
regards / pozdrawiam, Jaroslaw Staniek
http://www.linkedin.com/in/jstaniek
Kexi & Calligra (kexi-project.org, identi.ca/kexi, calligra-suite.org)
KDE Softw
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/100462/#review1276
---
The development happens on branch tools-koabstraction_refactorin
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/100462/#review1275
---
OK, I am contributing "a small" refactor with separate controlle
2011/2/2 Mani N C
>
> 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.
>
Thanks a lot for your inputs.
I will check with Marijn regarding that.
Br,
Mani
On Wed, Feb 2, 2011 at 1:31 PM, Boudewijn Rempt wrote:
> On Wednesday 02 February 2011, Jaroslaw Staniek wrote:
>
> > Just a thought:
> > BTW, do we want to consider having separate git repo for the
> > alternative
On Wednesday 02 February 2011, Jaroslaw Staniek wrote:
> Just a thought:
> BTW, do we want to consider having separate git repo for the
> alternative GUIs, or even one-per gui? With the current infrastructure
> it's quite easy. And this could show the 3rd-parties that there APIs
> allow for such d
On 2 February 2011 08:48, Boudewijn Rempt wrote:
> On Wednesday 02 February 2011, Pierre Stirnweiss wrote:
>> 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
On Wednesday 02 February 2011, Pierre Stirnweiss wrote:
> 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
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 o
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 inheritan
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
> My bad, I agree w
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,
M
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/100462/#review1134
---
One of the solutions is to have emit*() pure virtual methods in
> On Jan. 31, 2011, 1:34 p.m., Jarosław Staniek wrote:
> > I wonder what happens if you move the signals. It will be not possible to
> > connect to them in KoAbstractApplicationController code since
> > KoAbstractApplicationController cannot inherit QObject. The hack with
> > including .moc fi
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/100462/#review1132
---
I wonder what happens if you move the signals. It will be not po
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/100462/
---
Review request for Calligra.
Summary
---
This patch removes KoAbstrac
19 matches
Mail list logo
