[Kexi] Using KoProperty in Kolf

[Jaroslaw Staniek]

2009/9/21 Stefan Majewsky <majewsky at gmx.net>:
> Another idea: We use the same CMakeLists, but in the parent directory of
> KoProperty, we define some variable ${KOPROPERTY_TARGETNAME}, which is used
> anywhere in the CMakeLists instead of the target name "koproperty". This
> should make it easier to keep the CMakeLists in sync (e.g. if I want to add or
> remove some files from the build) while avoiding conflicts. I would set the
> variable to something like "kolfproperty" then, while you stay with
> "koproperty".

OK, feel free to commit this change (assuming you also commit addition
to koffice/kexi/CMakeLists.txt).

>> Then I also propose to remove the install( FILES ***.h ... ) section.
>> We'd avoid conflicts this way I guess.
>
> +1

I mean rather: comment out them. I also don't need to install them in
case of kexi.

>> I hope kdelibs wont become such a kitchen sink for everything we have..
>> It is already enough to use it on stripped down installations and on the
>>  mobile.
>
> If only kdelibs was as modular as Qt.
>
>> So yes, I wish we had the lib in kdesupport.
>
> Okay, noted inside my brain. I'll not insert any KDE dependencies.

Actually we have them, but as said, can be moved to separate libraries
providing factory(ies).
So you can do the same if you need editors that are even dependent on Kolf.

Also regarding being part of Qt - I don't think so, since the generic
answer so far was "we have already propety editor provided by
Designer".
IIRC there was 1 additional project (or even 2) in Qt Solutions, looks
like dropped already.

-- 
regards / pozdrawiam, Jaroslaw Staniek
 Kexi & KOffice (http://www.kexi-project.org, http://www.koffice.org)
 KDE Libraries for MS Windows (http://windows.kde.org)
 http://www.linkedin.com/in/jstaniek