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

List:       koffice-devel
Subject:    Re: Google Online document Plugin for KOffice
From:       "Dr. Robert Marmorstein" <robert () narnia ! homeunix ! com>
Date:       2010-07-05 16:39:04
Message-ID: 201007051239.04737.robert () narnia ! homeunix ! com
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


> Well, not only has Mani been involved in KOffice for a long time already,
> he's got a KDE svn account, so he's in every respect the equal of everyone
> else in KDE (or KOffice). He can commit any plugin to koffice trunk he
> wants. He did the work, he gets to decide.

I also have an svn account.  So if this is the only concern, I don't mind 
committing things to trunk.  For now, with only a handful of plugins, it makes 
sense for them to be in trunk.  In fact, I'd be very excited to see the 
publish-to-plugin enter trunk and become an "official plugin".

However, I also see Thomas's point.  It would be excellent to have an active 
development community contributing out-of-trunk plugins that distributions and 
users could pick and choose from (especially if they could be accessed with 
"Get-Hot-New-Stuff").  

Unfortunately, I don't feel we are really ready to do this yet.  Right now, 
the koffice API simply isn't stable enough to support a massive 3rd party 
development community.  It is very difficult to maintain plugins when the sand 
underneath your feet is shifting all the time. I'm not complaining -- the core 
koffice libraries simply aren't mature enough yet.  I would rather have solid, 
well-engineered core libraries to work from and that seems to be where we're 
headed.  Maybe in a year or two, things will be better.

Nevertheless, I think it is a good idea to plan for the future.  Setting up a 
"staging area" (preferably based on git) for encouraging 3rd party development 
is a good way to encourage community participation when the API is ready to 
support that kind of development.

Since many potential developers do not have SVN accounts, the staging area 
would need to be out-of-trunk.  Also, it's likely that not everyone would want 
to give up control of their code to the koffice developers by moving code to 
trunk.  Furthermore, trunk may not be the appropriate place for many plugins 
with utility to only a small number of users -- doesn't anything in trunk need 
translation strings and so forth?  I'm not sure it's a good idea to tie up 
koffice development resources on what would be essentially 3rd party software.

Hmm.  I've written a lot here.  Since I believe strongly in "those who write 
the code make the rules" perhaps I should go hack on the publish-to-plugin 
some more.

By the way -- I've had some time to hack on the plugin a little more and have 
preliminary support for storing and loading the meta-information fields (title, 
start and end date, etc) from variables.  I'm still having trouble updating 
the kword view to get the correct "insert variable" actions to show up.  I may 
have more questions later about how the KWView class works....

Thanks!

Robert

["signature.asc" (application/pgp-signature)]

_______________________________________________
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]