Re: Using KoProperty in Kolf

[Jaroslaw Staniek-3]

2009/9/18 Stefan Majewsky <majewsky@...>:

> Hi,
>
> as I pointed out in a blog post last month, I'm looking for a property editor
> to use in the course editor of the minigolf game Kolf 2. KoProperty looks very
> well suited for this job, but I would like to clarify some points with you:
>
> 1. How can we go about integrating KoProperty into the Kolf sources? Simply
> copying all files is not good, because you're actively working on it (and I'll
> probably also want to make some modifications, see below). svn:externals also
> seems not to be an option, because the build system seems to require a build
> of the complete KOffice.

Stefan, thanks for your interest :)
I propose copying (branching) the code as temporary solution.
I think about having the lib as Qt-only and putting it somewhere
outside of koffice.
Until then I guess we could exchange patches. Doing that please also
alter the cmake file, in particular change the name to something like
kopropertykolf or so. Later you shall be able to change to shared
qt-only library and packagers would not notice anything except just a
need for adding additional dependency.

Please not that your special editors and types could be implemented
outside of koptoperty in factories delivered by plugins. This could
avoid many internal modifications.

> 2. Which storage backend does KoProperty use? I need to read QMetaProperties
> from QObjects, and write values back in.

Own property set "Set" class and "Property" item is used.
You'll be able to map your Qt properties to these easily. In fact I do
that in Kexi Forms but since other uses of KoProperty are not based on
Qt properties, this code is not shared.
I am open to have it in KoProperty though.

> 3. I need to add support for my own data types (three-dimensional variants of
> QPointF, QSizeF, and QRectF). Is this possible?

It's possible to add of course and I am open for supporting you.
Reasonable medium where we can share the docs on how to use the
framework is probably techbase. How do you like it?

--
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
_______________________________________________
Kexi mailing list
Kexi@...
https://mail.kde.org/mailman/listinfo/kexi

[Jaroslaw Staniek-3]

2009/9/19 Stefan Majewsky <majewsky@...>:

> So for now, I would create a static copy of KoProperty as you described.
> Are you signed up on reviewboard.kde.org? This should ease patch management
> quite a bit.

I am, we could use koffice group for now...

> I'll try to create a patch for that next week, in order to get into the code
> structure and such. I have a question with that, though: How do you handle
> localizable captions for the properties (and the localizable title, e.g.
> "Table field" in Kexi's table designer) currently?

see Property::setCaption(), Property::caption()

> Techbase is a good idea. As I pointed out on Planet KDE some time ago, I'm
> very interested in extensive API and design documentation. You can also expect
> comments on and patches for the KoProperty API from my side, whenever
> appropriate.

Great!

> P.S. You have CCd some related mailing lists. Should I subscribe to these?

That's good idea, at least kexi@..., which is very silent one.

--
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
_______________________________________________
Kexi mailing list
Kexi@...
https://mail.kde.org/mailman/listinfo/kexi

Hi again,

I've looked into the source of KoProperty, and tried if I can get KoProperty
to build standalone (only with KDE 4 dependencies loaded) in a quick-and-dirty
way. What I've noticed immediately:

1. Some parts of KoProperty seem to depend on other code from Kexi:
        a) EditorView.cpp includes kexiutils/styleproxy.h
        b) editors/spinbox.cpp needs the KoUnit class
2. It still needs Qt3Support:
        a) Property.{h,cpp} use QVariant::{CString,PointArray}
        b) editors/pixmapedit.cpp needs some old Qt::WindowType values

What can we do to sort out these issues? They're blocking me from building
KoProperty without Kexi.

BTW another question on the build process: Once we get KoProperty to the point
that it does not need Kexi anymore, I could simply include it into the Kolf
repository with an svn:externals definition. Is this okay for you?

Greetings
Stefan


_______________________________________________
Kexi mailing list
Kexi@...
https://mail.kde.org/mailman/listinfo/kexi

[Jaroslaw Staniek-3]

2009/9/20 Stefan Majewsky <majewsky@...>:
> Hi again,
>
> I've looked into the source of KoProperty, and tried if I can get KoProperty
> to build standalone (only with KDE 4 dependencies loaded) in a quick-and-dirty
> way. What I've noticed immediately:
>
> 1. Some parts of KoProperty seem to depend on other code from Kexi:
>        a) EditorView.cpp includes kexiutils/styleproxy.h
>        b) editors/spinbox.cpp needs the KoUnit class

I am copying the class then, hopefully today.

> 2. It still needs Qt3Support:
>        a) Property.{h,cpp} use QVariant::{CString,PointArray}
>        b) editors/pixmapedit.cpp needs some old Qt::WindowType values

Please let me look at this today...

> What can we do to sort out these issues? They're blocking me from building
> KoProperty without Kexi.
>
> BTW another question on the build process: Once we get KoProperty to the point
> that it does not need Kexi anymore, I could simply include it into the Kolf
> repository with an svn:externals definition. Is this okay for you?

OK, unless you want to release Kolf in a binary form. Then we'll have
conflict between KOffice and Kolf.
So I propose to svn branch and merge changes (there will not be too
many I guess?).

Two copies won't be needed once we move the code to the outside of
kolf and koffice (but where?).

--
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
_______________________________________________
Kexi mailing list
Kexi@...
https://mail.kde.org/mailman/listinfo/kexi

[Jaroslaw Staniek-3]

OK,
Stefan, I've just commited a fix for qt3 dependency and removed
(unused anyway) dependency on styleproxy.
If there are other issues, you may want to fix them e.g. by disabling
some editors, e.g. those that depend on kobase library (KoUnit class).
We'll move such things to a separate plugin I guess.

--
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
_______________________________________________
Kexi mailing list
Kexi@...
https://mail.kde.org/mailman/listinfo/kexi

Am Sonntag 20 September 2009 21:38:26 schrieb Jaroslaw Staniek:

> > What can we do to sort out these issues? They're blocking me from
> > building KoProperty without Kexi.
> >
> > BTW another question on the build process: Once we get KoProperty to the
> > point that it does not need Kexi anymore, I could simply include it into
> > the Kolf repository with an svn:externals definition. Is this okay for
> > you?
>
> OK, unless you want to release Kolf in a binary form. Then we'll have
> conflict between KOffice and Kolf.

The first release of Kolf will most definitely be with KDE/kdegames 4.4. Until
then, a better solution than svn:externals should be available. For now, we
could also change KoProperty into a static lib, and not install the library
and its headers, in order to avoid conflicts? (Is KoProperty used anywhere
outside Kexi at the moment?)

> Two copies won't be needed

svn:externals is not a copy. It is a special property for a subdirectory of an
SVN repository, that tells SVN to checkout this part of the repository from
some other repository (and commit changes to there also). Much like a symlink.

> once we move the code to the outside of
> kolf and koffice (but where?).

The obvious places would be kdelibs, or kdesupport if the library becomes Qt-
only. We could also try to get it merged into Qt, if the Qt guys are
interested in it.

Greetings
Stefan


_______________________________________________
Kexi mailing list
Kexi@...
https://mail.kde.org/mailman/listinfo/kexi

[Jaroslaw Staniek-3]

2009/9/20 Stefan Majewsky <majewsky@...>:

> Am Sonntag 20 September 2009 21:38:26 schrieb Jaroslaw Staniek:
>> > What can we do to sort out these issues? They're blocking me from
>> > building KoProperty without Kexi.
>> >
>> > BTW another question on the build process: Once we get KoProperty to the
>> > point that it does not need Kexi anymore, I could simply include it into
>> > the Kolf repository with an svn:externals definition. Is this okay for
>> > you?
>>
>> OK, unless you want to release Kolf in a binary form. Then we'll have
>> conflict between KOffice and Kolf.
>
> The first release of Kolf will most definitely be with KDE/kdegames 4.4. Until
> then, a better solution than svn:externals should be available. For now, we
> could also change KoProperty into a static lib, and not install the library
> and its headers, in order to avoid conflicts? (Is KoProperty used anywhere
> outside Kexi at the moment?)

I try to avoid static libs because this increases link time on any
platform I know, what sucks.
I have another idea: what if I move my cmakelists.txt out of the dir
and you will use svn:externals and copy of the cmakelists.txt file
with just changed library name?
Then I also propose to remove the install( FILES ***.h ... ) section.
We'd avoid conflicts this way I guess.

>
>> Two copies won't be needed
>
> svn:externals is not a copy. It is a special property for a subdirectory of an
> SVN repository, that tells SVN to checkout this part of the repository from
> some other repository (and commit changes to there also). Much like a symlink.

sure but I mean copies of installed libs - that would be a conflict,
two libs with the same name and set of headers

>
>> once we move the code to the outside of
>> kolf and koffice (but where?).
>
> The obvious places would be kdelibs, or kdesupport if the library becomes Qt-
> only. We could also try to get it merged into Qt, if the Qt guys are
> interested in it.

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.

So yes, I wish we had the lib in kdesupport.

--
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
_______________________________________________
Kexi mailing list
Kexi@...
https://mail.kde.org/mailman/listinfo/kexi

Am Montag 21 September 2009 00:10:08 schrieb Jaroslaw Staniek:
> I have another idea: what if I move my cmakelists.txt out of the dir
> and you will use svn:externals and copy of the cmakelists.txt file
> with just changed library name?

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".

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

+1

> 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.

Greetings
Stefan


_______________________________________________
Kexi mailing list
Kexi@...
https://mail.kde.org/mailman/listinfo/kexi

[Jaroslaw Staniek-3]

2009/9/21 Stefan Majewsky <majewsky@...>:
> 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
_______________________________________________
Kexi mailing list
Kexi@...
https://mail.kde.org/mailman/listinfo/kexi

[Jaroslaw Staniek]

2009/9/21 Thomas Zander <zander@...>:

> On Sunday 20. September 2009 23.30.08 Stefan Majewsky wrote:
>> > once we move the code to the outside of
>> > kolf and koffice (but where?).
>>
>> The obvious places would be kdelibs, or kdesupport if the library becomes
>> Qt- only. We could also try to get it merged into Qt, if the Qt guys are
>> interested in it.
>
> Qt already has a KoProperty like lib, so I doubt you'll find traction there.
> I think a Qt Quarterly actually explains how to use it for apps, its the one
> used by QtDesigner.

No Thomas, it's different one.

--
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
_______________________________________________
Kexi mailing list
Kexi@...
https://mail.kde.org/mailman/listinfo/kexi