[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Google Online document Plugin for KOffice
From:       Inge Wallin <inge () lysator ! liu ! se>
Date:       2010-07-05 7:40:48
Message-ID: 201007051040.48572.inge () lysator ! liu ! se
[Download RAW message or body]

On Sunday, July 04, 2010 12:28:42 Thomas Zander wrote:
> On Sunday 4. July 2010 08.57.51 Inge Wallin wrote:
> > On Friday, July 02, 2010 23:16:57 Thomas Zander wrote:
> > > > I really would like to see this committed :-)
> > > 
> > > Having this in svn or git is certainly good, would love to see this
> > > too.
> > > 
> > > I don't really mind where this goes really, just wanted to take this
> > > opportunity to bring up the way that I've seen this handled in Plasma,
> > > the plugins are developed in a staging area and when they are of
> > > sufficient quality they are released together with the rest of the
> > > plugins.
> > > 
> > > The reason I bring this up is that we are getting more and more plugins
> > > in our main repository that don't actually pass our main criteria for
> > > release. The vector shape can't save yet as an example.
> > 
> > That is true, but I'm working on that as you may have seen from various
> > mails that I have written.
> 
> Yes, it was purely an example. :)
> 
> > That said, what *are* our main criteria for release for shapes?  Can you
> > point to the wiki page?  (I'm offline when writing this, otherwise I
> > would search first, but right now I have no idea what we have.)
> 
> We have various rules I've seen go past here; the "it should save what it
> shows" rule seems to apply. Doesn't it?
> But I think that deciding on the staging area to exist is step one,
> agreeing on rules of inclusion in the main koffice release is step two.

Not agreed.  The staging area, if it ever materializes, can only be a result 
of the rules.  We haven't decided on a staging area yet, so it's too early to 
set up anything.

> > > Having an official staging area for the various new koffice plugins may
> > > be a really nice thing to have so developers get more testing and help,
> > > and we can make some rules on when to include the plugins into the main
> > > repo and include them in the main release.
> > > 
> > > Opinions?
> > 
> > As long as this staging area isn't the developers own harddisk and
> > reviewboard, I guess it could be done.
> 
> People keeping stuff on a harddrive until its done is exactly what I want
> to avoid :-)
> 
> > For a staging area to work for me, the following two criteria have to be
> > fulfilled:
> >  * The code has to be completely visible so that other people can see it
> > and help out (as you also write above).
> 
> Definitely agree.
> My first thought was to have something similar to the plugin at; svn
> trunk/playground/office/highlight

This is *exactly* what I want to avoid.  I want it inside the KOffice source 
tree so that it's visible by everybody.  It's unrealistic to assume that 
people will check out various branches and alternative repositories.

> That has the disadvantage of needing cmake work to link to koffice.
> So its probably better to start a base dir with the CMake infrastructure
> already there instead. A "kofficeplugins" dir and the 'highlight' plugin
> can be a subdir of that with minimal cmake infrastructure needed inside
> that subdir because the 'kofficeplugins' dir already does all the
> discovering of the koffice headers etc.

I don't understand what you are proposing here.  Do you want it inside or 
outside of trunk/koffice?  I will be opposed to anything outside of it. Note 
that I'm still talking about where to put things that is destined to be part 
of the koffice package, not externally developed plugins.

> >  * It must be real easy to build a koffice with the "unfinished" shapes
> > included in the build.
> 
> Typing make install in the kofficeplugins dir should do that, so thats easy
> enough.
> 
> Maybe its better to directly start in git, to avoid a conversion later? I
> don't know.
> It should be simple and we have plenty of shapes that fit there. Including
> ones that are created outside of KOffice svn which need love from KOffice
> devs too!
> 
> > And another question arises: Is it too early to do this?  Many
> > applications are not exactly polished yet either.
> 
> Its purely responsive; we have a tree shape that just started, we have a
> formula shape that doesn't save, a vector shape that doesn't save yet.

The formula shape does save.  Only it saves inline, not in an embedded 
document.

> We have externally a marble shape and we have externally a highlighting
> shape. Then this new shape for google documents.
> And naturally the stuff that got unmaintained like plugins/scan/
> 
> So there are people writing these things, instead of working on the main
> apps. Which in my opinion is just fine (excellent news, even!) lets make
> them feel part of our community and have an official place where these
> things can grow and where I can find those plugins whenever i do a
> refactor in Flake so those can keep compiling!
> 
> Another big advantage is that it becomes clear what the status is of a
> certain shape, I'm not sure what the status is of the video shape right
> now. I'm assuming its not finished and thats why none of the OOo written
> documents with video open in koffice. But maybe I'm wrong and I should
> report bugs.

So far, so good.

> Anyway, I'm willing to setup a repository with some top-level cmake files
> that find the koffice libs and headers and then people can add subdirs
> with their plugins which then become very easy to compile and install for
> everyone that has the koffice devel package installed.

In my opinion: No external repositories.  Let's have it inside the main source 
tree.
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]