Hi!
As you might know there will be a K meeting on Sat 3rd at 13:00
here in Malaga.
The meeting will take place in the Mijas room (3.0.4) which is on
Floor 0 of the building with the computer rooms. (See map at the
office)

Saturday 03 September 2005 18.14, Sven Langkamp wrote:
Am Freitag, 2. September 2005 09:51 schrieb Peter Simonsson:
Hi!
As you might know there will be a K meeting on Sat 3rd at 13:00
here in Malaga.
The meeting will take place in the Mijas room (3.0.4) which is on
Floor 0 of the building with the computer rooms. (See map at the
office)

Can someone post a summary of the meeting?

I will do this as soon as I have some time over. Most likely, this will be
later this afternoon / tonight. If you are unlucky, you will have to wait
until tuesday or so.
-Inge

koffice-devel mailing list
koffice-devel (AT) kde (DOT) org

Sunday 04 September 2005 18.03, Inge Wallin wrote:
Saturday 03 September 2005 18.14, Sven Langkamp wrote:

Can someone post a summary of the meeting?

I will do this as soon as I have some time over. Most likely, this will be
later this afternoon / tonight. If you are unlucky, you will have to wait
until tuesday or so.

And here it is! Luckily, the apartment got their ethernet ports turned on, so
I am writing this when it is just 30 minutes until I have to leave for my
flight back home.

Unfortunately, I missed to write down who was there, so the participant list
is from memory. If you remember somebody that I forgot or if I have
misrepresented any of you, please just send a mail and correct it.

Minutes of the K meeting at Akademy in Malaga 2005

Date: Saturday sep 3rd 2005
Present:David Faure, Maintainer of KWord, release dude/manager of K
Thomas Zander, KWord
Peter Simonsson, Maintainer of Kivio
Jaroslaw Jasiek, Maintainer of Kexi
Inge Wallin, Maintainer of KChart
(forgotten name), not yet a koffice contributor but interested nontheless.

1. Discussion about wether to release another version for Qt3, or if we should
go Qt4 immediately. David bargained pretty hard for the Qt4 path, and I
wanted to get another Qt3 based release out. Jaroslaw(?) pointed out that
the Kexi and Krita people really wanted another Qt3 based release out since
they develop so fast. David pointed out that many, many of the bugs in KWord
can't be fixed without the new text rendering features of Qt4.

Decision: Since the port to Qt4 will take a very long time and we don't want
KDE4 to be released without a working K, we will go Qt4 as soon as
possible. David Faure will contact all the maintainers, and get a
confirmation. We will also help Kexi and Krita make their own releases
outside the standard schedule of K (A tip might be to look at the
release script created for the stand-alone releases of Kalzium by Carsten
Niehaus.)

2. New component in K: a mindmap application.

Inge wanted to have KDissert in K because it would complement the
current components nicely. It was pointed out that now was a good time to do
this since we will have a long time until the next release to work on the
integration with the rest of K

Decision: Inge approaches the maintainer of KDissert and asks wether he is
interested.

3. Discussion about how to attract new developers.

Some points made (I am in a bit of a hurry now, so I will write a more
in-depth mail about this later):
- The API docs should be better. There is now a feature that creates the
docs automatically by typing "make apidocs". What is missing is often a
top-level description of the design and usage of each library. In every
library there should be a file called mainpage.dox that should contain such a
description. The maintainers of the libraries are urged to create such a
file as soon as possible!

- Because of the upcoming switch from Qt3 to Qt4, there is a unique
opportunity to find small and easy jobs to start the K programming
career. We should make this clear to the community (see also point 5 below).

- We should try to get out more information on the dot, since this is where
the KDE developers tend to get their information. The switch from Qt3 to Qt4
and a call for new developers would be a good example of such a story.

4. We need to have some non-coder contributors as well.

There was a discussion about the website for K, and the need of a
maintainer of it. Comparisons where made to the kdeedu website, which is
really great, and the fact that they have a person who is really in
maintaining it. The skills needed to code an application and to maintain a
website are not the same, and we need to appreciate non-coders contribution
as well. examples would be doc writers and PR people.

5. PR

After a very short discussion where I stressed the need to make more people
aware of the fact that K exists, I was chosen to be the K
Marketing and PR Coordinator. My main task will be to work with the people
working to create PR for KDE in general and point out to them what a great
application suite K is, and that it in some ways is much better than
, namely:
- It is faster
- It is smaller
- It is much better integrated into KDE

As a side note, I will start this new assignment by trying to get a number of
articles written in various magazines. My angle will be the new and very
important new file format Document, that is supported by K and
soon also 2.0. I have already managed to do so in Sweden (the article is
not out yet), and I don't expect it to be any more difficult in the rest of
the world.

6. Some technical discussions about code sharing, and style handling.

No decision came out of this. It was agreed that code sharing was good, but
at this point people were getting tired and restless so they just wanted to
get out. It was generally agreed that code sharing will take place during the
ongoing work and not here at Akademy.

, that's it. Have I forgotten anything? Please speak up now or forever
hold your peace.
-Inge

Monday 05 September 2005 18:12, Martin Ellis wrote:

We were going to distribute lib/koproperty with the next Kexi release,
since koproperty wasn't released with 1.4, and hence won't conflict.

the other hand, if you release all of lib with your next Krita release,
then the next Krita packages probably will conflict with the next Kexi
packages.

solution is for you to release only the libraries in lib that you have
changed, and bump up their .so versions, so that they can be installed
alongside the existing versions from K 1.4 without conflict.

Thoughts?

I wouldn't have been at the meeting anyway because I had to leave Friday, so I
don't know how far people are willing to run to help us out -- but I have a
couple of points:

* I am on the verge of sharing chunks of code (palette, toolbox, layerbox)
between Krita, Karbon and Kivio. Besides that, there are a couple of bugfixes
necessary in the K libs to make the next release of Krita really smooth
(object sharing is the big one, but the warning-on-save is another one).

* We need a bugfix release really soon, as in, last week. This is quite
urgent. The chaos in Malaga and my illness made it impossible to do right
then, but it's a critical thing!

* Waiting for a Qt4 version of K before releasing the next feature
version of Krita will mean that we will have missed the window of
opportunity: both the Gimp and Cinepaint appear to be feeling, judging from
mailing list and cvs activity, the presence of hot coals in the trouser
seats. They will want to catch up with, and I want to release before that.
So, an official feature release in April 2006 at the latest, one that will be
picked up by all major distributions is necessary.

* At the same time, Qt 4 is so tempting that I've been thinking of doing a
pure Qt 4 port of Krita But my life is full enough already.

My preference would be to do a bugfix release of K next week; and a
K 1.5 release with improved Krita, Karbon and Kexi early next year. I'm
not sure I have heard a probable release date for a Qt4 based K, but if
it's going to be two years in the future, then that's just too long away.

Another option I've been mulling about is to create two K modules:
K, and K, so to speak, with Kivio, Karbon and Krita in
the latter package. Both use the same basic libs, but the porting to Qt4 can
start by forking the libs, and then start with sec. But that would have all
sorts of compatibility problems, of course, when embedding.

(Ps. -- would it be worth it to redesign embedding to fit in with the new Qt
Scribe API?)

Monday 05 September 2005 18:47, Boudewijn Rempt wrote:
* I am on the verge of sharing chunks of code (palette, toolbox, layerbox)
between Krita, Karbon and Kivio.

Big redesigns sound exactly like the thing to do after porting to qt4+kdelibsSnapshot :)

Besides that, there are a couple of bugfixes
necessary in the K libs to make the next release of Krita really smooth
(object sharing is the big one, but the warning-on-save is another one).

Bugfixes can be done in the 1.4.x branch anyhow.

* We need a bugfix release really soon, as in, last week. This is quite
urgent. The chaos in Malaga and my illness made it impossible to do right
then, but it's a critical thing!

I can't do it before September 18, I'm right now flying to the USA, from where
I don't have access to my desktop machine (where the l10n checkout is).
I plan to buy an external hard disk for my laptop, maybe some of my harddisk
space problems will be solved that way, for the future.

* Waiting for a Qt4 version of K before releasing the next feature
version of Krita will mean that we will have missed the window of
opportunity: both the Gimp and Cinepaint appear to be feeling, judging from
mailing list and cvs activity, the presence of hot coals in the trouser
seats. They will want to catch up with, and I want to release before that.
So, an official feature release in April 2006 at the latest, one that will be
picked up by all major distributions is necessary.

* At the same time, Qt 4 is so tempting that I've been thinking of doing a
pure Qt 4 port of Krita But my life is full enough already.

This is quite contradictory, isn't it? :) You want a koffice-1.5 and you want
a Qt4 port (which could be done on top of the soon-ported kolibs, no need to
go "pure Qt"!!!) at the same time? I don't think we have the man power for
that (at least in the rest of koffice).

My preference would be to do a bugfix release of K next week; and a
K 1.5 release with improved Krita, Karbon and Kexi early next year. I'm
not sure I have heard a probable release date for a Qt4 based K, but if
it's going to be two years in the future, then that's just too long away.

No, not two years. Around one, rather. That's the whole point of starting to
port now instead of later. If we go 1.5, we can't port now, this would only mean
merging hell for a year.

Another option I've been mulling about is to create two K modules:
K, and K, so to speak, with Kivio, Karbon and Krita in
the latter package. Both use the same basic libs, but the porting to Qt4 can
start by forking the libs, and then start with sec. But that would have all
sorts of compatibility problems, of course, when embedding.

Not sure what sec means (I guess it's not "security"), but anyway, I fail to
see the point if it's only for porting.

(Ps. -- would it be worth it to redesign embedding to fit in with the new Qt
Scribe API?)
In theory embedding should be unrelated to text engines, it should work
even for non-text-based apps We can and should redesign embedding,
but in a general way if possible.

Please, remember that Kugar is also using koproperty. Perhaps Kugar should be
included in the kexi-based K release. That said, I would hope that
Kexi maintainers are only planning on one more release before the port to
Qt4.

Let's not have a long period where everything but Kugar/Kexi/KProperty is
ported to Qt4 only to play catch-up. It would delay the rest.

Adam

Monday 05 September 2005 12:12 pm, Martin Ellis wrote:
Monday 05 Sep 2005 16:44, Bart Coppens wrote:
Monday 05 September 2005 17:25, you wrote:
I think that koffice-1.5 would be more suited :-)

If we don't release a new koffice I don't think that it's a good idea
to create a koffice-1.5 branch.

The problem is that there are changes in kofficelibs since the 1.4
release, on which krita depends (something in kofficepainter I think,
Boudewijn knows more about that). So we'd have to release a new
kofficelibs release anyway, either independent of krita (and kexi?), or
together with them. I think we'll have less trouble if we'd release them
together, but of course that's just my opinion. In any case there is a
need to release a new kofficelibs, and then koffice-1.5 doesn't sound too
confusing or bad

We were going to distribute lib/koproperty with the next Kexi release,
since koproperty wasn't released with 1.4, and hence won't conflict.

the other hand, if you release all of lib with your next Krita release,
then the next Krita packages probably will conflict with the next Kexi
packages.

solution is for you to release only the libraries in lib that you have
changed, and bump up their .so versions, so that they can be installed
alongside the existing versions from K 1.4 without conflict.

Thoughts?

Martin

koffice-devel mailing list
koffice-devel (AT) kde (DOT) org

Hello,
Inge asked me to add some more info related to the 'Minutes of the K
meeting' report.
FYI: Please consult the following:
#4._What_about_Kugar_

Monday 5 September 2005 11:41, Inge Wallin wrote:
Sunday 04 September 2005 18.03, Inge Wallin wrote:
Saturday 03 September 2005 18.14, Sven Langkamp wrote:
Can someone post a summary of the meeting?

I will do this as soon as I have some time over. Most likely, this
will be later this afternoon / tonight. If you are unlucky, you will
have to wait until tuesday or so.

And here it is! Luckily, the apartment got their ethernet ports turned
on, so I am writing this when it is just 30 minutes until I have to
leave for my flight back home.

Unfortunately, I missed to write down who was there, so the participant
list is from memory. If you remember somebody that I forgot or if I
have misrepresented any of you, please just send a mail and correct it.

Minutes of the K meeting at Akademy in Malaga 2005

Date: Saturday sep 3rd 2005
Present:David Faure, Maintainer of KWord, release dude/manager of
K
Thomas Zander, KWord
And KPlato and representing Krita interrests.

Peter Simonsson, Maintainer of Kivio
Jaroslaw Jasiek, Maintainer of Kexi
Inge Wallin, Maintainer of KChart
(forgotten name), not yet a koffice contributor but interested
nontheless.
That was Kevin

5. PR
After a very short discussion where I stressed the need to make more
people aware of the fact that K exists, I was chosen to be the
K Marketing and PR Coordinator. My main task will be to work with
the people working to create PR for KDE in general

This is called the Marketing workgroup.

and point out to
them what a great application suite K is, and that it in some
ways is much better than , namely:

[snip]

Cheers!